After countless hours of research, I found Microsoft hadn't documented this format. Unlike BMP, WAV, AVI, and other common formats, no official specification papers exist for this format in the public domain. I've come to believe it is one of Microsoft's "trade secrets", much like Pepsi's and Cocacola's formulas for their sodas are "trade secrets". My curiosity with respect to FRX files originated with the fact that someone on a forum once mentioned that they use the same format that PropertyBag objects use (and which is returned in a byte array when you get Contents property of the PropertyBag object). I realized that with the PropertyBag's ability to store ANY input, I could even get the actual byte data of a StdPicture object through the use of a PropertyBag. This would allow for very rapid setting and getting of pixel data, MUCH FASTER than PSet and Point, and provides an interesting alternative to API calls such as GetPixel, SetPixel, GetDIBits, SetDIBits, etc. In fact the only API call needed to transfer bytes or groups of bytes to and from a byte array is the CopyMemory API call. Thus I started researching this format on the net, hoping some reverse engineer or hacker had managed to figure out the format and posted it up on their website. But I had no such luck.
To avoid the legal problems of becoming a hacker myself (such as attempting to reverse engineer VB6.exe itself, with software such as PE Explorer, which would violate MS's license agreement), I took the more indirect approach, that I believe is legal, as it involved reverse engineering the file format, without reverse engineering the software itself.
This technique involved putting 1 or more properties into a PropertyBag, and of different data types (Byte, Integer, String, etc), and with different property names (such as "a", "aa". "ab", "ba", "b", etc) using the WriteProperty method, and then seeing what I got out of it with by storing the PropertyBag's Contents property in a byte array, and looking at the bytes (this is the "raw data" of the PropertyBag, meaning this is actual PropertyBag format). After several hours of this reverse engineering technique, I finally managed to write a complete (I think) documentation on the PropertyBag format (same format as used in FRX files from what I've heard). Albeit unofficial, it seems to hold correct for every input I give to the PropertyBag object, when checking the resulting output via its Contents property.
Attached to this thread is the text file I wrote, containing all the specs on this (previously undocumented) format.
To avoid the legal problems of becoming a hacker myself (such as attempting to reverse engineer VB6.exe itself, with software such as PE Explorer, which would violate MS's license agreement), I took the more indirect approach, that I believe is legal, as it involved reverse engineering the file format, without reverse engineering the software itself.
This technique involved putting 1 or more properties into a PropertyBag, and of different data types (Byte, Integer, String, etc), and with different property names (such as "a", "aa". "ab", "ba", "b", etc) using the WriteProperty method, and then seeing what I got out of it with by storing the PropertyBag's Contents property in a byte array, and looking at the bytes (this is the "raw data" of the PropertyBag, meaning this is actual PropertyBag format). After several hours of this reverse engineering technique, I finally managed to write a complete (I think) documentation on the PropertyBag format (same format as used in FRX files from what I've heard). Albeit unofficial, it seems to hold correct for every input I give to the PropertyBag object, when checking the resulting output via its Contents property.
Attached to this thread is the text file I wrote, containing all the specs on this (previously undocumented) format.