Program Files Virtualisation

I _think_ I understand the reasoning behind virtualisation of Program Files
(and other system folders) is to make older applications work with the new
security. But why are the virtualised files stored on a per-user basis,
rather than somewhere accessible to all users? Surely applications storing
settings under Program Files expect these settings to be the same for all
users, so why does Vista's "compatibility" features turn these into per-user
settings?

I have got around this in one case, where a small app stores all its
settings in a single configuration file under Program Files, by giving all
users full access to that one file. This seems to prevent a virtualised copy
of the file being created.

This wouldn't be so easy for other applications which may create several
files and folders under Program Files, particularly ones where downloaded
plugins are also stored there. For example, having logged in as an
administrator and installed extra language packs for Mozilla SeaMonkey, these
were then not available to other users, since they had been stored in the
"Admin" account's virtualised Program Files. Using Run As Administrator to
launch the web browser and install the language packs got around the problem,
but why could they not have been stored to a virtual store common to all
users in the first place?

Presumably I would be up against the same problem installing further add-ons
in the future - having to close down all instances of the web browser and the
quick-starter before running the browser as Administrator to install the
add-ons. (If I select Run As Administrator on it while there is an instance
running with lower access, it seems that the newly opened instance is also
opened with the lower access. Possibly this is to do with the "quick starter"
running, with user access, in the system tray being called on to actually
open an instance of the browser)

OK - so in this case I am installing add-ons to an application, so maybe I
should have to Run As Administrator to do that, even if that is a little
inconvenient. But a similar problem would exist with a spell-checker which
stores its custom words list under Program Files, so all users can access it.
Under Vista, each user would see their own version of the "global" words list!

I realise one solution would probably be to give all users full access to
the entire folder in which SeaMonkey is installed (and any other applications
experiencing similar problems), but presumably that would be breaking the
security which has been designed into Vista.

Is giving all users full access to certain files and folders within Program
Files the "right" way of achieving the result I want (ie. that all users see
the same global file rather than their own, provate vitualised copy of it)),
or is there some way to make virualised copies accessible to all users?

Thanks,
Mark.

I have several hundred .doc recipe files on my XP and they will not open
correctly with Vista. The XP opens them with Wordpad and reads correctly.
The Wordpad.exe file in Vista is larger, than in XP, and the files open as
garbage.

Hello,

Making the "virtualized" content accessible by all users would be just as
bad as making the original location world-writable, so there would be no
point.

You are correct in assuming this has to do with the security policy in
Vista.

In Windows Vista, as in all earlier versions of Windows NT, each
system-defined location has specific purposes that application developers
are supposed to adhere to.

The biggest thing application developers "break" is the taboo with accessing
program files.

Program Files is *NOT* the application's "scratch pad" area for storing
files and data. The program does not "own" its folder here, and it has never
been acceptable for programs to store files and settings here.

Applications have always been expected to expect this area to be read-only.

Program Files is for just that; static, read-only program files that
constitute the core files that an application needs to run, and that are not
user-specific.

User-specific data goes inside a user's profile folder or a few other
special folders.

All machine-wide configuration data goes inside another special folder
designed for this purpose.

Why is this?

Well, program-files is MACHINE-WIDE, and contains the executable files for
well-known programs and system components.

It is important that these types of files be SEPERATE from other types of
data because SPECIFICALLY these types of files SHOULD NOT be accessible by
non-administrators. Because allowing non-admin writes to this area would
allow anybody to replace these machine-wide program files with malicious
program files, that would affect every user on the computer.

Basically, the secure in Windows Vista works like this:

* If the file, directory, registry key, etc, belongs to a certain user, then
every program that the user runs has access to it

* If the file, directory, registry key, etc, does NOT belong to a certain
user, then only administrative programs have write access; all other
programs have read-only access.

This enforces the "rule" that only administrators (and administrative
programs) can access anything that will affect the state of the computer or
another computer.

So you are correct that a Vista-compatible program would need to ask you for
permission to update its program files (in order to run the updater as
admin) or have the updater running as a service in the background.

Virtualization is a hack that works within this security policy to make
these misbehaving programs work.

Unfortunately, the correct solution to this problem is for the applications
that are misbeaving to be modified to follow these guidelines.

As a hack, you can indeed do as you did by modifying the security on the
files that the application expects to be world-writable, or running the
application as administrator.

You are correct that these are the only solutions available to you.

--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/

Tom

If the files were created in Microsoft Word, then you need Word installed to
workwith those files. If you simply want to read those files and not make
any changes, there is a free Word Viewer available.

You can download the viewer here:

Download details: Word Viewer 2003:
http://www.microsoft.com/downloads/d...DisplayLang=en


--

Ronnie Vernon
Microsoft MVP
Windows Shell/User


