DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=nRJ2pmOjm94ft0SLJWyWCNYJPVmeGsE1K1v7LBkcOTzysIZ4rOeg2
	8GK3vX0qGRX/Xm/l9Hj7Hhl79pw6e6YhpN7EaRIs2ML+GNKz6r4ijzDVdeFzC2j7
	gvYbaPAoZkr3ghvmcAKKDSHvRC8/0NVFBPmZndwbBg6Dy6vSPxUS40=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Wed, 12 Mar 2014 19:41:36 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Compiled executables requiring admin rights - different results between MinGW host type
Message-ID: <20140312184136.GB2547@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <E29840B52F804D728672875F0A8D534E AT TKsamsung>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU"
Content-Disposition: inline
In-Reply-To: <E29840B52F804D728672875F0A8D534E@TKsamsung>
User-Agent: Mutt/1.5.21 (2010-09-15)

--rS8CxjVDS/+yyDmU
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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
>=20
> 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.
>=20
> Wow. Thank you tremendously for this explanation Corinna. How bizarre.
>=20
> >- 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
>=20
> 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.
>=20
> >- 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.
>=20
> 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

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--rS8CxjVDS/+yyDmU
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTIKpgAAoJEPU2Bp2uRE+g++wP/iyAGELnONZL7W8fVytw9a1L
ZWfvv8diZEuFACTSi4yovoF3S6kS63I8SZg/OV62oNOVUZG2BvDW9aiMIFVMxiMR
bwHEWDsyxKXJbvcbv2tytyIq7fF+WVUrFEScJo/g5RiLW08SQ2vM92YNRQ2XUz/r
7fCGwq4zhIIEK7Y45x6RSlLQilf0/Vip9Uy6vS6wkeIXnozgdoc+uEcr8JXFPfo3
d5kQBhSOpPB2UND0VJUY/p6Q5g2sH0s2zo4UwwDceaLnOpt6Z4Hex4jwghQxryly
GYJBJqk9OWvoS9aO2jZm6YardD+/K+iXdGe+i+9+CrFBho2XnnI3VdQ/ihLZPlC2
htxooXBtYKWUexAbCt7DLPusIvjZauCg8ocOEeEx/0zinujjND6d274WFeTIt5tp
p0SV2IHSA7BqK+NUWHdCO9Bn1aJwh4nPLad/JkSa9RnA3RfbM7oD0F/nZ5NQUai6
lJW91DMN9V81E332mdbdlS/3Bv9GVDLfb+c63pLKv8tAbfYdWD6Dirqx0F5OUsv6
G3Qqiu+ABmJAdsaEkQ8kl5obfgc1l/ARcYpeIs6wbJGlhia2hjjw6AzfJw4MneGR
XATucIWGk18cIiZQup+w2a3pxYz7m6vDSW7/TtH+uQWWnKLDanLYVHRoO89fwGHf
kNuFZxBDRBziEWhkUPMv
=+rRE
-----END PGP SIGNATURE-----

--rS8CxjVDS/+yyDmU--