Request for testing help: 32-bit Windows users

[jamespetts]

In version 11.33 of Simutrans-Experimental, I released an additional binary, the 32-bit large address aware binary. This was intended to allow Simutrans to use up to 3Gb (possibly 4Gb) of RAM without using the problematic 64-bit build (some code from Standard needs adjusting to allow even that to address more than 4Gb of memory, and it does not perform as well as the 32-bit build, as well as potentially having other problems). However, I have read about potential problems for people using actual 32-bit systems running large address aware binaries, which is why I included this as a separate build.

However, I have had some conflicting information on these problems, and it would help me very greatly if anybody running a 32-bit version of Windows could test to see whether this works for them. Note that, as the problem has been described to me, it might possibly crash the whole system (blue screen), so please ensure that you have saved your work before doing this and be prepared to restart if it goes wrong.

To run the test, you will need to download the latest (11.34) version of Simutrans-Experimental, and run simutrans-experimental-laa.exe rather than the basic simutrans-experimental.exe. You will need to download Carl's enormous GB map and pakset to stress test the memory consumption. You should load Carl's pakset and then his map using the -laa version of the executable. Please report whether this works or causes problems.

Finally, as a control, please also repeat the exercise with the normal 32-bit build of Simutrans-Experimental 11.34 (without the -laa ending) and report the results of that, too.

Thank you in advance.

[DrSuperGood]

I have been running the laa version on my 64 bit Windows 7 for a while now. It appears to function completely stably on that and has not caused any BSoDs or even crashed.

I am aware this is not a 32 bit version of Windows but I thought this information might encourage people to test as it "should" be stable.

It also has fixed the OOM crashes I got some times when in underground mode. The server map has reached the stage that if you are viewing underground and then someone joins (forcing a save and load) it can exceeded the standard x86 build virtual memory address space and so cause a fatal process error (well the game catches it but forces you to close it with a dialog item). Obviously the extended process size of laa fixes this to some extent. The 64 build also fixes this (by nature of 64 bit processes) but that has performance problems with the graphics.

[planestrainscomputer]

I am getting an out of memory error using Carl's amazing great Britain map. I tried all of his advice but none of it worked.

[DrSuperGood]

Are you using the laa (Large Address Aware) executable? How much memory does your computer have? How much page file storage do you have available? What OS are you using? This information is very useful to help debug problems.

As an example, if you are using XP 32 bit then I do not think laa makes any difference since the OS itself is limited to 3GB in total, of which it allocated graphic memory first before system memory.

[planestrainscomputer]

4gb of ram

[DrSuperGood]

4gb of ram

We need to know your graphic memory size (only if using discrete GPU with on board memory), OS version, page file size (maximum is sufficient) and most importantly OS version and build (eg Windows XP 32, Windows 7 64 etc). All of these factor in when your system runs out of memory.

A process could easily allocate 8 GB of pages on a 64 bit OS with 4 GB memory as long as there is about 6GB of page file. Windows XP 32 bit can only address 3 GB of memory while Vista/7 32 bit can address 4 GB. If you have a discrete GPU that memory is allocated first from any limit so a XP 32 system using a modern GPU (2GB memory) and with 4 GB main memory will only have access to 1 GB main memory.