Traditionally CnCNet has supplied a suitably patched spawner binary, hence the tests scripts operate under the assumption that the
spawner can be executed directly. Syringe-based projects (Ares, Phobos, yrpp-spawner) store the hooks/patches in a separate DLL that are applied at run-time by the Syringe executable.
Simple solution is to just replace gamemd-spawn.exe -SPAWN command with Syringe.exe gamemd.exe -SPAWN -CD. This will cause issues for debug sessions, because gdbserver launches the spawner directly. One way to address this is to attach to the process after Syringe has created it. Past experiences have shown problems when attaching, such as unusual bugs and inability to load symbols. If this proves out to be the case, a separate tool to apply the patches could be created as alternative to syringe. This could be implemented as a DLL to be loaded and initialized at the entry point.
Traditionally CnCNet has supplied a suitably patched spawner binary, hence the tests scripts operate under the assumption that the spawner can be executed directly. Syringe-based projects (Ares, Phobos, yrpp-spawner) store the hooks/patches in a separate DLL that are applied at run-time by the Syringe executable.
Simple solution is to just replace
gamemd-spawn.exe -SPAWNcommand withSyringe.exe gamemd.exe -SPAWN -CD. This will cause issues for debug sessions, because gdbserver launches the spawner directly. One way to address this is to attach to the process after Syringe has created it. Past experiences have shown problems when attaching, such as unusual bugs and inability to load symbols. If this proves out to be the case, a separate tool to apply the patches could be created as alternative to syringe. This could be implemented as a DLL to be loaded and initialized at the entry point.