Delphi Handbooks Collection


Delphi XE Handbook


Delphi 2010 Handbook


October 5, 2009

Non-Themed Windows Applications and Virtual Store

Given the comments to my recent blog post on changes in Windows 7, it is worth clarifying how Virtual Store works in Windows.

Given the comments to my recent blog post on changes in Windows 7, it is worth clarifying how Virtual Store works in Windows. 

If a Windows application is themed (that is, it has a manifest file indicating it is a themed application), when it tries to save a file under Program Files (generally the installation folder of the application itself), it fails with an error. This happens even if the user has Admin privileges (as applications are executed with standard permissions anyway). However, if you use the "Run as Admin" command to start the program, it has full write permissions anywhere on the file system.

If a Windows application is not themed (that it, it is an old application), when it tries to save a file in the installation folder under Program Files, it succeeds... but nothing gets written in that folder. The operating system, instead, redirects the request to a Virtual Store area under the User documents folder. On my system this is: "C:\Users\Marco\AppData\Local\VirtualStore". In Vista, this was true for file operations under Program Files and Windows, in Windows 7 this is also true for operations under the root of the C: drive (which used to fail in Vista, even for non-themed applications). Again, if you use the "Run as Admin" command to start the program, it has full write permissions anywhere on the file system.

Of course, you might have the same file both under your regular file system and Virtual Store (for example, modified .ini files), which can cause a good amount of confusion. If you use Resource Explorer, you'll see only the real files but you'll have a "Compatibility" button in the toolbar indicating there are files in the corresponding area of Virtual Store. If the non-themed application uses a File Open dialog box, however, you'll see both native and Virtual Store files as if they were in the local folder. Very confusing!

The rationale behind all this seems to be that older applications can still run instead of failing on Vista and Windows 7, while newer application must follow the proper rules for user documents. I find is quite odd that not so many Windows developers know about the behevior of Virtual Store a few years after Vista has been released, but Microsoft certainly did a limited job covering it (here is some good coverage, though). On the other hand, my Delphi 2007 Handbook has a detailed session (and a specific example) focused on this topic.





 

3 Comments

Non-Themed Windows Applications and Virtual Store 

IMHO Microsoft did - and does - the best to create 
confusion around manifest files and their proper use. 
There is no central place to find information about 
them, and there are a lot of entries in MSDN which 
cover just a side (i.e. side-by-side assembly or the 
like), and a lot of broken links.
For example when you speak about "themed" application 
actually you mean "manifested" applications - 
manifests can "theme" applications since XP, but 
AFAIK virtualization stops redirecting files 
operation when a Vista manifest is detected - not 
simply a manifest enabling themes, because a Vista 
manifest enables the system to know which privileges 
are required actually (a program with enough 
privileges can write to protected folders, if needed).
Vista manifest may have also some compatibility issue 
with XP, i.e. 
http://support.microsoft.com/Default.aspx?kbid=921337
Comment by Luigi D. Sandon on October 5, 19:30

Non-Themed Windows Applications and Virtual Store 

Indeed. I had a rough enough time finding out that
"sysnative" was the right way to spell "system32" when
looking for the system32 directory in a 32-bit
application on 64-bit Windows. I expect this hackery
will get worse over time...
Comment by Barry Kelly [http://blog.barrkel.com/] on October 5, 20:28

Non-Themed Windows Applications and Virtual Store 

So again, in your last article you told about a themed
Windows 7 app that can successfully store a file into
"C:\" but then it is redirected to the virtual store
instead. However themed apps are not affected by
redirection and will get an Access Denied. Seems to be
a typo.

AFAIK: Windows Explorer has a toolbar button that
tells you when files are stored in the virtual folder
of the current folder.

IMHO: It is also very confusing to talk of "themed"
and "unthemed" where one should talk about
applications with (Vista) and without manifest
(legacy). As a side effect the application's window
will get the benefit of a better look and design. But
that is not the point here, isn't it?

Okay, it's picky but it should be clarified:
"This happens even if the user has Admin privileges
(as applications are executed with standard
permissions anyway). However, if you use the "Run as
Admin" command to start the program, it has full write
permissions anywhere on the file system."
There is no such admin privilege. There are just
privileges that can do more or less harm to the
system. However a user is made to an administrator
because she belongs to the administratorS group. So
her token (an id card retrieved when logging on)
contains the adminS group in his list of group
memberships. There are some attributes attached to
each group that defines how to use the group in access
checks. In Vista, however, this admins group has an
attribute that tells Windows to use this group only
for deny access rules (in object Access Control List).
So it cannot be used if an object ACL allows access to
the admins group (because deny <> allow).
Of course most of privileges are removed from the ID
card to prevent harm.
And at last, it is possible to prevent access to
objects for admins. Vista does so in its system folder
by setting the access control list accordingly.
However admins can always reset the list (not
recommended). 




Comment by Christian Wimmer [http://blog.delphi-jedi.net] on October 5, 20:37


Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.