Re: Windows Emacs and "VirtualStore"

[Lewis Perin <perin@panix.com>]

A couple of days ago I wrote that running Emacs as a non-privileged
user on Vista or Windows 7 leads to some files being written silently
to places in the file system other than where Emacs (and the user)
thinks they're going.

As far as I'm concerned, I've solved part of the problem, at least
until the next time I upgrade.  Now when Emacs tries to write to a
place in the filesystem it has no right to write to, the program finds
out and complains to the user.

The fix doesn't require a change to the code of emacs, only to a
resource linked into the program: the Windows manifest, which is a
small XML script.  The manifest in the 23.1 Windows Emacs I have does
only one thing: it declares Emacs's dependence on
"Microsoft.Windows.Common-Controls".  This needs to be augmented by
some XML verbiage that tells Windows that the program is aware of
VirtualStore and prefers not to use it.  Here's the manifest I'm
using:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32"
      name="Microsoft.Windows.Common-Controls"
                        version="6.0.0.0" processorArchitecture="X86"
                        publicKeyToken="6595b64144ccf1df"
                        language="*"/>
    </dependentAssembly>
  </dependency>
  <assemblyIdentity version="1.0.0.0" processorArchitecture="X86"
  name="emacs" type="win32"/>
  <description>Mighty Emacs</description>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker"/>
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

Obviously, I'd love it if something like this script were accepted as
part of Windows Emacs.  But until then, it can be applied to the
binary using a tool like the free-as-in-beer ResHacker.

When I said the augmented manifest was *part* of the solution, I meant
that an ideal solution would allow the user to escalate privilege by
typing an admin password for an attempt to rewrite a file when the
first write failed.  I've no idea if this would be as simple as it
sounds.  Is there someone reading this who's in a position to comment?

/Lew
---
Lew Perin | perin@acm.org | http://www.panix.com/~perin/babelcarp.html