>>> I know that public variables are shared amongst all
>>> instances of a COM DLL, so I want to take advantage
>>> of this to pass info back to the calling applications.
>
>This is incorrect. Public variables are are shared amongst all instances of objects in a com dll ONLY IF all those instances are instantiated on the same thread and in the same process. If you have two EXE's loading your DLL, they'll each load their own copy of the DLL, and they won't be sharing public variables or data buffers. Similarly, if two different threads instantiate objects in your DLL, they each have their own thread-local storage, meaning they'll each have their own independent set of public variables, data buffers, and the like. So again, no sharing of data.
>
>One solution is to build your library as a COM EXE instead of a dll, and set instancing to Multi-use (in ProjectInfo - Servers). That way, your COM library will be loaded in its own process space with a single thread, and all your applications will call into it. Each instance may have its own private datasession, but public vars and the default datasession will be shared between instances.
>
>Alternatively, you could add your DLL to a Component Services (MTS) package, and set it to run in a separate process. But you'd have to make it a single-threaded DLL, otherwise you would have apps getting objects on different threads, each with it's own thraad-local storage, therefore each with its own set of public variables and data buffers.

Hi Tom,

It might not be clear from this thread, but we were actually talking about an approach which I showed at my presentation at last DevCon in San Diego, when COM DLLs istantiate a little multi-use COM EXE called Communicator and communicate through its public variables.