Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ouroborus]

Is there a way to permit DF to use more than 2GB on Windows 7 64-bit? I've tried using increaseuserva with no effect.

[0x517A5D]

It's because the DF executable does not have the LARGE_ADDRESS_AWARE header flag.

You could set that flag with the editbin utility (which is part of Microsoft Visual Studio but can be found elsewhere as well), as described here.

But my test crashed immediately upon embarking on a 16x16.

[sweitx]

It's because the DF executable does not have the LARGE_ADDRESS_AWARE header flag.

You could set that flag with the editbin utility (which is part of Microsoft Visual Studio but can be found elsewhere as well), as described here.

But my test crashed immediately upon embarking on a 16x16.

Hm... wonder why Toady One doesn't allow DF to use more memory?

[cerapa]

Hm... wonder why Toady One doesn't allow DF to use more memory?

Because it would become sentient and go skynet.

[Eugenitor]

LARGE_ADDRESS_AWARE isn't something you can just decide to toss into a program, and risks breaking other things.

What kind of embark are you running that DF needs more than 2GB of memory?

[SolarShado]

The main thing I've seen folks wanting DF to use more RAM for is gen'ing large and/or old worlds.

[Noble Digger]

DF used 1.35gb of memory for me on a 5x5 embark at a flat desert. Once I broke into the 2nd cavern level, that number increased to 1.72gb. Guess what happened when I broke into cavern layer 3?

I started a new fortress, that's what.

[darius]

It's because the DF executable does not have the LARGE_ADDRESS_AWARE header flag.

You could set that flag with the editbin utility (which is part of Microsoft Visual Studio but can be found elsewhere as well), as described here.

But my test crashed immediately upon embarking on a 16x16.

Hm... wonder why Toady One doesn't allow DF to use more memory?

1. Toady One does not have more memory.
2. Toady One does not know of that flag (e.g. i am programming for 6 years and did not know about this (and still don't know how to turn this on exactly) till about 1 year before).
3. This is not as simple as it sounds.
4. All of the above.
5. Toady One has other priorities
6. 4 and 5 and 6

P.S. This is just guesswork

[breadbocks]

I laughed so hard at 6. Which is really 4, 5, and 6, (which is really 4, 5, and 6)^∞.

[Thief^]

LARGE_ADDRESS_AWARE isn't something you can just decide to toss into a program, and risks breaking other things.

It should be something you can just enable on any well-made program. The things that break are:
1: Explicit checks that pointers are below the 2GB barrier
2: Hacks to use of the highest bit of pointers for a program's own purposes

Neither of which you should be doing anyway...

[ouroborus]

LARGE_ADDRESS_AWARE isn't something you can just decide to toss into a program, and risks breaking other things.

It should be something you can just enable on any well-made program. The things that break are:
1: Explicit checks that pointers are below the 2GB barrier
2: Hacks to use of the highest bit of pointers for a program's own purposes

Neither of which you should be doing anyway...

This reasoning also applies to compiling 32-bit software as 64-bit. Any well written 32-bit software can be compiled as 64-bit without issue.

But in reality there's always a set issues that spring up when trying to do something like this. E.g., my experience is that most programmers ignore (or worse, turn off) a lot of the compiler warnings so long as the software just works. (I don't like to ignore them myself, but I'm just weird that way. With gcc, at least, there's a switch that causes warnings to be treated as errors.)