When I first started programming in VDF, we were running VDF7. I came from a C/Delphi background in terms of Windows programming,
while I had some experience with VB and Java as well. Looking at VDF7 at that time was fascinating because VDF didn't produce
native executable. It produced something called "VD7". In order to run your VDF program, you have to run "DFRun.exe MyProgram.VD7"
In a sense, VDF produced something similar to "Byte Code" in Java or Intermediate Language in the .NET world. If you examine
the DFRun.exe closely, it's only 28kb in size. The bulk of the runtime resides inside DFRun7.dll. Moving on up, we have VDF9. It
was a big change for VDF because VDF would then compile directly to "Native" EXE. No more DFRun.exe, no more VD7 file. It was a
rather big change because turning Byte Code into Native Code is VERY difficult. It's a major architectural change to the runtime
library of VDF. However, upon closer examination, the excitment evaporated rather quickly.
The ".text" section represents the actual executable code in an EXE. ".rdata" represents "Read Only Data" section. If you examine
every VDF EXE, you will notice that the size of ".text" section is always going to be 289 bytes. With the information at hands, we
can safely deduce that VDF still produces Byte Code, but the Byte Code is now embedded into the Read Only Data section of a native
executable. The ".text" section of the code merely loads the ".rdata" section in memory, and hands the memory off to VDFVMXX.dll to
"interpret" the Byte Code.
