Some things must be understood regarding VCOFF and the image load/save process.
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
The V.EXE consists of various sections, which are common to all Windows executeables. If a Smalltalk image is being saved the first time, the V.EXE will be rebuild and a section named “.vimage” will be appended. During further saves the “.vimage” section will be updated.
The VM and VCOFF SLL parse the COFF/PE exe header to find a section named “.vimage”, which contains the snapshop of the image.
Bug #1 (applies to the VM and all VCOFF versions)
VCOFF-SLL and the VM use a hardcoded offset where they expect the PE-Header (0x84).
The Coff/PE documentation tells, that the PE header offset can be found at offset 0x3C in the EXE file.
Bug #2 (applies to VCOFF3AW.SLL)
When reading the PE header the code in the SLL ignores various settings in the PE header and writes hard coded values for ntSubsystemMajor, ntSubsystemMinor, osMajor, osMinor which may cause strange visual effects, because Windows emulates behavior of older Windows versions depending on this information. So it is impossible to patch the V.EXE once, because the next save image will overwrite this values.
Bug #3 (applies to SessionModel – buildExe code)
When the image is being saved, the V.EXE is being examined, if it already contains a “.vimage” section. This is done, by comparing the file size with a hard coded value. (the size of the V.EXE, at release date).
The correct solution would be to check the section table for a section with the corresponding name.
Bug #4 (applies to all VCOFF versions)
If a section has the size zero, (like the ‘.BSS’ section in Digitalks V.EXE) the section size was reported as zero. But the image loader reserves a memory page for all sections, even if the size is zero.
The code that calculates the size for a section must at least return a minimum size of “section alignment”.
Bug #5 (applies to all VCOFF versions)
The code that calculates the value for the PE header field “SizeOfImage” adds the section alignment twice. This seems to be a workaround for bug #4. If the header field “SizeOfImage” is not valid, the image loader will report an an error “V.EXE is not a valid Win32 application”.