my kitgen kits drop the modified date from embedded files (windows)

[Neil Bryant]

Hoping somebody can tell me what I'm doing wrong.

I need tclkits with a manifest for requestedExecutionLevel=="requireAdministrator", so I downloaded kitgen, and the source code for tcl 8.5.11 and 8.6.b2.

I'm compiling with VS2005, which chokes on a warning embedding the manifest, but I got around that, and it looks like everything compiles correctly.

If I build a starkit with either of these binaries, and use it to copy a file to the computer, the file has no 'modified date' in Explorer. In file properties, all the files show a modified date of 1/1/1970 (Windows Epoch) leading me to presume that the actual value is null.

If I do a local copy (from the file system to the file system) all of the dates populate properly. It's only when I copy one out of the starkit onto the file system.

I've looked at the googlecode-starkit pages, and don't see anything relevant (closest: metakit gets confused with embedded certificates), nor do I find anything at the tcl wiki.

I'm going to try some other things--metakit-based kits for example, and eliminate machine-based causes--but I'm hoping somebody might have an idea what's going on or ideally have fixed it before =]

aTdHvAaNnKcSe

[Neil Bryant]

FYI: I seem to have sorted it. A bit more testing, and I'll post where I'm at.

[Neil Bryant]

Nope. For what it's worth, it seems if I add any type of manifest to the file, it mucks up file extractions.

If I use the files from the tclkit goolecode site (eg, tclkitsh-8.5.9-win32.upx.exe), file copies are correct. These exe's have no manifest, and appear to have been built without need of one.

I've been trying to compile with VC8, which needs a manifest, or it complains it can't find the runtimes. With the manifest, it breaks the copy datestamps. I can't (I don't think) compile without a manfest, since the exe just won't run.

I've been trying to compile in VC6, for comparison--to see if adding the manifest changes things--but I'm not having luck getting it to compile at all.

Right now, I've stared at this too long, so I'm putting it down while I can still form a sentence. I will pick it up later, or look into alternate forms of extraction.

If anybody has any thoughts, I would appreciate hearing them. If they are simple enough for me to follow, I will attempt them =]

[Pat Thoyts]

You should not need to rebuild tclkit to update the manifest resource.
However, you need to peform
a couple of steps. The tclkit executable is a Windows PE executable
compressed with upx and
has a metakit database appended to the end. To change the resources
the safest method is to
split the file and decompress:
sdx mksplit tclkit.exe # this yields tclkit.head (the exe) and
tclkit.tail (the database)
then
upx -d tclkit.head
Now you can use the mt tool to merge the manifest update with the
embedded manifest resource;
mt -inputresource:tclkit.head;#1 -manifest:admin.manifest
-outputresource:tclkit.head;#1
then rejoin the pieces into a tclkit again:
copy /b tclkit.head + tclkit.tail tclkit-admin.exe
(you could re-compress tclkit.head again here if you want a small exe)

Where admin.manifest contains just the new parts of the manifest required:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>

The above steps give me a tclkit executable that requests elevation as
soon as I run it. However, if you are doing this you will
probably need to sign such an executable using a valid authenticode
certificate. You can't do that to a metakit based tclkit but
you can do that using the vlerq based executables. So re-do the steps
above using tclkit-gui.exe if you want to sign the exe.

[Neil Bryant]

Pat,

I want to thank you. Your instructions were exactly what I needed, and very precise. I followed them, and have everything working properly.

As somebody who had just finished a project by deadline when this issue popped up, I can't tell you how much stress you've saved me.

Thanks again,
Neil