Are binaries built on Windows 7 guaranteed to work on 8/Vista, 10, and 11?
Are binaries built on Windows 10 guaranteed to work on Windows 11?
I've seen some things that make me wonder if Windows 11 is still technically Windows 10 in at least some ways that might ensure apps built on Windows 11 be sure to run on Windows 10?
I'm worried not just about the EXE format but for instance the shared library APIs etc. One can build, I'm sure, on a newer Windows and use a DLL, or a function in a DLL, that doesn't exist on the older Windows.
All versions of Windows support the same "Portable Executable" format for EXEs, but it all comes down to (a) the linker settings in the metadata of the binary, (b) the architecture for the processor, and (c) the APIs it needs to import.
If you build a Win32 classic desktop application using _WIN32_WINNT=0x0601, the WINAPI_FAMILY_DESKTOP API partition (the default), and use a recent version of the VC++ toolset, it will set a linker value of "6.00 operating system version". The resulting binary is compatible with Windows 7 SP1, and depending on exactly what APIs you use it might work on Windows Vista SP2 as well. It will also be forward compatible to Windows 8.x, Windows 10, and Windows 11.
Both x86 and x64 Windows support 32-bit applications, although x64 Windows does not support super-old 16-bit Windows programs that technically work on 32-bit Windows.
There are many application compatibility bugs that can make a program that should technically work on a newer version of Windows fail, but these can be avoided by just testing on newer versions of the OS before shipping.
Officially the modern VC++ toolsets, the Visual C/C++ Runtime, and Windows SDKs do not support Windows Vista, Windows 7 RTM, or Windows 8.0 development.
See Microsoft Docs.
I'm trying to compile a program as 64 bits, it works perfectly with a simple console program but if I use my directX program it says me: error LNK1181: cannot open input file 'd3dx9.lib'. When I compile my directX program as 32 bits it works but in x64 it doesn't. I think visual studio 2013 has a default directory of directx with is x86 but I don't know if I'm right or not. I need to use x64 directX libs. How could I link them? Thanks for read.
VS 2013 comes with the Windows 8.1 SDK, and as of the Windows 8.0 SDK the DirectX SDK is considered deprecated. All versions of D3DX (D3DX9, D3DX10, and D3DX11) are also deprecated and are only available with the legacy DirectX SDK. You can use the legacy DirectX SDK in combination with the Windows 8.x SDK, but it requires the reverse path setup of VS 2010 or earlier. See MSDN and this blog post.
In your case, you probably don't have your project's VC++ Directories properties set up correctly for the x64 configurations:
Executable path:
Win32 configs: $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x86
x64 configs: $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x64;$(DXSDK_DIR)Utilities\bin\x86
Include path
Both configs: $(IncludePath);$(DXSDK_DIR)Include
Library path
Win32 configs: $(LibraryPath);$(DXSDK_DIR)Lib\x86
x64 configs: $(LibraryPath);$(DXSDK_DIR)Lib\x64
Note: If you were using the v120_xp Platform Toolset for Windows XP support, you'd actually be using the Windows 7.1A SDK, and would go with the same path order as VS 2010 which is the reverse of the ones shown here--i.e. the DirectX SDK paths would go first, then the standard paths. See this post if you are trying to target Windows XP.
This all said, unless you are specifically targeting Windows XP the recommendation is to (a) use Direct3D 11 instead of legacy Direct3D 9, (b) avoid using the legacy DirectX SDK at all, and (c) avoid using D3DX9/D3DX10/D3DX11.
See also:
Living without D3DX
DirectX SDK Tools Catalog
DirectX SDK Samples Catalog
DirectX SDKs of a certain age
In order to deploy C++ application built with VS2013 compiler under Windows XP, the "v120_xp" platform toolset has to be set: this make it possible the deployment from XP to 8.1. So next come the question: why this platform toolset is not the only one and the default? The "v120" platform toolset is suitable starting from Windows Vista. Is there any performance drawback? I've tested an application built towards both the platform toolsets under Windows 8 but I've seen no difference in performance (apparently..).
There are quite a few things you just can't do with the XP-dedicated toolset - it makes use of old headers and libraries, and so apps built with it just can't call a lot of newer APIs and use some fancy newer tools. A notable example is DirectX - quoting this MS page:
When building applications that support the legacy Windows XP platform,
you are using a platform header and library set similar to those that
shipped in the Windows 7.1 SDK rather than the Windows 8.x SDK with
the integrated DirectX SDK content (see Where is the DirectX SDK?).
Many of the "DirectX" headers and libraries are included with these
Windows XP compatible platform headers (see DirectX SDKs of a certain
age) such as Direct3D 9, DirectSound, and DirectInput. You will,
however, need to continue to use the legacy DirectX SDK for Windows XP
compatible versions of the D3DCompile API (#43), legacy D3DX9,
XAUDIO2, XINPUT, and PIX for Windows tool (the Visual Studio 2012
Graphics Debugger does not support Direct3D 9 applications).
Windows SDK 7.1A is installed as part of VS 2012 Update 1 for use with
the "v110_xp" Platform Toolset, which contains the headers, libraries,
and a subset of the tools that originally shipped in the Windows SDK
7.1. There are older Direct3D 10 and Direct3D 11 headers as part of this 7.1 era toolset which are outdated compared to the Windows 8.x
SDK versions using the standard "v110" Platform Toolset, particularly
the SDK Debug Layers installed by the Windows 8.0 SDK on Windows 7 and
Windows 8. The Platform Toolset "v110_xp" is therefore not recommended
for developing DirectX 11 applications, but it can technically be done
with some caution. Windows SDK 7.1A does not contain a dxguid.lib so
must either locally define the required GUIDs in your project by using
define INITGUID in one of your .cpp files, or use the legacy DirectX SDK version.
I have both Visual Studio 2012 Express for Desktop and for Windows 8, and I wanted to create Direct X applications and games. I know that there is a Windows SDK now, and in VS 2012 exp for win8 the IDE is pre-installed with the SDK (I know that from the new Direct3D project). My question is, if I wanted to develop applications for Windows Desktop (using VS2012exp) does it come Windows SDK or do I need to install Direct X SDK? And how do I know if my graphics card support which version of Direct X? Will any Direct X SDK version work with any Direct X version? As you can see I am a newbie at that stuff and any comment would be helpful. Thanks for your time.
If I wanted to develop applications for Windows
Desktop (using VS2012exp) does it come Windows SDK or do I need to
install Direct X SDK?
Yes, with Windows 8 SDK and Visual Studio 2012 (or Windows 8.1 SDK and Visual Studio 2013 preview) you can develop anything:
DirectX applications (both, Windows Desktop and Windows Store)
for any supported target platform (x86, x64, ARM)
for any reasonably modern Windows operating system (starting from Windows 2000/XP)
using any of API versions: DirectX 9.3, 10.0, 10.1, 11.0, or 11.1
Note:
DirectX 9 API is completely different from 10 and 11, and it is obsolete. Use it only if you targeting Windows versions below Vista.
DirectX 11 is more like an improved version of DirectX 10.
So in most cases, you will want to program for DirectX 11.1.
And no, you don't need to install DirectX SDK. It was deprecated (latest version - june 2010). Do not use it in new code. Use it only if you need to compile some old code which uses D3DX stuff (such as ID3DXEffect, ID3DXFont, ID3DXLine, ID3DXMesh, ID3DXSprite), e.g. samples from books or different SDK samples.
And how do I know if my graphics card support which version of Direct
X?
Well, if we talking about your videocard, you can look at your card vendor's or GPU vendor's site. Or any of informational utilities, such as GPU-Z.
If we talking about end-user hardware, since DirectX 10-11 there are feature levels. So even if you are using latest API (DirectX 11.1 at this moment), you can target old hardware (for example, if you using D3D_FEATURE_LEVEL_9_3, newer features, from D3D_FEATURE_LEVEL_10_0 and higher will be disabled).
Note, that to develop for latest feature level you don't need GPU that supports it. You can run and debug application on WARP device (ivery slow and meant for debugging purposes only, not for end-user release). For example, you can have old DirectX 10 card (Shader model 4.0), but target to DirectX 11 (Shader model 5.0)
Will any Direct X SDK version work with any Direct X version?
Latest DirectX SDK (june 2010) supports DirectX up to 11. No DirectX 11.1 support.
I'm a developer in Visual Studio who works with the DirectX tooling (the DX Diagnostic Tool and on the new project templates). You're asking a few different questions in here, but I'll try my best to answer the ones that I can.
1 - What SDKs are needed for DX application development? This link here as the best information on this. Basically as of the June 2010 DirectX SDK the DX SDK was combined with the Windows development SDK so if you install the most recent Windows SDK you'll have the right stuff for developing the newest DX applications.
http://blogs.msdn.com/b/chuckw/archive/2013/07/01/where-is-the-directx-sdk-2013-edition.aspx
This link also has more indepth info specific to the issue of DX Desktop apps on Windows 8.
http://blogs.msdn.com/b/chuckw/archive/2012/03/23/desktop-games-on-windows-8-consumer-preview.aspx
Note here that you can also install the June 2010 DirectX SDK on your machine, that won't hurt anything, we often install it ourselves as it has some useful sample applications to look at even if they are a bit outdated.
http://www.microsoft.com/en-pk/download/details.aspx?id=6812
2 - How do I know what my graphics card supports? I'm not sure if you mean how do I detect this in my DX application at runtime? Or if you mean how do I just look it up quickly for my specific system. To figure out your own GPU it's usually a pretty quick lookup, just find your device name and punch it in online, most stuff released in the last several years supports DX11 so you should be fine here. If you installed the June 2010 SDK that I mentioned above you can use the capability tool mentioned here:
http://www.danielmoth.com/Blog/What-DX-Level-Does-My-Graphics-Card-Support-Does-It-Go-To-11.aspx
At runtime DX has code to use to check if the running graphics card has the ability to use advanced DX 11 features.
http://msdn.microsoft.com/en-us/library/windows/desktop/hh404562(v=vs.85).aspx#check_support_of_new_direct3d_11.1_features_and_formats
http://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx
3 - Will any DirectX SDK work with any DX version? So here you basically always want to be using the latest DX SDK as you could see with the link on feature levels above you can target lower levels of DX while still coding using the most recent SDK. Just use the most recent SDK and target feature level 9 if you wanted to create apps that run on DX 9 cards.
Is it possible to link against VC6's MSVCRT.DLL in VC++10.0?
By default it seems to be linking with MSVCR100.DLL, but I don't want to redistribute yet another DLL (MSVCRT.DLL is already available in every OS that I support).
==EDIT==
To clarify: my application is a pure C application that makes WinAPI calls. I do understand that doing C++ will require the C++ runtime, which is not bundled in Windows by default (and most probably has to match the compiler anyway). My question is about pure C usage, and only the CRT functions that exist in the earliest version of Windows that I'm targeting.
(you can find an executive summary, or TL;DR, at the bottom)
Important: This answer refers to official Microsoft toolchains only, not to something like the MinGW toolchain (GCC-based) which is also known to link against msvcrt.dll. But I doubt Microsoft would be inclined to support that toolchain anyway ;)
Short answer: no!
Don't even try using Visual C++ 2010 for the task.
There's an official and supported method: use a standalone WDK, if you need your application to link against msvcrt.dll!
You should never attempt to use a compiler toolchain that doesn't match the CRT headers and libs. Use the toolchains as Microsoft intended, not a patchwork you create. Don't mix and match. Use what's handed to you by Microsoft. But use that (and don't be afraid by the FUD).
The newest WDK which you can use to link against msvcrt.dll (7600.16385.1) uses cl.exe version 15.00.30729.207. This corresponds roughly to the compiler that comes with Visual C++ 2008! Later WDKs will link against the CRT of the Visual C++ version they require.
The msvcrt.dll you'll find on, say Windows XP or Windows 7 is not the original DLL which was included with Visual C++ 6.0 (even the most updated version of VC6).
This has also been correctly stated in other answers. No surprises there.
However, the msvcrt.dll which you will find on modern systems will, contrary to what other answers suggest, allow programs that linked against the original VC6 CRT to continue to work. Even today. It's a contract. And the promotion of msvcrt.dll to a system DLL further validated that contract.
A little historical background
The toolchains used by Microsoft internally were somewhat similar to what the WDKs prior to the Windows 8 WDK provided. I will exclusively write about these and use the term WDK (or standalone WDK) uniformly, even when prior to the Vista WDK they were called DDK.
The good folks from OSR, who seem to have access to the Windows source code or people who do, confirmed during one seminar I attended some years back that the WDK used to be a trimmed down version of the toolchain used internally to build Windows around the time (~2005). Similar hints can be found from MSFT's own Larry Osterman and early works of Alex Ionescu on tinykrnl, the co-author of recent editions of "Windows Internals". BCZ likely alludes to build -cZ, a commonly used invocation with the WDKs I am describing here.
The reason it is interesting in this context is: all standalone WDKs allow you to create executables that link against msvcrt.dll by default. For the standalone WDKs msvcrt.dll is the CRT, just like for Visual C++ 2010 that's msvcr100.dll.
One should also note that the toolchains were updated alongside the Visual Studio toolchains. For example in the 3790.1830 WDK cl.exe reports as roughly on par with Visual C++ 2003:
C:\WINDDK\3790.1830\bin\x86>cl /version
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.4035 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
And for the 6001.18002 WDK (latest to support Windows 2000!) as roughly on par with Visual C++ 2005:
C:\WINDDK\6001.18002\bin\x86\x86>cl/version
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.278 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
For the 7600.16385.1 WDK it's on par with Visual C++ 2008.
Standalone WDKs
The WDK versions starting with the one for XP and up until (and including) Windows 7 SP1 did not require Visual Studio. They came with their own toolchain.
Versions prior to Windows XP required Visual C++ to build anything. If I remember correctly VC6 for the Windows 2000 DDK.
Versions starting from the Windows 8 WDK require Visual C++ again and integrate more tightly than ever with it (including wizards and even extensions for debugging and some driver-specific tasks). That's also the reason why when you use the respective WDKs, they will link to the CRT of the respective toolchain.
During the time of the standalone WDKs it was not unheard of - and that's the very reason for DDKWizard and VisualDDK - that people tried using Visual Studio to wrap the WDK build process. Some even used the unsupported method that Microsoft recommended against and built their drivers with the Visual Studio toolchains. Those unsupported methods amount roughly to what you are trying. So don't.
Anyway, the build process using WDK's build.exe with sources and makefile and so on was cumbersome and limiting. For example to build from any source file outside the current directory or its parent directory, you'd have to write your own NMake rules. After all build.exe was a wrapper around an NMake-based build. Your local makefile.inc would get included by the global one provided by the WDK/DDK.
Why linking to msvcrt.dll is officially supported
As mentioned earlier, linking against msvcrt.dll is supported with the standalone WDKs.
This is perfectly fine to do as well. In fact the USE_MSVCRT=1 statement in the sources file has exactly that effect. See here. Quoting from the 7600.16385.1 WDK documentation:
USE_MSVCRT
Use the USE_MSVCRT macro to instruct the Build utility to use the
multithreaded runtime libraries in a DLL for your build.
Syntax
USE_MSVCRT = 1
[...]
Note You should never list Msvcrt.lib or Msvcrtd.lib in TARGETLIBS. However, you can list Ntdll.lib in TARGETLIBS.
Why would Microsoft even offer this path if it were not supported by them? Correct, they wouldn't!
As a matter of fact said WDKs (XP..7 SP1) have been using the system DLL msvcrt.dll as their CRT.
Caveats
There's mainly one caveat. The way SEH is implemented has changed over time with newer Visual C++ versions. Since the toolchains from the standalone WDK correspond closely to specific Visual C++ version, they inherit the respective SEH handling.
For example when you use the Windows 7 SP1 WDK to target Windows 7 and with USE_MSVCRT=1, it statically imports _except_handler4_common. That function was not available on Windows Server 2003, for example. So trying to run such an application on versions of Windows prior to the targeted version may fail. So in such a case you are venturing into "unsupported territory" and all disclaimers apply. However, you have the option of using the method outlined here, i.e. linking to msvcrt_win2000.obj, msvcrt_winxp.obj and msvcrt_win2003.obj (available in the Vista and 7 WDKs) to achieve the level of (binary) backward compatibility you desire.
Well, on the other hand, if you decide to set WINVER=0x0601 you should also not be surprised to find that the resulting executable imports functions from kernel32.dll (or other system DLLs) which are not available on, say, Windows XP. So why expect different semantics with regard to msvcrt.dll?
As another side-note: even checked builds (commonly considered to correspond to debug builds) also link against msvcrt.dll, not its debug version counterpart! Because "checked" refers to the fact that assertions are left in; it does not refer to particular configurations of the CRT, such as "release" or "debug". The assumption that the unavailability of a debug build for msvcrt.dll in the standalone WDKs means it's somehow not the C runtime of those WDKs is plain and simple a misunderstanding of what checked build means.
There is another minor caveat. If you use, say, the Windows 7 WDK, to achieve linking against msvcrt.dll, you're using a toolchain unaware of developments since Windows 7. This includes import libraries, but also headers. So don't expect it to support features that were unavailable at the time it was released.
System DLL: msvcrt.dll
msvcrt.dll was promoted to the status of a system DLL some years ago, which means it comes included with the system (and can be relied on, literally) unlike other Visual C++ CRTs, for which you need to install the respective redistributable packages. Which is also the gist of the blog post by Raymond Chen quoted in another answer.
Since the standalone WDKs (XP..7 SP1) default to linking to msvcrt.dll as their CRT, there's no objective argument against it. Of course opinions vary.
A "reply"
Unfortunately this answer which has changed a lot since I first commented on it, perpetuates FUD and tries to pull quotes from purportedly authoritative sources out of context. It also links to original (MSFT) sources which - upon close inspection - do not support the statements for whose support they were linked.
Microsoft's Raymond Chen blogged on this a few years ago. From his
blog Windows is not a Microsoft Visual C/C++ Run-Time delivery
channel:
one DLL compatible with all versions of Visual C++ was a maintenance nightmare ... At some point, the decision was made to just give up and
declare it an operating system DLL, to be used only by operating
system components.
Emphasis mine. Think again, are you really writing something that
ships with Windows? Is it THAT difficult to add a supported file to
your setup program or link the static version of CRT, instead of
depending on a system component that Microsoft gave up on compiler
compatibility more than a decade ago?
Okay, so February 2010 is more than a decade ago (time this answer was written: March 2016)? Because that's the release date of the 7600.16385.1 WDK, which officially supports linking against msvcrt.dll.
And the rest of Raymond's statements may match what Microsoft initially intended, but he even admits that they gave up on that and promoted it to a system DLL.
Also, it's quite dishonest to mix truly ancient history (Windows 9x) with recommendations in favor of using standalone WDKs, which don't even support Windows 9x. The historical background Raymond describes is pre-W2K and non-NT. The background I describe above refers to the NT lineage of Windows and I only know the standalone DDKs/WDKs (and newer) from practice, so I cannot tell how it was or was supposed to be prior to that.
All that said: his blog is not to be confused with official documentation from Microsoft, although a lot of gems can be found on his blog and I've been an avid reader for years.
And although that is more than a decade ago, the msvcrt.dll version information in Windows 2000 (SP4) says:
Description: Microsoft (R) C Runtime Library
Product: Microsoft (R) Visual C++
Prod version: 6.10.9844.0
File version: 6.10.9844.0
... contrary to Raymond's introductory statement.
Only with Windows XP did that change to:
Description: Windows NT CRT DLL
Product: Microsoft« Windows« Operating System
It is amazing how many people are still in denial of this decision.
It's fair to assume after some previous comments that this is squarely aimed at me.
Well, I am not in denial of decisions made with the release of the Windows 8 WDK. But that doesn't "unrelease" the standalone WDKs which officially supported linking to msvcrt.dll nor does it "undocument" what can be found in their respective official documentation.
Hey, it's cool with me if you're in the luxurious position to only have to support Windows 7 or 8 and newer, or something along those lines. However, I have to support earlier Windows versions as well and so I'll make full use of the official tools provided by Microsoft for these Windows versions. Be that Visual C++ 2005 with the appropriate SDK integrated or be that a standalone WDK.
Those people caused "a lot of grief for the Visual C++ product team"
This statement refers to the aforementioned blog post by Raymond Chen, but pulls Raymond's statements out of context, specifically out of temporal context. The grief was caused by people trying approximately what the asker wants to do - and worse: reaching into the guts/internals of msvcrt.dll. And that was pre-W2K. It was not (and would not be) caused by using an official toolchain like the standalone WDKs from Microsoft.
The msvcrt version in modern versions of Windows has never been mentioned in the corresponding versions of Windows SDK.
While modern should be qualified, the use of "Windows SDK" suggests that it refers to all Windows SDKs after they were renamed from "Platform SDK". And I am inclined to readily believe that. But the poster is ignoring the standalone Windows WDKs (and prior to that DDKs) which not only mention it, but also use msvcrt.dll as their CRT. They are official toolchains from Microsoft aimed at both kernel and user mode development.
Microsoft update the CRT DLL (for example, when releasing a Windows Media Player patch) using a current toolchain that may or may not be made public.
That's correct. msvcrt.dll keeps getting updated because it has been promoted to a system DLL. And that is the contract one can rely on when using the WDKs. They're not going to break applications built with their own toolchains, just because they're patching msvcrt.dll.
You can count on them are not using the ancient WDK compiler and libs to build the msvcrt DLL in Windows
I'd not even be sure of that, but an official toolchain from 2010 isn't exactly something I'd call ancient. Besides, since Microsoft dropped support for XP and 2003 meanwhile, they only need to support Vista and onwards. That's bound to be easier with the latest Visual C++ version which directly provide the compiler and tools for the WDKs starting with the Windows 8 one.
(why ancient? Because the WDK team does not like people use their compiler to link against msvcrt either, and removed the loophole in version 8.0 to stop those "clever" people).
Oh really, does Doron actually say that at the linked forum post? Well, no:
the win7 wdk build deployed successfully because you linked against
the windows CRT (msvcrt.dll). we don't want 3rd parties doing that
anymore, so we removed that capability in the win8 wdk. it still
works for backwards compat. while it may deploy successfully, there
may be whck logo checks that make sure you use the right CRT
(emphasis mine)
The statement is about a "political decision" (and an official one at that) by Microsoft to change their stance. The "anymore" in fact implies that this only changed with the Windows 8 WDK. The first modern WDK that integrates with Visual C++ again (since the Windows 2000 DDK). So since the WDK has been demoted from a standalone toolchain to an extension that integrates with a given Visual C++ version, the new requirements are no surprise at all.
It is, btw, also dishonest to argue based on the Windows 8 WDK and newer, when the suggestions regarding standalone WDKs, which use msvcrt.dll as their CRT, were prior to that policy change. It's also dishonest to mix the history that led to the promotion of msvcrt.dll to a system DLL with the era after it had been promoted.
Glossary
CRT == C/C++ runtime
3790.1830 == Windows Server 2003 Service Pack 1 (SP1)
Driver Development Kit (DDK)
6001.18002 == Windows Driver Kit SP1 for Windows Server 2008/Vista
7600.16385.1 == Windows Driver Kit version 7.1.0 (Supporting Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003)
TL;DR
Contrary to this answer it is perfectly fine to use Microsoft's own and unchanged toolchains, such as the standalone WDKs, which support linking against msvcrt.dll (XP..7 SP1) "natively". It's even documented in the documentation that comes with those toolchains (unless you decide to not install it or close your eyes :)).
You "only" have to make sure to target the correct Windows version when building (essentially the same as defining the correct WINVER). But the same can be said for other system DLLs (e.g. kernel32.dll, user32.dll ...).
However, using any Visual C++ since 2002 to link against msvcrt.dll is bound to create trouble. Don't mix and match. Simply use the CRT matching those particular Visual C++ versions.
It's not the VC6 runtime. It's a system copy of MSVCRT.DLL that's bundled with Windows rather than Visual Studio. Each new version of Windows gets a new version of MSVCRT.DLL, as you can see by checking the file sizes.
You can compile against the system copy of MSVCRT.DLL by using the Windows Driver Kit. Note that this DLL is for use "only by system-level components." What's a system-level component? Well, a driver. Or, for example, a text service:
http://blogs.msdn.com/b/tsfaware/archive/2008/01/17/visual-studio-2008-issues.aspx
If you're building a text service DLL ... I would recommend installing
the Vista (or XP) DDK and use the DDKWizard instead. The DDK comes
with its own C/C++ compiler that uses the C Runtime Library that ships
with the OS (and won't cause problems with other applications) ...
More information:
http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/
A question arises, what does Microsoft do? They deploy their
applications to a variety of Windows environments. A look at Windbg’s
dependencies showed it’s using MSVCRT.DLL rather than one of the newer
CRTs. Microsoft’s new Network Monitor 3.1 also uses MSVCRT.DLL.
Windows Desktop Search is also using the old, trusty CRT.
How can all these new applications be using the vintage CRT? They’re
not still using the antique, unsupported Visual C++ 6.0, are they?
Well, no. The answer is more complicated and can be found in the
Windows Driver Kit (WDK).
Update: The Windows 8 Driver Kit introduced a new MSBuild-based build system, which no longer links against the system copy of MSVCRT.DLL. However, binaries built with the Windows 7 Driver Kit still work on Windows 8 and Windows 10.
MSVCRT.DLL is still shipped with Windows 10 for backward compatibility, so it carries a File version of 7.0.#####. A component that is still being actively developed, such as user32.dll, carries a File version of 10.0.#####.
An average "Petzold-style" Win32 program only needs a few functions out of msvcrt.dll. In my case, I often need the float-point formatting routines, like _sntprintf(). And it's unlikely that the functionality of such functions ever changes. For this reason, I created an msvcrt-light.lib import library (download) as a replacement for the standard library which I include in the MSVC project.
For full-fledged C++ programs, msvcrt-light.lib may not be suitable at all. Use the DDK as stated above.
This requires CRT compatibility across major compiler releases, which Microsoft tried to accommodate (e.g. added a VC5 heap to the VC6SP2 runtime) but eventually gave up on and introduced msvcrxx.dll that are in use today. If you look at the CRT source, you will find lots of #ifndef _SYSCRT, that's the difference between Microsoft's msvcrt.dll and the one used by your compiler when generating code.
Microsoft's Raymond Chen blogged on this a few years ago.
From his blog Windows is not a Microsoft Visual C/C++ Run-Time delivery channel:
one DLL compatible with all versions of Visual C++ was a maintenance nightmare
...
At some point, the decision was made to just give up and declare it an
operating system DLL, to be used only by operating system components.
Emphasis mine. Think again is it THAT difficult to add a supported file to your setup program or link the static version of CRT, instead of depending on a system component that Microsoft gave up on compiler compatibility more than a decade ago?
It is amazing how many people are still in denial of this decision. Those people caused "a lot of grief for the Visual C++ product team", and if you keep pissing them off, I won't be surprised if they piss you off sometimes like what they did in Windows XP that crashed a lot of VC6 apps. A lot of people did not follow Windows 2000 application developer guidelines and put settings/game saves in the Program Files folder. We all know what a good ending it is when Windows Vista was released.
By the way the dll is not VC6's. Using an old dll in the system would fail the Microsoft’s Security Development Lifecycle automatically. (https://blogs.msdn.microsoft.com/oldnewthing/20100607-00/?p=13793/#10020962). You don't realistically expect Microsoft use VC6 to compile its modern product, do you?
The msvcrt version in modern versions of Windows has never been mentioned in the corresponding versions of Windows SDK. Whatever compiler version or CRT lib version you use, it most likely won't match the majority of DLL versions on your customer's machine. Microsoft update the CRT DLL (for example, when releasing a Windows Media Player patch) using a current toolchain that may or may not be made public. You can count on them are not using the ancient WDK compiler and libs to build the msvcrt DLL in Windows (why ancient? Because the WDK team does not like people use their compiler to link against msvcrt either, and removed the loophole in version 8.0 to stop those "clever" people).