Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
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
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
Den 2010-03-19 07:18 skrev Ralf Wildenhues: 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? That's not the whole truth. If you use Visual Studio, the primary way to edit the resources is not to hack the text of the .rc file (you certainly *can*, but it's not the recommended usage pattern). I think most Windows IDEs have resource editors to make it more painless to design dialogs and draw icons etc. Also, the resource compiler supplied by MS (i.e. RC.EXE) doesn't compile to an ordinary object file, instead it produces a .RES file (whatever format that is, maybe it's COFF but I don't think so) which you then feed to the linker. So, the usage pattern is equivalent but warped (as usual). I don't know if the text in the Windows section should address these nits though... Cheers, Peter -- They are in the crowd with the answer before the question. Why do you dislike Jeopardy?
Re: automake.texi and @acronym
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
[ adding libtool-patches, in case anyone wants to disagree ]
* Karl Berry wrote on Wed, Mar 17, 2010 at 10:50:38PM CET:
I'm okay with changing the m4 and autoconf manuals with
s/@acronym{GNU}/GNU/
s/@acronym{(.*)}/\1/
So the preferred color now is this, I guess:
s/@acronym{(.*)}/\1/g
s/@sc{(.*)}/\1/g
and correcting capitalization afterwards. I'm fine with that.
Unless anyone complains, I'll prepare patches over the weekend.
Is the intention that even the n...@acronym{gnu} cases should be
replaced? Then what purpose is the @acronym keyword for?
The automake manual contains the uses below. The hits in fdl.texi seems
problematic to me...
j...@mocca:~/src/automake/doc master$ grep -e @acronym -e @sc *|grep -v -i -e
'@acronym{gnu}' -e '@sc{gnu}'
automake.texi:Portable packages should limit themselves to @acronym{POSIX} file
automake.texi:names. These can contain @acronym{ASCII} letters and digits,
automake.texi:more-generous @acronym{XOPEN} limit of 255 bytes. @acronym{POSIX}
automake.texi:limits file names to 255 bytes (@acronym{XOPEN} allows 1023
bytes),
automake.texi:If you depart from these rules (e.g., by using n...@acronym{ascii}
automake.texi:further: they should conform to the
@acronym{POSIX}/@acronym{XOPEN}
automake.texi:n...@acronym{posix} environments, you should avoid file names that
automake.texi:@acronym{DOS} file systems.
fdl.texi:@sc{ascii} without markup, Texinfo input format, l...@tex{} input
fdl.texi:format, @acronym{SGML} or @acronym{XML} using a publicly available
fdl.texi:@acronym{DTD}, and standard-conforming simple @acronym{HTML},
fdl.texi:PostScript or @acronym{PDF} designed for human modification. Examples
fdl.texi:of transparent image formats include @acronym{PNG}, @acronym{XCF} and
fdl.texi:@acronym{JPG}. Opaque formats include proprietary formats that can be
fdl.texi:read and edited only by proprietary word processors, @acronym{SGML} or
fdl.texi:@acronym{XML} for which the @acronym{DTD} and/or processing tools are
fdl.texi:not generally available, and the machine-generated @acronym{HTML},
fdl.texi:PostScript or @acronym{PDF} produced by some word processors for
j...@mocca:~/src/automake/doc master$
/Simon
Re: Repost: [PATCH] [cygwin|mingw] Create UAC manifest files.
On 19/03/2010 06:18, Ralf Wildenhues wrote:
[ ... 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?
Actually, I was wrong:
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?
Yep, that's basically it. The resource file defines objects from a certain
number of pre-defined categories, such as strings, icons and other small
bitmaps, and various struct-like things such as version infos; these are
compiled (along with some management data) into a .rsrc section that is then
linked into the exe.
A binary resource is a catch-all object type that just includes any old
arbitrary binary data you like, it's a bag-o-bytes.
However I misunderstood the docs I looked up. MS have defined a specialised
type of resource for manifests, you don't just throw them in as a blob, and
that means you just create a manifest resource type entry and include the
manifest xml data as a string directly within it; it doesn't refer to a
separate file on disk at all. So better wording would be:
... or can be built directly in by adding the XML contents of the file as a
manifest resource in a Windows resource file (@pxref{Resource Files}) that is
included ...
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.
I don't have a handy installation to find out on. I would guess that if you
enter the password incorrectly it asks you to try again, just like a regular
windows log-on dialog, and if you click Cancel, the application doesn't
launch. I'll see if I can find some more solid info anywhere.
This is where I'm at now.
Looking good, apart from the above only one nit:
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.
There's a word or two gone missing between granted and run!
cheers,
DaveK
Re: automake.texi and @acronym
Hi Simon,
Is the intention that even the n...@acronym{gnu} cases should be
replaced? Then what purpose is the @acronym keyword for?
I wrote about that earlier. Minor typographic change which is rarely
used in GNU manuals. De facto standard is not to use it. Which is
also simpler in the source. To try to use it consistently/everywhere
leads into deep waters (I have to do this in my TeX editorial life,
and it is exceedingly time-consuming). And it can't be used in node
names in any case, so there will always be inconsistencies. Do we
have to keep going with this?
The automake manual contains the uses below. The hits in fdl.texi seems
problematic to me...
I didn't realize that fdl.texi used it. I might be able to get that
changed, but I don't see that as a barrier to getting rid of it
everywhere else, anyway. No one reads fdl.texi, or expects perfect
consistency with the rest of a manual, anyway. For instance, its
formatting of its sections is idiosyncratic, to say the least. And
no, I don't want to go down that road, either.
k
How to build a noinst_ but still shared library?
Hi all, Well, here I am again with another dumb n00b question. From the automake manual: Libtool convenience libraries are declared by directory-less variables such as `noinst_LTLIBRARIES', `check_LTLIBRARIES', or even `EXTRA_LTLIBRARIES'. So: how do you build a shared library in your make check run, without it ending up installed somewhere during make install? (In case it's relevant, the project is all flat in a single non-recursive Makefile, so I can't just e.g. force the subconfigure in tests/ to use a bogus $prefix choice under $objdir somewhere.) cheers, DaveK ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: How to build a noinst_ but still shared library?
Hi Dave, * Dave Korn wrote on Sat, Mar 20, 2010 at 01:35:19AM CET: Libtool convenience libraries are declared by directory-less variables such as `noinst_LTLIBRARIES', `check_LTLIBRARIES', or even `EXTRA_LTLIBRARIES'. So: how do you build a shared library in your make check run, without it ending up installed somewhere during make install? (In case it's relevant, the project is all flat in a single non-recursive Makefile, so I can't just e.g. force the subconfigure in tests/ to use a bogus $prefix choice under $objdir somewhere.) check_LTLIBRARIES = libfoo.la libfoo_la_LDFLAGS = -rpath /nowhere Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
