patchEmbed an application manifest on MinGW

On Windows Vista, not having an application manifest with a requestedExecutionLevel can cause several kinds of confusing behavior.

The first and more obvious is Installer Detection, where sometimes Windows decides (by looking at things like the file name and even sequences of bytes within the executable) that an executable is an installer and should run elevated (causing the well-known popup dialog to appear). On git, this happens for executables with names containing "patch" or "update".

The second and more confusing is File Virtualization. With it, writes to some files which should fail are instead redirected to somewhere else, and reads to files might return different contents if a previous write was redirected. Even more confusing, not all writes are redirected; I recall reading somewhere that for instance writes to .exe files will fail instead of redirecting.

Needless to say, git wants none of that. Not only that, but File Virtualization has been blamed for dramatic slowdowns in git (see for instance http://code.google.com/p/msysgit/issues/detail?id=320).

There are two ways to turn off these annoyances. Either you embed an application manifest within all your executables, or you add an external manifest (a file with the same name followed by .manifest) to all your executables. Since for git some executables are copied (or hardlinked) with several names, it is simpler and more robust to embed an internal manifest.

A recent enough MSVC compiler should already embed a working internal manifest, but for mingw you have to do so by hand.

Very lightly tested on Wine, where like on Windows XP it should not make any difference.

References:
  - New UAC Technologies for Windows Vista
    http://msdn.microsoft.com/en-us/library/bb756960.aspx
  - Create and Embed an Application Manifest (UAC)
    http://msdn.microsoft.com/en-us/library/bb756929.aspx

Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
---
 Makefile                  |   29 +++++++++++++++++++++--------
 compat/win32/git.manifest |   11 +++++++++++
 compat/win32/resource.rc  |    1 +
 3 files changed, 33 insertions(+), 8 deletions(-)
 create mode 100644 compat/win32/git.manifest
 create mode 100644 compat/win32/resource.rc

Hi,

On Sat, 28 May 2011, Cesar Eduardo Barros wrote:

Is it possible that adding the resource object to GITLIBS would reduce the patch and be "more correct", too?

Thanks, Johannes

Em 28-05-2011 17:44, Johannes Schindelin escreveu:

I thought about it, but it felt wrong. It is not a library, it is an object.

Also, while adding it to GITLIBS would add the object to all the right rules (in fact, I did a search for GITLIBS to find all the places to add the new object to), I believe it would get the object linked twice in some of the rules (the ones which do a $(filter %.o,$^) would get it both from GITLIBS via the filter and from GITLIBS via $(LIBS) on the command line).

Hi,

On Sat, 28 May 2011, Cesar Eduardo Barros wrote:

Well, a library is a collection of objects. A .a file traditionally contains also .o files that define both global and local variables.

Even so, let's assume for a moment that you're right and a library is a library of functions (which I assume that you assume), and let's ignore for a moment that GITLIBS provides non-functions such as inside_git_dir and auto_crlf. Then the approach of adding another $(RESOURCE) in exactly all the places where we have $(GITLIBS) is so redundant that it asks for future inconsistencies (somebody _will_ forget, because things still compile). In that case, one patch to rename GITLIBS to, say, COMMON_OBJECTS, and another patch to add the manifest to the common objects.

But as I said, IMHO GITLIBS is aptly named and should take the resource, too.

Does it result in a link error? If not, it's not an issue.

Ciao, Johannes

Em 28-05-2011 18:19, Johannes Schindelin escreveu:

It is just a question of names: *LIBS is a list of libraries, *OBJS is a list of object files. It feels wrong to add something we call an object to something which is a list of things we call libraries. Yes, it is a weak argument, but it is the reason it felt wrong to me.

I see no big problem with it, as long as it does not link the object twice. Perhaps creating a new variable which includes both GITLIBS and RESOURCE_OBJS but is not included in LIBS (to avoid the double linking)?

It is worse. Not only would it not result in a link error, but it also would silently include the manifest resource *twice*. I recall that one of the pages I read while researching application manifests said that having more than one manifest with the same ID is an error, and we cannot know what Windows would do in that case (I would guess either "log an error and abort the executable" or "log an error and completely ignore the manifest"). And even if it works today, we never know what would happen in a future version of Windows.

The resource object really needs to be linked exactly once. It is one of those special objects which append or prepend data to fixed sections of the executable just by being linked to it (like the crt*.o gcc adds internally when linking). With these kinds of objects, even the link order is relevant (order is not a problem here because only this object adds to the .rsrc section, and the linker puts the section at the correct place). In fact, I do not even know if the resource format allows one to link more than one resource object in the same executable.