"Tom" <Tom@Metroplex.com> wrote in message
news:a9dMh.9695$Um6.5856@newssvr12.news.prodigy.net...
>I have several hundred .doc recipe files on my XP and they will not open
> correctly with Vista. The XP opens them with Wordpad and reads correctly.
> The Wordpad.exe file in Vista is larger, than in XP, and the files open
> as
> garbage.
>
>

Jimmy Brush wrote:
> Hello,
>
> Making the "virtualized" content accessible by all users would be just
> as bad as making the original location world-writable, so there would be
> no point.
I wondered if that might be the case.

>
> You are correct in assuming this has to do with the security policy in
> Vista.
>
> In Windows Vista, as in all earlier versions of Windows NT, each
> system-defined location has specific purposes that application
> developers are supposed to adhere to.
>
> The biggest thing application developers "break" is the taboo with
> accessing program files.
>
> Program Files is *NOT* the application's "scratch pad" area for storing
> files and data. The program does not "own" its folder here, and it has
> never been acceptable for programs to store files and settings here.
>
> Applications have always been expected to expect this area to be read-only.
>
> Program Files is for just that; static, read-only program files that
> constitute the core files that an application needs to run, and that are
> not user-specific.
>
> User-specific data goes inside a user's profile folder or a few other
> special folders.
>
> All machine-wide configuration data goes inside another special folder
> designed for this purpose.
I assume this folder is C:\ProgramData? Some of the folders already in
that location are not writeable by all users, but presumably it is up to
the program's install process to correctly set these permissions?

>
> Why is this?
>
> Well, program-files is MACHINE-WIDE, and contains the executable files
> for well-known programs and system components.
>
> It is important that these types of files be SEPERATE from other types
> of data because SPECIFICALLY these types of files SHOULD NOT be
> accessible by non-administrators. Because allowing non-admin writes to
> this area would allow anybody to replace these machine-wide program
> files with malicious program files, that would affect every user on the
> computer.
>
> Basically, the secure in Windows Vista works like this:
>
> * If the file, directory, registry key, etc, belongs to a certain user,
> then every program that the user runs has access to it
>
> * If the file, directory, registry key, etc, does NOT belong to a
> certain user, then only administrative programs have write access; all
> other programs have read-only access.
>
> This enforces the "rule" that only administrators (and administrative
> programs) can access anything that will affect the state of the computer
> or another computer.
>
> So you are correct that a Vista-compatible program would need to ask you
> for permission to update its program files (in order to run the updater
> as admin) or have the updater running as a service in the background.
>
> Virtualization is a hack that works within this security policy to make
> these misbehaving programs work.
>
> Unfortunately, the correct solution to this problem is for the
> applications that are misbeaving to be modified to follow these guidelines.
Unfortunately not likely in the first case I described, as that is a
small open-source utility which is not currently active. Setting
permissions on a single file isn't too much of a problem though.

>
> As a hack, you can indeed do as you did by modifying the security on the
> files that the application expects to be world-writable, or running the
> application as administrator.
I'd prefer not to make a program's entire folder world-writeable, as
would be required for Mozilla, but hopefully that's big enough to be
corrected fairly soon.

Interestingly, I have noticed one of Windows Live Messenger's files
being virtualised - is this a bug in WLM?

>
> You are correct that these are the only solutions available to you.
>

Thanks for taking the time to respond.

Mark.

<snip>

>> All machine-wide configuration data goes inside another special folder
>> designed for this purpose.

> I assume this folder is C:\ProgramData? Some of the folders already in
> that location are not writeable by all users, but presumably it is up to
> the program's install process to correctly set these permissions?

Yes, this is the machine-wide settings folder ... and the security on this
folder is set up such that any user can create data here, but once created
that data can only be modified by the user who created it, while being
viewable by any account on the system.

The OS enforces user-account seperation, even in this location .

Applications can of course override this behavior in their setup program to
make a truely world-read/writable file/folder, however if possible, it is
better for an application to find a way to work within the default
boundaries.

<snip>

>> Unfortunately, the correct solution to this problem is for the
>> applications that are misbeaving to be modified to follow these
>> guidelines.

> Unfortunately not likely in the first case I described, as that is a small
> open-source utility which is not currently active. Setting permissions on
> a single file isn't too much of a problem though.

Yes, you were lucky in that regard .

<snip>
>>
>> As a hack, you can indeed do as you did by modifying the security on the
>> files that the application expects to be world-writable, or running the
>> application as administrator.

> I'd prefer not to make a program's entire folder world-writeable, as would
> be required for Mozilla, but hopefully that's big enough to be corrected
> fairly soon.

I would hope so as well.

> Interestingly, I have noticed one of Windows Live Messenger's files being
> virtualised - is this a bug in WLM?

Yes - Vista-compatible programs must not rely on virtualization in order to
function.

>>
>> You are correct that these are the only solutions available to you.
>>
>
> Thanks for taking the time to respond.


You're welcome .



--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/