Mixed mode DLL and Loader Lock issue - revisited

[Roy Chastain]

I have read and re-read KB 814472. There appears to be a little 1984
New Speak in it.

I am referring to option 3.
DLL that contains consumers that use managed code and dll exports or
managed entry points

The minitialize and mterminate functions are straight forward and make
sense. The problem is with the code

BOOL WINAPI DllMain(HINSTAN CE hModule, DWORD dwReason, LPVOID
lpvReserved) {
Console::WriteL ine(S"DllMain is called...");
return TRUE;
} /* DllMain */
Now, this seems to me that this code violates the rule that no managed
code should be run under loader lock.

I have a c# main program.

static void Main(string[] args)
{
ManagedWrapperr .minitialize();
,,,,,
ManagedWrapperr .mterminate();
}

And to no surprise I see the following output
DllMain is called...
__crt_dll_initi alize is called...

(I added the line Console::WriteL ine(S"__crt_dll _initialize is
called...");
in minitialize after the call to __crt_dll_initi alize.

I would assume that putting a managed dll in the references (or in the
#using list) would be the same as making it statically linked in
non-managed environment. If that is the case then how does this code
actually do us any good? (The implication being that the load caused
by the referencing managed code as in turn called to OS to do the DLL
load which as already called DLLMAIN which should have run the
non-managed dll initialize (__crt_dll_init ialize).

Prior to putting the work around code into my dll, I did not have a
user defined DLLMAIN therefore my DLLMAIN should (I would expect) have
been unmanaged only, so why do I even get the loader lock problem to
start with?
-------------------------------------------
Roy Chastain
KMSystems, Inc.

[Bart Jacobs]

Roy,

Roy Chastain wrote:

I have read and re-read KB 814472. There appears to be a little 1984
New Speak in it.

I am referring to option 3.
DLL that contains consumers that use managed code and dll exports or
managed entry points

The minitialize and mterminate functions are straight forward and make
sense. The problem is with the code

BOOL WINAPI DllMain(HINSTAN CE hModule, DWORD dwReason, LPVOID
lpvReserved) {
Console::WriteL ine(S"DllMain is called...");
return TRUE;
} /* DllMain */
Now, this seems to me that this code violates the rule that no managed
code should be run under loader lock.
You are compiling this DLL using the /NOENTRY switch. Therefore the
DllMain function does not get called by the OS Loader. Therefore the
rule is not violated.

I have a c# main program.

static void Main(string[] args)
{
ManagedWrapperr .minitialize();
,,,,,
ManagedWrapperr .mterminate();
}

And to no surprise I see the following output
DllMain is called...
__crt_dll_initi alize is called...

(I added the line Console::WriteL ine(S"__crt_dll _initialize is
called...");
in minitialize after the call to __crt_dll_initi alize.

The DllMain function gets called during your
ManagedWrapperr .minitialize() call, not when the DLL is loaded.
I would assume that putting a managed dll in the references (or in the
#using list) would be the same as making it statically linked in
non-managed environment. If that is the case then how does this code
actually do us any good? (The implication being that the load caused
by the referencing managed code as in turn called to OS to do the DLL
load which as already called DLLMAIN which should have run the
non-managed dll initialize (__crt_dll_init ialize).
Could you rephrase this paragraph?

Prior to putting the work around code into my dll, I did not have a
user defined DLLMAIN therefore my DLLMAIN should (I would expect) have
been unmanaged only, so why do I even get the loader lock problem to
start with?

If you have a mixed DLL, VC++ always creates a DllMain that calls into
managed code.

See
<http://msdn.microsoft. com/library/default.asp?url =/library/en-us/dv_vstechart/html/vcconMixedDLLLo adingProblem.as p>.

In any case, it might be better to avoid mixed DLLs completely, by
splitting the Managed C++ project into a pure Win32 C++ project and a
C++ Class Library project. In the C# project, you can use P/Invoke and
pointer manipulation (using the "unsafe" keyword). The biggest
disadvantage of this is probably that you have to manually translate the
unmanaged function prototypes into P/Invoke method declarations. If your
unmanaged code is stable, this is doable, but if it evolves in parallel
with your managed code, it's a pain.

Bart Jacobs