Josh194
commented
3 years ago Note: the 'only' good option will likely be to have the backup process start the server its-self. The server executable will need to be protected, likely with a combo of permissions and checks such as a checksum.
Depending on usefulness, implement a system to quickly cleanup as much as possible on a crash (win32 has a built-in way of doing this), and have some way of recovering after a crash. The most important thing to note here is that as the communication files are backed by the system page, they do not have a name, and so the ONLY way to get a handle to one of them is to go through the core server, or a process that received a handle from another that already had one. If the core server restarts, it has no way of getting it's handles back. This is especially problematic for the future remote subsystems, as once the server crashes, there is no process to keep the file alive (iirc windows will automatically close a process' handles when it closes). One solution would be to have an independent thread (child process maybe?) that runs in the background and inherits all communication handles the core server opens. The only thing left to figure out is how the backup thread will know that the process requesting all of the communication handles is indeed the core server.