Static classes/constructors that implicitly cause the TAO_Singleton_Manager to
be initialized prevent DLL ORB functionality from functioning properly.  Such
implicit initialization of the TAO_Singleton_Manager can occur, for example,
when registering ORBInitializers via
PortableInterceptor::register_orb_initializer() since that call currently
requires that the TAO_Singleton_Manager be initialized due to the use of the
TAO_ORBInitializer_Registry singleton.

Some time back, when the DLL ORB support was first introduced, no static classes
containing code that implicitly initialize the TAO_Singleton_Manager existed. 
This allowed DLL ORB support to work as expected for quite some time.  However,
with the introduction of ORBInitializers and increased (and encouraged) use of
them, conflicts with the DLL ORB support began to arise, probably in part due to
a lack of understanding of what is required to ensure working DLL ORB support.

Code that uses the DLL ORB support must now take care to avoid including headers
 and linking libraries that cause the static classes in question (e.g. those in
the TAO_PortableServer library) to be instantiated, or at least make sure that
the TAO_Singleton_Manager is explicitly initialized for DLL ORB support a
priori.  Unfortunately, with the proliferation of static classes that cause
implicit initialization of the TAO_Singleton_Manager, working DLL ORB support is
becoming increasingly difficult to maintain.  Workarounds such as the ones
described in the following TAO ChangeLog entry must often be used:

   Fri Jan  2 00:59:33 2004  Ossama Othman  <ossama@dre.vanderbilt.edu>

It is unlikely that static classes will stop being used and introduced, meaning
that an alternative approach to the current DLL ORB support may have to be
developed in the long run.  However, a more immediate solution, as Bala
suggests, may entail making PortableInterceptor::ORBInitializer support pluggable.