[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.