Im developing a MFC DLL project in VS2008.
The dll compiles OK and I can call it fine from an GUI exe that a contractor has developed for me. Visual C++ Redistributables are required to be installed for my dll (and maybe the exe which is developed in C++ too)
Another company wants to licence my dll to use with their C++ exe. They have requested that my dll have no external dependencies. Is it possible to compile my dll to remove all external dependencies like the Visual C++ Redistributables?
Does setting /MT do this?
I have read Should I compile with /MD or /MT? which makes some sense but I am concerned about dll hell.
Can this create issues with exe calling my dll? I read somewhere about that the exe and dll need to be using the same Visual C++ Redistributables or something.
I am somewhat new to C++. Any advice appreciated.
You can link with the static version of the CRT (yes, /MT) but it is quite dangerous. You'll have to carefully review your exports. Make very sure that none of them return C++ objects, not even an std::string (or CString). Or any pointers that the client code has to release. This will go wrong badly because the client will have its own CRT copy and use a different heap. That will leak the returned object/pointer, crash the program on Vista and Win7 when their secure heap manager detects that the pointer doesn't belong to the heap.
It might be a matter of debate what exactly an 'external dependency' means. Having a dependency on the CRT is not exactly external. You will however have to supply them with a version of the DLL that was built on the same version of Visual Studio that they use. The CRT can only be shared if the version matches.
Why not you package all the dependent dlls into a installer package and release to your customer?
I have seen some of the software package does include the vc's dependent libraries....
Related
I have a simple MFC application built in Visual Studio. I want to be able to link it so any windows PC can run it without needed to install anything else. Just double click the .exe and you are good!
Looking at a debug build, here are my dependencies:
VERSION.dll
MSVCP140D.dll
Mfc140d.dll
KERNEL32.dll
USER32.dll
GDI32.dll
SHELL32.dll
OLEAUT32.dll
VCRUNTIME140D.dll
Ucrtgbased.dll
WS2_32.dll
I know two of those .dlls are from the Windows Visual C++ Library.
My question is, can I configure my release so that anything this .exe needs is built in? Or will I always need Visual C++ to be installed on the machine that wants to run it. I am guessing that latter, but not sure about the librarys static vs dynamic linking capability.
My question is, can I configure my release so that anything this .exe needs is built in? Or will I always need Visual C++ to be installed on the machine that wants to run it?
Yes, you can build the application with static linking, it won’t need the C++ and MFC runtime installed to run.
If you building with the dll dependencies for the C++ runtime and MFC (so not statically linking), you will need to install the VC++ runtime (not the full development environment) on all the machines you distribute to (for servicing this is probably a better option).
You’ll need to read up on the options /MT, /MD and /DLL, specifically to control C++ runtime and MFC linkage, although the IDE makes this much easier to control. Also note, you’ve linked in the debug version (/MDd et. al) of the C++ runtime and MFC, you wouldn’t normally distribute it like that. If you need to debug it off the development box, you can still do that by building with symbols and turning off optimisations to get more details on the applications errors.
I'm working on an application that needs to be compatible up to Windows XP (yea... I know...), my colleagues are arguing that they don't want to use std::string because it might load some dlls that might change the code behavior.
I'm not sure either if they are right or wrong here. At some point, there has to be some common grounds where the application can be loaded.
And so given the context where an application have to be self contained as much as possible, would this application be required to load a dll in order to use the stl or string or else coming from the standard libraries?
Also, assuming I use the -static-libstdc++ flag, by which order of magnitude will the executable be bigger?
In windows, STL is supported using CRT libraries. These libraries require the run time DLLs to be deployed before you running the application. Compiling code with different version of visual studio will create dependency on a particular version of CRT. Compiling code with vs2013 will need a version of CRT much different than the vs2010. So you cannot use/pass STL objects from one version of CRT to another dll consuming a different version. Please go through microsoft articles before consuming the CRT libraries. Below article is for vs2013:
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
I would suggest you to use ATL:CString which is much easier to implement & the static version library also much compact than CRT libraries.
I have a third-party DLL that depends on MSVCR80 and allocates resources that I need to cleanup. The library does not expose a free-function for doing this. Instead, I need to load the same runtime library and manually call the free function.
As a workaround I'm trying to write a "wrapper" DLL that loads the correct runtime and exposes the free function. This DLL is created using Visual Studio 2010 and is dependent on a separate runtime library. Doing LoadLibrary("msvcr80.dll") fails with error R6034 which I guess is because of manifest issues.
Is it even possible to load msvcr80.dll using LoadLibrary? Do I need to create a manifest, embed it into the DLL and store msvcr80.dll in the same directory as my wrapper DLL?
I realize that this is a flaw in the third-party library, but I'm pretty much stuck with this version. Getting the vendor to fix this is most likely not an option.
Probably there are better solutions, but in case everything else failed you could find somewhere a copy of VC++ 2005 Express Edition (=free, no piracy is needed ;) ), which uses the version 8.0 of the compiler, and thus the same runtime of the defective dll.
Then you would build your wrapper dll with it, which would just call the free provided by its CRT (double check that you're using the dll version!).
I have a dll that I distribute that will not run on some windows OS. Using dependancy walker I discover msvcp90d.dll missing on these systems. I DO NOT want any run time dependancies that require the C++ redistributable, and since the application that calls the DLL is not written in C++, it does not have any dependancy on the C++ redistributable.
I am guessing the I left the DEBUG option in the linker preferences on when I compiled the dll which is why it needs msvcp90d.dll?
ADDED:
Appologies, I pasted the wrong dll name in my original question.... too many hours in front of the monitor...
THe dll is a third party dll that I did not write compiled by me in VS2008.
MSVCP90 is nothing to do with debug (that'd be msvcp90d). You can remove your dependency by switching the compiler to /MT (instead of /MD). You also need to ensure that every static library you link to was also compiled /MT.
I recommend against building apps /MT because it has a significant negative effect on system performance and makes servicing take longer in the event of a security issue with the CRT.
Finally, note that /MT means that your CRT is private. So you must ensure that CRT/STL types don't pass across your DLL boundary.
Martyn
Your options as I see them:
Compile the DLL with the /MT option to use static linking to the C runtime.
Continue with dynamic linking to the runtime, but distribute the C runtime with your app.
It needs MSVCP90.dll because the dll was compiled with Visual Studio 2008 most likely. That is the release runtime. The short answer is if you don't want C++ runtime dependencies don't use C++ libraries or applications.
However you can do any of the following to solve your problem:
Install the redistributable to the target system to satisfy the dependency
Remove the dependency on that dll from your application
Recompile the dll against the version of VC you prefer that is already present on the target system
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.