>>>Thirdly, because of macro substitution, if VFP did produce a native compiler, it would have to include the entire run-time library.
>>
>>George, et al,
>>
>>Years ago there was a product named FORCE that was a native compiler. It forced (no pun intended but I'll take it *g*) developers to make declarations and so forth and when compiled ran like a bat out of, well, you know where. This was in the early 286-386 days. Great product but it never caught on with xBase programmers because of the ability of p-code to do those pesky macro substitutions. Great product, no market. Our pals in Canada who wrote CodeBase have kept their product up to date - to their credit - but I'd sure like to see what percentage of their overall business is from FoxPro programmers who need the kind of product you'd get from a CodeBase.
>>
>>Turns out that there's a pretty strong market for p-code.
>>
>>Not only that, and this might start a whole new thread, but having the ability of the p-code functionality IMO goes a *LONG* way towards developing what I would consider the almost-perfect application. That would be the one where all application information is contained in tables and the engine just loads and executes. Hard to do w/o macro substitution.
>>
>Hi Doug,
>
>Interesting points. Let me throw a couple of more out for general consumption.
>
>1. The term "stand-alone executable" is, under Windows, a total misnomer. No application truly "stands alone" because it is heavily reliant on the OS to provide it with services. Under DOS this wasn't the case. The best analogy I've heard in comparing the two comes from Ivor Horton (the author of several computer related books). To paraphrase him, "Under DOS, your application was the dog and the operating system the tail. The OS wagged when told to. Under Windows, your application is the tail, and it wags when Windows (the OS/dog) tells it to." In my opinion, the reliance on Windows for services does take some of the edge that native code compilers had.
>
>2. Performance related issues are hard to pin down (and getting harder). So many things other than the raw clock speed of the CPU can significantly impact it. These things range from the amount of available RAM, size and availability of the swap file, bus speed, video RAM, etc., etc. And all can have a positive or negative impact on performance.

George,

As Ned Flanders would say, "Iter-ding-dang-diddly-esting" *G*.

If you take those points and projects them out it seems we're all heading for a Unix-type solution where the O/S does the heavy lifting but without all the extra garbage collection. Two things:

1. I have used an old O/S by the name of Oasis (now THEOS if they still exist at all - The O/S) that ran 10 users on a Z80!!; at the same time!!; all using the same data!!!! THEOS "upped" the ante on the 2/386 platform and if they're still around I cannot help but think they're still doing facinating and wonderful things. It was a very cool O/S in that it had NATIVE support for five (5) different types of data; random, sequential, keyed and a couple of others I don't remember. Auto data file size increases; the whole works - On a 286! IMO what Windws _should_ have been.

2. Can't MSFT figure out some way to make their O/S more stable and faster? Unix systems, when properly set up, hardly *ever* fail or need some stupid reboot. Jeeze, I've hardly ever worked with Unix but that is a _compelling_ set of (two *G*) features. Reliability and speed. Not to bash MSFT but I sure wish they'd have as a part of their internship programs the requirement to manage a real-life scenarios.

I can still bring an NT server to its knees by doing some kind of heavy duty processing on it.

Hopefully when the 64 bit chips arrive they will be able to handle all the processing thrown at them and

You're absolutely correct to point out the fuzzy nature of today's programs though. I must confess to being *quite* attracted to the n-tier world. Makes lots of good common sense to me.

Best,