Print

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

[jonadab]

Is this a Linux thing?

Maybe sort of?  I can tell you for free that it's abnormal, in the Linux world, to distribute a pre-compiled binary that doesn't say which specific distribution, version of that distribution, and hardware architecture it's for (e.g., "Debian squeeze amd64").  People who don't want to compile for a whole bunch of different combinations of distro/version/hardware generally just distribute a source tarball.  Off the top of my head, the only other outfit I can think of that distributes generic "for Linux" pre-compiled binaries is Adobe.

I don't know exactly why the problem doesn't occur for you on Windows.  If I had to guess, I'd posit that maybe Windows doesn't come with the SDL library at all (it doesn't seem to come with much of anything *else*), and so perhaps DF bundles all the libraries it needs -- if so they would presumably be compiled for the same architecture as DF and so would work with it no problem.

I have no issues running DF on my 64-bit Windows box.

I actually do have a Windows system, but it's rather old and doesn't have a high-quality display or keyboard, so I'd prefer to get DF running on my main system if possible.

I haven't given up yet.  I'm going to do some fiddling and see which specific 386-compat thing is missing or whatever.  The error message leaves something to be desired, but I may be able to figure out what is needed when I have some time to look into it.  Today was really busy IRL (busy in a good way though), and I will probably have a couple more busy days coming up, but that's temporary...

I did already verify that the problem is NOT the fact that my system is a release out of date (oldstable), because I get exactly the same error on Wheezy.  I expected this, but I wanted to verify it before I start chasing down 32-bit compat libraries.

Update:  looks like I will be able to get it running on wheezy, albeit perhaps not on squeeze.  (The wheezy system isn't my best computer, but I guess it'll do.)  I had to install about eighty packages worth of i386-compat library dependencies that I'll never use for anything else, but I think it's going to work.

[GavJ]

I also have 64 bit windows and have never had any issue running DF, or in fact any other 32 bit program I can think of, of which I use many (combination of old research programs provided in appendices of papers I read from awhile back + older games). I didn't even think that was what this conversation was about... this is actually a problem?

If it is confined to Linux, then it honestly seems to me like you should just submit a Linux bug report for this, or contact Toady more directly or something. Fixing it would be a matter of fixing whatever broken dependency, not rewriting the whole game to be long address aware (which seems to be what most people here mean), which is unnecessary.

As the amount of things to keep track of will increase, and likewise the memory usage will rise - would you rather prefer maximum embark sizes shrivelling up to spending a lot of time actually making DF catch up with the times?

I can run a 16x16 fort just fine on my machine, for at least a couple of years. I haven't tried longer than that (due to FPS getting annoying, not memory crash). So logically, if:
1) 16x16 is possible now
2) The vast majority of people play on 4x4 or smaller
3) A lot of the memory used is for landscape, not items, thus doubling the amount of items or tracked info on dwarves/items/etc. would NOT correspondingly double the RAM. Far from it.

then

conclusion) Toady could store dozens of times more items or item info in the game without the default map size crashing and thus without most people ever even noticing (and if, say, 6x6 became the largest possible size, he could just remake maximum embark rectangles to 6x6 or equivalent area, and very few people would care.)

tl;dr, answer to your question: I'd personally much rather have the extra features than a 16x16 map option that will never be playable anyway or Toady spending a lot of time to upgrade to 64 bit to preserve an option for larger maps that will never be playable anyway...

[Putnam]

I could have sworn that 16x16 embarks were impossible due to the memory constraints.

[GavJ]

As mentioned above, I only played it for like 2 years, and I did not make nearly as extensive of a fort as I normally would in that time.

A full sized 100-200 dwarf fort with all the associated clothing and food storage and trinkets and blah blah on a 16x16 embark may very well crash. But the initial embark and limited population size and digging for a couple years worked fine for me.

Also, don't forget that different maps can vary wildly in height. Some are 20 z levels high. Some are 120. I might have gotten lucky with a thin world that worked, whereas if you embark on a 120 thick, it won't work right from the start. That is possible.

[Putnam]

By impossible, I mean "crash on embark" impossible.

[GavJ]

Yes, it might do that if you happen to embark on a 120-z-deep embark site. I may have gotten lucky and ended up on a 30-z-deep embark site when i did it (which would be the equivalent of only a 8x8 embark volume-wise at 120-deep). So I can't promise it won't crash on embark no matter what, as I have not exhaustively tested it, but it will sometimes work, at least.

[miauw62]

If Toady can maintain both a legacy and an SDL version, there's no reason he can't make a 64-bit version.

