Like you observed, in DllMain (from dllmodul.cpp) we check if __mixedModuleStartup and we don't call InternalDllMain. We do call it later, after managed initalization, using PostDllMain.
Not sure if you noticed how PostDllMain works: it's a small static object which is initialized in a specific CRT init segment, which happens to be after all static managed objects have been initialized (look into postdllmain.cpp for details).
Why do we do this? Because we assume that your CWinApp is compiled managed. Remeber that static managed objects are initialized after DllMain is called (while static native objects are initialized after before DllMain).
So, if CWinApp is managed, we cannot call InitInstance until after all managed objects have been initialized. That's why we wait to call InternalDllMain.
The problem with your code is that the module is mixed, but CWinApp is native.
If you compile the CWinApp definition with /clr, InitInstance should be called in the right order.
This is somewhat related to loader lock, because you cannot initialize or call managed code during DllMain: that's why we avoid initializing CWinApp during DllMain...
I hope this shed some light on the problem.
I'm sure you'll have more questions/thoughts!
Let us know!
Thx!
Ale Contenti
VC++ Libraries Team
浙公网安备 33010602011771号