Vista Security and Notepad

So I've finally get a Vista machine on my desk and erm, I am confused.

I am logged onto the machine using my domain account, and from another machine (where I am logged on using the same account) I have copied a folder from my local c:\program files to the Vista machine's c:\program files.

When I now go to the Vista machine and try to edit a text file from that folder (in good old notepad) I find that I have no permission to save it - okay fair enough, but why does notepad just refuse to save it and not give me the opportunity to authenticate as a user with the correct permissions?  Poor old notepad, it never gets any MS Love^TM.

Well, at least Notepad isn't lying to you. With virtualization enabled, most other editors are blissfully ignorant about the system redirecting it to somewhere in C:\Users\<Name>\AppData\Local\VirtualStore\Program Files

I understand why Microsoft implemented it, but I wish virtualization had been done as a compatibility option on a per-application basis, not a system policy. By default I think it would have been better to let programs detonate because of access errors, and then provide a temporary workaround for the user (via a compatibility option) and as an incentive for the author to fix their broken code which should not be storing data files under C:\Program Files to begin with.

littleguru wrote:

Give it your own love... Run it as administrator (just right click the shoutcut)

Doesn't help opening a file (in my case called .spf) after choosing notepad from the app list - I don't get a choice to run as admin. It also isn't very obvious to normal users.  After 3 hours total with Vista I am so far a bit non-plussed, no doubt it will grow on me ... I fully expect that a lot of issues I'll have will be because I am not used to it yet - it is always the same when moving to a new platform.

"Think simple " I guess something there's a simple way.

Rossj wrote:

Doesn't help opening a file (in my case called .spf) after choosing notepad from the app list - I don't get a choice to run as admin.

You have to start Notepad first (locate it in the start-menu, right-click, run as admin), then you can open the file and save it.

mstefan wrote:

Well, at least Notepad isn't lying to you. With virtualization enabled, most other editors are blissfully ignorant about the system redirecting it to somewhere in C:\Users\<Name>\AppData\Local\VirtualStore\Program Files

I understand why Microsoft implemented it, but I wish virtualization had been done as a compatibility option on a per-application basis, not a system policy. By default I think it would have been better to let programs detonate because of access errors, and then provide a temporary workaround for the user (via a compatibility option) and as an incentive for the author to fix their broken code which should not be storing data files under C:\Program Files to begin with.

But it does let applications decide, if the application doesn't have a manifest then its assumed to virtualize under a 'xp program compatability' thought. Newer programs that contain a valid manifest won't virtualize, and will cause permission errors rather than being 'blissfully ignorant' as you quite accurately stated.

stevo_ wrote:

But it does let applications decide, if the application doesn't have a manifest then its assumed to virtualize under a 'xp program compatability' thought. Newer programs that contain a valid manifest won't virtualize, and will cause permission errors rather than being 'blissfully ignorant' as you quite accurately stated.

True, but the vast majority of programs don't specify "requestedExecutionLevel" and there's no easy way for your typical "dumb end user" to control it on a per-application basis. I would just prefer if they would make the default "off" and have a compatibility option that can be selected.

My other related concern with virtualization is, despite Microsoft's warnings to the contrary, if it's always on by default unless it's disabled by policy (or the application has a manifest), then developers are going to get lazy and come to depend on it. The way it is now, they can just slide on by. I'd prefer the system kick them in the pants, encouraging them to actually fix their code. Ticked off users calling your support line asking why your software is broken is a wonderful motivational tool.

mstefan wrote:



My other related concern with virtualization is, despite Microsoft's warnings to the contrary, if it's always on by default unless it's disabled by policy (or the application has a manifest), then developers are going to get lazy and come to depend on it.

I suspect it'll be a three step policy:

1) Vista: Favour the end-user, virtualisation on by default. Gives developers time to identify and fix issues.

2) Windows 7: Punish bad developers. Virtualisation off by default, developers forced to explain workaround for their crappy software.

3) Windows 8: No virtualisation at all.

Addon: 3) Windows 8: No possibility to logon as an administrator.

4) Windows 9: Windows A.I. will do all the work for you.

Windows 9..... Microsoft was a very good company.... RIP.

or

Windows 9 : No posibility to login. (user is a pure evil which destroys OS and must be eliminated)

Windows 10: Will actually run on windows - like the ones on your house. So everywhere you go in your house you can keep your apps with you. (This works really well if you have a conservatory or greenhouse.)

Linux programmers won't like it naturally as they'll hate the fact that people on the street may be able to figure out what programs you're running, and that it forces them into the sunlight.

In order to combat the Windows monopoly, Linux will be coded to run on bricks and mortar, allowing it to be used in basements.

OSX 10.9 "Lion" will actually run on Lions. Sure they're a little dangerous but it looks so damn cool, plus the iCub is portable and adorable.

BSD will run on real deamons, finally settling the rift between computer science and religion.

Ok, that's enough stupid predicitions of the future.

Massif wrote:

Windows 10: Will actually run on windows - like the ones on your house. So everywhere you go in your house you can keep your apps with you. (This works really well if you have a conservatory or greenhouse.)

Presumably there will be a WoWoW compatability layer then?

mstefan wrote:


My other related concern with virtualization is, despite Microsoft's warnings to the contrary, if it's always on by default unless it's disabled by policy (or the application has a manifest), then developers are going to get lazy and come to depend on it. The way it is now, they can just slide on by. I'd prefer the system kick them in the pants, encouraging them to actually fix their code. Ticked off users calling your support line asking why your software is broken is a wonderful motivational tool.

I'm giving serious thought to adding this to all my dev machines for just this reason

Rossj wrote:

So I've finally get a Vista machine on my desk and erm, I am confused.

I am logged onto the machine using my domain account, and from another machine (where I am logged on using the same account) I have copied a folder from my local c:\program files to the Vista machine's c:\program files.

When I now go to the Vista machine and try to edit a text file from that folder (in good old notepad) I find that I have no permission to save it - okay fair enough, but why does notepad just refuse to save it and not give me the opportunity to authenticate as a user with the correct permissions?  Poor old notepad, it never gets any MS Love^TM.

Hi...I worked on the Save Dialog in Vista.

We understand that this is not the optimal experience. We looked into what it would take to have an elevation dialog here...unfortunately we couldn't due to security reasons. No where in the Shell do we allow the Exploer process to be elevated with a UAC dialog. Since the File Dialog is just a smaller version of Explorer allowing this window to be elevated would be too great of a security risk.

littleguru wrote:



David Washington wrote: Hi...I worked on the Save Dialog in Vista. We understand that this is not the optimal experience. We looked into what it would take to have an elevation dialog here...unfortunately we couldn't due to security reasons. No where in the Shell do we allow the Exploer process to be elevated with a UAC dialog. Since the File Dialog is just a smaller version of Explorer allowing this window to be elevated would be too great of a security risk.

Hi David. Thanks for joining the discussion.

Are there any plans to add a menu entry to the context menu of all files to open them with admin rights in the default editor (selected for the extension)?

Was thinking, I don't think this is the correct route, extensions map pretty much to applications and you can bump those up to admin as is.  Extending the virtualisation concept to say when lauching applications for files that the user does not have write access to, then prompt might be more useful. 

Personally what I would like is a 'Sys-Admin' mode that you could turn on from the UI that will prompt for all apps while your making changes to protected areas.  It should be very visable that your in this mode while it's turned on.  Actuall I would mind to much if I just had to log off and back on to do it.