Vista - same file name, different file contents 1

[mingis]

It's a repeated question, now to the right forum.

http://www.tek-tips.com/viewthread.cfm?qid=1434846&page=1

Recently I was forced to switch to Windows Vista and am experiencing strange behavior of the file system. In some mystical way there are files, which contents are different when opening them from different programs or different user accounts. Even deleted files sometimes could be opened so far like they were still on the disk. It seems also like the system allows for restricted user to have a "virtual local copy" of protected system files, write them with new data, while admin sees original contents of the same file. The same effect appeared also with HKEY_LOCAL_MACHINE registry keys - they could be written by restricted user (!!!), but the changes are invisible for administrator. And once the ordinary user writes the file / registry key, he does not see further changes of it made by administrator. What's the heck - errors, new sophisticated Windows features ("virtual storage"?), viruses? Vista SP 1 did not help. Thank you.

 

[linney]

The only hiccups I have seen with Virtualization, on my machines so far, is when using applications that are not marked with the made for Vista logo. Things like Ad-Aware SE6, will write the Definitions files to the Users virtualstore as the user does not have permission to write to the Program Files folder. When I tried to run Adaware, the user had permission to read from the Program Files, so consequently it read and loaded an old Definitions file from the Program Files folder.

I found that changing the access permissions to give the user write permissions to the various locations somewhat overcame this "virtual" problem.

As it seems to be by design, although I have heard rumors that it might be dumped for the next operating system, I don't know what else you can do?

File and Registry Virtualization – the good, the bad, and the ugly

http://windowsconnected.com/blogs/j...ualization-the-good-the-bad-and-the-ugly.aspx

Vista's new file redirection to the new "Virtual Store" breaks my app - any advice?

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=724064&SiteID=1

http://www.google.com/search?hl=en&...&cd=1&q="virtual+store"+disable+vista&spell=1

 

[mingis]

Thank you very much for responce.

First impression - virtualisation is the worst thing they could have invented. Well, at first look it seems good to have possibility to perform some local installation attempts without looking for administrator password. But it means allowed writing to the executable files in the Program Files directory. Allowed am not only me, allowed are also viruses running under my account. So it seems to be a total loss of infection resistance. Well, the whole machine remains intact, but my local environment could became totally littered. Am I wrong?

Time to go search how to make my applications Vista compatible. Or how to switch the whole stuff off. My approach for checking, whether I am allowed to write the file was simply to try open that file for writing. Should be changed to something more complicated...

 

[linney]

I have been using computers for years and I am still waiting to catch a Virus. I guess it depends a lot on one's surfing and downloading habits. Any file that is being written on the hard drive would have to get past any firewalling and a check by the Anti Virus software.

Many programs write to logs files, or as in my example, update files in the Program Files folder. As to the Virtual Store, I have never seen any warning that files are being written there, it seems to be done in the background and hidden from sight. I suppose making more use of the "Run as Administrator" option on older programs might eliminate Vista's use of virtualization?

 

[mingis]

Found the solution:

1. Install Microsoft Application Compatibility Toolkit 5.0

http://www.microsoft.com/downloads/...e9-b581-47b0-b45e-492dd6da2971&displaylang=en

2. Run Compatibility Administrator, press toolbutton "Fix", enter your application name, location, Compatibility: None, Compatibility Fixes: mark checkbox NoVirtualization. File/Save As - save compatibility db file "myprogram.sdb".

3. sdbinst.exe myprogram.sdb

That's it.

PS.
The whole story:

http://technet2.microsoft.com/Windo...2b2f-422c-b70e-b18ff918c2811033.mspx?mfr=true

It seems like MS Win98 freak developers of nothing to do now move around features invented in WinNT ages ago, trying to push them into Win98 understanding level and ear money from nothing - inventing the weel. Or slowly and carefully teaching Win98 users to switch from uncontrolled to UAC-ed environment, writing tons of papers, developing dozens of features, but totally obscuring and complicating the main simple and clear message: no more unrestricted access.

