David,

Hmm.. I really have no philosophical issues or gripes about splitting things apart whatsoever - if they can bring the desired speed or performance gains - which is what I'm thinking people are looking for. Cripes, I'd rather send all the developers to a seminar put on by Steve Gibson (www.grc.com), if he'd be willing to do one. Steve originally wrote SpinRite and writes ALL his code, including Windows dialog boxes in assemply language!. That's where I'd look before doing anything else. Steve consulted at Stanford University's AI lab in 1970 when he was 15 years old and is one of the original good guys. That and so dang smart it hurts. <g>

I still think that speed is king and man oh man, if we could get a version of VFP written in assembly...

I'd be willing to bet that if Microsoft paid Steve, say 500K to 1MM or whatever the market would bear that he could develop a lot of Windows code generic modules that all their stuff uses and by simply adding these to a C++ wrapper you'd get a LOT more bang for the buck. You could also amortize the expense across several product lines as well.

The problem I see with the splitting of things apart is that you either have to give folks the ability to put anything in the "mix" or nothing. The problem with FoxPro is that all of the internals are so intertwined as to essentially force you to pull the whole thing in, so there's no real gain. Unless I've misunderstood you here I really don't think the approach of adding pieces selectively is viable, again, because everything inside VFP is so tightly intertwined together. Great idea but I don't think it'd work.

The other option I already mentioned would be to put all the code response logic into a COM or COM+ enabled object. Having 5-6MB of code running on a server isn't a real big deal anymore and if the code that actually did the work was on the same central machine that had the data I could see a LOT of performance gains as you have eliminated the wire between your desktop and the server.

Best,

DD


>Doug,
>
>>I'd be willing to bet that a lot of bloat is there. The trick is which to keep and which to get rid of and what kinds of troubles would be caused by making the change?
>
>I can see a new compile options, similar to MTDLL, that limit the language elements to open up new possibilities. For example, how about a compile option specifically for Web Forms-related code which gets compiled to a COM object to run on the server. Why not add a few new features and eliminate a few old ones specifically for that one purpose and end up with code that can be pre-processed into C++ equivalent code.
>
>For instance, get rid of macro expansion and other interpreted issues for the COM server portion of Web Forms, and add strong typing and other necessary language features. This is an over-simplification, but the idea is to have a special set of VFP commands that can be used in a Web Forms code package, that will produce the exact same DLL or EXE that VC++ would have produced. No VFP runtime needed.
>
>For other projects, the full set of backward-compatible stuff would be available.
>
>Seems to me this is the direction things ought to be moving to open up new possibilities for VFP, without sacrificing what we can do now.