Doug,

>>>Then who supports such a beast?
>>Who supports MTDLL?
>Who pays for the support?

My point was that MTDLL is not a "beast" just because dozens of commands were disabled in it. It was designed that way and is supported that way by Microsoft. Same with any other new innovations in the core product. Who pays for the support is irrelevant.

>Ok.. I'm talking about changeing the actual FoxPro engine whereas, if I'm understanding you correctly, you are talking about what happens when you compile a FoxPro application.

Correct.

>Then, if I'm understanding you correctly anything that would require things like macro substitution could be constructed into a COM object where we could retain the older FoxPro behavior.

Correct. Flexibility.

>Many moons ago a product named "Force" attempted to do exactly this and they ran into quite a lot of resistance from the Fox community, probably more because of laziness than anything else... They're still around but really not much of a player though they were exceedingly fast relative to the then version of Fox.

Did they try to "force" people to abandon macro substitution instead of providing multiple options?

>1. SQL as a back end data repository.
>2. VFP-based COM & COM+ middle tier objects that could provide macro substitution processes if needed.
>3. VPF, VB or Other COM/COM+ middle tier objects that provide other non-macro substitution serveces, each built from the best base product.
>4. Desktop UI built from the best base product. I'm thinking Delphi or VB here.

Pretty much a description of Windows DNA n-tier distributed architecture.

>My thought was to re-engineer the actual base Visual FoxPro engine itself. Different issue altogether.

Re-engineer it to do what? We can already construct remote COM objects to do anything you want, and the engine itself is already available as a COM object with VisualFoxpro.Application with .DoCmd and .Eval, isn't it? Can you describe a scenario to explain your idea?