There are a variety of reasons why this happens. None of them good. Typically, it is not the result of "change at the kernel level" - hardly anything does that,
unfortunately; rather, it is most often the result of the rather simple read and
write locking scheme implemented in
32-bit Windows, and an unfortunate lack of organization in the way said operating system manages
libraries, and other dependent changes of a software package.
You see, when you install an application, it comes packaged with a few DLL's - these are often the same few for almost every application, but slightly different versions. The application's installer, out of some kind of nihilistic glee, likes to simply spray modifications all over your system, sometimes without caring too much what was there to begin with. This is a little like inviting a friend over only to have them get drunk and leave their shit all over your house. Of course, things that got changed overlap with things that were already there, or things that were already set up - and are depended on by half the other programs on the system. Hence, writing to them may have no effect, or fail - but the installer has a fiendish backup plan. It will restart you computer, but not before goosing your startup scripts to copy in its new files, and make any other changes, that it had been locked out of before, during the restart process.
"But why does every single program I try to install want to replace \winnt\system32\msvcrt40.dll with its own copy? Might that not create a dangerous unversioned dependency problem?" you ask... And the answer is... YES! That's exactly right, it will. The upside, as they must have spun it in Redmond, is that the OS has so many bigger problems, no one's likely to make a big stink about that one. Nonetheless, after a few months, your \Windows directory starts to look like the crackhouse master bedroom.
It goes beyond any one library, of course. There are plenty of things that the installer might be trying to modify that it must defer until that magic moment during restart when nothing has really started yet, and hence nothing can be locked - data or ini files, perhaps registry entries, and so forth.
As usual, it gets worse. Changes to system settings open up a whole new domain of problems. Unix system designers generally had to make provisions for almost any kind of maintenance to be done on the system without bringing it down - since a shutdown would likely affect many people. Ah, the days of big iron. Windows programmers had no such constraints, and chose to save themselves some trouble, and not have to think about how to get their system to handle many dynamic changes of state. It's not a lot of work in the scheme of things - mainly a matter of good design - but Microsoft didn't have any imperative to worry about that. Laissez-Faire strikes again.