>I was wondering is someone would mention this...I recently learned in a "What's new in VFP 6.0" training class that VFP 6.0 now does use apartment model threading and saw a COM server (EXE) used as a multi-threaded application supporting data requirement for a web form. One great advance is the the VFP EXE COM servers can now be registered remotely with CliReg32.EXE. Using FoxISAPI.DLL an EXE COM server was pooled into three instances (not a limit, BTW) and process three running instances of web pages requesting data.
>

The FoxISAPI pool is an internal pool that simulates multi-threading with
Out of Process Components. It's a very similar pool manager that also runs
in Web Connection (which includes many additional maintainence functionality
that FoxISAPI doesn't have). This set up has worked since server were
introduced to VFP and continues to be the most scalable way for Fox
Web applications.

CliReg32 has nothing to do with remote registration. It's simply
registration utility you run to register a type library rather than
the server. On the client machine you don't need to the server, but
you do need the type library so the server doesn't have to go looking
up the IDispatch interfaces on the server for additional round trips
for each method/property call.

>BTW, it took about 4 megs of sever memory to load the first instance of the pooled EXE COM server, and about 2.5 megs each for the other two.

Actually, that'll vary, but what you see in Task Manager is not accurate.
The truth is that it's probably much less as multiple instances of
the runtime use a single copy of the runtime - Taskman just can't tell
the difference. Of course it depends on what your servers are doing -
if you use memory and run queries that consume it the footprint will
get bigger. In my typical Web apps servers settle at around 10megs
given a machine with plenty of memory. Seems a lot, but is quite
alright for the load thrown at them.