Neil,

>Rewriting VFP (or any application for that matter) would not by default speed up VFP. If you develop a bad alogirthm then irrespective of the development language your code will be slow. It doesn't hurt to use assembly language for critical sections of code (example would be memory copies) but modern compilers do a damn good job (some better than others) of generating code.

Right! I'm sure the new compilers do a VERY GOOD job. Other than getting someone with Steve Gibson's expertise to do the final bit of tweaking I simply cannot get to the point in my mind to where I think doing anything different than that which is already being accomplished will do any good whatsoever.

David had suggested in cedeing to developers the concept that they could pick & choose the features they would include in a 'build'. While I think that's a great idea the simple fact is that all of the internal components of VFP are SO intertwined as to render this concept useless. Put one messagebox in and you start pulling other features in, each of which will need other, supporting features. Guess what? After two or three features and you end up with the equivilent of the entire current version, as a result of the current tight internal coupling of the various features...

The only two options I could then see were to rewrite the product in assembly and put the data engine where the data was to avoid network traffic.

In the case of the assembly rewrite it made no sense whatsoever to spend those kinds of development dollars and not spread the benefits around to every other MSFT product that could take advantage of them. That means that we atomize the product to its functional componenets; menus, reports, serial, parallel, screens, data management, etc. Well, in that case why not make the report generator/write work for ALL Microsoft products? That way you spread the development costs around as well. (I'll bet this is where we end up btw).

In the case of placing the data engine where the data is, I like this, only using the current product as a COM/COM+ server. Why rewrite the product for this??? SQL 7.0 and Terminal Services cover the other options, right?

>
>A good example of this is the games development world, most games and their support tools are written in C/C++ with critical sections being optimised assembly language.

Right. So one can optimize performance via assembly but I'd bet that the numbers of developers that were really any good at it are very far and few. So... We end up writing a C/C++ product that, by virtue of economies of scale, gives us almost assembly-like performance. IOW, we're right back where we started from...

>
>Good assembly language resources can be found at http://webster.cs.ucr.edu/ or try reading some of the graphics stuff by Micheal Abrash (Quake god!)

Thanks for the link.


Best,

DD