-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of John Dunn Sent: Thursday, October 19, 2006 3:23 PM To: 'boost-users@lists.boost.org' Subject: Re: [Boost-users] Support for VS 2005 C++/CLI (Peter Dimov)

...

Did you rebuild the Boost.Thread library with the new SP? You

Peter Dimov wrote : 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.