LoadLibrary question

[Tushar]

Hi All,
Could anyone please let me know if it is possible to load a library which
has been built with a /MD compiler witch into an exe which has been build
with a /ML compiler switch using 'LoadLibrary'?

I am sure that it can be done, but I want to know what will be the
implications of such a load? Would that be a good idea?

Also, if at all I am to load a dll into an exe which has been statically
linked to C runtime libraries (using /ML option), should the dll to be loaded
be also statically linked to C runtime libraries or it will be OK if the dll
has been dyanamically linked with C runtime libraries (using say /MD option)?
Thanks,
Tushar.

[Carl Daniel [VC++ MVP]]

Tushar wrote:

Hi All,
Could anyone please let me know if it is possible to load a library
which has been built with a /MD compiler witch into an exe which has
been build with a /ML compiler switch using 'LoadLibrary'?
Certainly.

I am sure that it can be done, but I want to know what will be the
implications of such a load? Would that be a good idea?
You'll have two heaps and two CRTs. As long as you don't try to share state
between the two CRTs, you'll be fine. Specifically, if you allocate memory
in the DLL, you mustn't try to free it in the EXE, and vice-versa. Note
that many C++ standard library objects hold onto heap-allocated memory
internally, so generally this means that you can't pass C++ standard library
objects between in or out of the DLL. If you use C-ctyle file I/O, the
FILE* and integer "file handles" will be unique to each CRT and you can't
share them between the EXE and the DLL.

Also, if at all I am to load a dll into an exe which has been
statically linked to C runtime libraries (using /ML option), should
the dll to be loaded be also statically linked to C runtime libraries
or it will be OK if the dll has been dyanamically linked with C
runtime libraries (using say /MD option)?

You'll have the fewest restrictions if everything is linked with /MD. Just
about any other combination results in multiple copies of the CRT and the
restrictions I mentioned above.

-ce

[Bruno van Dooren]

Could anyone please let me know if it is possible to load a library which
has been built with a /MD compiler witch into an exe which has been build
with a /ML compiler switch using 'LoadLibrary'?

I am sure that it can be done, but I want to know what will be the
implications of such a load? Would that be a good idea?

Also, if at all I am to load a dll into an exe which has been statically
linked to C runtime libraries (using /ML option), should the dll to be loaded
be also statically linked to C runtime libraries or it will be OK if the dll
has been dyanamically linked with C runtime libraries (using say /MD option)?

Hi,

using a dll that uses the multithreaded CRT dll is not a problem in your
case, as long as memory ownership is respected. with this I mean that memory
allocated by 1 runtime should be deallocated in the same runtime.

other than that it should be painless. if you follow the ownership rule, you
could mix different runtimes between dlls and apps.

the other way around could be dangerous: using a single threaded dll in a
multithreaded app could cause some problems.
--

Kind regards,
Bruno.
br**********************@hotmail.com
Remove only "_nos_pam"

[Peter Ritchie]

I disagree. If you're linking a singled threaded-compiled LIB into a
multi-threaded application (which is essentially what will happen with
LoadLibrary) you're only asking for troubles. Not only is this not
supported, it's not safe.

As you mentioned, you have to make sure that you don't use memory allocated
from one LIB with the other. Using any functions from one LIB are bound to
make allocations off one heap and be passed back. The application will not
know what is from the stack, what is from heap 1, or what is from heap 2.
The application will randomly start to fail.

When LoadLibrary is called, the DLL in question is fixed-up and loaded into
the same address space as the host application. You're asking the new DLL to
load its dependent runtime into the application's address space, static data,
thread-local storage, etc., and all. There's no way to tell what a call into
the DLL will use in terms of runtime resources.

Also, since the DLL is not using the same threading model, it's probably
being needlessly relocated; reducing performance.

I would suggest that you use a DLL compiled for the same threading model
that the application uses, if at all possible.

--
http://www.peterRitchie.com/
"Carl Daniel [VC++ MVP]" wrote:

Tushar wrote:

Hi All,
Could anyone please let me know if it is possible to load a library
which has been built with a /MD compiler witch into an exe which has
been build with a /ML compiler switch using 'LoadLibrary'?

Certainly.

I am sure that it can be done, but I want to know what will be the
implications of such a load? Would that be a good idea?

You'll have two heaps and two CRTs. As long as you don't try to share state
between the two CRTs, you'll be fine. Specifically, if you allocate memory
in the DLL, you mustn't try to free it in the EXE, and vice-versa. Note
that many C++ standard library objects hold onto heap-allocated memory
internally, so generally this means that you can't pass C++ standard library
objects between in or out of the DLL. If you use C-ctyle file I/O, the
FILE* and integer "file handles" will be unique to each CRT and you can't
share them between the EXE and the DLL.

