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.
Related
TL;DR - The MS docs state that binary compatibility between VS2015 and VS2017 libs is one-way, while I'd assumed it is necessarily two-way. Where's the catch?
First, for background:
Any MSVC++ built libraries are officially binary compatible between VS2015 and VS2017.
Specifically, you can use your VS2015 C++ app with the MSVCRT140 version from 2017. (VCRedist backwards compat)
The official documentation site states a confusing restriction.
Background / related Questions:
Is Visual-C++-2017 binary compatible with VC++-2015?
Questions about "Binary Compatibility between Visual Studio 2015 and Visual Studio 2017"
Binary compatibility between VS2017 and VS2015
The confusing restriction I find is:
There are two exceptions to this rule. Binary compatibility is not guaranteed in these cases:
...
When consuming libraries built with a toolset whose version is greater than the toolset used to compile and link the application. For example, a program that is compiled and linked with compiler version 19.12 can consume libraries that are compiled with 19.0 up through 19.12.
This caveat is, IMHO, both technically sloppy and confusing. What would the technical reason be for that?
I say it's sloppy because it is incomplete, because the interface between an executable and a DLL is pretty syymetric, but this bullet only covers "the application".
Specifially, and assuming all modules are built against the dynamic CRT version and this dynamic CRT version is the newest version available, I see the following combinations where binary compat is an issue:
my_2017.exe <-> my_2015.dll -- seemingly supported
my_2015.exe <-> my_2017.dll-- seemingly unsupported
my_2017.exe <-> my_2015.dll <-> my_2017_x.dll -- what now, in which "direction" is this supported btw DLLs?
Since binary compat - purely from the binary/interface perspective - must run both ways, I don't quite see where we suddenly could get an incompatibility here: API calls can go both ways (callbacks etc.), objects "move" both ways, even the order of DLL loading can be mixed.
This is an important point IMHO, as it means the binary compatibility as stated is severly limited:
If my application want's to consume any VC14* compiled library, I "officially" still must make sure that my application is built with the "newest version".
On the other hand, if don't build an "application", but have a DLL, I can seemingly consume any other VC14* DLL and be compatible?
With the VCRedist, we have exactly the case that is seemingly unsupported, namely we are allowed to consume a VC2017 library (CRT in this case) from a 2015 app!
Question
So, why(!) is this limited in the way it is, and how does it relate to inter-dll dependencies and also the inverted(!) CRT-dll version requirement.
Microsoft has since updated their docs, the relevant section of the current version of https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017 reads:
C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2019
...
When you mix binaries built with different supported versions of the MSVC toolset,
the Visual C++ redistributable that your application runs on cannot be older
than any of the toolset versions used
to build your app or any libraries it consumes.
The diff is at https://github.com/MicrosoftDocs/cpp-docs/commit/a505dccfb31eb49c2ffece4dabd24a0a61b1fcb3#diff-d488b4c71be450b2a39cdce495c229bf
There is no direct GitHub/MS-Docs issue for this, but this limitation makes a lot more sense: It just talks about the compatibility requirements of the redistributable, and requiring a VC runtime version that is at least as current as the newest module in use.
This, of course, can make sense, as this is not only pure binary compatibility.
Of course, what I said in the question still is valid: Any (old) VS2015 application must be compatible with the (new) VS2019 redistributable, so I guess all the interface surface that VCRedist-VC14.0 ever exposed should be binary compatible.
msvcr100.dll (Visual C++ Runtime) seems to have become part of the Java runtime on Windows after Java 1.6, and I'm thinking if Java ran on Windows all these years without it, why is it now I must put up with it, or can I configure it out of the picture.
I have a program that has a mysterious very occasional crash of msvcr100.dll. I noticed that I can rename msvcr100.dll after my Java program has started (so the dll is not loaded), but when I call Runtime.exec to spawn a Windows program, the missing DLL is "noticed" again, and gives the message "The specified module could not be found. Java Runtime Environment not valid."
In earlier versions of Java, this dll was not required, so my question: is there a way to tell the JVM that we don't want to use msvcr100.dll?
No, it is not possible. Oracle's Java runtime is written in C, and built with Visual Studio 2010, so it needs the Visual Studio 2010 C runtime library, msvcr100.dll.
Java 6 used the Visual Studio 6 runtime library, msvcrt.dll, instead.
The runtimes are not interchangeable. An application built for one runtime cannot use a different one. In any case, the runtime is unlikely to be the source of your problem.
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.
What are the different platforms/languages in which an app can be compiled and run on Windows without any prerequisites? I know of .NET but it requires the specific version of .NET to be present in the Windows installation.
C and C++, but Visual Studio defaults to dynamically linked library. Change the default to static and you will be fine.
That being said, ther are no compilers that come with windows. You must install a compiler to build the a program that will run everywhere after that. There are free version of the compiler in the Platform SDK and in mingw (Cygwin requires a dll).
If you are using Visual C++ as language and development tool, you may switch to Statically bound DLLs, which would produce larger binaries, but would run without any runtime-prerequisites. Visual C++ Runtimes are easily installable, can be distributed, or users may be asked to install them directly. If users are using Windows Update, they would anyhow get the latest VC runtimes.