.frx file format

[ravi15481]

hi friends,

Does anyone know what is the format the binary header and length of the binary file is stored in the .frx file. or any referece to understand the .frx file thoroughly. i wanna create my own binary file.

thanx in advance

[CVMichael]

If your making your own binary file, then you don't need to know how others work...

Make your own header(s), and your own data structue... it's all up to you...

The .frx file that VB is using, is used to store the pictures, icons, etc from your form, so any form that has pictures in it, you will also find a .frx file with it.

If you want to make your own binary file, why would you need to know how .frx works ?

[Shawn N]

Extract images from a VB project files

[ravi15481]

i want to create a .frx file that can be understood by vb. actually what i am doing is i wanna set an image to a picture box without opening the project i will just create my own .frx file for that image and set that .frx file in the .frm file(opened through notpad). all this i am doing b'coz i am compiling the project file from net.

thankx for ur quick response.

Please guys help me out, i need ur help very much

thanx

[Ben321]

Unfortunately the FRX file format is an undocumented and proprietary format. At least I ASSUME it is, because there is NOT ONE SHRED OF DOCUMENTATION on the internet about this file format's header, etc, that is needed to specify how an FRX file is structured internally. Trust me, I've been looking for it too, because I've been looking to write my own software in VB6 that can read data from an FRX file, just for curiosity's sake.

And that means MS has been trying VERY HARD to hide the specs on this file format, because it's now 2012, and the last post on here before me was from 2002. And in the day we live in where if anyone managed to figure it out, it WOULD BE on the internet, posted by whoever managed to reverse engineer it, yet we have not even a tiny bit of documentation on this file format ANYWHERE, it goes to show just how well MS has been making it VERY HARD to reverse engineer (and probably suing anyone into bankrupsy if anyone so much as TRIES to reverse engineer it). In effect it is one of MS's trade secrets I believe.

[techgnome]

The frx file is just a series of binary data. The information on what and where is in the frm file. Its the frm that determined where in the frx it needs to find stuff. So if you are going to replace stuff... you will need to read the frm find the object whose image you want to replace... get the address and the size... then go to the frx remove the segment, move everything up.... update the frm.... add your new bits to the frx and then update the frm again.

-tg

[Ben321]

The frx file is just a series of binary data. The information on what and where is in the frm file. Its the frm that determined where in the frx it needs to find stuff. So if you are going to replace stuff... you will need to read the frm find the object whose image you want to replace... get the address and the size... then go to the frx remove the segment, move everything up.... update the frm.... add your new bits to the frx and then update the frm again.

-tg

What is the header structure of the FRX file though? I already know the head structure of BMP graphics files and the WAV sound files that Windows uses. But what is the header structure of the FRX file?

[jmsrickland]

What data is in the .FRX file other than image and sound data?

[jmsrickland]

What is the header structure of the FRX file though? I already know the head structure of BMP graphics files and the WAV sound files that Windows uses. But what is the header structure of the FRX file?

I had no idea about a .FRX file. However, from just playing around I found this:

I have a Form with two picture boxes, Picture1 and Picture2. Picture1 was loaded with a .bmp and Picture2 was loaded with a .gif.

Now, I looked at the Form.frm file and I found this:

   Begin VB.PictureBox Picture2 
      Height          =   1335
      Left            =   3165
      Picture         =   "Form1.frx":0000
      ScaleHeight     =   1275
      ScaleWidth      =   1395
      TabIndex        =   2
      Top             =   1755
      Width           =   1455
   End
   Begin VB.PictureBox Picture1 
      Height          =   915
      Left            =   1650
      Picture         =   "Form1.frx":08CA
      ScaleHeight     =   855
      ScaleWidth      =   1215
      TabIndex        =   1
      Top             =   1335
      Width           =   1275
   End

Those numbers in red are the offsets in the .FRX file for those two images.

So, I open Form1.frx and I find this:

At offset 0000:
C6 08 00 00 6C 74 00 00 BE 08 00 00 GIF8

At offset 08CA:
26 27 04 00 6C 74 00 00 1E 27 04 00 BM

The header appears to be 12-bytes followed by the actual image data

Ok, so what does this header info mean?

