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
shared libraries.
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 its DLL's all over \Windows\System32 or some other equally dangerous place, 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 take a crap in your girlfriend's underwear drawer. Of course, those DLL's were already there - and they're in use by half the other programs on the system. Hence, writing to them causes an "Access Denied" error - but the installer has a fiendish backup plan. It will restart you computer, but not before goosing your autoexec.bat file (or equivalent) 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 these particular DLL's, 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 were happy to say "fuck it," save themselves some trouble, and not have to think about how to get their system to handle many dynamic changes of state - from IP address to (once) screen resolution. 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 Capitalism strikes again.