This is the mail archive of the cygwin-apps mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Nov 20 17:02, Corinna Vinschen wrote: > I added the sources for my now radically simplified test to this mail. > It consists of three files: > > add-cygwin-default-manifest.c: The source code adding the manifest. > cygwin-default-mainfest.rc: The default resource containing the > manifest. It's target-agnostic. > Makefile: The Makefile. > > To build the executable, just run `make'. This creates the > add-cygwin-default-manifest executable with the embedded manifest. > > To add a manifest to binary "foo.exe", run `make doit EXE=foo.exe' > add-cygwin-default-manifest.exe pulls its own manifest and copies it > over to foo.exe. This is the step which I didn't manage to reproduce > via objcopy. > > Note the crude way how `make doit' works. The UpdateResource > functionality is *extremly* sensitive against having an open handle to > the file still open in the same binary somewhere. If you try something > like this: > > doit: > strip $(EXE) > objcopy --remove-section=.gnu_debuglink $(EXE) > ./add-cygwin-default-manifest $(EXE) > > then you'll get an error message "EndUpdateResource: Win32 error 5". > Apparently, `make' has an open handle to $(EXE) and this is propagated > somehow to the child processes. As a side note, trying to call, say, > GetBinaryType before calling BeginUpdateResource, or even stuff like > CreateFile/CloseHandle(!!!) will end up with "EndUpdateResource: Win32 > error 5". As I wrote, *extremly* sensitive. That sounds much better > than "badly written"... As an additional datapoint: If you successfully call the UpdateResource stuff on a file with long section names, the resulting executable will actually run, and is cirrectly recognized as Windows 8.1 aware. The problem is that the sections with long section names will be broken, because the Windows functions somehow screws up the section strings. The result is that neither objdump, nor objcopy, nor GDB recognize any of these sections. Calling objdump -h either prints empty section names, or you get something like this: $ objdump -h ./foo BFD: ./foo: bad string table size 0 objdump: ./foo: Bad value Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgp4EpI9mdwlt.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |