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.
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.
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.
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."
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.
Popular installer packages include the "you should restart your computer now" dialog purely as boilerplate, you almost never actually need to do so. This is yet another sad case where the "power users" realized something was a non-issue years and years ago, but the platform holders couldn't properly communicate the fact to the public.
every time seems exaggerated (given that even something major as Visual Studio installs without requiring a restart). Would be like saying Debian always needs a restart after a bunch of updates. Yes it does sometimes, it doesn't on other times.
tip if you want even less restarting on Windows after installing (and less registry rot): always look for portable versions, if you can't find them first just try to get it yourself by extracting from the installer. You'd be surprised for how many installers this wor. Some installers you can just open in 7Zip/UniExtract and the likes and extract, others can be extracted using msiexec /a PathToMSIFile /qb TARGETDIR=DirectoryToExtractTo
Yeah, I guess it's not every time anymore, to the extent that developers tend to just package copies of all their app's dependencies with the installer, rather than try to update a shared DLL that may be locked by another program.
Which version do you have of VS that installs without requiring a restart? Because I have vs2013 ultimate and each time I install it in a new machine I have to restart it (maybe two times if I have also to activate hyper-v)
2013 pro; IIRC it was the same for 2012 pro, rest is too long ago to remember but I'm pretty sure it hasn't been like that always :]. You got me thinking now though: I don't think I ever installed on a fresh machine without any previous installations of VS where possibly the prerequisites would require a restart.
