Author Topic: Stay Away From Microsoft VISTA (Read 69796 times)

Renegade · « **Reply #25 on:** September 06, 2007, 07:07 AM »

There is nothing to prevent them from doing so, but in .NET you're not supposed to use the registry for app settings - there is a whole different system for that.

Perfectly illustrates my point about bad programmer habits
-MrCrispy (September 06, 2007, 12:51 AM)

Couldn't agree more.

I went over some of this in a podcast about application settings. Well, part of it was about application settings.

The real kicker is that in .NET it's MUCH MUCH harder to use the registry than to do things properly. That anyone would bother using the registry in .NET is simply amazing to me.

Here's the .NET way (bascially):

SomeSetting = SomeValue;
Settings.Save();

Done.

Edit: Corrected Typo.

Eóin · « **Reply #26 on:** September 06, 2007, 07:59 AM »

I too think that sometimes you have to cut the past loose. I myself always write my programs for unicode which limits me to Win 2k and better. But I think the advantages of unicode and support for multiple languages far out weighs the negatives.

f0dder · « **Reply #27 on:** September 06, 2007, 08:05 AM »

I too think that sometimes you have to cut the past loose. I myself always write my programs for unicode which limits me to Win 2k and better. But I think the advantages of unicode and support for multiple languages far out weighs the negatives.
-Eóin (September 06, 2007, 07:59 AM)

What about MSLU/Unicows?

Renegade · « **Reply #28 on:** September 06, 2007, 08:05 AM »

I too think that sometimes you have to cut the past loose. I myself always write my programs for unicode which limits me to Win 2k and better. But I think the advantages of unicode and support for multiple languages far out weighs the negatives.
-Eóin (September 06, 2007, 07:59 AM)

Agreed, but in the case you describe, ditching 98/ME only means ditching an audience that would never buy anyways.

Not much in the way of real negatives for ditching 98/ME.

As for "far out weighs the negatives"... I think you meant to write:

far out weighs the negatives...

mouser · « **Reply #29 on:** September 06, 2007, 08:07 AM »

I think some of the comments about backward compatibility warrant a further comment from me.

There are always very difficult choices to be made when balancing backward compatibility with new features. I think MS makes a reasonable choice to preserve backward compatibility. Yes it does make things messier. Apple is more willing to throw out stuff when they write new APIs, maybe that's just because they have a smaller developer pool which is more willing to be told: your code won't run on the new stuff, rewrite it.

However, the virtual store stuff that microsoft implemented for vista is to my mind, exactly the wrong approach for this kind of thing. In fact i think it's a textbook case of how NOT to handle backward compatibility.

The idea that they are quietly behind the scenes creating mirror copies of files and tricking programs (and users!) into think they are working with one copy of a file (or registry key) when they are really working with another, is so clearly a bad idea that they should have fired they guy who dared to suggest it. Don't even give him the end of the day to clear out his office.

