Building windows C ++ libraries without runtime?

Question

I am trying to create a C ++ library for use on Windows / MSVC.

My problem is that it seems that for proper communication I should distribute a bunch of different versions related to different versions of MSVC C ++ runtimes - single-user and multi-threaded, debugging and releases, different versions of compilers, various other security parameters and other options.

I would just like to distribute, possibly two, 32-bit and 64-bit.

My idea is to use another new operator (say mynew) and custom allocators for all my STL types. When creating lib, / nodefaultlib. Then, when you contact the parent project, they need them to change mynew to a new one, and my stl distributor to a standard one (or one of them). I think I will need to remove a few more functions. Naturally, I would give an example of the implementation of the library using the library, but this, I hope, will save everyone a lot of headache.

Is it possible? Has anyone ever tried this? Are there any better methods for creating / distributing libraries in Windows / MSVC?

Answer 1

You want static binding as a generic answer.

A quick note on Chris’s answer (I don’t want to deactivate, because it is mostly good, but ...):

DO NOT link to msvcrt.dll (unversioned); it is an OS version DLL, and if you reference it, your application probably will not work on other versions of Windows. As far as I know, you should always refer to msvcrt ##. Dll. The DDK may contain lib for it, but not reference it unless you really know what you are doing.

Answer 2

Link statically to the C ++ runtime library:

• Open the project properties.
• Go to Configuration Properties | C / C ++ | Code generation section.
• Install the Runtime Library in multithreaded (/ MT).

Answer 3

You do not need to use a custom allocator if you use C ++ and you wrap all distributions around std::tr1::shared_ptr (where you can specify the release function). This ensures that even when clients issue the last reference to a shared pointer, it is still encoded in your library (or CRT library), which is called when the object is to be freed.

This is one way of addressing the DLL Addresses. Hope it helps! :-)

Edit: I think I misunderstand the intent of your question. Instead of requiring any dependency on CRT, because you are worried about the infernal end of the DLL, I suppose you just need a version of your DLL that you can install anywhere. In this case, you can link your program to msvcrt.dll . It is available on any Windows system.

You have not heard about this from me, but apparently in the Driver Development Kit you can find some kind of import library that allows later versions of Visual Studio to reference msvcrt .