Cygport and auto-manifestize compatibility manifest

Corinna Vinschen corinna-cygwin@cygwin.com
Wed Nov 20 16:17:00 GMT 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20131120/cfd857c9/attachment.sig>


More information about the Cygwin-apps mailing list