| Date: | June 7, 2010 / year-entry #166 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20100607-00/?p=13793 |
| Comments: | 40 |
| Summary: | Commenter Sys64738 points out that Bjarne Stroustrup's Web site says that "Literally everything at Microsoft is built using various flavors of Visual C++ - mostly 6.0 and 7.0 but we do have a few holdouts still using 5.0 :-(" and wonders if it's true. Well, let's see. Visual C++ 6 came out in 1998 and... |
Commenter Sys64738 points out that Bjarne Stroustrup's Web site says that "Literally everything at Microsoft is built using various flavors of Visual C++ - mostly 6.0 and 7.0 but we do have a few holdouts still using 5.0 :-(" and wonders if it's true. Well, let's see. Visual C++ 6 came out in 1998 and doesn't support the /GS flag, nor does it support various replacement functions like As a result, I would suspect that the statement is no longer true. It may have been mostly true when the statement was originally written in the late 1990's, but things have changed a lot since then. (The statement wasn't even 100% true when it was written, because Windows 95 used a special version of the compiler not found in nature for selected portions of the operating system.) I find it interesting that the fact that the claim appeared on Bjarne Stroustrup's Web site caused the reader to turn off all brain functions responsible for critical evaluation of information. It is unlikely that Mr. Stroustrup has first-hand knowledge of the information on that page; it's almost certainly just a compilation of information reported to him by unnamed sources. (Actually, he even says as much in the opening paragraphs.) And do you honestly think that Visual Studio 2010 is compiled with Visual C++ 6? |
Comments (40)
Comments are closed. |
This reminds me of a comment that I found at the website of a prominent open-source advocate, which claimed that Microsoft doesn't use source control for any of its Windows development.
Seriously, where do people get this stuff?
VC6+Visual Assist X+WndTabs FTW (everyone said vc10 was the next vc6, it's not)
I think the idea that MS still uses VC6 internally was because the Windows Driver Development Kit required VC6 due to changes in the name-mangling of later VC++ compilers. This statement comes from when I was looking at writing a driver just a few years ago, and I don't know if it's true any more given the software policies as reported by Raymond.
I have a hunch none of Microsoft's C# apps were compiled using Visual C++ 6 either.
I work in one of the largest European investment banks. We use Visual C++ 6.0 for one of our most important software.
I just read somewhere that VS2010 was compiled with Visual Basic 6. Microsoft now calls this "legacy dogfooding."
I suspect this meme came about during the period when Microsoft was pushing hard to get everyone on VS.NET and everyone was going "screw that, VS6 is good enough for Microsoft, it's good enough for us".
I think this misconception might come from the fact that Windows code uses MSVCRT.DLL, which some people think is "the MSVC6 runtime".
Which actually brings up a pet peeve of mine: Why is it so hard for non-Microsoft developers to build software written in plain C against MSVCRT.DLL using Microsoft's tools? (For MinGW it is the default C runtime.) For much portable software written in plain C, MSVCRT.DLL is quite sufficient, and building against it has the benefit that you don't need to bundle any C runtime with your installer. (For C++, I fully agree that you want to use something relatively-latest-and-greatest. But then personally I much prefer C# to C++ anyway.)
It's not just that the version numbers are wrong; many of those products are not written in C++. I know that WinNT/2k/XP are mostly in C, and I'm pretty sure that SQL Server is also mostly in C. Of course C++ is still heavily used, but it's wrong to say that Windows is written in C++ when the kernel itself and all major DLLs are actually in C.
Gabe: That depends on how you define what Windows is.
IIRC, Windows was compiled with the WDK tools, which exist a bit outside the Visual C++ realm.
Pretty sure that the WDK has the Visual C++ compiler (sometimes the same version, sometimes a different build revision) and other tools but different headers and libraries.
LOL. VS2010 is far too slow to have been primarily written in a real language.
@Marquess,
Compiler/link toolchain is the same, though the revisions are not synchronized with VC releases.
There is a technique to link a program directly to Msvcrt.dll, instead of MsvcrXX.dll, by using a library which comes from the Windows Driver Kit. But if you want the program be functional on versions prior to Windows Vista, you need to link another object file, and this precludes using most of the secure CRT functions, unless you put some hacks into the code. Also, a debug build wouldn't work because Msvcrtd.dll is not publicly available. Definitely, this might be useful for small in-house developed tools, but not for more complex projects.
Although it might be misleading sometimes, the linker version field in the PE header structure would match the Microsoft compiler version used to build a specific Microsoft file. For example, most of Windows XP, as of Service Pack 3, was built with compilers based on either Visual C++ 7.0 (matching Visual Studio .NET 2002) or Visual C++ 7.1 (matching Visual Studio .NET 2003).
@blah:
Define "real" language.
http://xkcd.com/378/
Offtopic:
I'm coming to Redmond for a plugfest. If you see a man whistling a tune from, say, Mahler's 6th, that's probably me.
"For example, most of Windows XP, as of Service Pack 3, was built with compilers based on either Visual C++ 7.0 (matching Visual Studio .NET 2002) or Visual C++ 7.1 (matching Visual Studio .NET 2003)."
Probably depending on whether the file was from original XP or updated as part of SP2.
"There is a technique to link a program directly to Msvcrt.dll, instead of MsvcrXX.dll, by using a library which comes from the Windows Driver Kit. But if you want the program be functional on versions prior to Windows Vista, you need to link another object file"
Indeed, that is how MS internally does it, I think.
"But if you want the program be functional on versions prior to Windows Vista, you need to link another object file, and this precludes using most of the secure CRT functions, unless you put some hacks into the code. "
That is probably not a problem because MS likely internally use the Strsafe.h functions instead.
Windows uses the WDK. It just uses Msvcrt.dll, there's no need for any hacks.
I use the WDK for everything, including user space code. I find Visual Studio big and slow and useless, and I particularly dislike vcbuild/msbuild. I absolutely love WDK's build.exe + nmake.
@Tor Lillqvist, I *think* it's because you're not supposed to… See msdn.microsoft.com/…/abx4dbyh%28VS.80%29.aspx
Specifically (about halfway down the page):
What is the difference between msvcrt.dll and msvcr80.dll?
The msvcrt.dll is now a "known DLL," meaning that it is a system component owned and built by Windows. It is intended for future use only by system-level components.
It is known that Windows at one time used GNU make as its make program, GNU make was invoked recursively.
It is also known that some parts of Services for UNIX were at one time compiled with GCC.
strcpy_s is never a problem, there is a thing "Platform SDK"(i using version feb 03 or 04),
#include <strsafe.h>
#pragma comment(lib, "strsafe.lib")
i think that StringCbCopy() is better than strcpy_s.
It's amazing how many people, and sites, and still using VC++ 6.0 (I've joked in the past that Microsoft has two major C development suites, Visual Studio <insert-current-year-here> and VC++ 6.0). I support a globally-used piece of OSS and every couple of years I ask users whether I can disable 6.0 support, and every year I get the same chorus of replies saying "Hell, no!".
I think the reason for VC++ 6.0's ongoing popularity is that it runs circles around any of its successors in terms of speed and responsiveness (every time I've moved to a new version of VS I've felt like I was wading through molasses until I got used to the slowdown), and if you're doing straight C development there's nothing really compelling in newer VS releases that outweigh the bloat that comes with them.
I have to admit, I still develop primarily in VC++ 6.0, optionally in VS 2005 if I need newer features. 2008 and 2010 were just too painfully heavyweight to use. From informal surveys of people still on VC++ 6.0 this seems to be the general case, it's good enough for most purposes of the people using it and old enough that it hasn't succumbed to the VS bloat/molasses effect yet.
I'll observe here that nothing in the Microsoft section implies that the source is anything but a single email (probably from an MS employee), but from 6-7 years ago. I'd guess it was probably a lot more true 6-7 years ago.
We still have many use of VC6 here for old project maintainance.
While those project does have moved to VC2005/08, those companies (cough… banks) has bought components from much older version that's before we port-ed the source to newer compilers. They have paid renewal service contract so we can't drop those support, and under the terms we cannot change the required compiling/execution environment without their consent. (Considering my company even still have to support a few products for DOS, this is hardly surprising…)
Before I discovered WDK, I searched the binary Windows files for clues what version of the toolchain they used. And it was fun – kind of little detective game. Now I just go to %ddk%binx86_amd64 and check the version of c2.dll :-D
That said, the two other major MS products – Office and SQL Server have own pace and I do not know what compiler they use. Causal observation of SQL Server 2008 makes me think it's built with VS 2005 / VC9.
(Offtopic rant, feel free to ignore) While VS IDES since '98 are very bad for C/C++ developer, the compilers (and the other parts of the toolchain) are getting better and better. I'd use vs 2008 over vs 98 any time, simply because the compiler is MUCH less buggy (in terms of bad code generation), it understands C++ (the vc6 compiler was atrocious); it generates good code – I've seen instances where vc6 generates one screenful of code where vs2008 generates two asm instructions! And things like stack protection really helps finding bugs early in the development stage – it did this for me yesterday. For VS2010 – well, the new X++ 0x features are like heaven's gift, but the IDE is so slow that it's completely unusable.
While the speed of Visual C++ is an issue, personally I've found the tab behaviour (Goes in MRU order rather than the order of the tabs in the toolbar) and the lack of C99 support are bigger nuisances. This is Visual Studio 2008, mind, not sure if 2010 fixes any of that.
The way the compiler evangelises strcpy_s and kin is also a bit of an irritance, but you can shut it up easily enough.
VC++ 6.0 is fine if you're using C only. In fact in twelve years of fairly heavy use I've never found a code-generation bug in the C subset of the compiler, which is almost unique in any compiler I've used. And as you say, VS has been getting slower and slower with each release (your pain tolerance must be higher than mine, I regard 2005 as marginal and anything beyond that as completely unusable, not just the 2010 version).
VC++ 6.0 is fine if you're using C only. In fact in twelve years of fairly heavy use I've never found a code-generation bug in the C subset of the compiler, which is almost unique in any compiler I've used. And as you say, VS has been getting slower and slower with each release (your pain tolerance must be higher than mine, I regard 2005 as marginal and anything beyond that as completely unusable, not just the 2010 version).
"Literally everything at Microsoft is built using various flavors of Visual C++ – mostly 6.0 and 7.0 but we do have a few holdouts still using 5.0 :-("
This link is slow. The site is still up, so just get rid of the web.archive.bibalex.org/…/20071011225313 part.
In fact, looks like they already updated the page. public.research.att.com/…/applications.html now says that:
"Microsoft: Literally everything at Microsoft is built using recent flavors of Visual C++ (using older versions would automatically cause an application to fail the security review)."
So what is Visual Studio 2010 compiled with?
If CFF Explorer is to be believed, the IDE was built with VS2005. The toolchain … not so much.
[ASK]
Using Dependency Walker tool, a dependency from MSVCR100.DLL can be found. So it seems that they may have used VC10 to build VS2010 :-)
BTW: Part of the IDE changed from using native technologies like GDI (in VS200x, x <= 8) to WPF; so VS2010 must be a mix of C++ and C#.
PS:
I find it interesting that the fact that the topic is discussed on Raymond Chen's blog caused Bjarne Stroustrup to finally update his web site :-)
PPS:
I find it more interesting that several people still use VC6 (which – despite not having a C++0x-compliant C++ compiler – has a great IDE focused on C++, especially if combined with Visual Assist X and WndTabs), after several iterations of VS.
BTW:
public.research.att.com/…/applications.html
I was unaware of "Windows System 7" :)
In Windows itself, Microsoft doesn't have to worry when using recent "secure" functions from MSVCRT, because you know that the user has a certain version of Windows!
Now if only Microsoft would release the compiler they use internally for putting infrequently-executed code into different parts of the executable…
"(The statement wasn't even 100% true when it was written, because Windows 95 used a special version of the compiler not found in nature for selected portions of the operating system.) "
What was the banner this compiler displayed when it started up?
Microsoft had rapid succession with Visual Studio releases, which introduces new language features, new frameworks, new .NET platforms which was tightly coupled to each version of Visual Studio. One of the biggest Japanese company I'm working with still using Visual C++ 6.0 for developing. They're slowly switching for the new versions of Visual Studios. And we've a number of problems facing for creating build using msbuild, upgrading *huge source* and make it compatible with the newest versions of Visual studio. The product releases and business is important than upgrading to a new version of compiler and it's a mammoth effort. Most of their code are proven for long time even without the secure version of libraries. It's easy for small companies to switch according to Microsoft's frequent releases but for a big company, it's truly hard and the amount spend for license is too huge and it's for a short period of time and then Microsoft come up with entirely new product.
security APIs as a litmus test was not my first thought.
64-bit support is. Visual C++ 6's compiler doesn't support 64-bit.
I would still use VC6 if I didn't have to do 64-bit… the level of C++ it support is just find for almost everything we need in our 14 milion line of code app. There's just a couple of template things missing.
And.. edit-and-continue, debugging, browser, and find-in-file UI was fast and reliable. So much more productive..
The interesting question is, what build system MS uses? nmake? build from WDK? msbuild? VS ide build system? team build? internal one company wide? internal one for teams? batch files? Or gnu make using the posix subsystem :-)