Re: [Boost-users] Support for VS 2005 C++/CLI

From: Nat Goodspeed (ngoodspeed_at_[hidden])
Date: 2006-10-20 09:13:21

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of John Dunn
> Sent: Thursday, October 19, 2006 3:23 PM
> To: 'boost-users_at_[hidden]'
> Subject: Re: [Boost-users] Support for VS 2005 C++/CLI (Peter Dimov)
> 
> Peter Dimov wrote :
> > Did you rebuild the Boost.Thread library with the new SP? You
probably
> > still have a dependency on the old VC runtime in it if you didn't,
> > whereas the application now depends on the new runtime.
> 
> Yes, I did rebuild boost after installing the new SP.

[Nat] I've just run into a very strange behavior when loading DLLs in VS
2005, and I wonder whether your problem might be related.

Our app dynamically loads certain DLLs. I coded a static object in the
DLL whose constructor performs some initialization. The app loads the
DLL and the OS returns control to the requesting app. Surprise! Control
hasn't yet reached the static object's constructor! I'm floored by this
behavior, which seems to me to violate one of the fundamental promises
of the C++ language.

It appears that because this particular DLL contains both unmanaged
(native) and managed (CLR) code, somehow the compiler decided that it
would be okay to defer initializing this static native class object
until CLR initialization -- which only happens the first time control
passes into any managed code in the DLL! Before that time, we've already
called lots of native code in the DLL with this object sitting there
uninitialized.

One is tempted to invoke some managed code from DllMain() to force CLR
initialization as soon as the DLL is loaded -- except that it's flatly
forbidden. The MS runtime throws an exception with a stderr message to
the effect that you may NOT invoke managed code during DllMain(). (I
don't know the technical reason for that restriction. Probably that's
why Microsoft implemented this highly dubious "lazy initialization"
strategy in the first place.)

So far I've thought of no better workaround than to introduce a function
with a canonical name (e.g. "initManaged()") in each such DLL. Our
routine that dynamically loads a DLL will test for the existence of such
a function, and if found, will call it. But I haven't yet implemented
this workaround.

The chilling fact is that it's possible to begin actively using a
newly-loaded VS 2005 DLL containing unconstructed static objects. Will
such a system run any given third-party library? Flip a coin.

I have no idea whether this has any bearing on your problem -- but to
me, it seems to call into question the robustness of the whole VS 2005
C++ implementation.