Also, if at all I am to load a dll into an exe which has been
statically linked to C runtime libraries (using /ML option), should
the dll to be loaded be also statically linked to C runtime libraries
or it will be OK if the dll has been dyanamically linked with C
runtime libraries (using say /MD option)?

You'll have the fewest restrictions if everything is linked with /MD. Just
about any other combination results in multiple copies of the CRT and the
restrictions I mentioned above.

-ce

[Bruno van Dooren]

>I disagree. If you're linking a singled threaded-compiled LIB into a

multi-threaded application (which is essentially what will happen with
LoadLibrary) you're only asking for troubles. Not only is this not
supported, it's not safe.
You are totally right, but that is not what Carl and I suggested.
The question was if it is safe to load a dll that uses the multithreaded CRT
into an app that uses the single threaded CRT.
this is perfectly safe.

As you mentioned, you have to make sure that you don't use memory
allocated
from one LIB with the other. Using any functions from one LIB are bound
to
make allocations off one heap and be passed back. The application will
not
know what is from the stack, what is from heap 1, or what is from heap 2.
The application will randomly start to fail.
The dll should not have to know. a properly designed API does not have to
care.
e.g. the windows api can be used by any compiler in an application that uses
whatever CRT.
that is because it respects the memory ownership rule.

When LoadLibrary is called, the DLL in question is fixed-up and loaded
into
the same address space as the host application. You're asking the new DLL
to
load its dependent runtime into the application's address space, static
data,
thread-local storage, etc., and all. There's no way to tell what a call
into
the DLL will use in terms of runtime resources.

Also, since the DLL is not using the same threading model, it's probably
being needlessly relocated; reducing performance.

I would suggest that you use a DLL compiled for the same threading model
that the application uses, if at all possible.

that is unnecessary. people do not rebuild a dll for each possible runtime.
that is the whole reason for proper API design: to not have these problems.

basically, if memory ownership is respected, and the dll is built against a
multithreaded CRT,
there will be no problems.
http://vcfaq.mvps.org/lang/9.htm

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"

[William DePalo [MVP VC++]]

"Peter Ritchie" <PR****@newsgroups.nospam> wrote in message
news:2C**********************************@microsof t.com...

I disagree. If you're linking a singled threaded-compiled LIB into a
multi-threaded application (which is essentially what will happen with
LoadLibrary) you're only asking for troubles. Not only is this not
supported, it's not safe.
It is not the simple binary proposition that applies here - multi-thread
library good, single thread bad.

That is not to say that where you have control over both caller and callee
modules that they shouldn't be linked against the same version of the
runtime.
As you mentioned, you have to make sure that you don't use
memory allocated from one LIB with the other.
Yup.
Using any functions from one LIB are bound to
make allocations off one heap and be passed back.
This is the crux of the issue. Passing things that the runtime has allocated
across module boundaries is problematic. If you don't do that there is no
problem. I think that this is the point that Carl made in his post.
The application will not know what is from the stack,
what is from heap 1, or what is from heap 2.
Well, what can you say about _any_ application linked to _any_ version of
the runtime which can not distinguish between automatic and dynamic
allocation?
The application will randomly start to fail.
Maybe. Of course if an attempt is made to delete or free() and object in the
wrong module bad things will happen.
There's no way to tell what a call into
the DLL will use in terms of runtime resources.
Right.
I would suggest that you use a DLL compiled for the same threading model
that the application uses, if at all possible.

Absolutely.

Regards,
Will

[Tamas Demjen]

Peter Ritchie wrote:

I disagree. If you're linking a singled threaded-compiled LIB into a
multi-threaded application (which is essentially what will happen with
LoadLibrary) you're only asking for troubles.

They were talking about DLLs, not LIBs, though. It is perfectly fine to
load a DLL that uses a completely different runtime than the
application. I can even use a different branded compiler to write the
application than the DLL. Every plugin architecture is based on this
concept -- the application's writer can't control which compiler (and
runtime) will be used for writing the plugins. You can't reasonably
expect that when a new version of the application comes out, it breaks
all existing plugins, and forces the plugin manufacturers to rebuild
their code. Also, a good library is supposed to work with any compiler
that supports stdcall, even non-C/C++ languages. When you buy an OCR
engine, for example, it will work with virtually any language, any
compiler, whether it's Microsoft, Borland, Metrowerks, C or Basic or
Pascal. You can be certain that the library's runtime library is
completely different than your application's runtime library, 99.9% of
the cases.

Tom