Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.

[Ralf Wildenhues]

Hi Dave,

thanks for your quick review!  I've incorporated all changes not
addressed below.

* Dave Korn wrote on Tue, Mar 16, 2010 at 11:24:42AM CET:
> On 16/03/2010 06:17, Ralf Wildenhues wrote:
> 
> > and updating of system-wide software.  The level of privileges required
> > for some executable program to accomplish its task may be designated by
> > the program developer by means of a manifest file (@pxref{Manifest
> > Files}) or a compiled-in Windows resource file (@pxref{Resource Files}),
> > among other possibilities, and among many other system-specific metadata
> > that may be added to these files, such as program icons.
> 
>   This is slightly confusing, I don't think it quite makes it clear that
> what's going on is that the manifest file can be put into the resource file.
> How about something along the lines of ...
> 
> [ ... snip ... ]                       The level of privileges required
> for some executable program to accomplish its task may be designated by
> the program developer by means of a manifest file (@pxref{Manifest
> Files}), which may either be installed in the same directory alongside
> the executable, or can be built directly in by adding the manifest file
> as a binary resource in a Windows resource file (@pxref{Resource Files})
> that is included in the executable's final link.        [ ... snip ... ]

That's better, but it makes it sounds like the resource file is a
binary, and "built directly in" sounds unobvious to me.  Is "binary
resource" a technical term?  Would using just "resource" be enough?

AFAIU, the resource file (*.rc) is a simple hand-written text file,
which may refer to the manifest file (like a .c file includes a header),
then gets compiled by windres to an object file and linked in like any
other object.  Right?

> > This means, if your executable happens to match any of
> > those strings, even if it has no need for elevated privileges otherwise,
> > will needlessly prompt for a password, and if granted, work under
> > super-user access.
> 
>   Complex run-on sentence construction.  How about just
> 
> [ ... snip ... ]  If your executable does not need elevated privileges, but
> happens to match any of those strings, the OS will needlessly prompt for a
> password, and (if granted) run the executable with greater privileges than an
> ordinary user application is supposed to have.        [ ... snip ... ]

BTW, if the password is not given correctly, then will the program run
under lesser privileges or will it not run at all?  I think we should
document that as well, because either outcome has implications for the
developer.

>   And maybe here:
> 
> >  It is possible to turn off this hack by means of a
> > manifest file or compiled-in resource.
> 
> ... mention that you can indeed also turn it on (well, request elevated
> privilege) for files that have names that /do not/ match the patterns listed
> above.

Certainly.

This is where I'm at now.

I'm beginning to think the best and cleanest way is to get .rc handling
into Automake (should be straightforward), and just recomment to always
use that, or a hand-written .rc.$(OBJEXT) rule if windres is present.[1]
(Of course that still leaves libtool semantics to do for this issue, but
at least it releaves us from much thought about where the source tree
is, which libtool --mode=link does not know or care about so far.)

Cheers,
Ralf

[1] Incidentally, that's exactly what we do here in an application also
targeted for w32.



@node Windows pecularities
@chapter Windows pecularities

Autotools strive to provide some level of support for the various
Microsoft DOS and Windows systems.  The GNU
@command{config.guess} command recognizes and names few different
environments built upon this operating system and suitable for autotools
usage, such as Cygwin, MinGW, DJGPP, or Interix.  Besides the GCC ports
for these systems, other compilers may be supported to varying degree.

Compared to most Unix-like systems, these operating systems differ in
several respects.  Some of them may be handled transparently by the
autotools, but many of them require adaptation by the developer.


@node UAC
@section User Account Control (UAC)

The Microsoft Vista and all later versions of Windows provide increased
default privilege control over earlier versions for certain operations
such as the installation and updating of system-wide software.
The level of privileges required
for some executable program to accomplish its task may be designated by
the program developer by means of a manifest file (@pxref{Manifest
Files}), which may either be installed in the same directory alongside
the executable, or can be built directly in by adding the manifest file
as a resource in a Windows resource file (@pxref{Resource Files})
that is included in the executable's final link.

Now, there exists a large amount of legacy software built for older
versions of this operating system, which is not aware of these privilege
controls.  In order to allow these older programs to continue to work on
the newer system without failing due to lack of privileges, a special
compatibility hack was devised that lets the operating system assume
programs with names containing the substrings @code{instal},
@code{setup}, @code{update}, or @code{patch} would deal with system
program installation and as such should prompt for super-user
(Administrator) privileges.

Unfortunately, this hack applies to all software, not just old legacy programs.
If your executable does not need elevated privileges, but happens to match any
of those strings, the OS will prompt for a password.  If granted,
run the executable with greater privileges than an ordinary user
application is supposed to have; otherwise, the program will not be started.
It is possible to turn off this hack by means
of a manifest file or compiled-in resource; more generally, privilege
requirements and other system meta-data can be specified by using a resource
file for all kinds of executables, not just those matching names
mentioned above.

@command{libtool} ...


@node Manifest Files
@subsection Manifest Files

...

@node Resource Files
@subsection Resource Files

...