Running DF on 64-bit Linux is something of a PITA since it doesn't even tell you that the error is that it's a 32-bit executable, it tells you "file not found" when the file is right there. So you have to search around on the Internet just to know what the error is, and then how to fix it, and THEN you need to find all the dependencies. Did I mention that this, afaik, requires root access? So you may not be able to play DF without root. This is not an issue with DF, nor an issue with Linux, nor an issue with Aptitude, nor an issue with Ubuntu. It's not a bug you can fix, having 32-bit dependencies in a 64-bit era pre-installed is just silly. The only harm a 64-bit version will do is that the people still desperately clinging to XP won't be able to play, IF Toady doesn't compile 32-bit binaries.

Tl;dr: there's no reason NOT to create a 64-bit version, it will just make running DF on Linux much easier  and let people run even huger forts. Which may not be necessary, but that's a stupid reason. All it takes is a small amount of time.

[jonadab]

Did I mention that this, afaik, requires root access? So you may not be able to play DF without root.

This is a non-issue, as far as I'm concerned:  People who don't have root access shouldn't be installing software.  If you don't have root it's because you're not the sysadmin and somebody else is.  And if you have a dedicated system administrator, you should let them do their job.  Of course, this is only ever likely to be the case on work computers or school computers, which on the balance probably aren't supposed to have things like DF installed on them anyhow.

This is not an issue with DF, nor an issue with Linux, nor an issue with Aptitude, nor an issue with Ubuntu. It's not a bug you can fix, having 32-bit dependencies in a 64-bit era pre-installed is just silly.

Wait, *that's* probably why Windows users don't run into the problem:  The Windows world is plagued by so much badly-maintained proprietary no-source-available software that the authors can't be bothered to recompile for modern hardware even after 64-bit has been ubiquitous for most of a decade, and Microsoft was *aware* that this was the case because it's just fundamentally the way the universe works for Windows users, that they probably bundled duplicate 32-bit versions of every single library that comes with the OS. 

This is so absurd, it didn't even occur to me; but it's probably actually true, because the Windows world *is* that retarded.  Now that I think of it, they probably also have every single *version* of every library that has ever come with the OS, going all the way back to Windows 3.0 if not earlier, in order to maintain ABI compat forever and ever.  Which probably explains why Windows takes up almost as much hard drive space as a basic Debian install, despite having a tiny fraction of the amount of user-visible software installed.  All that space is probably taken up by ridiculous legacy compat libraries that shouldn't be necessary.

The only harm a 64-bit version will do is that the people still desperately clinging to XP won't be able to play, IF Toady doesn't compile 32-bit binaries.

s/play/upgrade/;  Nobody is suggesting that the old versions be taken down. 

And, in fact, I don't think I meant to suggest that the Windows version move to 64-bit only; I believe I was suggesting there's no point in providing a 32-bit *Linux* binary.  Linux users generally upgrade much faster than Windows users.  Windows XP, in fact, still has more market share than Eight, possibly more than Eight and Vista combined (in terms of actual installed userbase, not sales obviously; most systems sold with Eight are downgraded to Seven within a month), despite the fact that it dates to 2001 (or 2008 even if you count from the SP3 date), which is ancient history.  Nobody runs a Linux distro that dates from 2001, and even 2008 is banging up against the edges of the most extreme never-upgrade-ever situations pretty darned hard.

So yeah, I'd say continue producing 32-bit builds for Windows.

[My Urist Eternal]

jonadab: DF also runs fine on my 64-bit Macbook, from which I'm posting this right now. OSX dates back to what...2001? 

[LordBaal]

What would be the difference of a native 64Bits exe and one patched with the large address awareness patch?

[Thief^]

What would be the difference of a native 64Bits exe and one patched with the large address awareness patch?

LAA adds one bit to the usable address space of a 32-bit program when running on a 64-bit host. The net effect is a doubling of the amount of ram usable from 2 GB to 4 GB. This happens because on a native 32-bit Windows system, the top bit is used as a system/user address space separator, and so can't be used by the program (99% of the time, it's 0). On a 64-bit system that bit is bit 64, which is entirely outside the program's address space, so (for programs that don't do anything silly with bit 32 in their code) it becomes usable. LAA is only opt-in thanks to programs written in ages past which did abuse bit 32 of addresses for storing other data.

Native 64-bit adds an additional 31 bits of usable address space on top of LAA (the 64th bit is used as a user/system address separator, so only 63 bits are usable), increasing the max ram usable to effectively infinite (approx 8 billion gigabytes).

You also get various benefits to the compiled code, e.g. x86-64 guarantees SSE2, so the compiler can use it instead of the crap x87 instructions, and x86-64 has additional registers, reducing register spill (being forced to use ram because you don't have enough registers, which causes slowdown because ram is slow). These two can actually cause 64-bit code to be faster than the 32-bit version! (although generally, it's not noticeable)

