A visual history of Visual C++ (2017)(malsmith.net)
malsmith.net
A visual history of Visual C++ (2017)
http://www.malsmith.net/blog/visual-c-visual-history/
52 comments
Interesting to see the UI change (degradation) over time. The first version makes it very clear what's a button and clickable at first glance, while the latest version looks like a sea of whitespace and makes that far more difficult.
It doesn't point out the massive productivity boost of Visual C++ 6, IntelliSense (ie, autocomplete). This saved so much time from having to look up documentation.
I worked on that! I was a dev on the team that built the first IntelliSense engine for C++. It’s a miracle it worked at all. It was based on a hacked-up version of the C++ front-end, but when it inevitably hit errors attempting a single-pass parse of the current source, it would silently bull its way through and try not to get too screwed up. Doing that in the presence of templates was not a good time. But with the RAM and processing speeds available then, I’m still kind of shocked it worked at all, 28 years ago.
Oh, very cool! It was like magic when we got that!
nice documentation
heh, sorry, but intellisense was the first thing we (in a game studio) turned off immeadiately after install (by deleting the dll as there was no other way) because it was unacceptable resource hog. this was around VS 2003/2005/2008.
visual assist x worked better.
visual assist x worked better.
Brings back memories.
But with a focus more on C++ features.
I started with Visual C++ 1.0. There were no templates.
Visual C++ 2.0 had templates.
There was by Visual C++ 3.0. They went to 4.0 to sync the MFC (Microsoft Foundation Classes) versions.
IIRC, you could use a bit of STL with 4.0
Visual C++ 5.0 was mainly optimizer differences.
Visual C++ 6.0 was actually pretty good. However it lacked partial template specialization. I was a Boost author at the time and lots of Boost code had specific workarounds for Visual C++ 6.
Visual C++ 2002 also had no partial template specialization.
Visual C++ 2003 was the first version with partial template specialization and that could compile all of Boost.
Visual C++ 2005 and 2008 did not have much changes.
Visual C++ 2010 tried to get back to 6 in the IDE (there was a deliberate marketing as such). It also had some C++11 features. But no variadic templates.
Visual C++ 2012 had no variadic templates.
Visual C++ 2013 was the first with variadic templates.
Nowadays, Visual C++’is doing much better tracking the C++ standard and often has compiler and library features before clang and GCC.
But with a focus more on C++ features.
I started with Visual C++ 1.0. There were no templates.
Visual C++ 2.0 had templates.
There was by Visual C++ 3.0. They went to 4.0 to sync the MFC (Microsoft Foundation Classes) versions.
IIRC, you could use a bit of STL with 4.0
Visual C++ 5.0 was mainly optimizer differences.
Visual C++ 6.0 was actually pretty good. However it lacked partial template specialization. I was a Boost author at the time and lots of Boost code had specific workarounds for Visual C++ 6.
Visual C++ 2002 also had no partial template specialization.
Visual C++ 2003 was the first version with partial template specialization and that could compile all of Boost.
Visual C++ 2005 and 2008 did not have much changes.
Visual C++ 2010 tried to get back to 6 in the IDE (there was a deliberate marketing as such). It also had some C++11 features. But no variadic templates.
Visual C++ 2012 had no variadic templates.
Visual C++ 2013 was the first with variadic templates.
Nowadays, Visual C++’is doing much better tracking the C++ standard and often has compiler and library features before clang and GCC.
(Not so) funny that there was nothing "visual" in Visual C++. The dialog resource editor was a joke. I remember how I was relieved when I discovered Borland C++Builder, so I didn't have to switch to Delphi for Windows software development.
Even worse, to this day, Microsoft has completely failed to produce anything comparable to C++ Builder due to the internal feuds around C++ and COM.
C++/CLI could have been it (after the Managed C++ reboot), but its integration with Windows Forms has always been clunky, nevermind WPF.
Then C++/CX could have been it, but then there was this rebellion replacing it with C++/WinRT, nowadays in maintenance, only getting bug fixes, being good enough for WinUI 2.0 and WinAppSDK low level stuff and that is about it.
I was big into Borland from their early MS-DOS compilers, all the way into 1999.
Embarcadero might not be Borland, but still manages to put out great GUI RAD tooling, whereas Microsoft lost sight of what means a great developer experience for native applications.
C++/CLI could have been it (after the Managed C++ reboot), but its integration with Windows Forms has always been clunky, nevermind WPF.
Then C++/CX could have been it, but then there was this rebellion replacing it with C++/WinRT, nowadays in maintenance, only getting bug fixes, being good enough for WinUI 2.0 and WinAppSDK low level stuff and that is about it.
I was big into Borland from their early MS-DOS compilers, all the way into 1999.
Embarcadero might not be Borland, but still manages to put out great GUI RAD tooling, whereas Microsoft lost sight of what means a great developer experience for native applications.
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 screenshot of each version in the article, presumably that transition is visually documented...
I don't actually know in which release that transition happened. But since there's a screenshot of each version in the article, presumably that transition is visually documented...
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 a dependency check, its UI visibly redrew more slowly, etc. It was so bad that Microsoft had to create a special offer for the Visual Studio .NET (2003) upgrade for only ~$30.
This transition was not great for Visual Basic developers either since their language was transitioned from generating native code (VB6) to becoming dependent upon the .NET Framework (VB.NET), supported secondarily to C#.
This transition was not great for Visual Basic developers either since their language was transitioned from generating native code (VB6) to becoming dependent upon the .NET Framework (VB.NET), supported secondarily to C#.
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.
Quite awkward for what is such a key technology on Windows.
If memory serves, it was Visual InterDev that won, actually. The VID IDE was the forerunner to Visual Studio.NET 2002, which was the first unified Visual Studio IDE.
n.b. I worked on the Visual Studio Core team, which maintained devenv.exe, among other things, from 2003-2007'ish.
n.b. I worked on the Visual Studio Core team, which maintained devenv.exe, among other things, from 2003-2007'ish.
Visual InterDev was the first IDE I ever used outside of notepad.
It was bundled in with one Microsofts early webediting tools with office (97/200)....but not FrontPage.
I thought I was touching the future, it was so amazing! I really don't remember much about other than the impression that it left on me.
After Visual C++ 6. They broke a lot of the C++ IDE features and they weren’t as good as the prior versions (dialog editor etc) so for a long time we preferred staying on 6. I think if we could have the newer compilers but the snappiness of that UI many developers would be happy.
It’s also a product of the segmentation of the developer tools in Microsoft. The Windows team was responsible for the compiler rather than the Developer Tools team.
It’s also a product of the segmentation of the developer tools in Microsoft. The Windows team was responsible for the compiler rather than the Developer Tools team.
No, that's not really true. I was on the C++ compiler team from 1991 to 2006. When I first started, the DevTools team reported up through the Windows team, but never really felt a well-integrated part. We were never in the same building as the Windows team, for instance. I remember, probably 1992 or 1993, driving from building 4 where the compiler team lived to the Windows building (forget which one that was, maybe in the 12 to 15 block back then?) to get a copy of the Windows NT source on a hard drive. That's because I was a dev on the C++ compiler back-end team then (moved to the front-end in '95, IIRC), and compiling that source was a major test of the 32-bit compiler I was working on.
Don't remember when DevTools was re-orged out from under Windows, but I'm pretty sure it was by '95, and well before VC++ 6.
Don't remember when DevTools was re-orged out from under Windows, but I'm pretty sure it was by '95, and well before VC++ 6.
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.
Any idea how many devs are working at Microsoft on the C and C++ compilers these days? I've heard rumours that there's more on the Rust team and that C++ is taking a back seat.
No clue. I left as a full-time employee in 2007, did a few contractor gigs with various old teams of mine to help out, but that was done by 2013. I lost touch with how things were going internally after that.
The dialog editor is a good example of the damage that was done with the VS.NET transition. When they rewrote it to use the WinForms-based UI, they introduced a fundamental bug: the Z-order for picking was reversed so that clicking on a stack of controls selected the one on the bottom. Very annoying for controls like group controls intended to be stacked below other controls. Bug filed, WONTFIX'd, and it's still broken to this day.
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 explicitly for controlling cross-clipping of child windows during painting:
> Clips child windows relative to each other; that is, when a particular child window receives a WM_PAINT message, the WS_CLIPSIBLINGS style clips all other overlapping child windows out of the region of the child window to be updated.
https://learn.microsoft.com/en-us/windows/win32/winmsg/windo...
Furthermore, group boxes and tab controls require overlapping child windows, because they are designed for the controls that visually appear within them to be sibling controls that are raised in Z-order. This is why the dialog editor's current behavior is broken, because the editor's picking behavior is opposite the drawing behavior and USER32's hit test order.
> 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 explicitly for controlling cross-clipping of child windows during painting:
> Clips child windows relative to each other; that is, when a particular child window receives a WM_PAINT message, the WS_CLIPSIBLINGS style clips all other overlapping child windows out of the region of the child window to be updated.
https://learn.microsoft.com/en-us/windows/win32/winmsg/windo...
Furthermore, group boxes and tab controls require overlapping child windows, because they are designed for the controls that visually appear within them to be sibling controls that are raised in Z-order. This is why the dialog editor's current behavior is broken, because the editor's picking behavior is opposite the drawing behavior and USER32's hit test order.
Right! It is wxWidgets that doesn't support overlapping siblings due to other back-ends (besides Win32) lacking support.
the big thing I missed was their macro editor, it was really good for automating things.
I think that is right and perhaps that is why, as I recall, Visual C went from almost unusable to a pretty good development environment between version 2 and 4. This is all (old) memory and anecdote.
You know what this doesn't show?
Visual C++ v4.2b generating an assignment operator which invoked the destructor of a returned object before assigning it to the lval.
That was fun to figure out. :-/
Visual C++ v4.2b generating an assignment operator which invoked the destructor of a returned object before assigning it to the lval.
That was fun to figure out. :-/
I remember a bug in an old Visual C++ that would fill your RAM and swap (therefore hard drive) if you forgot a semicolon at the end of a class, like:
class A { int a }
int main(...)
I lost a game prototype to that bug as it crashed my HDD at the same time by writing swap over swap. Screwing up the S.M.A.R.T. page.
Hard reboot left it doa. With today’s tools it could have been recovered but I lacked gparted and a kali thumb stick to bring it back. So thankful for Linux.
Hard reboot left it doa. With today’s tools it could have been recovered but I lacked gparted and a kali thumb stick to bring it back. So thankful for Linux.
Nice one... I seem to remember MSVC 5 having a switch that made all functions virtual - or am I confused with another compiler?
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!
When Visual C++ was announced, I figured it would be the next step up. I had already learned some simple C, so probably it’s just like Visual Basic but you use an improved C for your event handlers? I harangued my dad to “borrow” a copy from his work, and sat down with the Hello World… Which was an incomprehensible 300 lines of Win32 message handlers and Hungarian notation variable names. Nothing “Visual” about it.
It did give me an appreciation for just how much work the Visual Basic team had done to hide the ugly guts of GUI programming.
- -
[1] I had a very easy childhood by most standards.
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!
When Visual C++ was announced, I figured it would be the next step up. I had already learned some simple C, so probably it’s just like Visual Basic but you use an improved C for your event handlers? I harangued my dad to “borrow” a copy from his work, and sat down with the Hello World… Which was an incomprehensible 300 lines of Win32 message handlers and Hungarian notation variable names. Nothing “Visual” about it.
It did give me an appreciation for just how much work the Visual Basic team had done to hide the ugly guts of GUI programming.
- -
[1] I had a very easy childhood by most standards.
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 much of the hard-work done for you in seconds. We rewrote our Win16/32 C app in VC++/MFC and it took us only a few months rather than years.
It was a revelation for me on the power of OOD/OOP in practice and a defining educational moment on Software Design, Frameworks and Libraries.
It was a revelation for me on the power of OOD/OOP in practice and a defining educational moment on Software Design, Frameworks and Libraries.
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.
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.
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.
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.
> 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.
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.
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.
> 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.
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.
The release dates for them should explain it (from wikipedia); MFC - 1992, VCL - 1995 and C++Builder - 1997
So VC++/MFC was already established by the time VCL/C++Builder came along. Also it was aimed mostly at the Delphi/Object Pascal crowd whereas most Win16/32 C SDK crowd found the transition to VC++ more natural.
So VC++/MFC was already established by the time VCL/C++Builder came along. Also it was aimed mostly at the Delphi/Object Pascal crowd whereas most Win16/32 C SDK crowd found the transition to VC++ more natural.
Oh? I must have forgotten / never known / got that mixed up. (I'm thinking the most likely is I mixed it up with some other, later, MS TLA.)
Thanks!
Thanks!
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.
Binders full of MSDN CD-ROMs...IYKYK
When / How did versioning enter versioning the awkward state we have today? There is cl.exe, MSBuild and build chain at the very least (now at work computer at the moment, pretty sure I am wrong with the making here) with versioning that is close enough to each other to be confusing and related to each other in word ways. Naming itself also feels confusing to me. Documentation also only helps when you already have a good idea what's going on.
>When / How did versioning enter versioning the awkward state we have today? There is cl.exe, MSBuild and build chain
The multiple confusing version numbers are caused by each software component (e.g. "cl.exe" vs "msbuild.exe" vs IDE "devenv.exe" vs platform toolkit SDK) evolving separately over decades. (https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Inter...)
E.g. Today's "cl.exe" at version 19.x goes all the way back to 1983 with Microsoft C 1.0 for MS-DOS. Just a text-based command line compiler with no C++, no GUI, no "Studio", etc. 43 years of the core compiler going from 1.x to 19.x. The Visual IDE component of VC++ version 17.x has a different version history going back to 1993 with 1.0. Microsoft C# also has different version numbers of C# language version vs .NET version vs CLR version, etc.
It's analogous to Linux world of different tools with different version numbers. GCC is 15.x, glibc is 2.4, make is 4.4, etc. If you include a "visual GUI IDE" like Jetbrains CLion, that's yet another different version (252.x) that doesn't match any of the others.
Microsoft could hypothetically "synchronize/unify" all version numbers for all disparate products to be a single number ... akin to Apple using version "26" to synchronize Xcode with iOS, etc by introducing large numerical gaps like v18 --> v26. That's probably not going to happen. Likewise, different groups at GNU are not going to agree to synchronize all version numbers such that next release will be GCC 20.0, glibc 20.0, and make 20.0.
The multiple confusing version numbers are caused by each software component (e.g. "cl.exe" vs "msbuild.exe" vs IDE "devenv.exe" vs platform toolkit SDK) evolving separately over decades. (https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Inter...)
E.g. Today's "cl.exe" at version 19.x goes all the way back to 1983 with Microsoft C 1.0 for MS-DOS. Just a text-based command line compiler with no C++, no GUI, no "Studio", etc. 43 years of the core compiler going from 1.x to 19.x. The Visual IDE component of VC++ version 17.x has a different version history going back to 1993 with 1.0. Microsoft C# also has different version numbers of C# language version vs .NET version vs CLR version, etc.
It's analogous to Linux world of different tools with different version numbers. GCC is 15.x, glibc is 2.4, make is 4.4, etc. If you include a "visual GUI IDE" like Jetbrains CLion, that's yet another different version (252.x) that doesn't match any of the others.
Microsoft could hypothetically "synchronize/unify" all version numbers for all disparate products to be a single number ... akin to Apple using version "26" to synchronize Xcode with iOS, etc by introducing large numerical gaps like v18 --> v26. That's probably not going to happen. Likewise, different groups at GNU are not going to agree to synchronize all version numbers such that next release will be GCC 20.0, glibc 20.0, and make 20.0.
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.
To this day, I experience a very brief spasm of regret when I just exit Visual Studio without closing the solution first.
Visual Studio 2022 still occasionally crashes or hangs on me.
Last one is 2012... I would like to see a sequel with how it evolved in the last 10 years.