David,

>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.

That's easy to say when you're not paying for it. <g>

Disabling a command isn't the same as removing it or never inserting it to begin with. Additionally, I stand by my assertion that to remove a few commands from VFP will essentially do nothing whatsoever to bloat or speed. You'd have to take a meat axe to it and there would IMO be no end of change or enhancement requests to MSFT. "Please allow us to take this out, put that it. No, not that way, this way. No, not this way, that way ad nauseum." That would drive support costs through the roof IMO and would be the quickest way to kill the product.

>
>>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.

Right. That's my point too, only from the point of view that even if you disable 75% of the commands you'd like to have inserted in your finished product you'd still need most of that 75% put back in because the compiler doesn't know what is dependent on what internally or not and neither do 99.8% of all VFP developers. Please do not misunderstand. I like the idea. I just do not think it would work because of the way FoxPro is designed and built internally.

>
>>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.

We can do this now as I had mentioned with VB & Delphi, for example. Make a VFP COM object that does your macro substitutions and bolt a VB/Delphi EXE on the front end.

>
>>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?

Yes.. There was no other way to make it work in the real world because of the nature of compilers vs interpreters. You had to declare everything up front. It wasn't a bad idea, rally. It forced developers to be disciplined and that IMO is what killed it. Developers were more interested in having their own way than having a fast product. Force was/is a VERY FAST product.

>
>>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.

Right. So why bother changing VFP then? <g> That's my point.

>
>>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?

Ok.. One more time... <g>

Speed. Location of actual command interpreting engine vs location of the data.

Put ths 'engine' on its own server, like SQL, only VFP. The data and the engine are on the same box serving the UIs of those who connect to it. Move the actual processing from the desktop to the server not to take away the processing speed of the desktop but to reduce the network traffic and as such possibly gain a performance boost.

However, since we can now do this, even though we still have that pesky macro substitition I'd say it's NBD. To remove what you want though is IMO an unworkable solution since it requires a re-engineering of the product with potentially no impact on performance whatsoever.


Besides, I know of several instances where a 100MB NIC is faster than memory access. <g>

Just can't win. *bg*

Best,

DD