>Could my foxISAPI COM do the housekeeping related to CoCreateInstance issues? Is the overhead required to create references to IIS/OS registry maintenance medthods asking a bit much for a little foxISAPI COM?

You mean from within your code? No, but you have to have the right permissions in order to be able to access the registry and run Admin tasks. The account your app is running under needs to be an Admin account.

If there's a CoCreateInstance() problem in FoxISAPI.Dll there's nothing you can do about it short of fixing the C++ source code.

>foxISAPI "parks" the formvars in an INI. Suspiciously similar to CGI. Maybe all IIS services do it - I [just] pretend the client / server data exchanges are strings. I remember working an XML reciept in a foxISAPI COM and used the "loadXML()" method (merge from string), and it worked.
>
>I guess foxISAPI or IIS just feel better assembling the packets in a disk file. Do they need to? IF they don't, can I turn it off? It's like vCard - a pain - let's make more work for ouselves:)
>
>Is there anything I can do to my COM's VBR, the foxISAPI.INI - or to the foxISAPI.c to improve the performace (86 the INI disk writes and turning off requests to "unneeded" services)?

File messaging should not be slow in low volume environments - but it can become a real bottleneck once load picks up because the file system slows down with more files in a directory.

FoxISAPI works with an INI file and there's no way to change that - its a feature of the ISAPI implementation. It also depends on what you do with the INI file. If you use Profile functions to read data out of it that'll be relatively slow because profile functions open and close a file for each read operation.

And why did you post this in htis section? FoxISAPI is not related to Web Connection in any way...