[GavJ]

his is so absurd, it didn't even occur to me; but it's probably actually true, because the Windows world *is* that retarded.  Now that I think of it, they probably also have every single *version* of every library that has ever come with the OS, going all the way back to Windows 3.0 if not earlier, in order to maintain ABI compat forever and ever.  Which probably explains why Windows takes up almost as much hard drive space as a basic Debian install, despite having a tiny fraction of the amount of user-visible software installed.  All that space is probably taken up by ridiculous legacy compat libraries that shouldn't be necessary.

It's not absurd at all... I would trade another 1% of my hard drive space for the luxury of never having to deal with file not found bullshit any day of the week, and twice on Sunday. That's an awesome deal. Notice how there's a couple of threads about this with multiple people complaining.  Yet how many threads do you see full of people complaining about havign 10 gigs fewer on their disks? None.

What would be the difference of a native 64Bits exe and one patched with the large address awareness patch?

There are actual code differences -- if the code does anything like pulling bit-operation shenanigans with that one extra bit (such as cramming an extra data flag in there), then it will crash if you flag it as large address aware. Oftentimes, you use that bit without even realizing it, so if you want to flag your software as large address aware, to be responsible, you'd have to go scan through your entire code written to date checking everything to make sure it doesn't use the top bit. That's time that Toady would not be spending writing new features, so until somebody actually explains a reason why we need to be playing on 120 deep, 16x16 embarks with 200 dwarves on them, I consider it a waste of time at the moment.

[Thief^]

Oftentimes, you use that bit without even realizing it, so if you want to flag your software as large address aware, to be responsible, you'd have to go scan through your entire code written to date checking everything to make sure it doesn't use the top bit.

You may have forgotten, but you can't (ab)use that bit without having written your code to do so. The vast majority of programs won't touch that bit, and so are safe to LAA. Given that people do indeed play DF with the LAA flag patched to on, DF is probably safe here (those people would have reported broken stuff, plus I think linux already behaves the same as windows does after you enable LAA, so the linux build would have been broken too).

Moving to 64-bit is much the same kind of "not doing stupid things" as enabling LAA: don't make assumptions about the size of a pointer (aka address): LAA: don't assume a pointer is 31 bits, 64-bit: don't assume a pointer is <= 32 bits.

Compiling 64-bit will likely be quite straight-forward, the compiler should warn about any conversions from 64-bit pointer to 32-bit integer, which is the usual crime people commit if they write 32-bit-only code. Another issue is calling memcpy with a hard-coded constant size instead of a sizeof(), which is relatively easy to ferret out.
Lastly, Microsoft don't support inline assembly code in 64-bit builds, but I would hope toady doesn't use any anyway (and if he does, it just needs to be moved to an asm file or replaced with C code/intrinsics)
(all of the above (directly manipulating pointers, using memcpy, and assembly code of any kind) are generally considered "things you should not do" in modern C++ anyway)

[GavJ]

Signed pointer arithmetic is an example of something that may unwittingly use that bit. But yeah, you have to be doing some pretty squirrely stuff. Keep in mind Toady is no professional programmer, though (well I guess he is, but you know what I mean). Assuming he follows conventions of modern 64 bit programmers in an office setting or whatever may not be a good assumption.

If people have been playing with LAA turned on, then that's a good sign. How many people, and for how long have they been doing this?

He should still probably check through everything anyway to make sure, but it is indeed less daunting if we already have evidence it is fine and doesn't crash.

[Thief^]

Signed pointer arithmetic is an example of something that may unwittingly use that bit. But yeah, you have to be doing some pretty squirrely stuff. Keep in mind Toady is no professional programmer, though (well I guess he is, but you know what I mean). Assuming he follows conventions of modern 64 bit programmers in an office setting or whatever may not be a good assumption.

Pointer arithmetic works just fine with full (LAA) pointers, as long as you don't convert the pointer to an integer before doing the arithmetic (which is undefined behaviour anyway) and even then it'll most likely work fine. Subtracting two unrelated pointers is also undefined behaviour, so to even get an offset with the top bit set you'd need either a single array of >2GB size, or to be doing something bad.

The good news is that because of the way negative numbers are implemented in x86, signed and unsigned addition (and subtraction, and truncated multiplication (32 bit * 32 bit -> 32-bit result)) produce the same results, which means it doesn't matter if you're using signed or unsigned numbers during pointer arithmetic

(this is officially something very clever by the original designers of the 8086 cpu at intel)