Advertisement Jump to content
Sign in to follow this  

using CRT with DLLs [RESOLVED, aka Verg is a dope]

This topic is 4931 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've searched around... but can't seem to come up with a solution to this... Much of our base code is built into static .libs, with either the /MT or /MTd switch, depending on which type of configuration (Debug/Release/etc...) Naturally, these switches map directly to which version(s) of the CRT are linked in. Now, building a DLL using this code seems to be impossible; if I link with /MT or /MTd, the linker complains that it can't find a "main" (or symbol "_main")... this being a DLL, there isn't one... ... and if I link the DLL using /MD or /MDd, there are conflicts (symbols already being defined, etc...) ----------------- Does this mean: I have to build all the base code with the /MD and /MDd switches and link them in? Isn't linking with /MD(d) virtually guaranteeing I'll have to redistribute MSVCRT(71)(D).dll with any app that uses the .dll? ----------------- And... if I build the DLL with the /MD versions of the CRT... can it still be called from code built with the /MT versions? Thanks for any reply. Chad [EDIT TO ADD] I've seen this from MSDN... but it doesn't really answer the question... although I'm nearly positive I'll have to re-build each of the .libs just for the .dll... and almost sure the .dll would still work with /MT(d) code calling it... just not "positive". That's really the only question... hopefully, I don't have to build *everything* with /MD(d)... [Edited by - Verg on July 24, 2005 11:49:08 AM]

Share this post

Link to post
Share on other sites
Ah, nevermind... this seems to answer it:

You can link your DLL with CRTDLL.LIB/MSVCRT.LIB regardless of what your .EXE
is linked with if you avoid mixing CRT data structures and passing CRT file
handles or CRT FILE* pointers to other modules.

When mixing library types adhere to the following:

• CRT file handles may only be operated on by the CRT module that created them.

• CRT FILE* pointers may only be operated on by the CRT module that created them.

• Memory allocated with the CRT function malloc() may only be freed or
reallocated by the CRT module that allocated it.

To illustrate this, consider the following example:

- .EXE is linked with MSVCRT.LIB
- DLL A is linked with LIBCMT.LIB
- DLL B is linked with CRTDLL.LIB

If the .EXE creates a CRT file handle using _create() or _open(), this file
handle may only be passed to _lseek(), _read(), _write(), _close(), etc. in the
.EXE file. Do not pass this CRT file handle to either DLL. Do not pass a CRT
file handle obtained from either DLL to the other DLL or to the .EXE.

If DLL A allocates a block of memory with malloc(), only DLL A may call free(),
_expand(), or realloc() to operate on that block. You cannot call malloc() from
DLL A and try to free that block from the .EXE or from DLL B.

NOTE: If all three modules were linked with CRTDLL.LIB or all three were linked
with MSVCRT.LIb, these restrictions would not apply.

When linking DLLs with LIBC.LIB, be aware that if there is a possibility that
such a DLL will be called by a multithreaded program, the DLL will not support
multiple threads running in the DLL at the same time, which can cause major
problems. If there is a possibility that the DLL will be called by multithreaded
programs, be sure to link it with one of the libraries that support
multithreaded programs (LIBCMT.LIB, CRTDLL.LIB or MSVCRT.LIB).

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!