I have a set of Windows programs that is mostly created with VB6 and VC++ 6. Its installer is created using InstallShield.
A couple users have recently reported a problem trying to install it on Vista. It is complaining that "MDAC 2.6 Sp2 cannot be installed on this machine. MDAC 2.6 Sp2 requires any one of the following configurations", and then lists several OSes, Vista not among them.
A little googling shows that there's a bug in InstallShield's handling of MDAC - it shouldn't be checking for it on Vista, because there is no such thing as MDAC on Vista (there's a new thing - "Windows DAC").
I could make the change to my InstallShield project suggested on that page, but I am concerned about doing so, because I have no way to test it (this problem does not occur on all Vista machines, and I haven't been able to make it happen on any Vista machine I have access to).
However, after looking at Wikipedia's page on MDAC, I can't imagine why we would need it for our programs in the first place. We're not using any databases, at least not explictly (maybe some Microsoft component that we're using is using it, though?).
I was not the original author of the InstallShield project. I am beginning to suspect that MDAC might have been inadvertantly added to it, or perhaps advertantly but just as "uhhh, maybe we need that".
How can I explicitly tell whether my programs need MDAC or not? I can look at the references and such in the VB6 and VC++ projects; is there any way to tell from those whether I can safely remove MDAC from the InstallShield project? For example, perhaps there's a single MDAC reference which, if not present in my VB/VC++ projects, means that my programs definitely do not require MDAC?
Thanks in advance for any help.
I expect you are right, MDAC was probably included with the original InstallShield project configuration, and nobody has bothered to remove it.
On the VB6 side you should be able to tell if MDAC is being used by going into the "References" dialog (I think its in the Projects dropdown menu of the ide) and checking to see if there is anything in there to do with MDAC or MSAccess. I haven't worked with VB6 in a while, but the text should look something like "Microsoft ActiveX Data Objects 2.x Library".
I'm guessing it is less likely that it is being used On the C++ side, but you could try searching for keywords like msdado, mdac and msaccess to see if theres any sign of a #import on one of the mdac dlls.
When deploying to Windows XP and later there is no reason to include MDAC or Jet 4.0, since even XP RTM (gold) shipped with MDAC 2.7 as well as Jet 4.0.
Microsoft Data Access Components (MDAC) release history
How to obtain the latest service pack for the Microsoft Jet 4.0 Database Engine goes into more recent Jet history.
MDAC releases include compatibility typelibs for ADO, so even if your program was compiled against MDAC 2.6 it will actually use the latest ADO on a target machine. The real grief can come if the program early-binds to ADOX.
ADOX never shipped with appropriate compatibility interfaces, so programs should almost always use late binding with ADOX.
DAO is another issue, but (a.) nobody should really be using it anymore without a good excuse and (b.) it died at DAO 3.6 so there should be no compatibility issue as long as your programs were upgraded to 3.6 and Jet5x (Jet 4.0, Access 2000 format).
The story gets more complicated when deploying downlevel from XP of course.
Beginning I think with Windows XP Microsoft began including MDAC. However, in MDAC version 2.6 and later they no longer included the Jet 4.0 components. (Jet 4.0 SP8 can be found here)
If you are using Visual Fox Pro you need to install either the ODBC or OLEDB drivers depending on you code for that.
ODBC
OLEDB
All of these downloads depend on having at least MDAC 2.6 installed.
Related
I have spent an incredible amount of time getting our product to run properly on customers' machines after we moved to Visual Studio 2015, and I still have one problem left to solve. The problem is that I can't get any of the C++ 2015 redistributables installers to work on 32-bit Windows 7 when it hasn't been patched (Windows Update).
The full story:
We upgraded all projects in the solution from VS 2013 to VS2015 and .NET 4.5.2, which also forced us to upgrade to "Microsoft Visual C++ 2015 Redistributable (x86/64) - 14.0.23506/23026)". We've done this kind of upgrade many times before, from VS2010 and up, and it never failed before.
23506 (for short) are the DLLs that accompany VS2015. We always found it easier to just XCOPY the DLLs into our installation folder. For some reason that doesn't work with the DLLs from VS2015 (23506). The program can't find them even when placed in the same folder as the executables. Why not?
Then I ran vcredist_xXX.exe that accompany VS2015, and the program runs fine.
But I want to XCOPY, so I discovered the download of 23026 from Microsoft, but there are no DLLs in there - only vc_redist.xXX.exe. Still, I copied the DLLs from somewhere in Windows - the paths to each DLL is listed in the registry. By the way, there are two extra DLLs installed that are not present in the folders in VS2015. "mfc140.dll" and "mfcm140.dll". Why?
But XCOPYing 23026 didn't work either, not even with the two extra DLLs. Running vc_redist.xXX.exe from 23026 worked fine.
Ok, problem solved, I thought. Using vc_redist.xXX.exe instead of XCOPYing. But no.
The final problem is that vc_redist.x86.exe (from 23026) and vcredist_x86.exe (from 23506) both fail when run on a 32-bit Windows 7 machine that hasn't been patched (Windows Update) at all after installation. For reasons I won't go into, that's the kind of machines we have to install our product on - unpatched 32-bit Windows 7 - no way around it. (The problem maybe exists on 64-bit unpatched Windows also, but I haven't got the time to find out.)
How do I get around this?
I am trying to link the C++ runtime statically and drop the DLLs alltogether, but it seems impossible when you have native C++ with C++ wrappers in a .NET project. This issue has already been reported by others, so no need to go into it here.
I have tried searching for DLLs to download, or a way to extract DLLs from the installer. Anyway, as mentioned above, I already tried just copying them from somewhere below C:\Windows. Doesn't work, so I doubt I can get some DLLs that will work. But again, why? If somebody can help me figure out this, it could be the perfect solution for our problem.
I have been thinking about finding the exact Windows patch(es) needed to get that installer - vc_redist.x86.exe - to work on those crappy machines. If it's just one or a handful of KBs that doesn't destabilize these machines, that would perhaps be acceptable.
A possibility that definitely should work is to downgrade the C++ projects to VS2013, which doesn't have this problem. I am really fed up of us always having to keep two versions of Visual Studio on our developer machines as a workaround for some silly problem, but if there's no other way, then so be it, even in 2016.
Found a quick and simple workaround. Turns out we only need to change the setting "Platform Toolset" to "Visual Studio 2013 (v120)" in all the C++ projects, in order to build with the good old DLLs that still work with XCOPY deployment. I was under the impression this setting would not go together with .NET 4.5.2, which we need, but it does. VS2013 will have to be installed along with VS2015, but we can live with that.
As stated, this is a workaround. It doesn't solve the actual problem stated in the title. But since I actually asked for a way around the problem, I'll close the issue with this answer.
As for the actual problem, if anyone is interested: I found some blog entries on the Visual C++ Team Blog - "Introducing the Universal CRT" and "The Great C Runtime (CRT) Refactoring". Where that leads, I'm not sure.
I was able to get this resolved on my local PC by following the updated step 6 on that article: https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
Once you copy the 20 or so DLLS folder it still didn't work for me, I had to grab the ucrtbase.dll and ucrtbased.dll along with all the usual 140 (mfc, mfcm,vcruntime, msvcp) from my SysWOW64 folder and finally i'm able to launch this on a windows 7 pc without requiring to install any patches!
Microsoft's vexing dumping of vdproj install projects in VS 2012 leads one to try Installshield LE which is sort of built into VS2012. Sadly, it creates installers that do not work in any way shape or form with 64 bit.
So for instance clicking the Office 2010 installed checkbox only makes a prerequisite for 32 bit Office. It fails to detect 64 bit.
After a lot of chickenless head exploration of Installshield the bottom line is:
1) You need the Professional or Premiere version in order to deal with 64 bit.
2) You need to edit their provided condition to make a compound one that ORs all the guids of Office that you are interested in together as it only checks for one of the many out of the box. This details the structure of the GUIDS: http://support.microsoft.com/kb/2186281?wa=wsignin1.0. I found it helpful to install various versions in a VM and then using regedit to see what the GUID ends up being.
This post is so that someone can actually discover this with a Google search, instead of it being hidden behind a paywall / private support site.
Update October '13 AlBear
There is a beta version of installshield LE for VS2012/13
To build x64 installation packages check on the help files
Look for "64 Bit" .
The way InstallShiel LE recognizes x64 target is by either defining the [INSTALLDIR] property as one of the 64 bit Folder or by defining at least one of the setup components as 64 Bit.
This works as I built an Excel 2013 Add that loads at startup and works fine.
For the Prerequisite for VSTO to work: You need to change file size and hash a it looks like the recommendations from Microsoft article "Deploying Office solutions vsto 2013" are outdated and the XML code recommended has the wrong file size and hash. Not too difficult to fix. However I think that Microsoft is unfortunately going through a period of crisis and this failure to provide reasonable support is uncharted territory .......
Cheers
InstallShield and WiX is like Visual Studio using VB.NET and SharpDevelop using C#. Just as those tools both create EXE's and DLL's using IL code but different language providers,
InstallShield and WiX both create Windows Installer databases using different languages. Just as a VB EXE can consume a C# DLL, an InstallShield MSI can consume a WiX Merge Modules. This gives you the best of both worlds.
The thing to understand is a VSTO AddIn installer isn't a 64bit MSI, it's a 32bit MSI that deploys an AnyCPU DLL with registry entries for either 32bit or 64bit Office. It's the bitness of Office, ultimately, that determines the bitness of your AddIn.
I have a template that I've used for a dozen customers. It uses InstallShield Limited Edition and it's Preq Bootstrapper to lay down all the dependencies and consumes a merge module authored is WiX and IsWiX (CodePlex). Otherwise ISLE is just a container for the UI and it's one feature.
The merge module takes care of all the dependency detection, gating logic, laying down files, installing certificates, setting registry values and so on.
Some more details can be found at:
VSTO 4 ( 2010 ) Lessons Learned
Office 2010 Bitness Pain
Apparently the small print referenced here should have been one clue: Does InstallShield Limited Edition Support 64 bit Installer?
The current Office prerequisite in Installshield is also misleadingly worded. It should really be "Office 2010 Home & Professional 32 bit".
Perhaps they intend to upgrade it over time to be comprehensive or perhaps everyone has to go through the same hassle to fix it for a few cases they care about. The support guy claimed there are too many GUIDS for all the combinations of versions, bitness, releases etc.
Home & Student, Home & Professional, Professional, Office 2010 Professional Plus License
32bit, 64bit, Languages mangled in there, Service Packs, etc. Depending on the set you care about the number of GUIDS is rather large.
When I attempt to install Microsoft Visual C++ 2010 Redistributable I get the following error.
I have an updated msvcrt.dll to replace the current one with but every time I delete/replace the old dll windows re adds the old one into the system32 folder again.
It would be useful to know the OS version you are using. Could be Windows 2000 or XP (my guess from the screenshot, but could be over RDP as well).
When msvcrt.dll became a first-class citizen (i.e. a system DLL) some time during the lifetime of XP, some changes were also made to it. Incompatible changes, I should add. Example: if you built a program against the VS CRT in former times (e.g. using the WDK/DDK) you could rely on the fact that it works starting with the least common denominator of existing msvcrt.dll versions. However, at some point MS decided that programs built to target, say, XP could rely on the new functionality that was snuck into newer versions of msvcrt.dll. Hence the observed incompatibility.
One way to make it work could be to add a file msvcrt.dll.local in the same folder or - failing that - to create a shim that enforced your intended behavior. See here.
Got similar error. Fixed it by restarting the server before the install.
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).
I'm trying to investigate why would my app, written in VC 2008, crash on bare Windows XP with c0000005. It works great on any windows vista and 7. On XP it would crash with no additional info. Below are the details and the result of a few days worth of my headaches, eliminating one reason after another. Here's the details:
I have Win7 ultimate with XP Mode with iexplore 6 and presumably no patches whatsoever.
I install my program and nothing else, since it is supposed to be install-and-run thing with no additional packages needed.
My app has compiled-in VC2008 runtime (using /MT, as opposed to /MD compiler switch)
I'm using firebird embedded, which needs VC2005 (edited, i wrote VC2008 before) libs for itself anyway, so i put them in my app's working dir
when i install VC++ 2008 on this XP Mode machine, it doesn't crash anymore, so debugging this way is impossible
I've narrowed this error's occurence down to the VC2005 runtime - right after i install it my app stops crashing. But i don't know what could be using it's components. When running the release version under VC2008 IDE, nothing shows any vc2005 libs being loaded (weird, if i say so myself).
My app's linker's dependencies lists these (i added only the first two, the rest was there courtesy of VisualStudio): jpeg.lib, gdiplus.lib, kernel32.lib, user32.lib, gdi32.lib, winspool.lib, comdlg32.lib, advapi32.lib, shell32.lib, ole32.lib, oleaut32.lib, uuid.lib, odbc32.lib, odbccp32.lib, comctl32.lib, %(AdditionalDependencies)
I am also using IBPP firebird interface, which loads these dynamically, so they are present in my app's dir (they need msvc?80.dlls):
fbembed.dll, ib_util.dll, icudt30.dll, icuin30.dll, icuuc30.dll, msvcp80.dll, msvcr80.dll
Please advise why would vc2005 runtime be a remedy for my app to not crash on a bare Win XP. Or how could i debug that one without installing vc 2008 on target machine. I'm starting to blame windows xp's components. Ultimately i want my app to not require any additional packages, such as VC2008 or 2005, especially when no component of my app requires the latter.
I am also using IBPP firebird interface ... msvcp80.dll, msvcr80.dll
The answer is in your question, these DLLs are VS2005 runtime support DLLs. They cannot be stored in your exe directory, they must be registered in the side-by-side cache. This does not typically cause an AV, but it isn't impossible if the code doesn't check the return value of LoadLibrary(). You can download an installer for them from Microsoft. It doesn't otherwise have anything to do with Windows XP, you just happened to try to run this program on machines that already had the DLLs installed. Very common on a dev machine for example.
If you don't want a dependency on them then you'll have to rebuild those DLLs that require it. Which is a good idea, having a dependency on more than one version of the CRT is pretty unhealthy.
If you are wondering why you are having to deal with this: it was Microsoft's attempt to put DLL Hell in the developer's lap instead of the user's. They've since withdrawn this, VS2010 again makes it a user problem. That was a pretty big party in Bangalore, I'd imagine.