[bruce511]

For the purposes of this reply, I'm talking about packages as distinct from Windows itself.

A reboot is required if something you are trying to install is already in uss. Windows locks executable files and dells while they are being used, so it's not possible for an installer to overwrite them. When an installer detects this it places the new file in a temp store, and windows empties this store on startup,

Thus if you are updating say Java, and the Java binaries are in use, then a reboot will be required. On the other hand if the binaries are not in use, then they won't.

So the need to reboot will vary enormously from one user to the next, based n their habits (do you close the program before updating it?) and also the kinds of programs they have running when they do an update.

Aside: some installers can detect that the program is running and terminate it as part of the upgrade process, thus explicitly avoiding a reboot. That's why say Firefox and Chrome never need a reboot. But that's easier to do with a program, and less easy with a runtime like say Java.

[useerup]

See also the Restart Manager (http://msdn.microsoft.com/en-us/library/windows/desktop/aa37...)

Restart Manager along with Windows Installer will manage stopping and restarting running applications/services to make sure that executables, DLLs, configuration files etc are updated atomically and transactionally.

[kyllo]

Windows locks executable files and dells while they are being used, so it's not possible for an installer to overwrite them

Exactly, and Linux doesn't do that, hence my comment. The Windows model is flawed--why do you need to lock a binary on disk when a copy of it is running in main memory? Linux just lets the installer overwrite the files on disk, so there's no need to restart the whole OS, just the program whose files were updated.

I assume Windows 10 will not change this behavior? A command-line package manager on Windows would be cool, but its utility will be limited if you still need to restart the whole OS just to upgrade a program that's currently running.

[wallyhs]

Why do you need to lock a binary on disk when a copy of it is running in main memory?

Because the copy in memory may still want to use the old version. Raymond Chen explained it here: http://technet.microsoft.com/en-us/magazine/2008.11.windowsc...

[kyllo]

To prevent DLL Hell, in other words.

Again, not a problem on Linux because Linux keeps numbered versions of .so files.

So it's not that Windows has to restart after replacing a file that is in use. It's just that it would rather not deal with the complexity that results if it doesn't.

In other words, "we didn't want to bother with versioning DLLs."

[whoopdedo]

It's more complicated than that. Windows doesn't have true inodes but rather uses the name alone to identify files. So you can't unlink any open file. (Try to delete a directory when you have a command prompt open in it.)

Windows did hack on a form of DLL versioning in the form of isolated assemblies. It's ugly and complicated and Microsoft still resorts to suggesting that you avoid DLL hell by bundling local copies of all your shared libraries. Which kind of makes me wonder why they're even called "shared" at all. May as well just statically link.