Hi: Jonathan Caves here. Recently I received some queries from users wanting to know what version of the Visual C++ compiler I use in my daily work. Well...that’s not really a simple question as I tend to use several different versions of the compiler.
Before I proceed a little aside on decoding the Visual C++ compiler version numbers. The compiler version number is usually something like:
The first two digits is the major version number of the compiler . This number stretches way back to the first C compiler that was shipped by Microsoft: some highlights along the way are:
6 - the last standalone C compiler
7 - Microsoft C/C++ - which included the first C++ compiler
8 - the first release of Visual C++
12 - Visual C++ 6.0
13 – Visual C++ .NET 2002
15 – Which will Visual C++ 2008
The next two digits are the minor version number. These are usually ‘00’ except for products like Visual C++ 4.2 and Visual C++ .NET 2003 (which was 13.10).
The next 5 digits are the build number. This is a number that uniquely identifies one build of the compiler from another it is incremented on a daily basis. For example: today’s build number is 20904: which you can decode as follows:
2 => year: but it is not a direct mapping: currently in DevDiv the base year is 2005 so ‘2’ maps to 2007
09 => month: September
04 => day
The latest set of one or more digits are used to identify Service Packs, etc.
For building I use the version of the compiler that the DevDiv build lab uses for the full product nightly build – this is currently build 15.00.20816.0 (which if you followed the explanation above you can see is a build from the middle of August). Using this build is important because I need to ensure that I can build the compiler using the tools that the build lab uses.
For testing I use a set of tools that I build on my machine – so I using a compiler that is only one or two days old (doing a full C++ compiler build takes at least 2+ hour even on a very fast machine so I tend not to do it every single day). Using a really fresh compiler is important as I want to ensure that I have all the recent changes that have been made to the compiler – just in case there is some weird interaction between my fix and some other recent change.
But this is only for Visual C++ 2008 targeted tasks. I am also currently responsible for handling all the QFE (Quick Fix Engineering) requests for the compiler so I also have on my machine Visual C++ 2008 Beta-2 (15.00.20706.01) Visual C++ 2005, both the original release (14.00.50727.42) and SP1 (14.00.50727.762) and Visual C++ 2003.
We also get bug reports from users against older versions of the compiler – so I also have Visual C++ .NET 2002 and Visual C++ 6.0 on my machine so I can compare whether or not code used to compiler with older versions of the product. Sometimes this ‘software archeology’ can take me back even further: recently a customer wanted confirmation that a bug only existed in Visual C++ 5.0 release so I had to find and install Visual C++ 4.2 and Visual C++ 5.0 and then I was able to confirm that the customer was correct – this specific bug only existed in Visual C++ 5.0.
On top of all this I also have to deal with builds of the compiler for x86, x64 and Itanium (the latter two come in both native and cross-compiler variants). So you can see that I don’t actually use a single version of the compiler tools and, with the exception of tools that we have released, I tend not to stick to a single version for very long. This may seem complicated (and it can be at times) but it does really help to ensure that the compiler we finally ship has been tested as thoroughly as possible.
I also use the Visual Studio IDE – though I don’t update this as often as I do the compiler tools (mostly because it take awhile to uninstall the old version and install a new version). Currently I am still using the Beta-2 release of the IDE but I do hope that if I find 1 hour of calm in the next week or so I can upgrade to a new release. I like to use a relatively recent version of the IDE so I can provide quick feedback to the IDE team on what I like and what I don’t like.
And then there's ret versus chk. :-)
ret ("retail") builds are optimized, and mostly equivalent to what actually gets shipped.
chk ("checked") builds, as I remember it being explained to me, are non-optimized compiler bits that run against msvc[rp]90.dll, the retail CRT. chk exists because dbg ("debug"), which runs against the debug CRT, is too slow.
As a libraries developer, I rarely build chk, because I don't usually have to debug the compiler itself.
Stephan T. Lavavej
Visual C++ Libraries Developer
It was just pointed out to me that in describing the compiler version number I missed something. Starting with Visual C++ 2008 you will be able to detect the 'minor' build number and hence will be able to detect whether or not you are building with a Service Pack.
The macro is:
and at compile time this macro will evaluate to the minor build number.
So given that the full version number of Visual C++ 2008 Beta-2 is '15.00.20706.01' the build macros will evaluate to:
Visual C++ Compiler Team
> so I also have Visual C++ .NET 2002 and
> Visual C++ 6.0 on my machine so I can compare
> whether or not code used to compiler
Do you mean you have these in different guest machines in a virtualized environment, or you really have them installed side-by-side on your real machine?
I have some multiple installations like this too, but I don't expect them to behave 100% the way they would if they were installed in isolation. There have even been enough reports of the difference between VC++6 + SP5 + SP6 vs. VC++6 + SP6 only, so if I had some need to investigate an older environment, I'd have to make sure there was no interference from any other versions.
There was even a case where I had to do a reinstall without installing the PSDK, because we had delivered source code and a customer without the PSDK couldn't compile it. That also reminds me of a case where a program that compiled without the PSDK stopped compiling when the PSDK was installed.
I would do side-by-side installations in order to test side-by-side installations and/or to do ordinary development of our own products, but not to test repros of problems doing compilations.
re:"doing a full C++ compiler build takes at least 2+ hour even on a very fast machine so I tend not to do it every single day"
Our software development life-cycle completely changed when we started doing continuous integration. You can use a tool like cruise control or similar. I highly recommend it.
Norman: no I don't have the full products installed. All I really have are the compiler tools (like cl.exe and link.exe), the include files, and the library files.
I do though have both Visual C++ 2005 and Visual C++ 2008 running successfully on the same machine.
Digby: call me parnoid but I like doing full builds of the compiler tools - if I change anything I like to make sure there are not unforseen issues.
Jonathan:do you develop under IDE,or just a notepad?
Morning: if I am working on a machine on which the IDE is installed (which includes all my development meachines) then I use the IDE: and usually a pretty recent version at that - I am just about to update to last Friday's build.
Hmmmmm. If the compiler team is using the IDE, then maybe would it be possible to have someone in the compiler team use the Japanese version of the IDE?
Theoretically Microsoft could let testing be done by customers as usual, but there are reasons why that doesn't always work. Sometimes customers are developers who have to get real products out for their customers' customers, so when Visual Studio crashes, we let it send its crash report (well most don't but some do) and we get back to work. On rare occasions when we have enough spare time to post things on the Connect site, answers come back like "closed" for no reason, or "closed - won't fix" or "closed - Connect site can't cope with Microsoft's Japanese error messages". If someone internal to Microsoft would use the IDE, maybe the IDE would get noticed?
(My latest discovery: Creating an ATL DLL doesn't crash VS2005 but it does require guesswork. It provides a checkbox so we can choose support or don't support. If you're wondering support what or don't support what, well I'm wondering too, but you know who to ask.)
Hi, Norman, The ATL Wizards issue you mentioned is a valid bug with Japanese product. The complete text for that check box should be "Support MFC". I will open a bug for that to get it fixed for future release.
Thank you for bringing up the issue to us.We are using our product regularlly for development purposes (we call it "dogfooding")aside from direct testing effort . However, I do agree that we may not be dogfooding enough with the localized version of the product such as Japanese product. We will try to make improvement on that side. Meanwhile, if you have any issues that you encounter when you are using IDE, you are welcome to contact me directly:firstname.lastname@example.org.
Hello Johnathan, nice informative post. There is only one thing I'd like to ask. Dont you people incorporate distributed build tools? For example you mentioned a 2 hour build time so you dont do that as often. what if you could incorporate distributed build tools? Do you have any or have used any? Why dont you use it/them? Why not? Basically we're starting to research on one and are trying to gather information about wether it would be feasible for you/developers.
> However, I do agree that we may not be
> dogfooding enough with the localized version
> of the product such as Japanese product. We
> will try to make improvement on that side.
Thank you. Now hoping to see improved results.
Zaki: I know there is a discussion going on about distributed build tools and what they mean. But to be honest at the moment I am happy distributing the build over the four processors on my development machine.
The two hours I mentioned above is for a full build of what we call 'vctools' which includes the CRT and ATL/MFC. If I just want an updated toolset then I can get one from scratch in just over 20 minutes.
as a driver developer,i prefer to use vc6 IDE,it's simple and very fast.of course vs2005 is wonderfull,i bought a copy but use it seldom,DDK/PSDK/VC6 IDE ,they're my favour.
in order to support multiplatform development in vc6 IDE,i wrote a plugin in the form of .pkg,it's helpfull.however,for some obvious reasons,some functions i want to add seem to be very hard.
as a old product,may you/your team publish some data format or other information.i don't want to write it with COM interface.it's toooo verbose.
Tell me how to make the Future build number
when the 3rd part(5 digits build number) will be overflow 5 digits.
e.g) base year 2005 ,
Today 2007/09/04 => 20904
Future 2010/09/04 => 100904 or what ?
maximum is to 10 years from base year?(0 - 9)