#7 exe file version information

[Anonymous]

please make editing of the version information (such as file version , fiel description, company name, product name and product version) of the file-to-be-created possible. now the created exe shows properties of the Tcl/Tk version in use.

thank you.

[Dennis R. LaBelle]

Windows versions of freeWrap are now generated without versioning information. There are no plans to include the ability to update that information into freeWrap. This capability is already available from other third party products (e.g., ResourceHacker).

[Jeff Godfrey]

With a modern freewrap (6.64 x64 in my case) is it still possible to update the version info within a wrapped application via ResourceHacker? Poking around in ResHacker, I don't see that info exposed (no "Version Info" group).

Thanks for any insight.

[Jeff Godfrey]

Guh... Never mind, I'm an idiot. I just realized that I simply need to add a new "Version Info" section to the wrapped EXE via Resource Hacker. Problem solved.

[Jeff Godfrey]

OK, I'm looking at this again and still having some problems. As mentioned above, I can add a new "Version Info" resource to my wrapped application. When I do that, all appears to be as expected when viewing the app's properties from within Windows Explorer. However, the app no longer runs. Double-clicking it simply does nothing. So, something must be getting corrupted during the ResHacker update of the application file.

I've also tried using the "verpatch" tool from here:

http://www.codeproject.com/KB/install/VerPatch.aspx?msg=3207401

Which results in exactly the same behavior (valid looking version info, but a no-longer-working application).

Can you suggest a method to update the version info without breaking the wrapped package?

BTW, I am using the 64-bit version of freewrap. Is that possibly related to the issues mentioned above?

[Dennis R. LaBelle]

This is not surprising. FreeWrap is compiled without any embedded version information resources.

Additionally, freeWrap is built by appending a ZIP archive after the end of the executable freeWrap program itself. Your version patching tool may be overwriting part of this ZIP archive and corrupting it. This ZIP archive contains the TCL script portion of the freeWrap application.

You may want to consider compiling freeWrap yourself and including your version information as part of the build process.

[Jeff Godfrey]

Dennis,

Would it be possible to simply "split" the provided FreeWrap.exe into 2 pieces (the EXE and the ZIP), update the version info in the EXE as needed, and then merge the pieces back together again? That seems like it would be fairly straight forward, but there may be more to it that I realize.

Looking at the docs, it seems that "::freewrap::getStubSize" might provide the appropriate split location. Does that make any sense?

[Jeff Godfrey]

Some experimentation (just by hand) makes me think there's more to it than I guessed above. Using the "getStubSize" command, I determined the size of the EXE portion and extracted that to a separate file. I then ran the verpatch tool on the new file to insert the version info. Finally, I added back the remaining portion of the original freewrap file (the portion beyond the "getStubSize" offset - the ZIP archive) to my modified EXE.

This again results in a non-functional file. So, there's either more to it than I had hoped or I made a mistake in my manual test.

Thoughts?

[Jeff Godfrey]

OK, so a bit of code diving shows that the value retrieved by the "getStubSize" command is simply stored statically inside the wrapped "freewrap_init.txt" file. So, at the very least, I assume that value would need to be modified after the insertion of the "Version Info" block into the EXE portion?

I'll quit guessing now and wait on some input... ;^)

Thanks.

[Dennis R. LaBelle]

Yes, to be safe, the freewrap_init.txt file would need to be updated. This isn't so easy since the freewrap_init.txt file is encrypted.

Additionally, you would need to run the following command on the recombined file in order to update file offsets in the ZIP component's file catalogue.

zip -A freewrap.exe

[Jeff Godfrey]

I assume that's the ZIP-3.1c app mentioned in the docs? Is there an EXE available anywhere, or do I need to build it from sources? I was hoping I could use the built-in "freewrap::makeZIP" command instead, but it looks like it doesn't support the ability to modify an arbitrary target file.

[Jeff Godfrey]

