> Will this also work without painstakingly reversing things in the binary, say in the case of a giant game executable?
You can get away with a Ghidra database that isn't accurate, as long as you know what you're doing. Basically, as long as the analyzers manage to identify all of the relocation spots inside your exportation, the rest doesn't matter that much. You can even get away with missing relocation spots inside your exportation, if you don't end up executing that code or accessing that data at run-time (if you do, then exotic undefined behavior ensues).
The most important thing here is getting references right and addresses typed as pointers (the type itself doesn't matter). I'm not going to discuss this into more details than that, because it would require a deep understanding of the internal algorithms of the extension. Any shortfall between a less-than-accurate Ghidra database and experience will be filled in by luck.
> If possible, I would be very interested in a simple tutorial that takes an arbitrary Windows executable, delinks it and replaces a single function, without all the extra steps necessary to run it on the PS1.
It's essentially the same steps regardless of the platform. Select the bits you want in your object file, run the analyzer, invoke the exporter, use the linker to create a new program.
I've made my Ghidra extension as user-friendly as possible, the rest is standard native development stuff (up to the point where you hit exotic undefined behavior and can't figure it out at a glance, hopefully you're well acquainted with your debugger if that happens).
> It might even be preferable if it worked with MingW, since I'm on Linux as well.
Actually, I've created a native port of a proprietary, statically-linked, Linux a.out i386 to Windows with MinGW [1] using my delinker. It was back when I didn't have a COFF object file exporter either, so it was the only toolchain for that target that could ingest ELF object files.
That being said, MinGW and MSVC are reportedly only compatible at the C ABI level. Mixing and matching different toolchains can increase the odds of something going wrong, so you're probably better off using the toolchain that the program was originally built with (hopefully it runs on Wine).
PS: remember that you are throwing your CS 101 handbook into the trashbin when you're using a delinker (and its teacher is unlikely to be of much help).
You can get away with a Ghidra database that isn't accurate, as long as you know what you're doing. Basically, as long as the analyzers manage to identify all of the relocation spots inside your exportation, the rest doesn't matter that much. You can even get away with missing relocation spots inside your exportation, if you don't end up executing that code or accessing that data at run-time (if you do, then exotic undefined behavior ensues).
The most important thing here is getting references right and addresses typed as pointers (the type itself doesn't matter). I'm not going to discuss this into more details than that, because it would require a deep understanding of the internal algorithms of the extension. Any shortfall between a less-than-accurate Ghidra database and experience will be filled in by luck.
> If possible, I would be very interested in a simple tutorial that takes an arbitrary Windows executable, delinks it and replaces a single function, without all the extra steps necessary to run it on the PS1.
It's essentially the same steps regardless of the platform. Select the bits you want in your object file, run the analyzer, invoke the exporter, use the linker to create a new program.
I've made my Ghidra extension as user-friendly as possible, the rest is standard native development stuff (up to the point where you hit exotic undefined behavior and can't figure it out at a glance, hopefully you're well acquainted with your debugger if that happens).
> It might even be preferable if it worked with MingW, since I'm on Linux as well.
Actually, I've created a native port of a proprietary, statically-linked, Linux a.out i386 to Windows with MinGW [1] using my delinker. It was back when I didn't have a COFF object file exporter either, so it was the only toolchain for that target that could ingest ELF object files.
That being said, MinGW and MSVC are reportedly only compatible at the C ABI level. Mixing and matching different toolchains can increase the odds of something going wrong, so you're probably better off using the toolchain that the program was originally built with (hopefully it runs on Wine).
PS: remember that you are throwing your CS 101 handbook into the trashbin when you're using a delinker (and its teacher is unlikely to be of much help).
[1] https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html