Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A visual history of Visual C++ (2017)

malsmith.net

Post reply on HN
Print view View original

41–50 of 53 posts

Re: A visual history of Visual C++ (2017)

#41

Post by zerr »

ack_complete wrote: post #40
zerr wrote: post #27

Earlier quoted context omitted.

Afaik Win32 API explicitly states that overlapping sibling windows/controls is not supported.

No, overlapping sibling controls is absolutely supported in Win32. It has a defined Z-order for child controls along with functions to manage it: > The system maintains the z-order in a single list. It adds windows to the z-order based on whether they are topmost windows, top-level windows, or child windows. https://learn.microsoft.com/en-us/windows/win32/winmsg/windo... The WS_CLIPSIBLINGS window style is also expli…

Right! It is wxWidgets that doesn't support overlapping siblings due to other back-ends (besides Win32) lacking support.

Re: A visual history of Visual C++ (2017)

#42

Post by becurious »

philiplu wrote: post #14
becurious wrote: post #12

Earlier quoted context omitted.

Did you ever work on the cross edition that would compile Windows apps for the Mac? I think that was a version 4 fork that never got another version.

No, there were two devs working on the 68k Mac compiler, with ~10 devs on the x86 side (though both targets shared a lot of code and differed mainly in the late codegen and peephole optimization phases). I never worked on the 16-bit code; the 32-bit and later 64-bit x86 backend was a different codebase from the 16-bit stuff.

If I remember from poking around at the 16 bit version in that timeframe (1.52?) there was still an option to generate P-code and (this is now nearly thirty years ago) that was used by Excel to minimize code size for the segmented 16 bit systems.

Re: A visual history of Visual C++ (2017)

#43

Post by pjmlp »

ack_complete wrote: post #4
copper_think wrote: post #2

One thing not mentioned is that Visual C++ and Visual Basic historically were separate IDEs with separate codebases. When the time came to unify them, only one of them could continue on. My understanding is that Visual Basic won, and that today's Visual Studio IDE (devenv.exe, msenv.dll, etc.) is the continuation of that VB codebase. I don't actually know in which release that transition happened. But since there's a…

That might have been the transition from Visual C++/Basic 4 to 6 (I skipped 5), but the cataclysmic one was the switch from Visual Studio 6 to Visual Studio .NET, when large portions of the IDE and build system were rewritten in .NET. Visual Studio .NET (2002) was much slower and much buggier than VS6. The native debugger was glacial at conditional breakpoints and debug output, the build system took an eternity to do…

To this day I would consider VB 6 the epitome of COM development tooling, neither .NET, nor the UWP trainwreck were as good, and C++ tooling only MFC is worth of mention, as something putting development experience first, instead of Windows division politics.

Quite awkward for what is such a key technology on Windows.

Re: A visual history of Visual C++ (2017)

#44

Post by pjmlp »

rramadass wrote: post #38
pavlov wrote: post #31

The “Visual” in this product’s name was one of the greatest disappointments of my childhood. [1] I had dabbled in both QuickBASIC and Quick C on MS-DOS building very simple text games and such. When Visual Basic for Windows came out, I was ten years old. It was a revelation because it let me build something that felt like real software. Place controls on a canvas and start wiring them up with event handlers — so easy…

Nobody who had not done Win16/32 SDK C programming ala Charles Petzold can ever understand what a paradigm shift in programming that Visual C++ with MFC was. I still remember having my boss get the Visual C++ software (around 1995/1996 ?) along with David Kruglinski's two-volume books on programming it, following the tutorial clicking through wizards and being gobsmacked at getting a full-blown ready-to-go app with m…

Those of us coming from Turbo Vision on MS-DOS, OWL on Windows 3.x, and CSet++ on OS/2, saw it as an improvement over Win32, however a worse is better, the worse of all modern C++ GUI frameworks at the time.

Lets also add MFC was born as Application Framework, and dumbed down because hardcore Win16/Win32 C folks at Microsoft were against its original design.

Re: A visual history of Visual C++ (2017)

#45

Post by PlunderBunny »

Was I the only one that consistently experienced a crash when exiting Visual Studio 6 without first closing the solution? I think this was running on some flavour of Windows 98 in 1999 or 2000. So I got into the habit of closing the solution first.

