Compiled executables requiring admin rights - different results between MinGW host type

[Corinna Vinschen]

On Mar 12 11:00, Tony Kelman wrote:
> >You won't believe it, but yes!  Welcome to the wonderful world of
> >UAC installer detection!!!1!11
> 
> I get the impression you've been frustrated by this one before...

Hmm, I'm too easy to read, apparently...

> >See http://msdn.microsoft.com/en-us/library/bb530410.aspx
> >and scroll down to the section called "Installer Detection".
> >
> >I'll wait while you read...
> >
> >[..."whistling while you work"...]
> >
> >Finished?  Fine.  So, the only fault of your application is it's name.
> >It's called "something-with-patch-in-it".  As everybody knows, an
> >application which is called "something-with-patch-in-it" is an
> >installer and needs elevation.  But only if it's a 32 bit application.
> 
> Wow. Thank you tremendously for this explanation Corinna. How bizarre.
> 
> >- Take one of the manifest files you find in Cygwin's /usr/bin dir,
> >  and copy it alongside your binary, for instance:
> >
> >    $ cp /usr/bin/patch.exe.manifest ./stringpatch.exe.manifest
> 
> That did the trick. In 64 bit Cygwin the only .manifest file I found in
> /usr/bin was install-info.exe.manifest (apparently from texinfo package),
> but that worked. Makes sense that 64 bit Cygwin wouldn't need as
> many of these, but my primary use case where I'm running into this
> issue is cross-compiling from 64 bit Cygwin to i686-w64-mingw32.
> 
> >- Wait until the next binutils version is released (should be in the
> >  next couple of days), and link your executable with the new linker.
> >  This will give you a default manifest integrated in your executable
> >  by default, which doesn't only claim compatibility with all existing
> >  WIndows versions, but also sets the RequestedExecutionLevel to
> >  "asInvoker", which avoids the elevation for this executable entirely.
> 
> Don't the various MinGW cross compilers have their own binutils? I look
> forward to this being the most convenient long-term solution, (renaming
> could also work, but that pull request is going to result in some confused
> looks and/or raised eyebrows) but will this need to come from upstream
> (MinGW.org for i686-pc, or MinGW-w64 for i686-w64) to change the default
> no-manifest-file behavior for any of the hosts besides 32 bit Cygwin?

Our maintainers of the mingw-binutls and native binutils package just
have to update the packages to the latest from binutils git.  Actually,
that reminds me...

JonY, ping?  A couple of days ago, Nick Clifton updated binutils for
Windows so that every executable, which doesn't provide its own
manifest, will get a default manifest.  This default manifest has two
purposes:

- It sets the RequestedExecutionLevel to "asInvoker", which is the usual
  default behaviour, and

- it makes sure to make the executable compatible with all released
  versions of Windows, which is *especially* important since Windows
  8.1.  The reason is this:

  The compatibility manifest was optional up to Windows 8.  An
  executable without manifest was treated as compatible with the current
  OS version.

  Starting with Windows 8.1, the manifest is not optional anymore.  An
  executable without manifest is treated as being incompatible with all,
  but the oldest still supported OS compatibility layer.

  On Windows 8.1 this means, *all* executables without compatibility
  manifest run in Windws Vista compatibility mode.  Which is bad,
  because the compatibility setting for Vista even reproduce old bugs!

So, if you have a bit of time, it would be nice to get new
mingw64-i686-binutils and mingw64-x86_64-binutils packages (as well
as a new Cygwin binutils, but cgf already knows about this).

Every time a new Windows version is released, we will have to update the
default manifest in binutils, too, but that's the price we have to pay
for compatibility.  Sigh.


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: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20140312/1a0da8a0/attachment.sig>