According to this article, the version of a referenced dll is embedded in the exe file.
Using ProcExp, I can see that the runtime loaded dll is indeed the latest dll available on my machine, but I'm interested to know the linked version.
As a side note, I built the project using the VS9 msbuild, and interested in the VC runtime (msvcr90.dll) version. In the VC9 redist folder it is 9.0.30729.1, runtime the .4926 is loaded.
My questions are:
Is there any tool with which I can extract the dll version linked to (from the dll/exe)?
Which version does VS link to by default? The one found in its redist folder?
Thank you.
Dependency Walker might do it.
Actually, Dependency Walker seems to not read (or at least display) the version linked in the file.
But I found that I can use mt.exe from the Windows SDK or ResEdit to read the embedded manifests.
Also, to summarize my findings (targeting amd64 using msbuild with the Windows SDK for Win7, which seems to use VS9 (SP1?) libs):
Without special effort, VS9 (non-SP1) version 9.0.21022.8 of the CRT is written in the embedded manifest. Maybe this is a VS9 platform baseline.
Runtime the newest dll gets loaded, according to the SxS policy (good read can be found here, along with the article referenced in the question).
People seem to had problems when the appropriate policies are not installed (via the redist package for example), see here and [here] and 4[here]5.
The latter SO tells that if _BIND_TO_CURRENT_VCLIBS_VERSION=1 is defined, then the linker would link against the VS9 SP1 CRT (version 9.0.30729.1), which as noticed before, is indeed in the redist folder.
For future account, it would be nice if:
There would be a table with CRT version X.Y. introduced in OS/SP/etc Z.W.
If one could know that what is a safe version to target, which is possibly available on most users machines by default.
Related
Did not find any suitable solution with existing questions so asking new question here.
We use log4cxx which has WS2_32.LIB as dependency. WS2_32.LIB is present in Windows SDK version 10.0.16299.0.
When using this log4cxx.dll on windows7 WS2_32.dll and all its dependencies gets loaded properly and application start normally.
but in windows 10 environment WS2_32.dll expects dependent dll's like API-MS-WIN-CORE-CRT-L1-1-0.DLL which are not part of windows10 or any of the microsoft visual c++ Redistributable which results in application error.
difference in WS2_32.dll and its dependencies between Windows7 and windows10 are clearly visible via dependency walker.
WS2_32.dll on windows 10:
whereas
WS2_32.dll on windows7 is
as shown here API-MS-WIN-CORE-CRT-L1-1-0.DLL is not a dependent dll in windows7 where as its in windows 10 which is not present in the system resulting in application error.
So what should be the way to make the application run successfully? what alternate dependency should be provided instead of WS2_32.LIB while compiling log4cxx.dll to avoid this issue in windows 10? Also where to find documentation about such changes between windows OS versions?
Please suggest.
The old depends.exe doesn't support those API sets and shows wrong data.
use the open source replacement called Dependencies:
Dependencies is a rewrite of the legacy software Dependency Walker
which was shipped along Windows SDKs, but whose developement stopped
around 2006. Dependencies can help Windows developers troubleshooting
their dll load dependencies issues.
I'm kind of lost with all these SDK windows versions.
For instance, I installed vs2013 on windows8.1, and I (also) need to link my apps against vs2008 runtime (platform toolset).
Should I install the whole VS2008 too or just the API. In the last case, what SDK do I have to install ?
You are talking about two very distinct things. The Windows SDK only covers the declarations and libraries that you need to make winapi calls. SDK v8.1 is suitable to target any modern Windows version since Vista, you select the Windows version you want to target by setting the _WIN32_WINNT macro. Note that XP requires an older SDK version, v7.1 is the last one that's still suitable and selected by setting the Platform Toolset to v120_xp.
The runtime libraries are a pure implementation detail of Visual Studio C/C++ projects and completely unrelated to the SDK. When you build such a program on VS2013 with the /MD compile option then it will have a dependency on msvcr120.dll, possibly msvcp120.dll and others. These DLLs implement the C runtime library and the C++ standard classes. And possibly MFC, ATL, OpenMP and AMP if you use those libraries.
If you still have a dependency on the VS2008 version of those libraries then you are liable to have a Really Big problem. You can obtain the release versions of those DLLs from the redist installer you can download from Microsoft. Having a dependency on the debug version requires having VS2008 installed on your machine. But having trouble linking the program and misery at runtime is highly indicated, the runtime libraries changed a great deal between VS2008 and VS2013 thanks to the new C++11 language standard. Having more than one CRT in a program is in general liable to cause lots of trouble.
You need to strongly pursue getting the library that still has the VS2008 dependency rebuilt. Contact the owner of the library if necessary to get an update.
I wrote a large and complex C application on Windows XP. Now I am recompiling on a 64bit Windows 7 machine. When I run certain executables I get this error:
The program cannot start because MSVCP71.dll is missing from your computer. Try reinstalling the program to fix the problem.
Apparently this is a .dll that used to come with windows but now does not (see especially this MSDN forum and this previous stack overflow question.)
Supposedly I should generate this DLL from Microsoft Visual C++ and "extract the DLLs from the merge modules." However, I am using gcc, mingw and make and I would prefer to avoid going to Visual Studio.
There are lots of copies of this dll available to download from unverified sources on the internet, but none directly downloadable from Microsoft. What should I do? Do I need to install Microsoft Visual C++? Is there any way to do this with gcc and mingw?
Update: #Sheng Jiang 蒋晟's hint was crucial. What I hadn't realized was that my dependency on MSVCP71.dll only arises out of linking to a third party DLL. I was able to identify the third party DLL and find a copy of MSVCP71.dll running on another system with that DLL in place. Now I can include the MSVCP711.dll along with the third party DLL and everything runs smoothly.
There is no downloadable redistributable released for this file. Only merge modules are provided on the CDs. Programmers are expected to embed those merge modules into their setup programs, or extract the files into their program's install folder. This file is not intended for System32 as that is a violation of Windows Logo requirement.
Since you are not using the Visual C++ tool chain, the MS-STL dependency comes with a third-party component whose author did not provide a proper setup program. Although you can get the dll from other products, however, you need a product that explicitly grant you the redistribute rights to be able to redistribute the file to your customers. Such redistribute rights come with Visual C++ 2003 and probably InstallShield X and other install package authoring software.
For evaluate proposes you can obtain the file for the component from other products that have a dependency on the file, such as SQL Server 2005, the .Net 1.1 runtime or its SDK, Crystal Report 10 etc. Beware of version mismatch. If the component requires SP1 or later edition of MSVCP71.dll, it may not work with the RTM edition.
I dont have a link from Microsoft but you can download it from here (link fixed and now points to correct file).
Now move it to C:/Windows/SysWOW64 (64 Bit) or C:/Windows/System32 (32 Bit)
Here's another download available: http://www.addictivetips.com/windows-tips/fix-msvcp71-dll-and-msvcr71-dll-missing-error-in-windows-7/
Not sure if this will work, but maybe a reinstallation or update of MS VC++ Runtime solves that (Microsoft Download Center ).
MS Office, Oracle client, and sql developer all have msvcp71.dll. I found a copy already on my PC. No need to download from untrusted website.
It works if we copy the file msvcp71.dll from C:\ORACLE\product\10.2.0\Client_4\oui\lib\win32\msvcp71.dll and past the file in the folder C:\winnt\system32.
My company is always having problems with software not working because "run-times" or missing. I hear people say this a lot (you need the 32-bit run times, Microsoft run-times, etc etc).
What exactly is being referred to? DLL files? Something different? Can anyone please clarify?
Run-time is basically the time at which your code is running (as opposed to compile-time or link-time).
In the context you're seeing it, it means run-time libraries, those libraries needed to load an execute your program.
This is dynamically linked stuff (DLLs or shared objects) since statically linked code can't be missing (it's in the executable file itself).
A classic example is to depend on Microsoft's C run-time or .NET libraries but not ship them with your product. That means your executable will run on any machine that has those libraries already there (such as those with Visual Studio installed) but not necessarily every computer you want to run your code on.
I answered a question here regarding the difference between static and dynamic linking which should hopefully add to your knowledge. The dynamic linking allows you to update certain parts of the application without recompiling or relinking. You do this by dropping in a new version of the DLL. Unfortunately, having that code in a separate file means it can go missing.
That would be one cause of the problem but I suspect the most likely is just that someone didn't do their installation code very well, otherwise everything needed would have been installed.
A runtime in this context is a runtime library - a shared library (on Windows indeed a DLL), most commonly specifically referring to the one which provides basic functionality of the language. It implements the functions that are thought to be "built into" a language core. Thus, no program compiled with a compiler which requires a runtime library will run if such a library for it is not installed - or if the program is specifically statically linked (with everything needed packed into the executable).
To give you a practical example - here are some links to some common runtimes:
Microsoft Visual C++ 2008 SP1 Redistributable Package (x86) (x86 means 32-bit)
Microsoft Visual C++ 2010 Redistributable Package (x86)
Microsoft .NET Framework 4 (Web Installer)
These are system-wide installs - so any software that requires a particular runtime will be able to use it, once installed.
They are probably referring to Microsoft's 3rd party libraries and the .NET framework.
Your company's applications probably uses some 3rd party libraries such as MFC, ATL etc. in case of application's written in a .NET language e.g. C#, VB.NET, if you're developeing using Java there is a JRE (Java Runtime env) that have to be installed for the application to run.
If the required dlls/framework ween't installed/deployed on the customer's machine you'll probably get a "runtime error".
This is a deployment issue - which with the correct install process can be solved - e.g. the installer can check if the required framework is installed and if not install it as part of the installation process.
That is, can I get away with DLLs in the install directory or does the installer need to ensure that MingW is fully installed?
If you install the Qt SDK, it will actually install its own MinGW tree.
This does not directly answer your question, but generally speaking, to ensure I have all the right dependencies when creating an installer, I do the following:
Use Depends, a Microsoft tool that shows what DLLs a Windows executable (.exe or another .dll) depends on. This will not show dynamically loaded DLLs though, such as QT plugins. I believe Depends is part of the Platform SDK (it used to be, anyway), which you should be able to download. See here for example.
Use a virtualization tool (like VirtualBox or VMWare) to install a fresh copy of Windows and your application. If it complains of missing DLLs on startup, you missed something in the install package.
You should be aware of any dependencies on the Visual C++ run-time. There are many different versions out there, and if your app depends on them, you need to install the correct version to the Windows\WinSxS directory. Microsoft provides a redistributable for each version of Visual C++ (including the express edition, which you can get for free). I only mention this because I noticed when installing Qt SDK that the VC++ redistributable was getting installed, so the Qt DLLs may have a dependency on the VC++ run-time.