Can someone shed some light on the meaning of the reserved1 memo field of vcx/vct class libraries?

[Olaf Doschke]

Today I compared some source code folders and compared file pairs via checksums. This reveals changes in class libraries, which surely did not change for years, but the changes merely seem to be due to recompiling, no essential changes. Inside VCX files I found a difference in bytes 3 and 4 only, which store last update time. That even changes, if you just open a class to read source code. Fine, I can cope with that and skip it for a checksum calculation of VCX files.

The differences in VCT files turn out to be spread all over the file, but I found out the differing bytes are mostly (perhaps all) in reserved1 memo fields. They contain a list of include files (.h), though the main include file for any class is stored in reserved8. The reserved1 field just differs in single bytes and I wonder what these bytes mean. It seems they always start with the same include file as given in reserved8, but then add further include files, which are included indirectly via #INCLUDES in the initial include file. I haven't tested yet, if these memo fields are just filled via compilation or build.

My assumptions aside, if anyone can point me to more than the description of the fpt file structure in the VFP help, please post a link. I am specifically interested in the reserved1 memo field meaning of records with platform="COMMENT", not platform="WINDOWS", for the platform="WINDOWS" records reserved1 is "Class" for the main record of a class or empty otherwise, that's uninteresting. The COMMENT record always is the last record of a class and mainly empty aside of the Objname containing the class name and reserved1 some include file info.

FYI: the file size itself doesn't differ a single byte, but in the general case this is not sufficient even considering the vcx file has only changed in bytes 3 and 4. Also a PACK of both library copies didn't change the situation. Actually quite obviously, as the memo contents stay the same, the differing bytes are not in unused fpt (vct) memo blocks.

Bye, Olaf.

 

[Mike Lewis]

Interesting question, Olaf. As far as I know, Reserved1 only ever contains the word "Class", and only for the first record within each class within the VCX. All the others are empty. I've just checked several of my own VCXs, and don't see anything to contradict that. Then again, I don't use .H files much in VCXs, so don't put too much weight in that. I know this doesn't answer your question, but I thought I'd mention it anyway.

As far as the internal structure of the FPT file, I found this link:

https://msdn.microsoft.com/en-US/library/8599s21w(v=vs.80).aspx

But you probably found that yourself in your research. It shows a memo field as having a 4-byte signature (to disinguish text from "picture"), a 4-byte length, and then the memo itself. Not much help in this case.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

Actually, in the Comment record, Reserved1 contains a string like "VERSION = 3.00"

Tamar

 

[Mike Lewis]

Yes, I noticed that too, but forgot to mention it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[ggreen61]

From my "digging" into the VCX and SCX files for an editor, I found the following:

For a VCX,
[ul]
[li]Reserved1 field in the first record always has Version=3.00[/li]
[li]Reserved1 field with a value "Class" indicates the beginning of the class definition; Reserved2 field contains the number of records following that are included in the class[/li]
[li]Last record of class definition (as given by value in Reserved2 field) the Reserved1 field contains a compiled representation of the include file from the class definition start record[/li]
[li]Reserved8 always stores the relative path to the header file; this is on the row that has field value Reserved1="Class"[/li]
[/ul]
For a SCX,
[ul]
[li]Reserved1 field in the first record always has Version=3.00[/li]
[li]Reserved1 field in the last record has a compiled representation of the include file; my editor stores the header in the Reserved8 field and this is updated in the last record in the Reserved1 field when the COMPILE FORM command is issued.[/li]
[/ul]
There does not seem to be any other use or information stored. I do not know if there would be side-effects if something were stored there or if it would be simply ignored for other records. The documentation for the SCX and VCX file types only gives "reserved" and indicates this field applies to forms and controls.

 

[Olaf Doschke]

I could reproduce a filled reserved1 memo:

1. Create am include file [tt]incl.h[/tt] with the only line [tt]#include foxpro.h[/tt]
2. Create any class (eg a form) and in the class menu set the include file to [tt]incl.h[/tt]
3. Use a constant of [tt]foxpro.h[/tt] inside that class, eg in set somevar = T_CHARACTER

Now build an EXE.

Open up the VCX as table and in the 3rd record you'll find something like this: [tt] - incl.hÆÒA[G ...\Microsoft Visual Foxpro 9\foxpro.hÎÓº‰1[/tt]

So the essential thing is you use some constant defined in the indirectly included file and VFP stores some info here. The binary data in front of, between, and after the include file names seems to vary per compilation, indeed comparing CREATEBINARY(reserved1) before and after a compilation changes just some bytes of the binary data between the file names. Since no path changes between compilations I assume the data is about compilation time and file times. VFP has to know when it needs to recompile. Not only, if your code changes, but also if the include files change, I assume that binary data is about that aspect.

Bye, Olaf.

PS: It might be sufficient to just include foxpro.h directly. Also the explanation VFP uses this to know when it needs to recompile is just an assumption.

 

[Olaf Doschke]

I solved the comparison problem by selecting all records excluding COMMENT records from vcx/vct files, they barely contain anything more than the class name already found in other records. I am now computing a checksum on a translation of all data into one string via CURSORTOXML, still the curiosity of the meaning of the binary part of the memo remains.

Bye, Olaf.