I couldn't find any EXE version of ZIP-3.1c on the InfoZip website. I grabbed the source, but I really don't have the toolchain here to build it easily (nor, any remotely current knowledge of it). I've been in the Microsoft / Visual Studio world for too long I guess.

Anyway, hunting around on my dev box, I found a a copy of the 2.31.1897 exe. I know that's not the recommended version, but I thought I'd give a try anyway. The following process seems to have been successful in my limited testing:

1. Get the stub size of the target freewrap.exe file (freewrap::getStubSize).
2. Split a copy of freewrap.exe into the EXE and ZIP portions using the gathered stub size
3. Run the previously mentioned verpatch tool to insert appropriate version information into the EXE file.
4. Merge the (modified) EXE file and the ZIP file back together (freewrap_updated.exe).
5. (At this point, the merged file won't run as a Wish shell when double-clicked)
6. Execute --> "zip -A freewrap_updated.exe"

Now, the modified "freewrap_updated.exe" runs successfully as a Wish shell, and presumably can be used to wrap my application with appropriate version info.

Now, a few questions:

1. The above process obviously doesn't fix the now incorrect result returned from the "getStubSize" command. Assuming my application doesn't use that command (which it doesn't) is this safe or is it potentially problematic for the inner-workings of freewrap?
2. Do you expect any problems from me using an older version of the ZIP application to execute the "zip -A" step? Again, it seems to have been successful.
3. Your original comments to the OP of this thread were:

   There are no plans to include the ability to update that information into freeWrap. This capability is already available from other third party products (e.g., ResourceHacker).

That doesn't really appear to be the case - at least not in a remotely straight forward manner. Based on the above, is there any chance you might reconsider adding this functionality to freewrap itself?

[Dennis R. LaBelle]

The freewrap::makeZIP command can be used. The command supports the -A option and can be applied to arbitrary ZIP files. That is exactly what freeWrap itself does when it builds a wrapped application.

The freewrap::getStubSize command is used by freeWrap::reconnect command. The stub size only matters if you are including and already wrapped application into another wrapped application for the purpose of distribution. In such a case freeWrap stores removes the freewrap "stub" and includes only the wrapped application's source code. The freewrap::connect command is used to reattach the application code to the freeWrap stub and write the file to disk.

Having an incorrect stub size does not appear to be a concern for your usage of freeWrap. However, you should realize that you can't use your technique on the same copy of freeWrap more than once since it relies on the stub size being correct.

Using an older version of the ZIP application for the "zip -A" is fine. However, you could have used the freewrap::makeZIP command.

[Jeff Godfrey]

Thanks for the additional input Dennis.

I guess my confusion with the freewrap::makeZIP command is that the PDF doc lists its signature as:

makeZip [-options] [-b path] [-t mmddyyyy] [-n suffixes] [ZIPfile FileList] [-xi list]

Looking at that, I didn't see how to specify an external file to process. So, I assumed it could only be used to modify the running instance - though that probably doesn't make any sense.

Just typing "freewrap::makeZip" into the freewrap shell, I see this:

wrong # args: should be "freewrap::makeZIP Name_of_ZIP_file [options]".

So, there it's clear that an arbitrary file can be defined. Perhaps the signature should be updated in the PDF?

Also, thanks for your comments on my now-incorrect stubSize. I understand the ramifications and don't expect them to be a problem.

[Jeff Godfrey]

Another update - in case it's helpful for someone reading this in the future.

I realized that the above-outlined procedure can be simplified to just:

1. Build your final, wrapped application as normal.
2. Run "verpatch" (mentioned above) to insert the appropriate version info.
3. Run "zip -A <yourwrappedapp.exe>" (also mentioned above) to fix the file offsets.</yourwrappedapp.exe>

The only obvious miss is that the "getStubSize" command will return the original stub size instead of the modified (now larger) size.

If that's not a problem for the wrapped application, then I'm good with that.

Thoughts?