>>>The fact that I have been (successfully) running some VFP 6.0 "object modules" in the VFP 7.0 environment lends little credibility to "table offsets" and "run-time library entry points".
>>
>>No, this doesn't prove it. This can happen if the tokens don't change (which is usually the case). The addresses aren't stored in the compiled code, but in the runtime library. Further, long before Fox even existed, I studied how languages and operating system are designed at the assembly language level. My statement is based on first hand knowledge of the area, not an opinion.
>
>The fact that Refox can decompile without requiring access to the "runtime library" contradicts your statement. Even more telling is that FPDOS .FXPs will run in the FPW environment, and vise-versa.

No it doesn't. You posted no evidence to this, just speculation. It only proves that Refox is aware of what the tokens mean. Nothing else. In fact, I took a version of Refox that was produced before VFP 6.0. I took a simple fxp file produced by 6.0 containing nothing that wasn't in the language prior to 2.6 and it worked fine.

You can choose to believe this or not. I really don't care.

>And compilers/interpreters can be written in virtually any language; assembly language is irrelevant to the issue. (Mine were written in C and operated on Pascal).

True.

>>>(You also seem to be implying that FPD was a "machine-code" compiler; false again).
>>
>>FPD did have the option of producing code that did not require the run-time library to be distributed. This was described as "Stand-Alone" in the build options. This is fact.
>
>That was accomplished thru the "Distribution Kit"; an extra cost add-on that was also available for FPW and had nothing to do with "machine code".
>
>The "Distribution Kit" provided an .ESL file (eg. FOXDX260.ESL) that substituted for the development .EXE (with certain features disabled); nothing more.

All I'm saying is that you could, in FPD, build an executable that did not require you to distribute the run-time, just the executable.

>That setup is very similar to what is happening in VFP today, with the exception that one does not now have to pay "extra" for the ability to distribute without the developement environment.
>
>>Again, it's a matter of definition, with mine being more precise. As I said, that doesn't make me wrong or you right or the other way around. You're entitled and so am I.
>
>The fact that no one has stepped forward and come up with a "simple" (known) tag for VFP (ie. It's NOT a "compiler" or an "interpreter"; it's a <...>) I think says it all.

As I said, my definitions of these terms are different (not to mention older).