Thanks for the info.
Yes, mtdlls could require more effort if not supported properly. That's what I've tried to do with ActiveVFP. I think with the current state of ActiveVFP, it's as easy or easier than any other way to implement web applications (especially Version 3 which will be released this weekend as soon as I do the builds).
As far as MT, do you mean because mtdll support is still in AFP, that it is truly multi-threaded? Or are you saying that the regular AFP(VFP EXE) servers running in the background provide a multi-threaded environment for VFP web apps? As you know, multiple exe processes running in the background servicing web requests is not true multi-threading.
>Hi Claude,
>
>>there wasn't much enthusiasm for it in your product anymore.
>
>Our own enthusiasm isn't what counts. <s> What's important to us is what our customers demand. We equally offer a variety of engines and do our best to fix any issue that customers report when using one of them. However, due to the issues our customers discovered with VFP (not AFP) and the performance tests they did, most of them decided not to use the MTDLLs. The gain in resources wasn't worth the additional effort for them.
>
>>As far as regular AFP being truly multi-threaded, is it?
>
>Yes, it is. All internal threads are MTDLLs, the engines are configurable. We default to EXE8 (VFP 8 out-of-process), but our customers can freely choose between MTDLL, MTDLL9, EXE7, EXE8, EXE9 and IDE.