>>>But one thread per apartment is a single threaded apartment....aren't we discussing MTDLLs where there are multiple threads per apartment all accessing the same address space.
>
>No, that's the point: VFP uses STA rather than free-threaded. IIS does create a STA and loads COM into it for multithreading whereas VFP itself and other clients including NET can't do it for COM without help. In addition to the previously referenced article, see this one: http://foxpert.com/docs/com_intro.en.htm

OK :-{
Have I got it right this time:
If you compile your VFP server using the 'Single-threaded COM server' option it will use the (non-threadsafe) VFP7RENU.DLL. In this case additional copies of the runtime have to be loaded for each use.
If you compile your VFP server using the 'Multi-threaded COM server' option it will use the threadsafe (VFP7T.DLL) runtime. In this case the same copy will be used but this means the requests have to be queued to be serviced by the same instance.

Still doesn't seem that either option is particularly satisfactory - and we're back to what I said before (but for the wrong reasons):
One way you eat RAM and time by loading additional copies of the DLL
The other way you have to queue the requests and get no paralleling benefit.

Should this then be regarded as a shortcoming of COM servers in general?
And what happens with the MTDLL option in a multicore environment ? (I've no idea - just looking for an answer)