Whoops, your comments wound up in my spam queue! Sorry for the obscene delay.

——The Registry——
I can’t believe I overlooked the fact that the Registry is backed up at system restore points! Duh! How would it be able to revert to old settings without having kept a copy of them? Oy.

Yeah, ideally users shouldn’t have to edit the Registry, but I’ve often seen them have to or been told to by a techie who was looking for a quick fix. Then again, this isn’t really so different from telling an OS X user to run a terminal command in its obfuscation level, so there you go.

I don’t believe that the install location of programs should ever be stored anywhere. With no method of keeping in sync the actual location and the Registry/.ini/preference’s value for the install location, problems will always crop up. What if I want to run it from the Desktop while I’m evaluating it? If it breaks because it was installed to the applications folder and can’t find its stuff as a result, then that system is broken.

Uninstalling things should be as simple as dragging to the trash, ideally. Even better would be if when you dragged an app to the trash it it asked you whether you wanted its preferences file and app support folder nuked too. But this wouldn’t have to be through paths, it could be done by name: whenever a .app “folder” is trashed, the system could look in the preferences folder to see if there’s a matching file. If there was, it would parse that file and find any other support folders and files. If the app was installed through an actual package installer, the system would additionally search through its receipt and offer to get rid of its support files. All this could be accomplished without paths to the application bundle at all.

——Abstraction (Start Menu vs. Applications folder)——
From a security standpoint, you’re close to the mark about Mac OS X’s abstraction, but not quite there, I think. Theoretically, a piece of malware could hide inside an application bundle, but this presents problems: with each software update, the bundled apps are updated by throwing away the old apps and replacing them with new ones, which would remove anything bad hiding inside of one. For any piece of third-party software, malware can’t be sure of it being installed at all, and apps that use Sparkle also trash their old selves and replace them with new ones. This leaves vulnerable third-party apps that don’t use sparkle or a comparable updating mechanism. How successful will a piece of malware be that can only target Mac OS X systems with Audio Hijack installed be?

Correct me if I’m wrong, but in Windows, updating an application involves throwing away old files and replacing them with new ones, rather than throwing away the whole C:\Program Files\myApp folder and replacing it with a new one, right? Say \myApp has the following files:

myapp.exe
myapp.lib
dependencies.dll
otherStuff.dll
bigHonkinVirus.exe

If this application updates itself by replacing the files it already knows about, it will ignore the virus hidden inside unless it is smart enough to check for the existence of unknown files, but this could break other things or erase user data that happened to be in there–which is possible since it’s just an ordinary folder (compared to bundles, which do not show up as folders without explicitly ordering them to show their contents). Unless the application completely throws away its parent folder when it updates, it can’t be sure of ridding itself of malware. Or at least this is the way it seems to me. Feel free to correct me if I’m wrong.

But primarily, the reason I prefer Mac OS X’s abstraction (applications folder) is that it’s closer to the source. If you delete something from your start menu, it’s still installed. If you torch an application’s folder in C:\Program Files, its start menu folder is still there, as are its Registry values, meaning it still shows up as installed from Add/Remove Programs and Programs & Features. Even if you uninstall, a lot of rogue programs won’t remove themselves from the start menu or clean up their shortcuts on the desktop and quick launch bar, sadly (although this isn’t really Windows’ fault).

Mac OS X’s abstraction is right on top of the implementation. If you delete the abstraction (the pretty icon) the implementation’s gone too. In order to break an application by tinkering with its frameworks and such, you have to pass through the abstraction—by right-clicking on it and choosing “show package contents”.

——UAC——
You’re right about UAC being privilege elevation when you’re not running an admin user. That’s absolutely correct, and something that I hadn’t even really considered when I wrote the post because I’ve never actually come across a non-admin Vista box. Most of the non-admin users I come in to contact with are in businesses and universities and such, and few have moved to Vista yet. My workplace is among those who have thus far stuck with XP (and Windows 2000, don’t ask).

What I was talking about, though, was when you ARE an admin user, because then you don’t need to put in a password at all. It just asks for confirmation, essentially badgering you for confirmation to do something that you *already* have sufficient privileges to do. I guess it’s cool that it runs as a standard user unless you hit something that needs admin rights, but really, is the dialog necessary? Am I going to decide not to change my desktop icons because I know it requires the admin rights I already have?

Nothing about a password-less UAC prompt will dissuade me from doing what I wanted to do. Keeping underprivileged users from changing settings they don’t have the right to change, fine. It’s teriffic that Vista has this ability. But badgering those who *already have* those rights every time they try to exercise them? It’s totally understandable for UAC password prompts to pop up for non-admin users, but anytime one pops up without a password, that’s basically asking you, “hey, I know technically you’re already cleared to do this, but are you sure it’s the right thing to do? Maybe you should take a closer look.” That’s infuriating to me.

Also, I had no idea that UAC prompts popped up in the center of their parent window! Since the screen dimmed, I never paid attention to anything but the prompt, and you have to admit, that seems to have been the design goal. I can see it now that you mentioned it, but to your average end user it’s sure going to look randomly placed, and regardless of reason, it still has the effect of inhibiting muscle memory, since its buttons are in different locations for each non-maximized window that spawns one.

I realized a little after I wrote the post that UAC prompts would indeed not interrupt something else. I admit I was in the wrong in not editing my post to reflect this, and I apologize for the error.

——UAC re: Virus in installer——
You’re right that a virus hiding inside a an installer or executable is something that all platforms are vulnerable to. But UAC gives you the illusion of security. If you think you’re being protected and you don’t really know the precise way in which the system can fail, you might let your guard down and rely on UAC as a security mechanism.