Spiral float of evolution:
Win2000:
"many enterprise IT departments have no other option but to make all of their users administrators."
So, let us kill NT security at all in WinXP:
"By default, <...> the Windows XP Setup Wizard creates all user accounts as local administrators."
But:
"Unfortunately, running your enterprise workstations as administrator also makes your network vulnerable to “malware”—the overarching term for all malicious software, including viruses, Trojan horses, spyware, and some adware."
So, let us invent virtualization in Vista. But it is not so nice too, so it should be considered as "short-term fix and not a long-term solution".

I predict in Vista-2 they will tell - well, virtualization is not so bad - let's continue to use it so far.

IMHO, virtualization is good feature, "Run As" too, but in no case as default presetting. Internally in API level "Run as" elevation is present there, I think, also for years. I did not understand, what's actually new int that whole UAC stuff? Well, except virtualization, of course. My proposal would be to implement virtualization as a "Run Virtualized" mode, parallel to "Run As" - for those, who don't know admin's pasword or don't want to harm the whole system using bad designed Win98 applications.

 

[dilettante]

Virtualization may not be carried forward to future Windows OSs (such as Windows 7). UAC almost certainly will, even though it may be altered a little - and even more likely renamed to get away from the bad press surrounding the "UAC" name.

The purpose of reg/file virtualization and the other AppCompat shims is to let old programs continue to install and run under Vista even though they may do forbidden things. For the most part in prior Windows versions these "things" (like writing to Program Files folders or HKLM keys) have been advised against since the Windows 2000 days and before.

For the first time in Vista we have to play by the rules. This has been a bit of culture shock, since many of us were only dimly aware of these "rules" if at all.

If a program that does not advertise itself as "Vista aware" (via manifest entries) writes to someplace like "Program Files" it won't be aborted. The activity gets virtualized to a per user psuedo-Program Files location.

If a program is marked "Vista aware" such an operation causes the program to be aborted. This will also occur if you've marked the program as requiring AppCompat shims with "No Virtualization."

In both cases the process prevents malware from altering or overwriting legitimate Program Files executable code with virus or trojan code. That is the goal.

Turning off UAC defeats almost all of the new protections in Vista of course.


We've had this information (and several testing tools related to it) available to us for almost two years now. Microsoft began publishing the stuff around the time Vista betas became widespread. The same sorts of assistance are out there now for 2008 Server but I suppose just as few people are reading and following that advice now.

It isn't whether you get viruses, it's a question of whether you want your programs to open the door to viruses on a user's machines. This is what happens when you require elevation for no good reason except to work around the rules of the road. Even more dangerous is installing into fully read/writeable locations. The worst is telling users to run w/o UAC.


I'm not a huge fan of micromanaged corporate networks with everything locked down to a point where users can't do anything but send emails. However poorly behaved software encourages admins to do just that - and effectively ban your software from their networks.

As it turns out there aren't that many things we need to do differently in new programs to be good Vista citizens. Old programs need to live with the shims or will require a reworked version.

Maybe a more productive discourse would be to catalog the sorts of coding changes we need in order to make programs work better under Vista and 2008 Server. Along with that we could describe practical ways we find to comply with these requirements.

 

[mingis]

For the first time in Vista we have to play by the rules.

No, by the rules we played in Win2000. In Vista there is virtualization switched on by default, allowing old programs to do bad things without any hint about any rules and even about what is actually going on.

Virtualization may not be carried forward to future Windows.

I see one good further application for virtualization - allow users to install and manage theyr programs without waiting for help from IT department. Admin Approval Mode is, of course, a good solution for that (I have finally understood it). But I'm sceptic, that all enterprizes will allow theyr employes to run under admin accounts.

 

[dilettante]

Per-user MSI installs can already be done by non-admin users unless prohibited through Group Policies... until Vista:

Specifying a Per-User or Per-Machine Installation

Of course by not setting ALLUSERS you can still create working per-user, non-admin MSI packages I believe, or just install via:

[tt]someapp.msi ALLUSERS=""[/tt]

I'll have to test that.