The proper solution would have been simpler, clearer, safer, and better for everyone. When a program is attempting to access files it's not allowed to in one of these privileged directories -- prompt the user, explain the problem, and let them switch the program to run in "compatibility mode" where it IS allowed to access these directories like it could in WinXP, etc. If they want to run it in compatibility mode, fine. If not, don't run it. If you then wanted to let them switch into some insane virtual store more, with a huge warning, you could even do that (though if you ask me i wouldn't provide such an option).

f0dder · « **Reply #30 on:** September 06, 2007, 08:13 AM »

The proper solution would have been simpler, clearer, safer, and better for everyone. When a program is attempting to access files it's not allowed to in one of these privileged directories -- prompt the user, explain the problem, and let them switch the program to run in "compatibility mode" where it IS allowed to access these directories like it could in WinXP, etc. If they want to run it in compatibility mode, fine. If not, don't run it. If you then wanted to let them switch into some insane virtual store more, with a huge warning, you could even do that (though if you ask me i wouldn't provide such an option).
-mouser (September 06, 2007, 08:07 AM)

Simply fix the NTFS filesystem permissions of that _one_ application folder to allow non-admin access.

Carol Haynes · « **Reply #31 on:** September 06, 2007, 08:45 AM »

How about letting installed apps be 'pseudo-users' (say initially in the 'applications user group') like System, .Net or ASP users - then you can use user settings to set what access each application has very specifically. If certain settings are required to use an app for everyone using that app it could be set up in the installer with appropriate warnings to system administrator doing the installation (eg. via popup permissions and in the system log each instance of changed access rights could be noted with specific details).

f0dder · « **Reply #32 on:** September 06, 2007, 09:39 AM »

It could be called "Legacy Applications Group", or LAG

- might seem a bit messy to do it this way, but certainly less messy to use a feature present since the initial NT/NTFS days, instead of the shoddy way it's done in Vista.

Eóin · « **Reply #33 on:** September 06, 2007, 09:51 AM »

What about MSLU/Unicows?
-f0dder (September 06, 2007, 08:05 AM)

I suppose the only real issue is that I don't have access to a win 98 machine to test on. But in these days of running VMs that's not really an excuse, I still have an original Win 98 cd.

wraith808 · « **Reply #34 on:** September 09, 2007, 03:45 AM »

Mouser- the "feature" that you complain about has actually been around for a *long* time- it's just that most users don't run afoul of it in general use. Try running a program over remote desktop that uses the windows directory or the registry. I dare you...

You'll run into the same problem, because Terminal Services virtualizes the registry and the windows directory. It's not as aggressive with the whole keeping the old versions, which I'm sure is a pain. But it's been around for a while and too few people made waves over it- I've coded around it *at least* three times. But that's what you have to do in the end- code around M$'s mistakes ^H^H^H^H^H^H^H^H designs and be ready to remove your hack when they get things right... $:-\$

uryan · « **Reply #35 on:** September 09, 2007, 09:09 AM »

Mouser, I don't really see how MS could have done it any other way. Prompting for a 'compatability mode' that allows access would break the concepts that limited users shouldn't be able to modify the program files directory and that different user accounts should have individual settings. Although it may have been good to include a few different options since there is clearly no one size fits all solution.
In the end, Microsoft have for a long time been telling developers they should not store program settings in the program files. It was completely undermining the user accounts system, and it got to the point where they decided they needed to do more about it.

mouser · « **Reply #36 on:** September 09, 2007, 09:30 AM »

My main point, which I really feel strongly about, and which i think touches on the same kinds of horrible problems with a wide variety of systems (including CSS, html, etc.), is quite straigtforward, and let me phrase it as a design rule:

When bad behavior is detected, do not try to "help" the user by quietly accepting the error and using hidden confusing procedures that silently try to "correct" the problem by the scenes, and end up hiding and obfuscating what is really happening and where the problem is (or in fact that there is a problem at all).

A less specific way to say it is: Report errors explicitly, and adapt to them in the most straightforward transparent way as possible. If the problem is a backward compatibility issue, and you need to allow the program to run, then Explicitly report the compatibility violation to the user and ask them to explicitly enable a compatibility mode, and explain the effects of this option.

mouser · « **Reply #37 on:** September 09, 2007, 09:37 AM »

I think i can state it even more clearly, and I crown this: "The Rule Of Harmful Protection"

"Do not try to be clever by hiding actions you perform to protect the user -- you will only hurt them in the long run."

Nudel · « **Reply #38 on:** September 09, 2007, 09:40 AM »

IMO, programs should not be modifying files in any location that gets virtualised in the first place. If it causes problems then the program was probably wrong to start with, and had been wrong for a long time (NT4). (I still run plenty such programs, though, and I'm glad they worked by default when I switched to Vista.)

Adding manifests to things is usually easy (there are some exceptions, like InstallShield exes) and programmers have had to do that since XP, anyway, in order to get the new-look controls. It's just another line in the same manifest file.

The virtualisation stuff can be confusing, I agree, but I think it makes sense given the alternatives. Hopefully it can go away in the next version of Windows after Vista forces developers to *finally* pay attention to the rules about where to store data (which, when ignored, usually meant those programs didn't work without admin rights in NT4, Win2k and XP).

The only thing like this that I feel MS messed up with is the way 64-bit works. Apparently with the aim of making it as easy as possible to recompile apps with hardcoded "System32" paths and so on (which should not be hardcoded in the first place; there's an API to get the system directory), they've given us a weird OS where different apps see completely different folders/registry and 32-bit binaries are in directories whose names end in "64" while 64-bit binaries are in directories ending in "32". God knows what 128-bit Windows will look like.

Maybe MS were worried nobody would port apps to 64-bit if it wasn't trivial but it turns out people are having to port anyway as their users are going to 64-bit Vista (sometimes for good reasons, sometimes just because 64 is a bigger number than 32, heh). It also turns out that doing a search & replace for "System32" in your code (or even making the code call the API like it's supposed to) is a trivial job compared to inspecting and testing for all the other 64-bit errors that come from bad pointer casts (almost always due to the archaic way Win32 casts everything to LPARAM/WPARAM/BOOL/etc.).

Nudel · « **Reply #39 on:** September 09, 2007, 09:47 AM »

Can you give an example of a real problem that virtualisation has caused? It seems to affect settings and other files written by programs more than it affects any documents explicitly saved/edited by the user.

I agree that a message might have made sense saying "it looks like this program is crap, do you want to enable virtualisation for it?". That'd be annoying for the first day or so but after that they'd all be set up... Then again most users would just click Yes without understanding the consequences, so what difference does it make? People who understand what's going on can simply look in the virtual store folders to see which programs have been affected.

I disagree that UAC itself is bad. I think UAC is a good system and is designed in the only way it can be. The problem is how the APPLICATIONS use UAC, and especially Explorer. The amount of prompts that Explorer displays is ridiculous but that's the fault of Explorer, not UAC. UAC is actually quite flexible and, I think, well designed. Explorer of a load of crap, but then it always has been. Try Opus for fewer UAC prompts (e.g. 1 prompt when you create a folder in a protected location, instead of 4 with Explorer) as well as for a timed administrator mode (like on the Mac). All of that is done via the UAC mechanism without using any hacks or undocumented tricks. Explorer gives UAC a bad name.

Nudel · « **Reply #40 on:** September 09, 2007, 09:56 AM »

BTW, You can turn off Virtualisation via the Local Security Policy control panel. Local Policies -> Security Options, then the last item in the list: "User Account Control: Virtualize file and registry write failures to per-user locations".

f0dder · « **Reply #41 on:** September 09, 2007, 11:20 AM »

BTW, You can turn off Virtualisation via the Local Security Policy control panel. Local Policies -> Security Options, then the last item in the list: "User Account Control: Virtualize file and registry write failures to per-user locations".
-Nudel (September 09, 2007, 09:56 AM)

Nice!

- something to keep in mind once I'll have to move to Vista.

MrCrispy · « **Reply #42 on:** September 09, 2007, 03:09 PM »

Mouser, the problem with your rule is that it breaks applications. To the user, if they run something and are prompted with dialogs they cannot understand, it is broken.

The deeper issue is even if they are prompted, the only way to let the app run is to virtualize. The compatibility mode you speak of cannot allow the old app unlimited access to the real parts of the system and hence must virtualize them. From the POV of an old app, there is no problem and no error, and it must remain that way - thats the definition of backward compatibility.

So as I see it, your issue is with the 'silent operation' and not the actual technology. Is that right? If so I don't understand why it is so - an OS does so much 'behind the scenes' thats its silly to expect users to be involved in these decisions. You might as well complain that the OS should notify the user whenever the page file is used because an app is using too much memory, because the page file is slower.

The way it is done, both old and new apps continue to run. I suppose the key is how you define 'problem ' - is it something that affects the user experience or is it something technical that programming can take care of.

mouser · « **Reply #43 on:** September 09, 2007, 03:22 PM »

The points that you guys are making in favor of the virtualization are not unreasonable but let me disagree.

First, to the point that several have made that "The deeper issue is even if they are prompted, the only way to let the app run is to virtualize. The compatibility mode you speak of cannot allow the old app unlimited access to the real parts of the system and hence must virtualize them."

I disagree. There are lots of cases when VISTA+UAC allow programs to write to the "real" registry and the "real" directories like \Program Files. In these cases, the UAC pops up and requires user to enter an admin-level password. There is absolutely no reason that Vista couldn't prompt users if a program tries to access these directories.

I assert that a more general fundamental flaw in VISTA UAC is that it doesn't have the ability for users to greenlight applications for admin access just like a firewall, though i understand that some people might disagree with this. Either way, I see no reason that instead of virtualization (or indeed PRIOR to defaulting to virtualization), VISTA shouldn't pop up a message asking user whether the program should be authorized to access the directories or else virtualized. I believe virtualization is a horrible last choice resort, and should be treated as such, and that it is not something that should be done silently behind the scenes.

The point was made "what's so bad about virtualization"..
As I explained in my original post, virtualization creates mirror shadow copies of files, hidden deep in a directory no user is ever going to find. The files are hidden from the user, where they will never be backed up or accessed. Instead the program thinks its modifying files in one directory and so does the user. When they user goes to look -- he/she may find files there with the names they expect, but guess what.. they aren't the files the user has actually been working with. If the user deletes these files from the real directory.. guess what, they aren't really deleted, since the program will find the invisible hidden files in the virtual store. If the program tries to delete or rename files, oops, they are working with the virtual hidden files, and so god help it if there are files with that name in the native directory. It's a total travesty in my opinion, and prone to some very confusing experiences and potential user data loss. This is not like notifying the user about using a page file, which is simply a performance issue, this is about causing serious confusion both to users and to the programs, which think they are working with one file when really they are working with another hidden one.

mouser · « **Reply #44 on:** September 09, 2007, 03:28 PM »

Also,
It's fine to say: Programs shouldnt be writing in those directories. Perhaps we can all agree with that.

The question is: What's the best way to handle programs that don't obey this good practice standard. My contention is that MS chose the WORST solution to this backward compatibility problem. They could have:

1. Forbid programs from running that try to do this -- breaks backward compatibility which is not desired, but at least it forces compliance and good practices. Probably not acceptable because people need to use non-compliant programs.
2. Create some insane hidden complicated behind the scenes silent virtualization tool which creates confusion for both programs and users about what files are really being accessed at any given time. This is the solution MS went with.
3. Create a compatibility mode so that admins can mark certain programs which are able to access directories and registry as in WinXp/2K. Warn user if programs attempt this and let them indicate that the program should be treated this way. I contend this would have been best solution to handle backward compatibility. (letting programs write to their own home directory by default would be good idea too, imho).

mouser · « **Reply #45 on:** September 09, 2007, 03:40 PM »

One last point:

If you believe that it is BAD for programs to write to the registry or their directories in Program Files (which everyone who approves of virtualization seems to agree upon here), then you should be APPALLED by the MS solution which is completely SILENT when a program does this. No warning is displayed, no notice to the user saying "this program is doing something bad", and no notice about what is being done about this. To me this is the grossest, clearest flaw in the approach, and i find it inexcusable and harmful, with no redeeming aspects.

It's like if you go to have your car inspected, and the mechanic finds a hole in your gas tank, and puts a little piece of tape over the hole. When you come in to pick up your car the mechanic says: everything is fine. Later on a long trip the tape falls off and you run out of gas in the middle of nowhere. When you call the mechanic he says "well i didn't want to bother you by telling you about the problem so i just handled it."

MrCrispy · « **Reply #46 on:** September 09, 2007, 03:48 PM »

I disagree. There are lots of cases when VISTA+UAC allow programs to write to the "real" registry and the "real" directories like \Program Files. In these cases, the UAC pops up and requires user to enter an admin-level password. There is absolutely no reason that Vista couldn't prompt users if a program tries to access these directories.

UAC is for security - it has nothing do with compatibility. You could disable UAC and never see the prompts. Virtualizing is a way to ensure old apps work. Its like emulation and CANNOT be replaced. e.g. Windows can (and has in the past) change the location of imp registry keys and yet still let old apps that need them work. This is impossible to do without virtualizing, because the old app doesn't even know about the 'real' stuff. I cannot stress this enough.

The files are hidden from the user, where they will never be backed up or accessed. Instead the program thinks its modifying files in one directory and so does the user. When they user goes to look

That is the entire point - the user should not have to go look manually at these locations. Please give an example of the problems you point out.

If you believe that it is BAD for programs to write to the registry or their directories in Program Files (which everyone who approves of virtualization seems to agree upon here), then you should be APPALLED by the MS solution which is completely SILENT when a program does this. No warning is displayed, no notice to the user saying "this program is doing something bad". To me this is the grossest, clearest flaw in the approach, and i find it inexcusable and harmful, with no redeeming aspects.

1. It lets the program run. This is the most imp thing.
2. The app is not writing to program files or the registry, it thinks it is. A user should have NO reason to look at those directories or registry keys because all user data should be stored in the user data folders, for which a standard API has existed since W95.

Please tell me why you consider it a flaw and harmful other than the fact that you don't agree with it.

Let me give another example. I don't know if you've used VSS (volume shadow copy) which is a Windows service that virtualizes the entire file system to allow programs such as backup, system restore, previous versions in Vista etc to take snapshots of a live filesystem. It is completely transparent, high performance and absolutely indispensable.

I would also like to point out that virtualization (man it seems like I'm saying that every 3rd word

) is technology that is being used in nearly every consumer and server level OS and hardware. It is here to stay.

mouser · « **Reply #47 on:** September 09, 2007, 03:55 PM »

Mr Crispy, it seems to me that your arguments may make sense but only each in isolation and not as a whole cogent argument.

you say:
"2. The app is not writing to program files or the registry, it thinks it is. A user should have NO reason to look at those directories or registry keys because all user data should be stored in the user data folders, for which a standard API has existed since W95."

Which is all fine and well in terms of the ideal case where a program is saving everything in user document folders..
but the whole point of the problem is how to handle programs that DONT just write files in user document folders.

If it was the case that the program was only saving files in User Data folders then this whole discussion is moot.

The entire discussion revolves around the case when the program is behaving like a "portable" app, saving settings and files in its home directory for example.

The ground rules for this debate are: How do you handle programs which save files (settings, user documents, etc) in folders other than the ideal User Documents directory. It's no use saying "programs shouldn't do that", that's not the issue. The issue is how do you preserve backward compatibility for these programs.

I listed my prefered solution to preserving backward compatibility and described why i think the MS choice was horrible. You surely disagree with this for rational reasons, but it's no good to say that you disagree with me because programs shouldnt be writing to their program files subdirectory, since i'm not arguing that they should -- i'm only arguing about what to do when they try to do so.

mouser · « **Reply #48 on:** September 09, 2007, 03:57 PM »

You asked for an example of when the VISTA solution leads to horrible results as i claim.
Here's one:

Imagine a legacy notetaking program.
It starts out when installed with a data file called Notes.data in its program directory.
As user adds notes, they get added to this Notes.data file.

MrCrispy · « **Reply #49 on:** September 09, 2007, 04:01 PM »

Another perspective - applications are written to use an interface. The implementation of that interface is upto the OS and can change at any time. The only contract the OS has is to provide an old interface to existing apps so as not to break them, but it doesn't (and shouldn't) have to offer the same implementation. If an app depends on that, it is wrong.

Let me use an analogy - say you are an analyst and call a company to talk to their CFO. You always say to the receptionist - 'can I talk to the CFO' and she transfers you to Steve. Well after a few calls, you just get Steve's personal number (instead of his extension) and call him directly. A few years later, Steve is fired (all those millions he embezzled!). So now you can't reach him because you are not going thru the proper API (interface). However, for those people who call his extension, the company puts in place a redirect in the PABX system, so that anyone who calls Steve is actually transferred to Lisa. The same applies to his email. Steve is now virtualized.

The reason this works is that people don't want to talkt o Steve, but the CFO. And apps should also not write to hardwired locations.