Is it feasible to make CoH Large Address Aware?

[Sunsette]

I don't know much about programming, but I know that CoH is a 32-bit program, which means that, like most 32-bit programs, it's probably restricted to 4 GB of RAM. This restriction includes video RAM and would be responsible for a large amount of the slowdown the game faces in conditions which would not at all be conceivably challenging to most modern computers.

 

I also know that while 32-bit executables can't normally get all the benefits of being x64, like multithreading, it is possible to make many of them Large Address Aware, which allows the executable to use all of the memory that the computer has available to it. This kind of dirty hack is most famously done for PC installments of games running on various forms of Bethesda's Creation Engine, like TES V: Skyrim. For that game it was a matter of flipping a handful of hex bits manually, but I know that's not the case for every 32-bit program. On the other hand, most games I've tried this with, we didn't have access to the source code.

 

So, my question and suggestion: Is it feasible to make CoH LAA? It would be nice if so.

[jack_nomind]

LAA is the technique (flag) used to make 32 bit programs use up to 4gb of memory.  It can be done locally by the user with a utility.  If we have everything we need to do so, it would be better to compile a 64-bit client.

[Sunsette]

You're right, I was confused; the limit is lower normally. Normally 2 GB, right?

 

Wouldn't full x64 be a lot harder?

[jack_nomind]

You're right, I was confused; the limit is lower normally. Normally 2 GB, right?

 

Wouldn't full x64 be a lot harder?

 

Yeah, normally 2GB.

 

Full 64 bit support is a matter of finding or making replacement 64-bit compatible libraries and recompiling the client and replacing/recompiling associated files (like dlls).  It could be anywhere from "three clicks in a modern compiler environment" to "rewrite half the calls in the entire source and also new custom low-level libraries for things we couldn't find replacements for."  I think it's probably closer to the former (I think that probably the client is relying mostly on public or commercial libraries that have since been updated for facially identical x64 versions), but that diagnosis is beyond my hobbyist-level skill.  In either case, it does require recompiling the client, and I don't know where that code is.

[Sarrate]

I don't know much about programming, but I know that CoH is a 32-bit program, which means that, like most 32-bit programs, it's probably restricted to 4 GB of RAM. This restriction includes video RAM and would be responsible for a large amount of the slowdown the game faces in conditions which would not at all be conceivably challenging to most modern computers.

 

Yes, a 64bit application can consume far more memory than a 32bit application, that doesn't necessarily translate to better performance. Additionally, depending on other factors (both code and data), it still might not use that extra data if it's designed to page data in & out at a lower RAM level.

 

I don't think your statement about video RAM is entirely true. While you couldn't have (for example) a single OpenGL buffer larger than 2-4 gb, it should be possible to consume more than 4gb of VRAM on a 32 bit application.

 

I also know that while 32-bit executables can't normally get all the benefits of being x64, like multithreading, it is possible to make many of them Large Address Aware, which allows the executable to use all of the memory that the computer has available to it. This kind of dirty hack is most famously done for PC installments of games running on various forms of Bethesda's Creation Engine, like TES V: Skyrim. For that game it was a matter of flipping a handful of hex bits manually, but I know that's not the case for every 32-bit program. On the other hand, most games I've tried this with, we didn't have access to the source code.

 

In 32bit versions of Windows, the OS would reserve 2gb of the 4gb address space to allow it to do "things" (I'm not entirely sure what, honestly) in the processes address space. The Large Address Aware flag basically reduces the reserved amount to 0, allowing the application full reign on the 4gb address space. If Windows needed to do something in there and it couldn't, it could cause problems. Not sure how big a deal that is in 2019, just saying.

 

As for threading, that has nothing to do with 32bit applications. You can have create heavily threaded 32bit application just fine. Most applications of the day weren't, though, because CPUs didn't have as many threads / cores available, clock speeds were still rising, and it's a lot harder to write good multi-threaded code than it is to write single threaded code. Additionally, graphics APIs at the time were largely single threaded, so threading wouldn't help when it came to issuing draw calls to the GPU.

 

This meant that games tended to be heavily single threaded. (Not saying they never used threads, but the lion's share of the work was.)

 

So, my question and suggestion: Is it feasible to make CoH LAA? It would be nice if so.

 

Yeah, normally 2GB.

 

Full 64 bit support is a matter of finding or making replacement 64-bit compatible libraries and recompiling the client and replacing/recompiling associated files (like dlls).  It could be anywhere from "three clicks in a modern compiler environment" to "rewrite half the calls in the entire source and also new custom low-level libraries for things we couldn't find replacements for."  I think it's probably closer to the former (I think that probably the client is relying mostly on public or commercial libraries that have since been updated for facially identical x64 versions), but that diagnosis is beyond my hobbyist-level skill.  In either case, it does require recompiling the client, and I don't know where that code is.

 

Don't forget that when switching between 32bit and 64bit, various types (like pointers) can change in size. This can cause all kinds of problems. If data is being serialized (aka reading/writing to disk, from a socket, etc) using those types, bad things can happen if there is a mismatch. If the code is doing any funny business like storing a pointer value in an int, that's suddenly a huge problems (8 byte pointer doesn't fit in a 4 byte int).

 

As you mention, jack_nomind, any dependencies would also need to be recompiled for 64bit. That's not a problem if you have the source, but if you don't and are just linking in a library (statically or dynamically), you're kinda stuck in a bad spot. Even if you do have the source, then you'd have to deal with all the above issues all over again.

 

I suspect there would be a lot more issues recompiling for 64bit than you'd first think... especially given the - ah - reputation of the code base.

[Sunsette]

That was very interesting/informative additional information, thank you.