A visual history of Visual C++
04 Mar 2017Visual C++ was Microsoft's implementation of a professional Windows hosted IDE for developing Windows software. From humble beginnings, it's grown into a very versatile, popular, and powerful tool. I used every version of Visual C++ since 1.0, and thought I'd collect some Visual C++ screenshots and comments on these versions.
Visual C++ 1.x
| Visual C++ 1.0/1.5 (16-bit) | Visual C++ 1.1 (32-bit) | |
|---|---|---|
| Minimum (official) host OS version | Windows 3.1 | Windows NT 3.1 |
| Minimum (official) target OS version | Windows 3.1 | Windows NT 3.1/Win32s 1.1 |
| CRT DLL | N/A | MSVCRT10.DLL |
Visual C++ 1.0 was the first release of Visual C++, released in 1993 for 16 bit development. Version 1.5 was released later as a 16 bit development tool, and there was also a Visual C++ 1.1 for 32 bit development, pictured above. These represented Microsoft's first major push into a Windows based IDE for C++ development. Prior to IDEs, Windows development was mainly done with command line compilers and a developer's editor of choice, coupled with a Windows SDK that provided tools for Windows specific problems.
My first experience with these versions was fairly bad: the Windows specific tools were still seperate from the IDE, so the IDE itself represented a Windows editor, and the system required a fair mount of RAM compared to a DOS based solution so performance wasn't great. The main advantage of Visual C++ as opposed to earlier tools is an integrated debugger, which particularly in 16 bit Windows, was a huge advance. Note that 16 bit Windows is a cooperatively multitasked system, so a process cannot be "stopped" to debug it or the system will hang; previous debuggers relied on stopping and debugging all of Windows. Visual C++ would emulate the behavior of a stopped process without actually stopping it, giving the appearance of interactive debugging.
In 32 bit land the world was very different. Visual C++ 1.1 shipped with tools that contained useful bug fixes over the original NT SDK, but the two were very similar. Because NT had a debugging model for processes that was designed, and the SDK shipped with an interactive debugger, the advantages of Visual C++ in 32 bit land was more limited.
16 bit Windows had a very different model to 32 bit Windows with C runtime libraries. Because each process could determine its own memory model and floating point behavior, C runtime libraries were always statically linked into the application. In 32 bit Windows, however, the option of a dynamically linked CRT was created and Visual C++ 1.1 used MSVCRT10.DLL. This choice was a little frustrating for me, since the NT SDK used CRTDLL.DLL which was included with the operating system, whereas MSVCRT10.DLL was not, leaving the developer choosing between buggy tools with simple deployment and fixed tools with painful deployment.
Visual C++ 2
| Minimum (official) host OS version | Windows NT 3.5 (works on NT 3.1) |
|---|---|
| Minimum (official) target OS version | Windows NT 3.1/Win32s 1.2 |
| CRT DLL | MSVCRT20.DLL |
Visual C++ 2 was exclusively a 32 bit release in 1994. This screenshot, which focuses on the editor, does not do justice to how radical this release really was. Most of the Windows SDK tools are now integrated, so editing dialog boxes, menus etc are all built in to the IDE. The CRT DLL was bundled with future OS releases, including Windows 95, and this release was the last release before Windows 95 shipped so a lot of 32 bit software was written with it. There were 3 releases - 2.0, 2.1, and 2.2. Although I never used anything except 2.0, it's my understanding that the main enhancements focused on updating the SDK in preparation for NT 3.51 and Windows 95.
Visual C++ 4
| Minimum (official) host OS version | Windows NT 3.51/Windows 95 |
|---|---|
| Minimum (official) target OS version | Windows NT 3.51/Windows 95/Win32s 1.25 |
| CRT DLL | MSVCRT40.DLL |
Visual C++ 4 was the first "designed for Windows 95" release, which updated the SDK and UI to conform to Windows 95 guidelines. Frustratingly for developers though, the CRT DLL didn't ship in the first version of Windows 95, so despite the UI look and feel deployment remained a challenge. There were also three releases - 4.0, 4.1, and 4.2. The screenshot above is from 4.1, but aside from SDK changes the differences are minor.
The other major change in this release was integration of the help/documentation system into the IDE rather than relying on WinHlp and other external tools.
One subtle change that happened at this time was seperating Visual C++ between two editions, a standard and professional version. The important difference is that the standard edition does not have an optimizing compiler. As a matter of pre-history, QuickC did not have an optimizing compiler either, so in many ways this was restoring to a traditional dichotomy. However, the practical effect was that people who had the standard edition were not aware the functionality was missing and the result could be some fairly inefficient code for the unwary.
This is also the only Visual C++ IDE I spent any serious time using.
Visual C++ 5
| Minimum (official) host OS version | Windows NT 4.0/Windows 95 |
|---|---|
| Minimum (official) target OS version | Windows NT 3.51/Windows 95 |
| CRT DLL | MSVCRT.DLL |
The Visual C++ UI was updated to more closely resemble the IE 3/Office 97 UI of its day. Toolbars had double ridge grips and seperators, with mouseover highlights. Functionally though, the UI differences seem minor.
Under the covers though, the switch to MSVCRT.DLL was significant. The intention was to bundle this with the operating system and ensure applications could (eventually) stop distributing it. In the short term this created a challenge, because Windows 95 and Windows NT 4 didn't have this DLL, but in the long term this went according to plan - Windows 98 and Windows 2000 did ship with it, so over time the need to distribute the DLL went away.
Particularly as the DLL deployment rolled out, Visual C++ 5 was nice for generating compact binaries by default. It also included the first version of NMAKE that could pass all objects needing building to a single compiler process, which allowed clmp to function.
Visual C++ 6
| Minimum (official) host OS version | Windows NT 4.0/Windows 95 |
|---|---|
| Minimum (official) target OS version | Windows NT 3.51/Windows 95 |
| CRT DLL | MSVCRT.DLL |
Visual C++ 6 was a small update to Visual C++ 5 in terms of both UI and functionality. The biggest change that I observed was having an install time check for Internet Explorer 4 and moving the documentation system to HTML Help. This check was looking at the registry only however, and the HTML Help system worked (albeit without perfect CSS formatting) with Internet Explorer 3.
Under the covers, the dependency on Internet Explorer 4 was also problematic. By default the headers would use new structures that are only supported when Internet Explorer 4 was present, so unless a developer consciously set values like _WIN32_IE themselves, programs generated tended to have an IE4 dependency.
One of the things that made Visual C++ 6 so long lived is it was possible to use an updated Windows SDK, up to Windows 2003 Service Pack 1. This meant that a developer could use Visual C++ 6 without sacrificing any operating system functionality, while retaining the benefit of using MSVCRT.DLL.
Visual C++ 2003
| Minimum (official) host OS version | Windows 2000 |
|---|---|
| Minimum (official) target OS version | Windows NT 4/Windows 95 |
| CRT DLL | MSVCR71.DLL |
Visual C++ .NET 2003 was the next release I really used. There was an earlier, very similar release, Visual C++ .NET 2002. The main difference between the two, for native code developers, is that 2002 supported NT 4 as a host system whereas 2003 required Windows 2000. The UI was radically updated, but I spent so little time using it that I can't really analyze it intelligently. The change to the CRT DLL meant that it was not loaded on any released version of Windows at the time, whereas MSVCRT.DLL was almost ubiquitous by this point, so there was no incentive to use 2003 as opposed to Visual C++ 6 with a newer SDK.
Shortly after this, the Visual C++ toolkit was released, which was a freely downloadable form of the same compiler, with optimization support. This marked the first step towards eliminating the crippled standard edition.
Visual C++ 2005
| Minimum (official) host OS version | Windows 2000 |
|---|---|
| Minimum (official) target OS version | Windows NT 4/Windows 98 (but NT 4 doesn't really work, sigh) |
| CRT DLL | MSVCR80.DLL |
Visual C++ 2005 revisited the UI once more to make it more consistent with the Office 2003/.NET 2.0 UI.
Under the covers, this finished the work of retiring the crippled standard edition of the compiler. Although it was available in multiple editions, all included and optimizing compiler, so for native code developers not depending on extra libraries and tools the editions are interchangable.
The CRT DLL was marked to run on Windows NT 4 but the developers had clearly not read the fine print on MSDN, which indicated that GetLongPathName is only available via a statically linked library and is not in the base system. This means that the CRT DLL won't load on NT 4 out of the box, and getting the compiler to generate NT 4 binaries requires statically linking the CRT. It's also possible to generate a "fixed" CRT DLL for NT 4 since source code for the CRT was available, but great care should be taken to not install that CRT on a system that should have the real CRT instead.
Visual C++ 2008
| Minimum (official) host OS version | Windows XP |
|---|---|
| Minimum (official) target OS version | Windows 2000 (but 2000 doesn't really work) |
| CRT DLL | MSVCR90.DLL |
Visual C++ 2008 was very hard to distinguish visually from 2005. I always laughed a bit seeing the "9" in the icon, being a simple visual indicator that it's different in some trivial way.
The more substantial change was updating the CRT to depend on Windows XP. Windows 2000 support could be retained by not using the DLL. At the time I was a Windows 2000 user, so this release didn't get much use.
Another seemingly unnoticed detail is that this compiler was the first to document and fully support multi process compilation, which is necessary to exploit modern hardware to improve compile times. For older compilers, there's always clmp.
Visual C++ 2010
| Minimum (official) host OS version | Windows XP |
|---|---|
| Minimum (official) target OS version | Windows XP |
| CRT DLL | MSVCR100.DLL |
Visual C++ 2010 updated the UI to be based on WPF, presumably in order to convince developers that it was a viable framework for them to use. This might have been more convincing if it didn't dramatically regress load times, particularly on low memory systems. For me this cemented every negative preconception of WPF I'd already developed. To this day I've never used it for anything.
For me personally, this was the last release of the compiler that could run on XP, and the last release I could hack up to run on NT4.
Visual C++ 2012
| Minimum (official) host OS version | Windows 7 |
|---|---|
| Minimum (official) target OS version | Windows XP |
| CRT DLL | MSVCR110.DLL |
Visual C++ 2012 was the release that coincided with support for Windows 8 development. It included the menu bars that SHOUT AT YOU BECAUSE THEY CAN, and updated the minimum host OS version to Windows 7. When it was released, this compiler did not support targeting XP, a decision that was hastily reversed in the first update. I've always been a little curious about this - who really wants to target a 2001 operating system with a 2012 compiler? And were so determined to move from 2010 to 2012 while targeting 2001 that they forced support to be added? Although this situation seems a little comical outwardly, XP support has been retained ever since.
...and onwards
As of this writing, Visual C++ 2013 and 2015 are released and 2017 is in RC. Visually these come with different themes but are still visually similar to 2012. The main enhancements are in C++ support (which I don't use), so my only encounters with them is to validate that they can compile my code, in case somebody else wants to do that. I have no good reason to use them just yet. Maybe one will emerge - the one theme running through this list right from the start is that each release wasn't that useful on its release day but became much more useful later, once CRT DLLs were deployed, older operating systems retired, and hardware had advanced.