I've opened up my program in Dependency Walker. It shows the following DLLs:
GDI32.DLL
OLEAUT32.DLL
IMM32.DLL
WINMM.DLL
KERNEL32.DLL
USER32.DLL
SHELL32.DLL
OLE32.DLL
ADVAPI32.DLL
WS2_32.DLL
MSVCP100.DLL
MSVCR100.DLL
So I'm guessing half of those are part of Windows and the other half is part of C++, right? What is the best method to find out which are part of the OS and which aren't?
Don't package up any DLLs that you didn't explicitly add into the project yourself.
Read the documentation for your toolchain (Visual Studio, or whatever) to find out if there are any redistributables that you need to include in your package. Those may include some DLLs.
If you are not allowed to publish an installer (the form of which is generally taken by said redistributables for Microsoft products), then you shall not simply manually dump DLLs instead. You shall remark in your release notes that those dependencies must already be installed on the target system. You make them a pre-requisite for your application.
MSVCP100.dll and MSVCR100.dll contain the runtime libraries for C and C++. Everything else in the list belongs to windows. One way to determine if a DLL belongs to windows is to look at it's path (c:\windows...) and then check for a digital signature from MS. It's not foolproof but it'll get you a bit closer to determining if the DLL belongs to windows or not.
Edit: See this answer by Lightness Races In Orbit concerning distributing Windows DLL's
Other than looking them up using Google, there's probably no easy way to tell. However, in this case I can tell you that MSVCP100.DLL is the C++ standard library code, and MSVCR100.DLL is the C runtime library.
Dependency Walker itself has list of 'known system DLLs'. You can find it in Options -> Configure Module Search Order menu.
Related
I dislike having to distribute an installer for programs compiled with Microsoft's compiler. I prefer to use DLLs packaged in the same directory as the executable. So, what are the required DLLs for MSVC++ 2010?
There's no one simple answer, because it'll depend on what dependencies you build into your program.
You might want to use dependency walker to find what DLLs are actually used by any particular project you're distributing (though be aware that it will list things like kernel32.dll that you can't distirbute right along with those you need to). Before you distribute anything, you need to check license agreements to assure that you're allowed to do so.
I have a Visual Studio 12 project; source code written in C++; it's an OpenCV project. I want to give my compiled program to someone else, but, on other PC, I getting an error message about missing some dlls. My program using many OpenCV (maybe, not only) dll's. How can I resolve that problem? Maybe in VS 12 available an option to include all dll's in .exe?
It's a pretty similar question without proper answer:
include dlls in visual studio c++ 2008
DLLs themself can not be "statically linked" into an executable; that completely defies their purpose (well, actually you can use some really weird voodoo tricks to actually do it, but this is neither recommendable nor should you try it if you have to ask this question).
The simple solution would be to identify all the DLLs your program requires (just starting the program in the Debugger will generate a log file listing them all) and copy those DLLs into the same directory as the EXE resides in; as it happens the directory with the EXE file in is also the first directory where the system looks for DLLs before advancing to the standard system directories in default configuration. Package it up and distribute it that way.
the more complicated solution would be, to build static opencv libraries from src, then link your program against those, resulting in 1 large binary exe-chunk, that does not use any dlls (apart from ffmpeg, not sure about that one).
to build static libs, you'd need to run cmake with : BUILD_SHARED_LIBS=OFF
but take a deep breath, before doing that. linking your program will be sigificantly more difficult, because now you have to link all the zlib,libpng, whatever dependecies manually ( which before got conveniently linked into your dlls )
again, the most simple solution is to deploy all the opencv dlls with your program.
You can use the Windows Dependency Walker to determine which DLLs your program needs to run.
Actually, this only tells you which DLLs your program needs to launch successfully. If you load DLLs dynamically (via LoadLibrary) then you are on your own.
If you opt for the accepted solution (package the DLLs with the EXE file), and you don't want to go into the trouble of finding which DLLs to use, then you can copy all the OpenCV DLLs. They're not so big (65 MB on OpenCV 2.43). They are located at ...\opencvXXX\build\x64\vc10\bin\
where XXX is the OpenCV version. You can use x64 or x86 depending on your platform (32 or 64-bit). And the version of vc can be different on your system (vc9, vc10, etc...)
I want to create a light-weight portable application in C/C++ for Windows. I don't want to statically link everything because I want to keep the size of exe as small as possible. I also use Dependency Walker to track the DLL dependencies of my exe file.
My question is that what are the list of DLL dependencies that an application can have and stay portable across different versions of Windows? With this list at hand I can check the output from Dependency Walker with the list and choose which libraries to link statically and which to link dynamically. I prefer the list contain OSes from Windows XP higher, but having Windows 98 in mind is also interesting.
Create a basic Win32 application in something like Visual Studio and check the dependencies with Dependency Walker. Those are your base dependencies. All of the standard Win32 DLL files will be required, including user32.dll, kernel32.dll, and so on. (Although some of this varies, depending on what you want the application to do. In some cases, you can get away with only kernel32.dll, but you won't be able to show a window on the screen. Probably a fairly useless app.)
Keep in mind that the last version of Visual Studio that can compile applications that run on Windows 98 is Visual Studio 2005. Visual Studio 2008 can target a minimum of Windows 2000, while VS 2010 can target a minimum of Windows XP SP2. You'll need to either use an older version of the compiler, or edit the executable file's PE header manually to change the subsystem field.
If you're really into things like this (although it's honestly a waste of time) you should investigate Matt Pietrek's LIBCTINY, originally from an article published in MSDN Magazine back in January of 2001. This little library makes it theoretically possible to use the /NODEFAULTLIB compiler flag in order to avoid linking to the CRT.
If you are linking to standard Windows DLLs then there's no issue because the DLLs are already present on the target systems.
For other DLLs, if you have to distribute the DLL then your total executable code size will be greater than if you had used static linking. You only end up with smaller executable code size if you have multiple applications that use common libraries.
In other words, although dynamic linking sounds seductive, old fashioned static linking may be better for you.
Now, if you are concerned about linking to a C runtime then you could consider using mingw which can link against the Windows C runtime which is present on all systems.
I'm assuming you're using VC. Microsoft provides the list you're looking for in MSDN. See:
Redistributing Visual C++ Files
Determining Which DLLs to Redistribute
Note that the list changes based on VC's version (you can choose yours on the top of the pages). Also, on modern versions of Windows, it is advised to properly install the runtime dlls using VCRedist_*.exe - it would probably make your programs less portable than you wish, but it's a one-time installation of (sort of) system components, that no-one will ever have to uninstall.
I am using Visual Studio 2005 to build a DLL. By opening the DLL in a text editor I can see that it refers to multiple MS CRTs as follows. How can I find the name of DLL which the dependency elements refer to? I am trying to specifically find the source of the dependency which links to the 8.0.50727.5592 version of the CTR, it is the last one.
Any ideas?
Most likely, you're getting the dependency injected automatically because you're linking against a 3rd party library that uses a different version of the runtime that you're using. Check the libraries against which your dll links and most likely one of them will have the exact extra dependency that you have there. By the way, you can use VS2005 to open a dll and look at its embedded manifest.
I know it's an old post but I had the same issue and found a great tool to list all dependencies for any included libs. I use VS 2010:
In command prompt, go to Microsoft Visual Studio 10.0\VC\bin and run command:
link /dump /directives libpathandname.lib
This will list out all linker dependencies including exact CRT versions.
I'm not sure whether it will tell you exactly what you need in this instance, but Dependency Walker may shed some light on it. It'll show which of the dependent dlls depend on the CRT and it may show the versions from the manifests, though I'm not sure.
I use MSVS 2010 and MSVC++E 2010 to build my applications in C++ and I've notice a lot of my friends (who test my apps on their PCs) don't have the Microsoft C++ runtime library installed on their computers. I've started including the Microsoft C++ redistributable package with my apps, but this seems unnecessary. Would I be able to instead include the libraries in my executable directory? I know that one of the libraries used is msvcr100.dll, but are there also others I need to include? Or is the redistro my best option?
in your project options, for code generation, you can choose the STATICally linked libraries instead of the DLL versions. That eliminates the need for an external dependency like this, at the cost of a larger EXE.
You don't necessarily need to HAVE to have the runtime library within your executable directory, you may use a Manifest File that has a relative path which points to runtime if you wish. But yes, you can include the libraries within the install of your application.
I think we lug around the msvcr as well as the msvcrt and the msvcp DLLs which now that I'm writing that out, might be a bit overkill.
When you build your application to a static runtime, you don't need to distribute the runtime dlls.
Otherwise you have to include the Microsoft runtime.
Links to runtime installers for Visual Studio 2010
Compiling your project with /MT solves the distribution problem. Be careful though, it can get you in trouble when you use DLLs. They will have their own memory allocator. If they export a function that exposes a pointer or a C++ object that needs to be released by the client code then you'll have a very hard to diagnose memory leak on your hands. Very easy to do, just return an std::string for example.
Anyhoo, the setting is found by right-clicking the project in the Solution Explorer window, Properties, C/C++, Code generation, Runtime Library setting.
Also note that VS2010 supports local deployment. Just put the msvcr100.dll file in the same directory as your EXE. You also need msvcp100.dll if you use STL or iostreams.