Thanks for this, Rick.

Yes, I will be doing some reading. Someone (Craig B., I think) suggested "Distributed Applications with VB 6" and I plan to start there.

regards,

Jim N

>
>I think it would pay if you spent the time reading a book on this...
>
>
>>How does the "in essence multiple copies of your server..." square with "they share a runtime,..." below? Here's how I interpret that: The server ('your server' in the statement) is actually reentrant, so the 'sharing' of the runtime (same thing as 'your server'???) means that even though multiples are processing, it is only the data (and GetMained) parts of the 'server' that take up *additional* resource.
>
>The runtime is just a binary. The actual memory space is what's important here.
>COM moves these off to separate protected areas on separate threads.
>
>How exactly the VFP runtime manages this I don't know. My guess is that behind
>the scenes the VFP runtime runs multiple instances behind the scenes (it used
>to do this explicitly with foxr1.dll, foxr2.dll etc). But what's really duplicated there isn't all the code, but the memory footprint (about 600k or so). The binary footprint is reused... If you look at a process monitor you'll
>see only one copy of foxrt.dll in memory even with 10 objects loaded.
>
>You can do the same with a C++ component. Even if the object is not thread safe
>COM will be able to run the thing concurrently. This is due COM's partitioning
>of threads into 'apartments' that localize the object's data.
>
>COM performs the magic of thread isolation - VFP just conforms to the model
>and provides the memory protection and COM does the rest. If