Print

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

[jonadab]

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.

Hmm...  different perspectives, and I think we're talking at cross purposes.

I'll try to explain a little.  First of all, this is not a "Linux problem".  It's a Dwarf Fortress problem, very specifically.  It is not something that would ever happen with any of the software included in any Linux distribution, ever.  We're only even discussing it because we're trying to run software that for no obvious reason hasn't been compiled for the most popular hardware architecture in existence, a situation that is almost totally unheard-of in the Linux world.  The *only* other software I've *ever* heard of doing this (distributing 32-bit precompiled binaries only) is the Adobe Flash plugin, which virtually everyone in the Linux world hates with a fiery burning passion -- and it doesn't depend on any dynamic libraries, so the problem we're having with DF doesn't exist with it.  So DF is literally the ONLY software I've EVER heard of that this "you don't have the library, even though you have the library" problem would ever apply to.  Calling it a Linux problem is offensive.  It is not the kernel's fault that this software A) wasn't compiled for the correct architecture, B) links dynamically against non-trivial libraries, C) doesn't include copies of those dynamic libraries, D) wasn't compiled for the correct architecture, E) doesn't even know how to print a clear error message when it doesn't find the cross-architecture libraries it needs, F) isn't even available as source so that we could compile it correctly ourselves, and G) did I mention that it wasn't even compiled for the correct hardware architecture?

Trying to run an old 32-bit binary of software that for some unknown reason has never been compiled for 64-bit might sound reasonable to a Windows user, because Windows users tend to have a rather extreme aversion to compiling software, but in the Linux universe the idea of installing a bunch of extra duplicate copies of libraries, compiled for a legacy hardware architecture you're not using, just to avoid recompiling something, is *highly* absurd.  Compiling your own copy from source is by far the most common way to install anything that hasn't been packaged for your particular distribution.  We do it all the time -- ordinary *users* do it all the time, not just developers.  It takes like two minutes. 

If there were a source tarball of DF available, I'd have grabbed that first and compiled, before even running into this weird issue, because grabbing a source tarball and compiling it is a much more normal thing to do than downloading a precompiled binary release that isn't specifically labeled as being for my specific distro/version/hardware (Debian squeeze amd64 in my case).  We're not accustomed to the idea of trying to run crusty old binary builds from a bygone era that weren't even built for our actual hardware, let alone the version of the OS we're using.  We don't *need* to be accustomed to that sort of thing in the Linux world, because all the major distros normally compile everything including the kitchen sink (pretty much literally) for every single hardware architecture they support (which for most distros is at least a dozen different ones) every time they do a release, which depending on which distribution you use can be anywhere from every three months to more like every 2 years.  (Debian is near the slow end of this spectrum.)  And anything that our distro *hasn't* packaged, we can usually easily compile ourselves.  We don't have piles of ancient binaries sitting around that were compiled years ago for a different hardware architecture that isn't still manufactured and nobody has used for years.

I wouldn't blame my car if I tried to put coal that was meant for a nineteenth-century steam engine into the gas tank and the internal combustion refused to burn it unless I install some extra components that don't come standard.

I've installed *hundreds* of different software packages on this computer in the couple of years that I've had it, *dozens* of which are third-party software not included in the Debian distribution, and I've been doing similar things on all the computers I've had since the late nineties.  I believe this is the first time I've ever encountered a situation where I needed to install dynamic libraries compiled for a different hardware architecture in order to get something to work.

Now, I want to soften all of the above by saying, I understand that DF is the work of mainly one developer, and he probably has other stuff to do besides just DF, which is after all just a game, and so obviously we cannot expect extensive support for every platform.  That's very understandable.  I may complain about there not being a 64-bit Linux build, and I'd really like to see there be one, but I do understand that every platform a developer has to support takes additional effort.  I don't want to give the impression that I think I'm entitled to have perfect support for any platform I happen to choose to use from every developer and every piece of software in existence, even if it's a platform they personally have no interest in.  There's software out there that doesn't provide any Linux support *at all*, and DF does provide a build.  This fact is not lost on me.

But I do want to convey the idea that a 32-bit binary-only release does not by any means constitute full Linux support.  I don't want there to be any confusion about that.

[GavJ]

Yikes uh I'm not sure that all would make me particularly more enthusiastic to work more closely with the linux community... Coal in your gas tank... really?

[Miuramir]