To this day, I experience a very brief spasm of regret when I just exit Visual Studio without closing the solution first.

Re: A visual history of Visual C++ (2017)

#46

Post by rramadass »

pjmlp wrote: post #44
rramadass wrote: post #38

Earlier quoted context omitted.

Nobody who had not done Win16/32 SDK C programming ala Charles Petzold can ever understand what a paradigm shift in programming that Visual C++ with MFC was. I still remember having my boss get the Visual C++ software (around 1995/1996 ?) along with David Kruglinski's two-volume books on programming it, following the tutorial clicking through wizards and being gobsmacked at getting a full-blown ready-to-go app with m…

Those of us coming from Turbo Vision on MS-DOS, OWL on Windows 3.x, and CSet++ on OS/2, saw it as an improvement over Win32, however a worse is better, the worse of all modern C++ GUI frameworks at the time. Lets also add MFC was born as Application Framework, and dumbed down because hardcore Win16/Win32 C folks at Microsoft were against its original design.

With VC++/MFC, Microsoft wrest control of PC Programming Tools leadership from Borland. MFC was a true game changer (and later ATL too) and the VC++ IDE with wizards and integrated debugger was the icing on the cake. As i said you had to go through the pain of doing everything tediously and laboriously by hand in Win16/32 SDK to really appreciate what a paradigm shift programming with MFC was.

MFC was no dumbed down application framework but a higher level OO abstraction on top of Win16/32 SDK. It is one of the largest and most successful application frameworks in the industry. You had to learn its own concepts and architecture which were somewhat complex and had a steep learning curve but the payoff was excellent. I remember going through all the MFC Tech Notes from MSDN and poring over the "MFC Internals" book to get insight into its design and techniques. You learnt how to modulate OOD/OOP principles in service of practical implementations. Two good examples are; 1) Making all member variables of framework classes "public" (!) in order to allow the developer to drop back to Win16/32 SDK as needed and not be constrained by the application framework 2) The technique of MESSAGE_MAPS to avoid vtable memory blowup but still provide virtual function like functionality.

When i see kids on HN badmouth OOD/OOP and specifically Inheritance for code reuse via application frameworks for skeleton apps, i just shake my head and control the urge to smack them up the side of the head :-) They have been so spoiled with all the powerful application frameworks/libraries available today they simply have no idea of the design effort it took to come up with these frameworks/libraries but take everything for granted.

Re: A visual history of Visual C++ (2017)

#47

Post by pjmlp »

rramadass wrote: post #46
pjmlp wrote: post #44

Earlier quoted context omitted.

Those of us coming from Turbo Vision on MS-DOS, OWL on Windows 3.x, and CSet++ on OS/2, saw it as an improvement over Win32, however a worse is better, the worse of all modern C++ GUI frameworks at the time. Lets also add MFC was born as Application Framework, and dumbed down because hardcore Win16/Win32 C folks at Microsoft were against its original design.

With VC++/MFC, Microsoft wrest control of PC Programming Tools leadership from Borland. MFC was a true game changer (and later ATL too) and the VC++ IDE with wizards and integrated debugger was the icing on the cake. As i said you had to go through the pain of doing everything tediously and laboriously by hand in Win16/32 SDK to really appreciate what a paradigm shift programming with MFC was. MFC was no dumbed down…

I stand by my comment and it is even slightly documented on Wikipedia.

> One quirk of MFC is the use of "Afx" as the prefix for many functions, macros and the standard precompiled header name "stdafx.h". During early development, what became MFC was called "Application Framework Extensions" and abbreviated "Afx". The name Microsoft Foundation Classes (MFC) was adopted too late in the release cycle to change these reference

MFC was a dumbed down version of Application Framework Extensions, which was more in line with the higher level approach done by OWL and CSet++.

It might have seen brilliant for those coming from raw C and Petzold never having seen what Borland and IBM were doing, but other folks like myself have knew better.

Unfortunately Borland's mismanagement eventually gave the crown of Windows C++ frameworks to Microsoft, and IBM also wasn't much better with OS/2.

And to this day there is nothing visual in Visual C++, to the level of C++ Builder, and FireMonkey framework.

While ironically ATL, WRL and WinRT are all worse in developer tooling than what MFC had to offer.

