That only concludes that sins still will not go over 2 gigs. These "patches" may give sins the 2 gigs of "room" it needs in your system, but they will not force sins to use more than what is hardcoded into it. Kind of like trying to force a square peg into a round hole.

Other games like the X3 series were patched by the developers over time to use more than 2 gigs of ram. I believe like how it was explained before by making it use more than one process. TBH I am not exactly sure how they did it. However Sins is optimized to use only a single core 32 bit CPU. We have tried in the past to ask the dev's if what was done to games like X3 can be done with Sins. The answer was a loud resounding NO! I believe it was not that it couldn't be done. Just that IC/SD at the time didn't have the money, manpower, or resources to do it.

Just as you said, it didn't pass the 2GB peak......But just like Major Stress said, it may give the room if needed, probably this is the reason why it not crash like before. Loading and saving data on disk still need some RAM , right?

Yes, either 4GB patch or LAA could work on the "memory doge" as this program doesn't have RAM control at all to avoid crash. But I guess SSE has a very 'strict' RAM control to hold the RAM below 2GB. Without source code change, all kinds of those patch will not work.

If we recompile it, most of problem about RAM will be end. But just like Reply 26 said, the answer was a loud resounding NO. Another question is if don't make the game two version (64 bit and 32 bit) the 32 bit will lose this game as the a 32 bit OS can not support 64 bit program.

We wouldn't be able to recompile it, but Ironclad could. After compiling for an x86_64 target, you wouldn't need to delete the old, 32-bit .exe, just make both available and let uses with 64-bit OS's choose which .exe to launch (quite a lot of games do this, actually).

You can. The Microsoft article does point out some possible problems though, so porting to x86_64 isn't as easy as I originally thought; it really depends on how Sins was programmed, but it definitely would take more than an hour.

Apps do indeed benefit automatically from having /LAA added (as long as they rely on fairly standard memory allocation calls)... assuming they don't start crashing in new ways, like I said. The don't need changes to make use of /LAA's main benefit. "Porting" to /LAA is basically a series of manual (or at least some semi-automatic) code checks to be somewhat sure the app can handle the 3GB address space without running into certain kinds of pointer bugs stemming from 2GB addresses assumptions, e.g. assuming that all pointers are 31-bit and using the top bit for some special purpose, ensuring that pointer subtractions don't overflow when moving to 3GB because signed 32-bit integers don't fit the difference between extreme addresses in the 3GB space, etc. But I do suspect that most programs don't have the kind of weird pointer manipulation that would cause problems when using 3GB, so the MS guys may be too conservative with their (code auditing) recommendations...

Sins already crashes a lot and I think it's occasionally from its memory management, although not necessarily because it runs out memory; other kinds of mm bugs are possible. From what I see, I think only some part of Sins can really make use of the extra RAM granted by /LAA; the 10% gains (to 2.2GB) don't seem worth the hassle of risking new bugs, but YMMV as they say.

Perhaps some mods require the extra ram, but the stock game, even with 100 bomber squads on the screen, stays under 1GB for me, although it does start to lose fluidity when zoomed in (to see 500 individual bombers) but it's the CPU, not the GPU [or RAM] that's the limiting factor there.

Sins does benefit from a SSD more than most games; its loading times are pretty slow from a HDD.

I would think the benefit of the SSD would be load times only, yes?  Unless you have a lot of the memory usage going to a pagefile?

I think Sins does use the paging file because if it is too small, you will find textures won't load in the game, you just get the white squares....

Ahh, ok.  For the longest time I thought the PF was simply an "extension" of sorts of the normal RAM and that it was only really used once the physical RAM was starting to run out (within the limits of what the OS could support, of course).  I didn't realize individual applications could not only uniquely identify the PF space, but could explicitly cache things into it.

If your paging file is ~2GB or less, overtime your Sins game will be unable to load textures...you could have all the RAM in the world, it wouldn't matter....large mods run into this issue faster, but it can happen with vanilla, and even for users who have large quantities of RAM (basically anything 6GBs or bigger)...