... First of all, this is not a "Linux problem". 

As someone who has to support real-world deployments in (not idealized, everything-is-documented-open-source fantasy world) Unix-ish OSs including Linux, this is *absolutely* a Linux problem.  Developers have made in a variety of cases clear decisions to limit backward compatibility, usually for philosophical reasons in ways that annoy actual users who are trying to do work not be part of a movement.  Other OSs have managed user-invisible handling of not only varying bitwidths, but varying *architectures*; this is not a technical limitation. 

Don't get me wrong; my life would be far easier if everything was open source, and we prefer it any place we can, and preferably versions off of epel or other well-recognized and updated repos.  But in the real world, there are plenty of situations where you get stuck with software blobs that do something important (and usually expensive) that are much harder to keep running smoothly year after year under Linux than Windows or Mac OS X.  Sometimes it's trivial stuff, that you go "why isn't that automatic?" after you finish banging your head on the desk.  For instance, one piece of software claimed to be RHEL (etc.) 5.x compatible; and as RH usually works a version back, we figured it should be easy to get working under 6.x.  Nope; turns out they originally compiled it for RHEL 4.x, and were *already* depending on the one-version-back feature to run under 5.x; running under 6.x failed in a wide variety of unhelpful error messages.  But everything eventually *actually* worked; I just had to run around the directory structure putting in links such as from libc.so.6 to allow it to be called as libc.so.5 and so on... something the system really should have been able to figure out itself.  Having to keep manually installing .i686 versions of libraries in addition to the .86_64 versions really seems backwards compared to other OSs. 

In the real world, there are certainly people still on OS X 10.6 Snow Leopard because they're still depending on code written for PPC; Apple at least gave them a decade of seamless cross-architecture compatibility, let alone cross-bitwidth.  Some older folks still grumble about having had to rewrite their stuff every decade; there are many reasons why FORTRAN is still so widely used in research, and one is because most versions allow you to just specify -f77 or whatever and get on with it. 

IMO, in a better world, there would be dynamically-linked versions of DF with well-defined and documented dependencies; and a (much larger) static version that was as completely self-contained as practical.  But that's currently a lot more work for Toady; automated build systems are getting a lot better, though.  Perhaps we're getting close to the time when it would be practical to set up and donate something along those lines. 

[c6r]

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...

Hey, I play on larger maps.I'm trying to get a 16x16 map running right now (I have in the past), but the windows version keeps crashing.  The linux version I can get going, but I don't play majority on linux and trying to transfer the save file has not worked.  A 64 bit version would be awesome for me.

[Thief^]

Hey, I play on larger maps.I'm trying to get a 16x16 map running right now (I have in the past), but the windows version keeps crashing.  The linux version I can get going, but I don't play majority on linux and trying to transfer the save file has not worked.  A 64 bit version would be awesome for me.

Look up "Large Address Aware.exe". If you're running a 64-bit Windows, it can double the amount of ram available to DF.

[My Urist Eternal]

Calling it a Linux problem is offensive.

Offensive? Keep in mind you did refer to the "Windows world" as "retarded" (which many people consider to be an offensive word in any context, not just this one). And yet the Windows method is much more reasonable and realistic for use in the real world in which everyone is not an OS hobbyist.

[Thief^]

To weigh in on the linux debate: I've installed 32-bit only software on 64-bit linux quite a few times, and the error messages are always useless. It's not a DF issue, I doubt toady even wrote the error message, I suspect it comes from the compiler directly.

It's almost always commercial software/games that have this problem, which you'll never get source released for (at least not while they're still commercially viable). At least you're more likely to get commercial releases in 64-bit now.

[Sizik]

Microsoft puts a lot of effort into making Windows backward-compatible. If your favorite program (or one required at your workplace) that you've been using for 10 years doesn't work on the new version of Windows, what's going to be easier: bugging the developers (who might not still be in business) to fix it, digging up the source code (if it's available to you, and if it even exists anymore) and fixing it yourself, or simply just not upgrading Windows?

Here's a good snippet about the subject:

The most impressive things to read on Raymond's weblog are the stories of the incredible efforts the Windows team has made over the years to support backwards compatibility:

