If memory serves, Microsoft cannot actually do it, due to differences in file system semantics. In Windows, it's not possible to replace a file that's in use.
Unfortunately, the last time I had to do system-level Windows programming was such a long time that all I remember are a bunch of things starting with hwndsomethingsomething, so I certainly don't remember if this is the case, nor the specifics (if I ever knew them, I was very young and therefore very stupid at the time).
However, the opposite problem - that of (thread-safely) ensuring that you're not stepping on another process' file when you're writing, wiping or moving it - is pretty tedious under Unix. The only way to do it reliably - that I know of - is via flock, which is opt-in and therefore not always an option (e.g. the other process is a third-party application that doesn't lock its files), and doesn't work on remote filesystems
There is no design decision without at least one compromise hanging on its tail.
DLLs and other components installed system-wide are almost never the same file: Updates install new versions of most DLLs into the SxS system and compatible applications load newer versions when they are restarted.
notalaser|9 years ago
However, the opposite problem - that of (thread-safely) ensuring that you're not stepping on another process' file when you're writing, wiping or moving it - is pretty tedious under Unix. The only way to do it reliably - that I know of - is via flock, which is opt-in and therefore not always an option (e.g. the other process is a third-party application that doesn't lock its files), and doesn't work on remote filesystems
There is no design decision without at least one compromise hanging on its tail.
throwawayish|9 years ago
digi_owl|9 years ago
JdeBP|9 years ago
* https://news.ycombinator.com/item?id=11415366
IsmaOlvey|9 years ago