On real filesystems (namely everything in Unix and Linux from like the 1970's on), you can safely replace a file with a new one (with the same name) even if it's being held open already -- you unlink ("delete") the old file (or rename it), but the filesystem won't actually delete it until whatever's got it open lets go of it. In the meantime, since the name is unlinked from the filesystem, you're free to put another file there with the same name with new data and it won't change what the existing process sees.
This allows some very useful techniques, like a process opening a temporary file and then immediately unlinking it while it's still open, so no other process can even *see* it, much less poke around in it. The temp file is still there (and perfectly usable by the owning process), but it's inaccessible to the world. This also lets you replace a running executable seemingly in-place without screwing up the older version that's still running.
On NTFS, you aren't allowed to replace a file if it's open by any process whatsoever, because NTFS is stupid. Not even the kernel can do it. Since Windows updates almost always need to make changes to system files that are already open for one purpose or another, this means updates have to be installed in stages.
That's why "we're installing updates, don't turn off your computer" usually only goes to 30% when it pops up during shutdown or restart -- it's just staging the updates and not actually applying them yet. Typically on first reboot the regular kernel and update mechanisms can finish the update -- it'll go from 30% to 100% and let you log in as usual. For "deep" updates that require replacing stuff like the kernel, HAL, core drivers or the update installer, there's a second reboot in the cycle to allow those updates to happen (the first reboot re-jiggers the boot loader to load the new kernel on the second reboot, which then goes back and removes the old kernel again).