Jan Dubois
Fri, 07 Nov 2008 16:00:55 -0800
Hi Georg,
Yes, external manifests are a good workaround in this situation.
[OFFTOPIC] Note though that they won't always work if the executable already
has an embedded manifest (e.g. to request using the
"new" version of the common GUI controls). The external manifest still seems to
be used in Windows XP, but in Windows 2003 and later
all external manifests are being ignored when an embedded manifest is found.
This is obviously not a concern for FC, which doesn't
have an embedded manifest.
Cheers,
-Jan
PS: Is your re-colored icon downloadable anywhere? Also, does anyone have a
higher resolution icon (or even PNG) file for FC?
Nowadays I mostly run Windows inside VMWare Fusion on OS X, and the low res
Windows icons look pretty blurry when using "unity" mode
(seamless desktop integration).
Of course I wouldn't mind seeing a native OS X version of FC, but I'm not
holding my breath. J
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Dr. Georg
Czedik-Eysenberg
Sent: Friday, November 07, 2008 3:23 PM
To: File Commander mailing list
Subject: Re: [FC] Strange behaviour in Vista
Dear Jan!
Partially I had the same ideas as you had:
I installed the FC twice:
* Installation 1 worked in the legacy mode.
* Installation 2 worked in admin mode via a LNK file with "run as admin"
setting.
Furthermore it had an INI file with other colours
And I also changed the EXE's icon resource to a differently coloured one
(in order to see the difference also in the task
bar).
But I was not fully satisfied with my solution, as I wanted installation 1 to
wotk in normal user mode, not in legacy mode.
When I read your e-mail (MANY THANKS!!!), I tried to add a manifest to the EXE
in installation one
It did change its behaviour, but strangely it behaved in the admin way although
my manifest contained level="asInvoker".
At the end I found a much better (simpler) solution (external manifests):
Now I have in installation 1 a file "fcw.exe.manifest" with the following
contents:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0"
processorArchitecture="X86"
name="ExeName"
type="win32"/>
<description>elevate execution level</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
And in installation 2 it has the following contents (and no need for a special
LNK file any more):
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0"
processorArchitecture="X86"
name="ExeName"
type="win32"/>
<description>elevate execution level</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Kind regards, Georg
Jan Dubois schrieb:
File Commander should have an "asInvoker" manifest. That way it manipulates
the normal filesystem. You can still run it elevated
by starting it from an elevated cmd.exe session, or invoking it with "Run As"
from the context menu, or even have a separate
shortcut with the "RunAs" setting set to Administrator.
You should be able to add the manifest yourself using a tool like mt.exe from
the Windows SDK, or reshacker if you don't have the
SDK installed. This way you don't have to wait for Brian to make another
release.
One thing I would like to see would be different color sets that FC would
automatically choose based on whether it is running as
admin or not (checking the actual process token to see if the process is
elevated and not relying on whether the user is a member of
the Administrators group).
You can kind of do this yourself too by having FC installed twice, configured
with different color schemes, and then make
corresponding shortcut icons that run one with normal privs and one as admin.
The main annoyance is that changes to directory
shortcuts are not automatically propagated to both instances. On the other
hand having separate command histories for normal and
elevated instances is actually an advantage. Personally I like using a red
background for shell windows that are running with admin
privs to make it real obvious that I should be more careful about things. J
Cheers,
-Jan
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Dr. Georg
Czedik-Eysenberg
Sent: Thursday, November 06, 2008 3:43 PM
To: File Commander mailing list
Subject: Re: [FC] Strange behaviour in Vista
Dear Jan,
many thanks for the perfect explanation of this tricky Vista function.
The question is now:
Should a tool like File Commander better have a manifest (with "run as
invoker") to ensure,
that we get informed when we try to modify a file without permission,
i.e. it sees and modifies files like the other (modern) programs do?
Or is it better, that it has no manifest and therefore sees and modifies files
like legacy programs do?
Or is there some third possibilty (like being able to switch between these two
modes)
or being warned, when VirtualStore is used ... ?
Kind regards, Georg
On Thu, 06 Nov 2008, Dr. Georg Czedik-Eysenberg wrote:
I found a very strange behaviour in Vista:
File Commander (started normally, not in admin mode) allows me to copy
files into "C:\Program Files" and also to create directories there,
but both are only seen then by File Commander, not by any other software
(like "cmd" or Windows Explorer).
Similar when I edit the contents of files there (using File Commander's
internal editor).
Can anybody else reproduce this effect?
You are encountering the "VirtualStore" feature of Vista: When running an
executable, it will check if the resources contain a manifest that tells
the loader the required privilege level (run as invoker, run as administrator).
When the manifest specifies "run as administrator" then you'll get a UAC
prompt to request permission to run with admin privs and after that you are
free to write to "C:\Program Files".
When the manifest specifies "run as invoker" then you will run without admin
privs, and the program gets a permission error when it tries to open a file
for writing in the "C:\Program Files" area.
When you don't have a manifest though Vista assumes you must be some kind
of legacy program that doesn't know about the stricter permission enforcement
of Vista. Instead of generating the permission error Vista will create
a shadow tree in your user directory, normally
C:\Users\USERNAME\AppData\Local\VirtualStore\Program Files
When you open a file for writing in the C:\Program Files tree it will first
be copied to this VirtualStore and then opened there. You are free to modify
any files in C:\Program Files this way, but you won't actually update the
real (protected) files.
Similarly when you read a file from "C:\Program Files" and don't have a manifest
then Vista will first try to open a file in the VirtualStore and only if it
doesn't exist open the real file (in read-only mode). This way the caching
happens lazily only for files that actually get opened for update.
Things are even more convoluted when you are running 32-bit applications on
64-bit Vista (in addition to the VirtualStore there is also file-system and
registry redirection for specific trees).
Only slightly related is one other feature: If your program looks like it
might be an installer, then Vista will assume that you want to "run as
administrator" even when you don't have a manifest. The heuristics for
"looks like an installer" are not fully documented, but include having any
of the substrings "setup", "install", "patch" or "update" in the filename.
So if you ever wonder why you cannot run patch.exe normally from a
cmd.exe prompt, that's why. There is a policy for these heuristics that
you can disable in the policy editor. It is enabled by default for
machines that have not been added to a domain (I guess with the assumption
that users in a domain are normally not supposed to install software
themselves).
It is all a very clever way to provide backwards compatibility while still
improving security. It is a nightmare though to figure out what is really
happening on your machine.
Cheers,
-Jan
PS: There is more stuff, like the automatic application of compatibility "shims"
to applications to work around known compatibility problems, but this post
probably already contains much more than you wanted to know about Vista.
_______________________________________________
Fc mailing list
Fc@silk.apana.org.au
http://silk.apana.org.au/mailman/listinfo/fc
Bug Tracker: http://bugs.silk.apana.org.au/
_____
_______________________________________________
Fc mailing list
Fc@silk.apana.org.au
http://silk.apana.org.au/mailman/listinfo/fc
Bug Tracker: http://bugs.silk.apana.org.au/
_______________________________________________ Fc mailing list Fc@silk.apana.org.au http://silk.apana.org.au/mailman/listinfo/fc Bug Tracker: http://bugs.silk.apana.org.au/