Re: Cygport and auto-manifestize compatibility manifest

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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