Hi Claude,

>They had problems because of CD??

Sure, it's not supported in MTDLLs, but doesn't cause an error. CD causes VFP to overwrite a memory location with the current directory path. If the new path is longer than the previous one (C:\Windows\System32 in most cases), it overrides vital parts in VFP. Part of it is the memory location that holds the SET PATH line. When this happens, every command that accesses a file causes an "Invalid path or file name" error. However, there's no guarantee that this is the only command. This was in VFP 7 and early 2003. Since then, the documentation of CD has been extended by the following sentence:

"The CD and CHDIR commands are not supported in either single or multithreaded DLL servers. These commands change the default directory of the entire process, so all threads which are part of the process are affected. Use the SET PATH command in DLL servers, in place of SET DEFAULT."

> I can't believe any developer expects to take code line by line from a desktop app and expects it to run without modifications of some sort on the web.

They had web applications that were previously written for EXE COM server. The MTDLL and the EXE COM environment are different. We had several problems there. Secondly, for years many leading VFP developers talked about writing business objects without user interface, because this would allow them to re-use the objects in web application. Many customers did so, but obviously they never tested their code in an MTDLL runtime. After all, it's all FoxPro and as long as you avoid UI, you should be safe, shouldn't you? The truth is, the MTDLL runtime differs from the VFP runtime in many aspects. Unless you test the code in both runtimes, you can't guarantee that it works in both.

> What kinds of major problems did they have if you don't mind my asking?

The CD issue was a big problem for many customers, because AFP 2.x changes to the web directory when a requests comes in to make it easier to deal with pathing. Aside from the usual UI related stuff, we had problems with code that relied on timers. They don't fire in an MTDLL. COM automation failed in many cases, because call backs were not working due to the different event processing loop. We had problems where VFP displayed an error dialog instead of raising the TRY...CATCH handler, for example, when a field validation rule is violated. We had problems with customers insisting on the VFP 7 runtime since their code was written for VFP 6, or because there wasn't a service pack 3 for VFP 8. Think of an MTDLL without TRY...CATCH. We had problems with bugs that only come up in an MTDLL under stress, not in a regular EXE. For instance, when calling a function, VFP suddenly drops all but the first two parameters. When your code says oBizObj.Load( "ALFKI", "curCustomer", 3 ) it's confusing if the third parameter is suddenly .F. A lot of third party tools do not work in the MTDLL environment. We had problems with PHDBase and Cryptor, for instance.