* you can find an explanaition here: Serverwartung 21.11 it's german but i guess google translate will do the job
I translated the post, and I loved to see that it confirms (and more than that, it completes) my previous post about 32bit/64bit compilation.
Display More"Runes of Magic is still running of a 32bit client and having issues with memory leak.". And regarding this quote, I'm still waiting for further explanation, because 32bit software should still run properly on Windows 10/11. I don't understand why would you blame the 32bit architecture of a software, for having game crashes
This is not difficult to answer.
If you have a 32-bit application, you can address only 2 Gigabytes of memory by default. In theory, you could opt into getting access to 4 GB, see the documentation: Memory Limits for Windows and Windows Server Releases - Win32 apps | Microsoft Learn
However, since I have never seen RoM use more than 3 GB of RAM, I doubt it takes advantage of this option.
Anyways, if you continuously generate garbage memory usage and don't clean it up, there will be a point when you cannot acquire more virtual memory from the operating system, let alone deal with memory addresses that don't fit into 32 bit pointers. Most programs just crash if they reach this point, because it is viewed as a non recoverable error.
Now, if you compile for a 64 bit architecture, you can address 128 TB of memory in Windows and the situation of a crash is delayed to a much much later point in time, because you can leak way more memory until the all the available amount of memory is used (practically it will be the size of your RAM + swap file size minus lost gaps due to memory fragmentation, which is usually smaller than 128 TB)*.
Now the crash happens after a week of running RoM or perhaps not until a full year has passed (who will do that in practice?).
Thus, being restricted to the 32 bit memory addresses may not be the root cause, but upgrading to 64 bit makes the painful symptom of crashes due to memory leaks go away in practice.
*Assumption: parts of the program don't explicitly or implicitly depend on the memory limit and, because of this, don't have to be adapted a bit first
This is a great explanation! From your shared article, I understand that a Windows 64bit OS can increase the max limit of allocated memory of a process to 4GB (by setting the IMAGE_FILE_LARGE_ADDRESS_AWARE flag). And, as I understand, you supposed that RoM does not take advantage of all these 4GB, since it crashes before reaching 3GB of the allocated memory
Also, it makes sense what you said about the connection between 32bit client and the game crashing: the limitation of 2GB/3GB/4GB given by the 2^32 possible memory adressing makes the client reach the max allocated memory (due to memory leaks) faster, than if it was built on 64bit.
I'd have a brief conclusion to this: there are only 2 options, in regard of fixing this problem:
1. Developers can try building the client on 64bit, but the biggest headache, in my oppinion, are the 3rd party libraries which can lack 64bit support, considering there's a 16 yrs old game.
2. Developers can try analyzing the source code and observe where the memory leaks come from. A common and very visible case where memory leak occur is at transporting to another zone (personally, I get most of the crashes because of it)
Thank you for your answers!
