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];
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.