In 2025 starting a new Visual Studio project, it is the grandpa MFC that wins out in Visual Wizards, dialogue editors and COM integration tools.

Agree that many folks around HN and similar sites lack the background of having been actually there, moving up from MS-DOS, getting to carry around Petzold's book, learning the new way of doing UIs, and why things became as they are.

Re: A visual history of Visual C++ (2017)

#48

Post by rramadass »

pjmlp wrote: post #47
rramadass wrote: post #46

Earlier quoted context omitted.

With VC++/MFC, Microsoft wrest control of PC Programming Tools leadership from Borland. MFC was a true game changer (and later ATL too) and the VC++ IDE with wizards and integrated debugger was the icing on the cake. As i said you had to go through the pain of doing everything tediously and laboriously by hand in Win16/32 SDK to really appreciate what a paradigm shift programming with MFC was. MFC was no dumbed down…

I stand by my comment and it is even slightly documented on Wikipedia. > One quirk of MFC is the use of "Afx" as the prefix for many functions, macros and the standard precompiled header name "stdafx.h". During early development, what became MFC was called "Application Framework Extensions" and abbreviated "Afx". The name Microsoft Foundation Classes (MFC) was adopted too late in the release cycle to change these ref…

My point was that MFC is not a "dumbed down" version of anything. What you are pointing out is merely a name change done by marketing from what the designers called it internally. This was explained in the documentation itself and obvious in the file names and class prefixes used in the library.

Borland's OWL predated MFC (not sure by how many years) and hence held the lead before MFC came along. Once the latter become available there was no longer any compelling reason to stick with Borland and of course their management failed to counter the threat and lost it all.

I myself started with Borland's tools on MS-DOS, moved to Windows with straight Win16/32 SDK programming and then moved to VC++/MFC before moving away from Microsoft platforms to Unix/Linux in the late 90's. It was a highly educational and career-forming experience.

Re: A visual history of Visual C++ (2017)

#49

Post by pjmlp »

rramadass wrote: post #48
pjmlp wrote: post #47

Earlier quoted context omitted.

I stand by my comment and it is even slightly documented on Wikipedia. > One quirk of MFC is the use of "Afx" as the prefix for many functions, macros and the standard precompiled header name "stdafx.h". During early development, what became MFC was called "Application Framework Extensions" and abbreviated "Afx". The name Microsoft Foundation Classes (MFC) was adopted too late in the release cycle to change these ref…

My point was that MFC is not a "dumbed down" version of anything. What you are pointing out is merely a name change done by marketing from what the designers called it internally. This was explained in the documentation itself and obvious in the file names and class prefixes used in the library. Borland's OWL predated MFC (not sure by how many years) and hence held the lead before MFC came along. Once the latter beco…

Unfortunately I lack the Microsoft Systems Journal in an accessible way with said articles about the real story behind how MFC came to be, so that I could reference it here.

Re: A visual history of Visual C++ (2017)

#50

Post by CRConrad »

rramadass wrote: post #48
pjmlp wrote: post #47

Earlier quoted context omitted.

I stand by my comment and it is even slightly documented on Wikipedia. > One quirk of MFC is the use of "Afx" as the prefix for many functions, macros and the standard precompiled header name "stdafx.h". During early development, what became MFC was called "Application Framework Extensions" and abbreviated "Afx". The name Microsoft Foundation Classes (MFC) was adopted too late in the release cycle to change these ref…

My point was that MFC is not a "dumbed down" version of anything. What you are pointing out is merely a name change done by marketing from what the designers called it internally. This was explained in the documentation itself and obvious in the file names and class prefixes used in the library. Borland's OWL predated MFC (not sure by how many years) and hence held the lead before MFC came along. Once the latter beco…

> Borland's OWL predated MFC... I myself started with Borland's tools on MS-DOS, moved to Windows with straight Win16/32 SDK programming and then moved to VC++/MFC before moving away from Microsoft platforms

So you totally missed / skipped Borland's VCL[1], right?

That would explain your comments: It's the only way I can see how one could come to think that "Microsoft had the lead" in Windows IDEs at... Well, ever.

___

[1]: Written in Delphi and of course used there, but also used in C++ Builder.

Post reply on HN