I've played Sins since its release and have played large mods since around entrenchment...over that time, I would have used several ATI CCC versions for an AMD card on a Dell with Vista and eventually W7 as well as several NVIDIA driver versions for a NVIDIA card on a Lenovo with W7, W8, and W8.1...2 totally different graphics cards, computer manufacturers, dozens of driver versions, and 3 operating systems...I would be very surprised if the issue is a driver, because that is a lot of drivers to be at fault...

Well the default setting lets windows manage it and set whatever size it wants, which apparently isn't good enough for Sins...I've always had to go in after each reinstall and manually set it (I usually pick 4-8GB as my range) and that seems to fix the problem...

Before Rebellion, I only had paging file issues when playing really big mods, though for a while I just thought it was an issue with the mods...eventually I saw in a mod ReadMe to up the size of the paging file, and realized what had been happening...with Rebellion, I get it with the base game if I play several games without restarting the computer, so even without mods I'd still need the larger paging file size....of course with mods like SOGE, the larger paging file size is a must...

As a little aside, on my current computer if I manually set it, it seems to already be set with a max of 2GBs even though it recommends a min of 4GBs...go figure...

Way back in the day though, before Entrenchment, I played with a friend who always would have textures not load late in the game...he had lots of RAM, and remember this is original Sins so he should never have run out of RAM...I don't know if it was a paging file thing or not, but he experienced the same symptoms...

I don't know how Sins is programmed, but it definitely has memory issues....lots of skilled players restart their game after finishing a match on ICO to avoid crashing while in the lobby, and that's assuming they don't crash while viewing the end-game stats...a dev actually confirmed these MDs were simply related to memory...with all that in mind, the fact that manually increasing the paging file size fixes the issues I've experienced (as well as many others who have used mods), I'm inclined to think the issue is the game...I'm sitting here with 8GB of RAM and a video card with 2GB of its own memory, there's no reason Sins would make use of the paging file unless it was programmed to go that route...

Two quick notes based on that presentation:

• On 64-bit Windows /LAA actually gives the app the full 4 GB entirely for user space (the 1GB/3GB split is for 32-bit kernels) and this requires no special boot flags (unlike the 32-bit kernel case). As for testing your machine's LAA config: http://technet.microsoft.com/en-us/sysinternals/bb963901 has the "testlimit" utility. The 32-bit version of that utility when ran (with the -r flag) on 64-bit Windows 7 can indeed allocate 4032MB of user/app space; and if you have enough physical RAM, like I do, you can pass testlimit -d, which will also touch every page allocated, forcing the OS to actually provide the app with that amount of RAM (instead of just address space.) [I suspect "-d" would work just with enough pagefile, but it will thrash your disk/SSD like crazy.] Given that nobody posted Sins getting anywhere close to 4GB (when /LAA patched), there are probably quite a few limitations in the Sins code.
• There are some 31-bit gremlins even in the Microsoft DX9 code, for example "D3DX9’s Effects system uses the 32nd bit. High-bit indicates a handle vs. a string. There’s a mitigation [in] DirectX SDK (June 2007) or later. Eliminate string usage for D3DXHANDLE. Create with D3DXFX_LARGEADDRESSAWARE." So for /LAA the effects code needs to be recompiled with that in mind; more at http://msdn.microsoft.com/en-us/library/windows/desktop/bb172855(v=vs.85).aspx. I've looked at the calls Sins makes to D3DXCreateEffectFromFileW, which it calls a lot on start-up. Alas, the flags Sins passes to that function are always set to 0x20=32 so never include D3DXFX_LARGEADDRESSAWARE (1<<17=131072), which is needed for proper operation under /LAA. And you cannot simply put a shim DLL in between to fix that; see the previous msdn link why not.

It appears Sins devs have investigated using LAA, but decided against it: https://forums.sinsofasolarempire.com/427540/page/1/