Using Visual Studio 2008 and its C/C++ compiler, how do I create a Win32 DLL that is dependent only on other Windows DLLs, and has no dependency on the Microsoft C runtime?
I have some C code I want to place in a DLL that is entirely computation, and makes almost no use of C library functions.
For those it does use (eg memcpy), I'm happy to rework the code to use the Win32 API equivalents (eg CopyMemory).
Use the /NODEFAULTLIB linker option and (of course) make sure you have no actual dependencies on the runtime. You'll also have to specify & define your own entry point for the DLL using the /ENTRY linker option or alternatively have your own entry point function that matches the name expected by the compiler/linker (for a dll, that's _DllMainCRTStartup
).
Matt Pietrek's article from way back when on LIBCTINY will probably have all the information you need:
- http://msdn.microsoft.com/en-us/library/bb985746.aspx
You may have more dependencies on the CRT than you think. It tears down resources like thread local storage, and global class initializers are run by the CRT before main().
Consider linking with a static CRT, as someone said, and if you really really don't want to, use /NODEFAULTLIB and /ENTRY as someone else said.
Oh, and instead of reworking memcpy, consider using the super-fast compiler intrinsic for it. You can turn on intrinsics with /Oi.
for "Debug" mode try this:
- Go to Project\[Projectname] Properties...
- Open Configuration Properties
- Open C/C++
- Open Code Generation
- For Runtime Library Select Multi-threaded Debug (/MTd) instead of Multi-threaded Debug DLL (/MDd)
for "Release" mode, do same steps except that selecting Multi-threaded (/MT) in the last step.
This causes any C Runtime function that used in your program to be statically-linked to your binary file.
The /NODEFAULTLIB
linker flag is not actually the proper flag. It will ignore all default libs, including others like uuid.lib
.
What you want is the /Zl
compiler option, "omit default library name in .OBJ".
You'd have to make sure none of the Win32 DLLs you use need the C runtime as well or else you back at square one. Compiling your DLL statically won't matter if one of the Win32 DLLs depends on the C runtime.
The only way I can see this working is to statically link ALL your dependent DLLs (if that is even feasible) into your DLL. This of course means you would have to recompile to take advantage of any DLL updates.
Some Windows libraries depend on the C runtime (ODBC32.DLL, for example)
so I think you are on a hiding to nothing here. Why would you want to do this, anyway?
Compile it with static microsoft lib.