> patching a runtime initialization table might be ordinary (and even acceptable) in a leaf executable where the dependencies are carefully checked for conflict

> patching a runtime initialization table might be ordinary (and even acceptable) in a leaf executable where the dependencies are carefully checked for conflicting initialization behavior, but it's pretty dangerous in a library (or crate) that might get mixed into all kinds of executables with different initialization expectations. I'm not sure why that would be the case. Any C++ static constructor ends up in that table. Any Rust crate using #[ctor] ends up in there. > It's close, but you're relying on much racier and flimsier primitives. The trick that I'm most familiar with in Win32 applications is to create a named pipe or other IPC mechanism to communicate over, since the failure modes there are much better defined (and not subject to race conditions). As opposed to WaitSingleObject? Or what exactly are you objecting to here exactly? I'm also not sure which race condition you are referring to in particular. The main race this has (or any other library that does something similar) is that it needs a utility process to spawn to inherit the handle of the copy gc process. No named pipe will resolve this.