>>Joking aside, Fox compiler is doing more than just tokenize the keywords - it lists variables, interprets the #defines, hoops the loops etc. Its object code, IMO, is then just a set of parameters to pass to the runtime, a line at a time. Now this would pretty much be the scope of what any decent p-code should be doing. The definition of 'interpretation' would involve parsing the source code, looking keywords up some tables, finding their codes and routines to call, parsing the parameters and passing them to these routines etc. FXP has all of these done already, and the runtime is not doing any of these (except when you use macros, eval(), dynamic properties in grids, and Compile command). Ergo, p-code is compiled code. It doesn't need further interpretation and transformation into another form to be run; it's ready to go, just pass it to the runtime.<<

FoxPro (among others) has, in effect, decoupled the first 2 stages (scanning and parsing) from the third stage (excution) and stores the output/intermediate code/p-code on a medium external to the process for subsequent execution in order to avoid having to repeat the first 2 stages when it isn't necessary. If this simple evolution has now made the term "interpreting" not applicable, then I disagree.

>You can think of it this way, since VFP .exe will find the runtime, and pass it the p-code. Though, nothing is run directly on the processor nowadays; it all goes through several circles of he... operating system.

Nothing runs directly on the processor ?

Sorry, but, ALL machine code "runs on the processor(s)". The OS performs the loading and satisfies "operating system calls" for I/O etc.; but at some point, all "native compiled" programs get a slice of the processor(s).

As long as there are native compilers like C, Delphi, Fortran, etc., there will be programs that (for the most part) run directly on the processor.

>The only compiled code, then, would be C without any dlls, or just plain assembly code. And you wouldn't be able to run it directly on the processor, because the OS would recognize it and fly a few circles around it before allowing it to commence.

?

Many DLLs are compiled to native (machine) code. Their functions can be statically are dynamically linked. When these function execute, they execute directly on the processor. Even a VFP FLL written in C will run directly on the processor, even when it is making VFP API calls, since the API is another set of DLL functions.

I thing the concept of the OS being a "shell" is being taken far to literally; at some point the OS hands off control where the "machine code" in the program is executing directly on the processor. It's only when the program ends, there's a system interrupt, or the program specifically asks the OS the perform a "protected/privilaged" service that the OS regains control and starts it's own "execution".

You can debate degrees here (of "time-slicing"); ie. self-loading programs that work directly with the BIOS, single or multi-tasking operating systems, standard or virtual memory ... but ALL "machine code" executes "directly" on the processor.

We may be making great strides in the art (?), but there are certain basic concepts that have not changed.