Doug,

My last try to explain...

>Disabling a command isn't the same as removing it or never inserting it to begin with.

Disabling it (like MTDLL does) *is* what I'm talking about.

>Additionally, I stand by my assertion that to remove a few commands from VFP will essentially do nothing whatsoever to bloat or speed.

My suggestion was not about bloat or speed. It was to make it possible to pre-process code into C++ code.

>You'd have to take a meat axe to it and there would IMO be no end of change or enhancement requests to MSFT.

I haven't heard many complaints about the feature set of MTDLL's, except lack of printing capability. I don't think MS has been swamped with conflicting enhancement requests about it.

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

Here again, I'm *not* talking about us developers deciding which commands should be disabled for each project we do. The VFP team would decide what to disable, as they did with MTDLL. I think they can figure out what's dependent on what, as they did with MTDLL.

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

Could be. I've never seen the source code for VFP.

>>Pretty much a description of Windows DNA n-tier distributed architecture.
>Right. So why bother changing VFP then? <g> That's my point.

But you *are* arguing for changing VFP (see next paragraph).

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

How do the UI's connect to it? DCOM?

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

Move *what* processing from the desktop to the server? Responses to UI actions like mouse clicks, keystrokes, etc? Or are you talking about the business logic being moved to the server? That's of course what n-tier design is all about.

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

To remove what I want is not what I'm talking about. I'm done...