Why is it sometimes that I need to restart my computer after installing new software and at other times I don't?
Is there any reason why it needs this reboot or why it's not always one way or the other?
Why is it sometimes that I need to restart my computer after installing new software and at other times I don't?
Is there any reason why it needs this reboot or why it's not always one way or the other?
It depends.
If the software being installed affects an integral part of the operating system then a restart is required. For example a new kernel for the operating system.
On Windows systems, it is often used used because users are considered to be too stupid to use their computers properly. As an example, Microsoft publishes details of how to change the "Node Type" used for networking on its website, including the instruction to "restart the computer" when all that is required is a restart of a network service as detailed here. Because we, as users are too stupid to restart a service, we are told to restart everything.
For some pieces of software, I have come to the conclusion that it is a habit and is often not necessary even when told to do so. If I don't think that a piece of software should have done anything major to the operating system, I tend not to bother, and haven't experienced any problems (and if there were problems they would be easy to solve).
Sometimes a piece of software will make a change that cannot come into effect while the computer is use. Some reasons might be - a file is in use, the change can only occur during boot up of the computer, there might be a security issue which can only be done before the computer has its networking active, maybe the virus scanner would interfere with the install.
Sometimes, it's just sloppy programming by the developers.
I'm sure there are many more.
Often when you install new software a DLL (file) that is used by lots of other software packages need to be upgraded to a new version. (This much more likely to be the case when upgrading an application you already have installed.)
If the DLL is being used by an running application, part of it will be loaded into memory and the rest will be read from disk when it is needed. Therefore the DLL will be locked on disk. (Think of the problems if it was not locked!)
A DLL that is locked cannot be updated, so the installer will ask windows to replace the DLL with the new version the next time the machine is restarted. Hence the need for a restart.
Some better installers will tell you the applications that should be closed down before running the installer, so letting the DLL be updated without a restart. However that make the installer’s UI more complex and leads to more support calls.
An installer for an application can also get the application to save its state, shut it’s self down, then restart after the DLL has been updated. This can only be done if the DLL is used by a single application. Most self updating applications do this – this should be the norm for mass market applications when there are lot of users.
All of the above can lead to complex logic that is hard to test. Testing installers takes a long time, as you need to try to guess every state a user’s machine may be in. So it is often best for an installer to be simple and always work, even if it leads to a few more restarts for the user.
It is not often that a user decides to buy a different application due to installer restarts, so the vender spends the time (money) working on what is needed to get user’s to buy their applications.
How often have you had a problem after installing an application that sorted itself out when you did a reboot? Think of the support costs of lots of users phoning up with problems that are sorted out just with a reboot. It can quickly become very tempting as a developer to always get the user to do a reboot after installing your software even when you think it is not needed.
Most operating systems and software were written in the days when diskspace and memory cost a lot of money. There is now a move for applications to have a private copy of all DLLs they use, hence making upgrading easier, but using more storage space.
On servers this is being done with "containers", however "containers" don't work well for desktop software, as you wish to be able to access the data saved by one application with anther application. (Otherwise just use a iPhone.)
The reason is because if you don't: you will crash. From Raymond Chen:
Even if you replace a file that is in use, there may still be code in the system that wants to use the old version. For example, suppose you have two files which work together:
- A.dll
- B.dll
You issue a patch that updates both of the files, but
A.dll
is in use. No problem. You simply replace both of them. As a result, programs that were still usingA.dll
keep using the old version, but new programs will use the new one. And all programs get the new version ofB.dll
.Now a program that was using the old
A.dll
decides to call a function in. It naturally expects the old version ofB.dll
, but instead it gets the new version. Depending on what sort of change you made toB.dll
, this call may work—or it may crash. Both DLLs assume that its partner comes from the same matched set.
To be completely honest, it's less work (and therefore less $$) on the part of the software developers to assume that updates will always result in a restart. This is probably as much a decision of the bean counters as it is of the developers.
Ultimately, there are very few updates that could not, in an ideal world, be done without restart, but it takes a lot of pre-planning, and there are some risks, given the wide variety of possible configurations a system might have.
It has to do with the fact that it is very hard to change code as it is running without causing some major problems. The solution: stop everything before changing the code, that way you can be sure nothing is running. It is a brute force hack that is largely unnecessary a lot of the times that it is supposedly required, but it can be absolutely necessary, especially if you happen to be updating particularly important code. There is actually an entire company that specializes in making updates that DON'T require a reboot for this particularly important code. The way that they do it is in this paper http://www.ksplice.com/paper.
You're required to restart when important system files for Windows are being modified, because Windows does not allow these files to be modified while they are in use. So most updates from Windows Update require a reboot, as do programs that integrate themselves into Windows (like antivirus). Until you reboot, Windows cannot perform the last few steps necessary to "install" the program.
You can compare this to Linux, which rarely requires you to reboot. Even when you are asked to reboot, you usually only need to log out and back in. This is because a typical Linux environment is comprised of many different separate programs that work together to create a complete OS. If an important file is modified during an installation, you usually at best only have to restart the one specific program that uses the file.