A visual history of Visual C++ (2017)
malsmith.net
A visual history of Visual C++ (2017)
1–10 of 53 posts
Re: A visual history of Visual C++ (2017)
#2One 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...
Re: A visual history of Visual C++ (2017)
#3One 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…
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.
Re: A visual history of Visual C++ (2017)
#4One 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 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#.
Re: A visual history of Visual C++ (2017)
#5Interesting 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.
Re: A visual history of Visual C++ (2017)
#6One 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…
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.
Re: A visual history of Visual C++ (2017)
#7One 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…
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…
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.
Re: A visual history of Visual C++ (2017)
#8One 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…
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 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.
Re: A visual history of Visual C++ (2017)
#9You 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. :-/
Re: A visual history of Visual C++ (2017)
#10One 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…
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.