The problem with making something multicore AFTER THE FACT, is that most of the code might rely in sequential execution. If a subsystem of the engine is nicely abstracted away from the rest, and ideally already has a command queue mechanism... then it's halfway easy to multithread it.... because all the groundwork has already been done. If instead a subsystem is just as interwoven with other "modules", as MS software for windows, barely has any abstraction and no "queue" whatsoever, then you basically have to rewrite that entire part of the engine, and then rewrite how all the other parts access it.
I suppose obvious candidates, which might with some luck (okay, a lot of luck, given that this is beth) fit the above requirements, AND provide a nice performance boost, would be:
1. Havoc. The whole thing afaik is already using "virtual threads" (probably coroutines) anyways, so the api and queueing probably is already there.
2. That dumb as brick script interpreter of theirs - almost certainly, there is already some kind of "scheduler" in the engine. Scripts might not easily be runnable in parallel, but if at least ONE script at a time can be executed parallel to the rest of the engine, then this still would be a plus.
3. With a lot of luck (really a LOT), the render subsystem might be multithreadable - it should be obvious why this would bring a major performance boost. The problem is, that i have a really bad feeling, that the render api is tightly integrated with other subsystems, and almost certainly they all operate on the same shared worlddata... which makes any multithreading pointless, since it would be dragged down in mutexes.
P.S.: A pseudo 64bit binary might actually be possible - with some limitations. If one already has the disassembled code, all nicely cleaned up... then one could compile it to run in 32bit more but "large addressspace aware". Replacing the memory allocator shouldn't be too hard - heck OSR already is doing it. Most of the engine would remain limited to 2GB, but for a few small but ressourcehungry subsystems, one could hack them to make use of the additional memory. The downside is, that this will not work out of the box for the player. Windows has a switch in one of its configfiles, to enable this extended addressspace mode. By default, it is disable. Why? No idea, i guess they needed a reason to sell 64bit OSes. Who back then would have switched to a 64bit OS, when the 32bit RAM limitations are gone (in the midterm) ? It's a bit like what intel and then AMD did with their CPUs. Want to know why stuff is so much faster in 64bit mode? It's not 64bit. Instead, with 64bit CPUs they introduced additional features and cpu registers, that got nothing to do with 64bit itself. Then they artificially disabled those features in 32bit mode, so that to people it looks as if 64bit makes stuff so much faster.