I work on the optimization algorithm so the performance really matters. The algorithm is about 8 times faster when compiled in VS 2010 compared to VS 2008. Googling shows that it is not my fault (see e.g. https://stackoverflow.com/a/5560184/890355). The problem is that the final project must be built under VS 2008.
The solution I tend to is to built my algorithm as DLL in VS 2010 and then link it to the main project. Is it possible to use VC++ 2010 run-time libraries with my DLL under VS 2008? If so, what is the least painful way to do it?
Any other ideas?
Thanks.
The runtimes are not an issue. Nothing stops you from linking your DLL against the VC2010 runtime and then using that DLL in other projects. It doesn't matter if those projects are built using Visual C++ 2008 or any other language.
The tricky part is designing the DLL interface. Simply exporting some C++ classes is risky since it exposes you to incompatibilities between the different compilers. I think your best bet would be to either expose a C-style interface or use COM. I think COM is the best approach, but if you're unfamiliar with the technology, then a C-style interface will work fine. (COM could also be over-kill if the interface is simple.)
If you ask for any other way to combine 2008 and 2010 libraries in one executable other than moving 2010 part outside into a DLL, than the answer is probably "there is no other easy way to achieve this".
But if you don't want to "VC++ 2010 run-time libraries ... under VS 2008" (that is building against 2010 libraries in old 2008 IDE), but "use a 2010-compiled DLL in your 2008-compiled program", it is perfectly possible.
The easiest way, as we do it in our projects, is to build (both .exe and DLL) against statically linked standard libraries (MFC, if you use it) and then use LoadLibrary in your .exe to load the DLL. In the DLL you can export (_declspec (dllexport)) a function (preferably inside extern "C" {} guards) and use it in the .exe through GetProcAddress.
Static linkage and explicit loading save you from a lot of inconsistency bugs caused by different runtimes.
If you are worried about DLL loading and function calling costs, you can try to make these calls as rare as possible (maybe by moving not only the algorithm, but also some more high-level logics into the DLL). See this issie too.
And you can build all your code in one IDE (2010) using native multitargeting (however you will still need to build you main app and DLL separately against v9 and v10 libraries respectively).
You can if you're careful, and the MS documentation provides some hints. I have answered this question before here:
Wondering if the lower version of visual studio can use the dll built using higher version of visual studio?
Related
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'm trying to make a binary that can be run on any windows machine without the visual c++ stuff installed (I'm assuming that's what MSVCP120D.dll is however my searching was not very fruitful as to what this actually is). I made a game for an assignment and wanted to have other people (non-devs without VS stuff installed), help me test it but they kept getting errors saying that the above dll is missing. I'm not using any Visual C++ stuff and have the /Za flag set to ensure that it's just ANSI C++. Does Visual Studio support compiling ANSI C++ and if so how do I go about making it not use Visual C++ stuff, if it doesn't support this what compiler should I use?
As you can see here, the MSVCP DLL is the platform's implementation of the C++ Standard Library. In short what that means is you cannot distribute your application without needing the "stuff" that these libraries provide. All compilers regardless of platform would need some kind of implementation of the Standard Library. Typically this is distributed in the form of libraries.
However you can distribute your application so that the "stuff" is built in to your program directly, rather than being shipped in a separate DLL. In order to do this, you must statically link your application to the Standard Library.
There are a few ways to accomplish this. One way is in Project Settings. In "Project" > "Configuration Properties" > "C/C++ Code Generation" > "Runtime Library", choose "Multithreaded (/MT)" as opposed to "Mutithreaded (Static)".
By the way, the "D" in "MSVCP120D.dll" you mentioned above means "Debug." This means that you are trying to distribute a debug build of your program. You should (almost) never do this. Distribute release builds instead.
You have three options (in the order I'd recommend):
Don't statically link, instead get people that want to run your game install the visual studio re-distributable package. 32-bit VC 2010 version here: http://www.microsoft.com/en-us/download/details.aspx?id=5555
Statically link the CRT (the dll you don't want to require at runtime) see here for details: How do I make a fully statically linked .exe with Visual Studio Express 2005?
Build an app that doesn't even use the CRT at all. Here you will have to implement your own operator new that calls HeapAlloc(), and operator delete that calls HeapFree(), its an interesting challenge ;). To do this you tell the linker to ignore all default libs.
Build with the static runtime libraries rather than the DLL versions.
Go to Properties, C/C++, Code Generation, Runtime Library and select /MTd or /MT rather than the /MDd and /MD options.
Configure your project to link against the runtime statically rather than dynamically.
First of all the D on the end of the name indicated a debug build. If you make a release build then it will need it without the D. This is important because microsoft do not allow the debug libraries to be distributed without visual studio.
The machine you are trying to run the program on may already have the release runtime installed as lots of programs use it. If not then install http://www.microsoft.com/en-us/download/details.aspx?id=30679 on the machine ( I think that's the right one but can't check at the moment)
You'll want static linking, that 'builds in' the external library calls into your binary. It does have the added affect of larger binary file, but in your case that doesn't sound like that big of a deal.
On a side note, MSVCP120D.dll is the Microsoft Visual C++ 12 debug DLL (dynamic link library) that contains all of debug C++ libaries (i.e. iostream, string, etc). That library is what you would be 'baking in' to your final binary.
Hope that helps.
I encountered this error when I tried to execute my exe on a different machine that had a newer version of Visual Studio on it. You need to change the project properties and re compile in order for this to go away.
To do this:
Open up solution that you are trying to run
Right click on the Project file - > Properties
In Configuration Properties and General, Ensure Platform Toolset is configured to be the correct compiler on your machine. If it is not correct, it should give a message next to it saying that it's not installed.
Build and run the code again and you should no longer get the issue.
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 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.
How do you tell Visual C++ Express 2008 to statically link runtime libraries instead of dynamically? My exes do not currently run on computers w/o some sort of VS installed and I would love to change that. :)
Sorry, I do not have VC++ Express to test, but in Standard edition I use Project Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library. Dll and Dll Debug are for dynamic linking.
Are you 100% sure that you want to do this? Please consider that if you do and there is a security vulnerability found in the runtime library, Microsoft will not be able to patch your application via Windows Update.
Another solution is to package the Visual C++ Runtime Redistributable with your application. It installs very fast and does not require Visual Studio. It is also important to note that you should not distribute code linked against the debug runtime libraries as those do require Visual Studio. See this blog post for more information on packaging the redistributable.
EDIT: With that said, it's up to you. My point is simply that you should not disregard dynamic linking based solely on the idea that users must have "some sort of VS installed", which is not true.
See the answer to this question: How do I make a fully statically linked .exe with Visual Studio Express 2005 ?. It's for VS2005 Express but the answer still holds.
For the C-runtime go to the project
settings, choose C/C++ then 'Code
Generation'. Change the 'runtime
library' setting to 'multithreaded'
instead of 'multithreaded dll'.
If you are using any other libraries
you may need to tell the linker to
ignore the dynamically linked CRT
explicitly.
You can install the C runtime redist on the target machine and you're executable would run there as well with dynamically linked C runtime.
(Oh sorry, that had already been mentioned).