I’ve known people who did this and got burned as a result. Since previous versions of Windows did nothing overt about security, now that Vista does, people assume they’re more protected and try to rely on it to protect them. If it can’t, then it’s practically worse than nothing at all since it can drive them to unsafe activities without knowing that they’re not secure.

——Price——
Hmm, that’s interesting. I had no idea that previous versions of Windows were so expensive! I’ll admit that I actually did no research. Oops. Perhaps that was a poor idea. Perhaps I will abandon that habit in the future.

Firstly: I completely agree with the main part of your argument regarding the registry: the *nix method (ini files) in superior to it in many, many ways.

A couple of points, however: you are incorrect in saying there is only one backup of the registry. It is backed up (in addition to key system config files) as part of setting a system restore point, which is done on installing new programs, making changes to the system, every so often on a sechedule, or can be done manually. You can roll back to any point (e.g. screenshot at http://snurl.com/1q8hi).

Your observation that the acronyms HKCU, HKLM etc. are cryptic is a slightly strange one: of course the acronyms are cryptic, all acronyms are cryptic; but they’re not referred to (in Windows) by their acronyms. The full names (HKEY Current User; HKEY Local Machine…) are what is used in regedit, are not at all cryptic. The data types used inside the registry (DWord, hexadecimal) are indeed cryptic if you’re not a programmer and aren’t used to them, but the registry is, after all, a database for programs and Windows to store their settings between sessions, and its datatypes are as such ones that will be useful to programmers; end users aren’t supposed to edit it manually.

You note that programs register their location in the registry for various purposes (for example, the path of the uninstall program so that add/remove programs knows where it is) and that if this is changed, you can have problems; but I’m afraid that I don’t see how this would be any different if ini files were used rather than the registry: you’d still need to edit the path in, say, the add/remove programs ini file in my example when you move the program.

(Incidentally, I completely agree with you about programs putting themselves in a subfolder under their company name).

Those are minor points, though; for the most part I agree with you. Now for a major one: your next point is baffling. You complain about the Windows 95 start menu, a way of abstracting users from the underlying program files. And you give a screenshot of underneath the abstraction; the MS Office program files. OK. Fair enough.

But then, “by contrast”, you show the Mac OS Applications folder. Which you seem to be unaware is a Macintosh program launching abstraction, equivalent to Windows 95′s Start menu. It is ridiculous to show screenshots of one OSes application launching abstraction and the other OSes internal program files folder as if the two were comparable. And it’s quite clear that you’re a very experienced Mac user, so surely you must realise that the Applications folder *is* an abstraction, that that’s not ‘all there is’. If you really didn’t, then, well, you’ll know for the future: to see the internal program files behind the abstraction, the analogue to the screenshot you post of the MS office files, control-click (or Right-click) on the application and select Show Package Contents from the context menu.

I completely agree with you on the irony of MS selling antivirus software; though I suspect that if they did try to bundle the capability in with the OS they’d face an antitrust lawsuit of epic proportions from Norton, Mcaffee et al.

What next? Ah yes, UAC. There are a couple of minor problems with your comment on this, and one very, very major one.

Minor problems first: you state that “you are forced to acknowledge its presence and deal with it, even if you were in the middle of something else”. This is rubbish. If a UAC prompt is triggered by a background window (say, a program installing in the background), it will stay in the background until you alt-tab or click on the background window. Next you state that “the dialog box appears in a random location each time to prevent you from being able to quickly click on “OK””. This is also rubbish. It appears in the exact centre of the window that triggered it. Next you say “No, I’m not making any of this up”, which is amusing, since there was no part of that paragraph which you *didn’t* appear to make up.

The major problem, though, dwarfs those into insignificance, and that is the statement that “Note that none of these tasks actually require elevated permissions; Windows just feels the need to make you confirm your action to make sure it was originated by you and not a piece of malware”.

Oh, dear.

UAC is a privilege elevation dialogue. That is what it is, and that alone; its purpose in life, if you will, is privilege elevation.

Just like gksudo or kdesu in Linux. Or Authenticate in… Ummm, Mac OS X.

That’s why your statement is so puzzling: ignorance in someone who’s never come across dialogue-based privilege elevation before is understandable, but the OS you normally use does exactly the same thing! In both, when running as a standard user, you are prompted to enter an administrator user and password to perform administrator tasks. Compare the Authenticate dialogue with the UAC dialogue. The only major non-aesthetic difference between them is that Vista gives you the names of all the administrators, so you just need to remember the password, wheras Mac OS doesn’t. Otherwise, the dialogues are substatially identical.

And the only major difference in functionality between Authenticate and UAC is that, with UAC, there’s an additional mode whereby, if you log on as an administrator, you can choose to run both standard and administrator tokens simultaneously, so programs normally run under the standard user token for security, but if you need to you can elevate programs to the admin token without needing to type your password (when running in this mode the UAC dialogue misses out the username/password entry). Mac OS has no such mode. Other than that, they’re substantially identical in functionality.

(Incidentally, the “sandbox” feature of IE7 is just a byproduct of UAC: IE runs with very low privileges, even lower than standard user privileges; you need to elevate to, for example, interact with other programs on the conputer).

Your situation of a virus embedded in software the user is installing is correct, but again, exactly the same “security hole” is present in all modern operating systems: if the user wants to elevate and knows the admin password, the OS can’t exactly stop them. How could it be any different?

Re the price: Windows 95 Full RRP’d for $209. Vista Home *Premium* RRPs $240. The difference can easily be accounted for by 12 years of inflation.

You’ve made some excellent posts on this blog, as I’ve said in the past; but this, I’m afraid, was not one of them. Fatally badly researched, and the “No, I’m not making any of this up” between two paragraphs both of which were substantially rubbish was especially galling. Dissapointing.