Well, knowing a little about computer numbers I knew something about number being in some sort of reverse order (I think it's called Little Indian or Big Indian, IDK which is which) and I also knew that somewhere in this string of mumble jumbo hex there had to be the size of the image data. So I right mouse clicked on the two image files on the disk at looked at their properties to get the data size.

The .gif file has a sise of 2,738 and the .bmp has a size of 272,158

So I converted these sizes to hex and I get this:

2,738 = &H08BE and 272,158 = &H04271E

If you reverse the digits in the header on every 4-bytes you get this:

C6 08 00 00 | 6C 74 00 00 | BE 08 00 00 | GIF8

00 00 08 C6 | 00 00 74 6C | 00 00 08 BE

and

26 27 04 00 | 6C 74 00 00 | 1E 27 04 00 | BM

00 04 27 26 | 00 00 74 6C | 00 04 27 1E

Looking at the above reversed digits I notice that the last 4-bytes is the size of the image (in red) and the first 4-bytes is the size + 8. I have no idea what the second 4-bytes mean.

[jmsrickland]

Continue from above post

I added a text box to the Form and added some text to it at design time. I looked at the .FRX file again and it showed this:

3C <-------------------- the text I added to text box ---------------->

The 3C = 60 = total number of characters in the text including vbCrLf's.

Here it appears that only the length of the data is in the header and not the other stuff you saw with a picture box.

I then added some more text to the text box and now the .FRX file showed this:

FF 0B 01 <----------------------- data ------------------------------>

Switching 0B 01 around to 01 0B = 267 = total characters in text ------------------->

I don't know what the FF means

Looking at the .FRM file it now shows this:

   Begin VB.TextBox Text1 
      Height          =   3675
      Left            =   5280
      MultiLine       =   -1  'True
      TabIndex        =   3
      Text            =   "Form1.frx":0000
      Top             =   165
      Width           =   2790
   End
   Begin VB.PictureBox Picture2 
      Height          =   1335
      Left            =   3165
      Picture         =   "Form1.frx":010E
      ScaleHeight     =   1275
      ScaleWidth      =   1395
      TabIndex        =   2
      Top             =   1755
      Width           =   1455
   End
   Begin VB.PictureBox Picture1 
      Height          =   915
      Left            =   1650
      Picture         =   "Form1.frx":09D8
      ScaleHeight     =   855
      ScaleWidth      =   1215
      TabIndex        =   1
      Top             =   1335
      Width           =   1275
   End

Note that VB added the text box info on top of the picture boxes info and also changed the offsets to the picture boxes to their new locations.

It appears that the .FRX file has no consistency to the format. It just depend on what is in the file.

One thing for sure is that you will have to look at the .FRM file to get the offset of what you are looking for in the .FRX file.

[Doogle]

what i am doing is i wanna set an image to a picture box without opening the project i will just create my own .frx file for that image and set that .frx file in the .frm file(opened through notpad). all this i am doing b'coz i am compiling the project file from net.

Why?

[Ben321]

I want to know the overall format of the FRX file so I can create my own software that can create images, but it has bigger implications than that. There is also the fact that PropertyBag objects store data in this same format, and with these I can convert StdPicture into something that shows the actual bytes of the image. This allows editing the actual bytes of the image so that I can edit pictures faster than I could with PSet and Point. But first I must reverse engineer the general format used by the FRX file (and thus the format used by the PropertyBag object).

[DataMiser]

Why even bother with the frx file it is only useful in the designer which will create it for you. It is not included with your exe and is not something your end users would be making changes to. If you want to edit images then why not either use an existign image format or create your own. I can't see where there would be any reason to bother with the frx in such a way.

[jmsrickland]

DM is correct Ben, you can't use the .frx to do what you want. It could serve you no purpose at all. Besides, the images stored in the .frx file are nothing more than the actual file format of the image itself. You might as well open a .bmp, .gif, .jpg, or any othe file and parse the data yourself. It's the same thing that is in the .frx file. .Bmp files are straight forward; that is they contain the pixel data on a pixel by pixel basis, they are uncompressed image data. Not so with gif and jpg files as the image data is compressed and you would need to understand LZW compression to be able to reproduce the image let alone edit it.

[Ben321]

DM is correct Ben, you can't use the .frx to do what you want. It could serve you no purpose at all. Besides, the images stored in the .frx file are nothing more than the actual file format of the image itself.

Actually that's not quite true. You see, the FRX file is stored in the same format that you get when using PropertyBag.Contents to get the contents of a PropertyBag. The PropertyBag has a header itself, and each property it stores has a general property header before the actual data. The actual data can start with its own header if it is a String or an Object for example. Since an StdPicture is an object it first starts with an object header, before it even gets to the image header (which starts with BM, the same as the start of a BMP file header). So you are VERY WRONG to say that it simply stores the desired data. No it doesn't simply store the desired data, it stores TONS OF METADATA too! And you have to sift through that to find what you are looking for. That's why I hoped there was an official specification, but if there is it is not available to the public. It must be a Microsoft "company secret" (sort of like Pepsi's formula is for their soda). However I've managed to reverse engineer the PropertyBag format that is used both in the Contents of a PropertyBag, and the FRX file.

