Say what you will about Windows Vista but don’t think that it isn’t a big deal. Regardless of how you may feel about Microsoft, they put a lot of work into the Vista operating system. Sure the UI may not be as snazzy as Apple’s OS X and it is barren of some features from the promised land like WinFS. But there is an awful lot under the hood. Yes it is true that a Vista box really should have a recently upgraded machine to afford the resource costs the OS takes. But if you can afford the machine that runs the OS well rest assured that there are changes worth having. The problem that Microsoft faces is that these changes are not easy to quantify for the average consumer. How would you explain to your Mother about the benefits of the new media APIs? Or try convincing your boss to upgrade the entire IT department so that your machines could leverage PnP-X and Function Discovery. No, the innovations that underline the OS are not obvious to the layman. However there is one exception: security. 

Microsoft has taken on the security marketing checklist item quite seriously. It wasn’t enough to simply say that the OS is secure, they had to prove it. In a world where you are the biggest target for hackers and their ilk, it doesn’t matter much how secure you are because any breach will be heralded as yet another failure. The perception that Windows has a horrible security infrastructure is difficult to shed, even though more security issues were found in Apple’s OS X (64 items) taking an average of 51 days to release fixes during 2006 compared to Windows’ 62 issues with an average fix turnaround time of 17 days ( Symantec’s study of security fix response times shows Microsoft as faster than its competitors. With Vista Microsoft introduces a new way to manage security using the User Account Control (UAC; pronounced like “you-ack”). With previous versions of Windows users would run as system administrators because they would often have to perform administrative tasks. Think of UAC as serving the function of the SU command in Unix; elevating the user to “Super User” long enough to perform some task then falling back to just an ordinary user. With UAC the OS will ask the user to verify the intent when performing an administrative task, asking for administrator credentials if the user is not a member of the Administrators group. This safeguard encourages users to log in as mortals, not administrators. None of this happens if you are logged in using the Administrator account. 

Of course, with great safety comes great sacrifice. The sacrifice that UAC asks for is usability. When I try performing daily computer activities I find myself cursing UAC and all of its frustrating glory. With all of the overhead having to wait for permission seeking dialogs to open then clicking affirmative I find it takes considerably longer to perform even the simplest of tasks. UAC can be disabled, or if you are adventurous using the policy editor you can selectively disable specific UAC features which you don’t like. However, by doing so means that you have become about as vulnerable as you were before UAC.  I have not yet run into show stopping problems with UAC and Perl programming. Nor do I expect to. But it is worth keeping in mind that some functions in a Perl script may inexplicably fail because Perl doesn’t have any concept of process elevation nor any way to determine if a function call (eg. unlink) may fail because the user isn’t running in a privileged or elevated process. Thus your script may run just fine for one user, but fail for another; even if there are no obvious file permission issues.  All in all I am happy that UAC exists. For my users it is a great way to prevent them for doing something regrettable yet enabling me to complete my work. Microsoft’s MSDN Online has an article on UAC that is worth reading. It is a bit dated (September 2005) but still relevant. It is worth noting that the article makes reference to LUA (Limited User Account) which was later (after the article was published) changed to UAC.