4gb Patch

[gordonamiller]

Further clarification for those with 4GB or more running 64 bit Windows, and running a Large Memory Aware program.

If the executable is 32 bit, the most any process can use is 2GB user memory and 1GB system memory. Yes all the ram is available, but only 2GB user memory per process. If the executable is 64 bit, you get all your ram as user memory (minus what the system uses) available to all processes, subject to availabilty.

So is it worth making your 32 bit executables Large Memory Aware ?

The answer is definitely yes, provided the program or one of its components doesn't have extra consistency checks on the original file contents. The all new improved 4GB patch is a must-have for all people that can use it. You get another 1GB of user memory allocated to the process.

There are 3 common ways to patch a 32 bit executable.

1. binedit from MASM/VB/VC++ toolkit. Requires use of a DOS command line. Does not make a backup, so you need to make a copy first. Needless to say, you need to install a MS developer toolkit that contains binedit.

2. CFF Explorer. You change the PE header LMA bit with a GUI, but you have to "Rebuild" the PE header prior to saving, or the PE checksum will be wrong. Needless to say, you need to install CFF explorer.

3. 4gb_patch. Does everything you need, and makes a backup. Small standalone that does not need installing.

And the winner is : option 3. You know it makes sense. Make sure you use the new version, 44.0 KB (45056 bytes) executable dated Sat 12 Nov 2011 11:31:42 GMT. Available here - http://www.ntcore.com/files/4gb_patch.zip

Daniel says he will change the version number (still says 1.0.0.1) and year (still says 2007) and his website when he gets a chance. We should all be very grateful for his good work. I know I am.

[PaulH2]

As previously pointed out, this has not been relevant to RailWorks for some considerable time, as RSC correctly started compiling it as Large Memory Aware about 18 months ago. So, my advice to all, don't bother with any of these approaches, it won't make any changes to TS 2012 whatsoever...

Paul

[peterfhayes]

Paul is correct, as I understand it TS2012 is LARGEADDRESSAWARE and this fix from NTcore may not help as it is mainly useful for programs that do not have the LAA flag set such as MS Flight Simulator 2004 (FSX SP2 has the LAA flag set)..
A lot of people here seem to be getting confused by virtual memory which in fact is what MS usually deems to be the "paging file".
Ref: http://en.wikipedia.org/wiki/Virtual_address_space
The 4GB "fix" refers to the "Virtual Address Space" which is limited in a 32-bit program to 2GB in a 64-bit OS. If the LAA flag is set then TS2012 can use all of the 4GB Virtual Address Space (Minus a few kb used by the system, etc) but only in a 64-bit OS. Now if it were a 64-bit program it could use 8TB of VAS.
The VAS has nothing to do with physical RAM or Virtual Memory (paging file) other than you need both present for the VAS to operate optimally.
Now in a 32-bit OS eg Win XP, if the LAA flag is set in the 32-bit program, you can increase the VAS from around 2GB to nearly 3GB by using the /3GB (plus/userva flag in 128Kb increments/decrements from userva=2560) switch in the Boot.ini file (or use bcedit in Vista and win7). Ref: http://msdn.microsoft.com/en-us/library/ff556232.aspx. But in this case any videocard memory will be subtracted from the VAS that the 32-bit program can use and there may be other issues restricting the system to 1 GB of VAS).
All programs/applications load into their own Virtual Address Space so that if the become corrupt or whatever only the application crashes and not the whole of the Windows OS resulting in the dreaded BSOD.
Regards
PeterH