>1.) String processing which should be equivalent or better than PHP. So to sum up: VFP is a big bump up from PHP because it is technically better on windows than PHP and does data far better and should be equal or better as far as things like string processing and built in commands. Plus, again, it's real easy especially if you already know it.
>
>2.) Absolutely, multi-threading is multi-threading - multiple simultaneous threads working at the same time. Of course MTA is technically better but, for 95% of web sites you would never see the difference! (and, I might add, PHP isn't even multi-threaded at all, won't even take advantage of multi-cores, yet still is #1 in web apps!)

Aren't you misunderstanding the issue here? It is the web server (whether it be Apache or IIS) that launches the thread and in the case of PHP the thread is irrelevant. The problems arise when any components used to handle the thread request are not themselves threadsafe. In the case of a VFP COM component I don't think you can do achieve that without instantiating a separate instance of the runtimes for each thread. That doesn't scale well.....

>>1) If there isn't any data involved, then where is the benefit to using VFP in comparison to other tools ?
>>2) Are you really stating that the STA model is equivalent to a true multi-threaded MTA component?
>
>>(Added (1) and (2) -- Edited for clarity to show which comment I was responding to)
>
>>PHP is 32-bit, has no problem being marketed, and is actually kicking Microsoft's a$$ in web applications. This is beyond dispute!! If I want 64-bit with Foxpro I can always go to a 64-bit SQL backend where 64-bit actually makes a difference. 32 bit applications (no data) are actually faster than 64 bit or didn't you know that?? (1) And VFP mtdlls are indeed multi-threaded dlls and support full multi-threading and multi-cores.(2)