Look at the scenario from the customer's standpoint. You bought programs X, Y and Z. You then upgraded to Windows XP. Your computer now crashes randomly, and program Z doesn't work at all. You're going to tell your friends, "Don't upgrade to Windows XP. It crashes randomly, and it's not compatible with program Z." Are you going to debug your system to determine that program X is causing the crashes, and that program Z doesn't work because it is using undocumented window messages? Of course not. You're going to return the Windows XP box for a refund. (You bought programs X, Y, and Z some months ago. The 30-day return policy no longer applies to them. The only thing you can return is Windows XP.)

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

[Thief^]

You should see the list of compat shims windows has these days. The stuff on the compatibility tab in the properties of an exe or shortcut is only a tiny fraction of the compat support windows has. Most of the options there activate multiple shims, and the "OS Version" selector activates dozens.

Microsoft has the advantage that due to various things (Windows Error Reporting, Smart Screen, etc) they have a database of nearly every executable ever created, and have built up information on exactly which compatibility shims are needed for each of the older ones. As a result, nearly anything you care to throw at it will run. Even Windows 3.1 applications will still run on modern 32-bit Windows (64-bit Windows finally dropped support for 16-bit applications).

See here for a tool that lets you dig into the guts of the Windows compatibility system:
http://blogs.technet.com/b/askperf/archive/2011/06/17/demystifying-shims-or-using-the-app-compat-toolkit-to-make-your-old-stuff-work-with-your-new-stuff.aspx

[Dirst]

You should see the list of compat shims windows has these days. The stuff on the compatibility tab in the properties of an exe or shortcut is only a tiny fraction of the compat support windows has. Most of the options there activate multiple shims, and the "OS Version" selector activates dozens.

Microsoft has the advantage that due to various things (Windows Error Reporting, Smart Screen, etc) they have a database of nearly every executable ever created, and have built up information on exactly which compatibility shims are needed for each of the older ones. As a result, nearly anything you care to throw at it will run. Even Windows 3.1 applications will still run on modern 32-bit Windows (64-bit Windows finally dropped support for 16-bit applications).

See here for a tool that lets you dig into the guts of the Windows compatibility system:
http://blogs.technet.com/b/askperf/archive/2011/06/17/demystifying-shims-or-using-the-app-compat-toolkit-to-make-your-old-stuff-work-with-your-new-stuff.aspx

Master of Orion II doesn't run under Windows 7, so I think these Microsoft people need to get their priorities straight!

[LordBaal]

Master of Orion II doesn't run under Windows 7, so I think these Microsoft people need to get their priorities straight!

hahaha that's true!

Spoiler (click to show/hide)

Hope this link! get you on the track of making it work pal

[Pidgeot]

(64-bit Windows finally dropped support for 16-bit applications).

Yes, partly because x86-based CPUs running in native 64-bit mode don't have a way to execute all 16-bit programs without leaving the operating mode of the CPU, partly because they needed more data for handles.

Essentially, 32-bit Windows deliberately limits handle IDs in order to support 16-bit code.

EDIT: Edited for accuracy.

[Dirst]

(64-bit Windows finally dropped support for 16-bit applications).

Yes, because x86-based CPUs running in native 64-bit mode don't have a way to switch to 16-bit mode - the only way to do it is to emulate the entire CPU, and that's going WAY beyond what the 16-bit layer in 32-bit Windows (NTVDM) does. If the CPU had allowed it, it is very likely 16-bit support would still be available in 64-bit Windows.

And what if I want to control a traffic light from the early 1970s?  Are you telling me it can't run 4-bit code either?! 

[GavJ]

I wonder what people generally prefer? Stuff just simply working no matter what you want to play or use? Or always proactively switching over to the most up to date technology at any moment and avoiding ever using any redundant libraries, even though disk space is dirt cheap? If only there were some way to take a vote about what most people think the "Correct" way to make an OS is:

[My Urist Eternal]

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

You can read the whole post here, and though it's dated (it was written in 2004), a lot of it is still apropos:

http://www.joelonsoftware.com/articles/APIWar.html

Another snippet:

"The Windows testing team is huge and one of their most important responsibilities is guaranteeing that everyone can safely upgrade their operating system, no matter what applications they have installed, and those applications will continue to run, even if those applications do bad things or use undocumented functions or rely on buggy behavior that happens to be buggy in Windows n but is no longer buggy in Windows n+1. In fact if you poke around in the AppCompatibility section of your registry you'll see a whole list of applications that Windows treats specially, emulating various old bugs and quirky behaviors so they'll continue to work. Raymond Chen writes, "I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95.""