In defense of Windows Vista's Restart Manager.

First, Mary Jo Foley says, “The technology is designed to update parts of the operating system or applications without having to reboot the entire machine.” That sentence is slightly misleading because the Restart Manager isn’t actually responsible for actually updating anything but we’ll get to what the Restart Manager is really all about in a minute.

Then I came across this article on Slashdot about the Restart Manager with a grossly overstated (and thus inaccurate) title, “Vista To Be Updated Without Reboots.” Of course, the majority of the Slashdot crowd jumped all over the article as a way to point out how updating files UNIX is superior to Windows. I don’t really mind people claiming UNIX (whatever flavor) is superior to Windows (I don’t care, they are all just operating systems to me) but I do have issues when the masses spread incorrect information.

But really it wasn’t until this article showed up on digg.com that I decided to correct some of the technical misconceptions that were developing around the Restart Manager and reboots on Windows in general.

Why are reboots necessary?

Let’s start by explaining why reboots are necessary on Windows for some patches. When the Windows operating system loads a file for execution (usually executable files end in .com, .exe, or .dll) it locks the file such that other programs cannot delete or modify the file while it is executing. The file remains locked until the program exits or is specifically unloaded (for example, you can write your executable such that it can unload dynamically linked libraries). Obviously, this behavior means that if you need to update an executing file that you need to find a way to get the file to stop executing.

There is one twist though. Let’s say the file you need to update is some part of the core operating system. How would you update some file like ntoskrnl.exe or hal.dll? Those files are loaded very early during the boot process and will essentially always be in use. If you can’t delete files when they are locked during executing how could you ever update these files?

The answer is that while the Windows operating system prevents executing files from being overwritten or deleted, it does allow you to rename them. Thus, an update to ntoskrnl.exe requires this four part dance:

1. Rename the executing “ntoskrnl.exe” to something else, say “ntoskrnl.exe.deleteme”
2. Move/copy the new “ntoskrnl.exe” to the location where the old one used to be
3. Reboot (to get the old “ntoskrln.exe.deleteme” to no longer be running)
4. Delete the no longer executing “ntoskrnl.exe.deleteme”

The daring developer might suggest, “Hey! If you can replace the files without rebooting then why reboot at all?” There are two major problems with avoiding the rebooting:

1. The old file is still running. This fact means that if our update was a security patch then you are not actually patched. Until no one is executing that file the security vulnerability will continue to exist. A reboot is the surest (and most heavy-handed) way to ensure that the machine is executing the updated files.
2. New executions of the file get the updated version while the old executions of the file keep using the old file. Having two versions of the same file may not be a problem in all cases but there are certainly situations where it will lead to catastrophic failures. For example, consider a piece of code that is used to communicate between processes. If one process has the old version of the code and a newer process loads the new version of the code there could be unexpected behavior that could, in the worst case, cause one or both processes to crash.

For these two reasons, updates to software that is executing tend to err on the side of safety and request a reboot.

But (insert your flavor of UNIX here) handles replacing files-in-use is better than Windows!

After reading a couple of the Interesting and Informative comments on Slashdot then playing with Reid’s PowerBook running OSX, I think it is fair to say that Windows’s and UNIX’s handling of this particular problem isn’t terribly different. In both cases, a reboot is required any time that you really want to update an executing file that cannot otherwise be stopped.

So the real differentiator on the platforms is how many executing files can you stop when trying to apply updates? And that brings us to the Restart Manager.

What the Restart Manager really does…

…is two things:

1. Locates the processes that are executing files that need updating. This first step is very important and not as straight forward as you might initially think. Sure, it is easy to tell say that the user should close Microsoft Word when updates to Microsoft Word are being applied. But what if Word is being used as the editor for your emails in Outlook? What if Word is being used to view a .doc file inside Internet Explorer? In those cases, the user may not even know Microsoft Word is running. Compound that problem with the many programs that run quietly in the background and the number of programs that may use shared libraries of code. All in all, tracking down the different processes that are currently executing a particular file is important.

2. Provides a mechanism to stop and then restart programs. This part of the Restart Manager is how it got its name. Once the files currently executing are located, the Restart Manager can be used to tell all the different types of processes (both visible and those quietly running in the background) to stop. Equally important to stopping the processes while the updates are applied is ensuring the processes get started again when the updates are complete. In fact, the new Restart Manager API in Windows Vista allows processes to be “freeze dried” and restarted later. I can’t explain how cool it was when I saw the demo where all of the Microsoft Office 12 applications quickly shutdown during an update then re-opened with the cursor in exactly the same place as before the update. This Channel 9 clip shows the same thing on a small demo application (it all happens so fast you don’t even see the application disappear).

At this point I want to make it very clear that there is nothing the Restart Manager can do to prevent a reboot when an update to ntoskrnl.exe or hal.dll is necessary. Stopping and restarting any those files means you rebooted. However, the hope is that updates applied to higher levels of the software stack will be able to take advantage of the Restart Manager feature.

But my (insert your flavor of UNIX here) never has updates that require a reboot!

Well, that means one of the following things:

1. Your operating system is so perfect that there are no security or reliability flaws.
2. Your operating system is modularized such that all updates applied were to modules that could be restarted.
3. Your operating system is no longer supported and nobody bothers to update it.
4. You are exaggerating.

I think it is safe to say that neither #1 nor #2 applies to Microsoft Windows today. Thus, there will continue to be updates to the operating system for a while into the future. Maybe one day reboots will be a thing of the past but not until developers reach a higher level of perfection.

One last thing on reboots, runlevels.

The Informative Slashdot comment here notes that Linux can drop back to “runlevel 3” when doing updates. How much of the operating system is still running at runlevel 3 and below? Or asked another way, how much can be updated at runlevel 1, 2, and 3? I’ve proposed a few times that we should add a ‘happy place’ just above Windows boot/shutdown that sounds much akin to runlevel 1. The question I haven’t answered is, “How much can be updated in such a ‘happy place’?” Or asked another way, “How well is Windows modularized such that a majority can be updated while in such a ‘happy place’?” This is something I want to look at in the future.