After much experimenting with a PropertyBag object, by putting in different things to a property bag with WriteProperty method, and then getting the data back out into a byte array with the Contents property and analyzing the results, I managed to create my own (obviously unofficial) "documentation" for the PropertyBag format. I'll create a new thread just for that topic alone, as it pretty much deserves its own topic. And by the way having access to the raw bytes of StdPicture objects (via the use of PropertyBags) allows byte editing of images, which is A LOT FASTER than PSet is for editing pixels. That is in fact what started me on my quest to find the FRX object, when someone on another forum said that PropertyBags actually use the same format as FRX files but didn't bother to explain that format. I've had to research it, and when research failed to get me answers, I had to reverse engineer the file format myself.

[DataMiser]

Seems like a watse of time to me but ..... good luck.

[si_the_geek]

Same here...

If your reason for doing it is speed of image manipulation, I recommend that you use DIB Sections. There are many good tutorials/examples (such as at vbAccelerator), and the speed is not only very good, but it also has decent room for algorithm-specific optimisation (I've had improvements of over 30%).

For some things you may find that Windows-based image manipulations (such as those via WIA) are the best option.

[techgnome]

I question it only because any changes done to it affect the form at design time... not at run-time... so why not just edit the image in a proper image editor and then re-load the image in VB... but hey... what ever... clearly you know better than the rest of us.

-tg

[jmsrickland]

Actually that's not quite true. You see, the FRX file is stored in the same format that you get when using PropertyBag.Contents to get the contents of a PropertyBag. The PropertyBag has a header itself, and each property it stores has a general property header before the actual data. The actual data can start with its own header if it is a String or an Object for example. Since an StdPicture is an object it first starts with an object header, before it even gets to the image header (which starts with BM, the same as the start of a BMP file header). So you are VERY WRONG to say that it simply stores the desired data. No it doesn't simply store the desired data, it stores TONS OF METADATA too! And you have to sift through that to find what you are looking for. That's why I hoped there was an official specification, but if there is it is not available to the public. It must be a Microsoft "company secret" (sort of like Pepsi's formula is for their soda). However I've managed to reverse engineer the PropertyBag format that is used both in the Contents of a PropertyBag, and the FRX file.

After much experimenting with a PropertyBag object, by putting in different things to a property bag with WriteProperty method, and then getting the data back out into a byte array with the Contents property and analyzing the results, I managed to create my own (obviously unofficial) "documentation" for the PropertyBag format. I'll create a new thread just for that topic alone, as it pretty much deserves its own topic. And by the way having access to the raw bytes of StdPicture objects (via the use of PropertyBags) allows byte editing of images, which is A LOT FASTER than PSet is for editing pixels. That is in fact what started me on my quest to find the FRX object, when someone on another forum said that PropertyBags actually use the same format as FRX files but didn't bother to explain that format. I've had to research it, and when research failed to get me answers, I had to reverse engineer the file format myself.

I never said it didn't store other items. I said it stored an image in the same format as the actual image file format.
If you looked inside of a .BMP file for image X you will see exactly the same thing in the .FRX file for image X plus 12-bytes of data that preceed the image data. The image stored in the .FRX file is not in a StdPicture format. Go back and look at my post #9. It tells you how an image is stored in the .FRX file. As far as other items in the .FRX file I wasn't referring to them; only image data.