Why do even small updates require a system restart

Hi all.

I've often wondered why so many Windows Updates require a System Restart including often quite small updates.

This is akin to having your Mobile Phone provider shut down the network every time for example they want to add new a new suscriber or make an app available.

I remember back many many years ago a popular IBM mainframe application C.I.C.S was a bit like that -- even a small change meant stopping and restarting that application -- In those days there wasn't an Internet so that really was one of the very few "Online" applications available. Of course this was a nuisance to the users and meant that the I.T dept usually had to do their maintenance at night or other times when users weren't on the system.


However technology and programming techniques have surely moved on from the Dinosaur age. I know that sometimes files are locked by a running application but surely these can by a decent bit of programming be moved to a Cache by the OS, the data areas flushed and the application updated without requiring a restart.

These days of 24 hour multi country / Global operation re-starts are a BIG NO NO or a hideous inconvenience.

I've used many Linux systems and its very RARE indeed -- in fact almost NEVER - especially with a Linux server that you need to reboot / restart after routine maintenance.

I'd say that a production type system NEVER needs a re-boot - unless of course changing MAJOR pieces of hardware like a Motherboard or doing a complete OS or Kernel upgrade.

Normal day to day maintenance / software upgrades certainly don't require a re-start.

OK on a home computer not too much of a big deal but in 21 st century it just seems to me that updates etc should be almost painless and run with minimal user interaction - unless as before like Linux you are changing a MOBO / equivalent or re-installing / upgrading the OS.

I'm referring here to typical systems -- of course not those where people are tinkering about with them -- adding / removing hardware etc etc. but normal "Mom / Pop / small office" type systems.

Cheers
jimbo

Its a bit wierd though. Sometimes Windows Update says I can keep using Windows while it installs updates, then afterwards it says Restart to finish installing. Huh? Sometimes theres a you "may" need to restart, in other words its not predictable till windows actually tries to patch the respective files and discovers they are locked. At least when the kernel is updated, the update can be clearly flagged as needing a reboot, there should be no "may" about it.

Hello!

but surely these can by a decent bit of programming be moved to a Cache by the OS, the data areas flushed and the application updated without requiring a restart.

The infrastructure to do this already exists (pretty much; it would need a few additional methods to be added, but all of the "cache" which you talk about, required filter drivers etc. etc. are already written)

Look up the Volume Shadow Copy Service. This has existed prior to Vista, but I am mainly talking about the overhauled Vista/7 one. Knowledge of how VSS works down to the very deepest level will help you immensely. I cannot go into full depth here. Also, remember that (simplistically put) an .exe is copied into memory, and not executed off the hard disk itself. (the actual process is a bit more involved than that)

But there is a reason that it is not used for the purpose you speak of.

Look at these code snippets:

for (int i = 1; i < 6; i++)
{
// Do some magic with array[i];
}

Corrected code:

for (int i = 0; i < 6; i++)
{

// Do some more, better, magic with array[i];
}

OK. Let's imagine that the application's memory has been frozen, and that the code has been switched in and out. Changing code in this way will always be a bit dangerous.

But in the above example, it shouldn't be too dangerous.

But it could, and would have been a lot more drastic. And if pointers become involved, things could become very dodgy, and even create a security vulnerability after an update, but before a restart.

Microsoft could implement an out from under our very own feet policy, and modify the files while the image is in memory, and then leave the image in memory until that image is restarted, but then you have programs with maybe the .exe updated, but a shared .dll not, and the very involved process of updating becomes confused, things get lost, bugs appear, etc. etc.

I personally like things as they are.

And the ones which sometimes require a restart are purely based on whether the target program, for example notepad.exe was in use at that time.

Richard

You already answered your question. Sometimes it is needed to access files that are in use. Would you try to change your oil or do any maintenance on your car while driving it?

Besides, I have two OSX systems in my company and two Ubuntu systems, and both often need to be restarted after updates, so it isn't just a Windows thing.

I mean, if some code gets changed, then the initialisation routines may also be changed. And if the initialisation routines have already run, with the old version, and then the new code executes, all sorts of odd things could go on in memory, with pointers pointing all over the place, uninitialised variables etc. etc. etc.

That was why I suggested the method of replacement of the file but not of the memory image. This solves the initialisation routine problem by not having the new code run yet.

But it also introduces a few new problems:

1) Things could become really messy, and problems galore! But it could be done. Assuming Microsoft perfected it .... (read point two)

2) The image would not actually be updated until it is dropped and restarted in memory. You point to a production server environment. Some applications there never stop until a system restart. And therefore they are not updated until a system restart. But if you then provide the illusion that they have been updated without a restart, then the server may never be restarted, and so fully updated servers would be full of already patched security vulnerabilities!

Richard