Yep that makes sense but I never herd of that until fix until now. I had sins running exactly the wasy you had on 32bit vista. It crashed when it hits about 1.85 gb when my virus scan software turns on, but it sometimes it just crashes on high memorey usage, I had only 2gb of ram at that time but my simple fix was upgrading ram so I spent $60 bucks on 4gb of ram, it was the cheapest and best deal. Now my computer can run on about 3.6gb of ram, and sins is fine on max and on huge maps 300+ planets, and lots ships quite fine. I'm hoping to upgrade to 64bit vista to use 6gb of ram.

It could be done but it would screw up the determinism required for multiplayer. The issue has been coming up more often now because of the additional textures and the unbalanced use of mines. Once we have mines rebalanced and more texture optimization (we didn't do much optimization for the beta) it shouldn't hit the the barrier in normal play unless people are using a crazy mod. 

Thank to call 7DS a crazy mod... the barrier is not related to the system... using linux and sins, i can use fully my 16 gb ram... some game have go over the 10 gb... the barrier is the limit on the number of mesh and texture that YOU have put in the engine...

For info, we are in 2009... when the game was out in 2008, the only computer's find at my usual food market was already all with 64 bits processor... First 64 bit processor was made in 1961 but for the x86 desktop familly, it have begin in 2003... it is nothing new...6 year in computer evolution is like prehistoric time...

But in some way, i am happy that you have no 64 bits version... all know OS compilers today use the LP64 model (including Solaris, AIX, HP, Linux, Mac OS X, FreeBSD, and IBM z/OS native compilers). Only Microsoft's VC++ compiler uses the LLP64 model. These last create a overflow error when a pointer is assign to a long register... because microsoft is the only one who have keep the long register to 32 bits in place of 64 bits like other...

Sure, you have made me mad... your comment is like a insult for modder who try to find solution for go around YOUR OWN BARRIER...

For info, the well know texture memory leak from Sins is partially resolved on Linux system... This problem exist from day one... the last version 1.12 don't yet resolve it... don't you think that a solution to the old problem will resolve some of the memory problem...

use

http://www.ntcore.com/exsuite.php

1. Open CFF Explorer and then open your SC2 .exe file.
2. Go to the "File Header" section (under Nt Headers) and click the "Click here" on the Characteristics row.
3. Check the "App can handle >2gb addressest" box, then click OK
4. Go to "Save as", and then rename your existing SC2.exe (for backup)
5. Save the current version as SC2.exe, and voila, the game now won't crash when it's memory space gets too big (you still might want to restart occasionally if you have 4GB of ram or SC2 will push all your other programs out of memory)

helped me with sc2

great way to fix games

Way to necropost a 27 month dead thread....

Supports the "Rebel" 3 GB of RAM? Supports the "Rebel" 3 GB of RAM? Or by using the correct title PE_Tools game EXE file?

+
http://www.maxi-pedia.com/3GB+switch+Windows+boot.ini+3+GB

just because sins is a 32bit game does mean i can afford to be cheap.

Moderators, please lock this thread.  It is out of date.

Possibly because that's only a band-aid on the actual problem that would split the community in two.

Uh? How would it split the community in two if the official version of the binary comes with LAA Enabled?

Your logic doesn't make sense. You seem to be suggesting that only half the people would receive or use the version with LAA enabled. I don't understand how that's possible, if everyone is downloading the patch from the patch server. It would be like every other patch: upgrade, or get left behind with a few hold-outs who don't like the new version. Rebellion, itself, is going to be infinitely more divisive to the community than any bit-twiddling could ever be, because a lot of people are saying they don't want to pay all that money for an expansion, and some people just don't like Titans period. So you're going to have some people playing Original Sins, some people playing Entrenchment, some people playing Trinity, and some people playing Rebellion. Is that divisive enough for you?

And for systems that don't actually take full advantage of LAA (for example, 32-bit systems that don't have the 3GB switch on), there would still not be a problem, because the binary would be bitwise-identical to the binaries that 64-bit users use. It's still a 32-bit binary with the LAA switch enabled, regardless of whether or not the system is taking advantage of it. Those people would just be more prone to crashing, which -- gee -- is exactly where we are today.

The difference would be that, as it stands today, everyone crashes when we exceed the 2GB limit, unless you set up a custom game where all the players have the LAA switch enabled. If you enable it by default, then only the people who are too incompetent to enable a switch in boot.ini would crash (and if you're on any 64-bit OS, you don't even have to enable any switches). So considering that quite a lot of people either (a) have a 64-bit OS, or ( have enabled the 3GB switch, we'd go from minidumping like crazy, to only occasionally one or another person minidumps because they can't type a few characters into a plain text file in the C:\ directory.

As for the checksum issue; that's ridiculous. It's totally feasible to add in code to certify more than one version of the architecture-specific files. If a 64-bit version of Sins is just waiting on this one tiny thing, I'll volunteer to hack together the code in C++ or Lua or whatever Sins uses, and I'll even sign an NDA license and do it for free without taking up hardly any developer time from Ironclad.

The issue to me seems indefensible. It's just laziness or apathy that is keeping the default Sins shipping as 32-bit only and without the LAA flag enabled. There's no good technical reason not to, at least, flip the damn switch. 64-bit I could understand might be a little more challenging if some of the code as designed is not 64-bit clean; but I haven't gotten the indication from the developers that this is the case.