Print

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

[LynXsh]

Greetings!
Missed some versions and decided to finally grab the latest DT available. But it seems that it lost WinXP support somewhere between v41.2.0 and v41.2.1.
I know, nobody loves necromancy but sometimes it's not us to decide which OS the machine has.
So, I've the question: should I stick to v41.2.0 on this station or there will be WinXP supporting releases now and then?
Thanks!

[Clément]

There won't be Xp compatible builds any more. One could still make them with minor (at the moment) patches, but you would still need something more recent than Xp for building it (and it has been the case for a long time).

[Starver]

I've still got a (final ever?) working DT on my XP machine, from a prior period when I knew I had to not kust tale the standard download, I think (it's a while ago, I've slept since!). It's my generally offline PC[1] so what works keeps on working unless I actively do enough to break it.


When I get back to that particular machine (at the weekend) I'll have to check what versions of everything I think I have. It may have involved Windows patching (or maybe taken advantage of some auxilliary .dlls/whatever I had to use to solve a related issue with something else), but that might take more effort to establish.

I will of course bemoan that someone/several someones (upstream of Clément) has made the conscious decision to needlessly drop backwards compatibility (and/or make it necessary to jump through many awkward hoops to re-establish it). The last time I had to look explicitly at this problem (for someone else) it turned out to be an attempt to grab a non-XP system call that wasn't even supposed to be used (lazy compiling/linking process, outwith the obvious control of the programmer).

Not that I expect everything to be fully 8086-compatible[2], but it's Windows-executable encapsulation that is the big problem, and you can never predict what they will do with that even if they tell you their plans.


Maybe (and I've resisted this on my example of this legacy equipment, so far) the solution is to dual-boot[4] to a Linux build. Yes, there's a lot of 64bit-only/default distros you need to steer round (assuming it isn't 64 bit hardware, despite the XPness) or try to find the right legacy build that's not differently bad in terms of required dependencies, whether you go for a build or package or whatever from there on in.


[1] My online stuff, on my own equipment, tends to be either Raspberry Pi or Android, neither of which (easily!) run DF anyway, so the fact DT is at least as hard to run on each, respectively, has never been an issue I ever decided to try to solve.

[2] Oh, ok then, make it MMX-era/586, for the pipelin8ng bonus though DF never really needs anything other than integer operations, when you look at it.

[3]Nvm

[4] Containerising/OS-within-OS is probably a worse idea without a more modern system with the more current possibilities already built in. I imagine the slowdown of using something like a Cygwin environment would be worst-of-all-worlds in many ways[5]. And if you can run WSL then you're on a system where you wouldn't need to!

[5] Ironically, I used to run Windows DF on Linux via WINE, a lot, in my early days with DF. I dread to think how inefficient that was, but that was the better hardware at the time - though dual-booted with XP I was mostly booting to Fedora for everything else - and I don't even know if a native Linux build/package/semi-source was available for DF. It was definitely long before DT would have had to have been factored into the equation.

[Clément]

I will of course bemoan that someone/several someones (upstream of Clément) has made the conscious decision to needlessly drop backwards compatibility (and/or make it necessary to jump through many awkward hoops to re-establish it).

I won't. New OS adds new system calls (or library calls for windows) that can dramatically improve some part of your application. DT don't use directly anything that requires Vista or later, but I've dropped support for linux kernels much more recent than Windows Xp (and no one complained, although I did prepare workarounds for CentOS/RHEL 6).

[2] Oh, ok then, make it MMX-era/586, for the pipelin8ng bonus though DF never really needs anything other than integer operations, when you look at it.

MMX/SSE is not for floating point only, it can be used for vectorizing integer operations too. You can implement string operations using SSE.

[5] Ironically, I used to run Windows DF on Linux via WINE, a lot, in my early days with DF. I dread to think how inefficient that was

Wine would only slow down the API calls it is emulating. Everything else is run natively, I don't think the performance impact would be huge for DF.

[Starver]

Spoiler: My technoluddite agenda... (click to show/hide)

I'm a bit reductionist, I know. What could be a direct memory access (or as close to as makes no difference, while maintaining both system safety and hardware-agnostism) for precise and least-effort control is now a system call to some HAL that reprocesses into some lower-level HAL that(...) eventually persuades the kernel or one of its surrogate threads to service the request in possibly the very same way as a direct poke/peek would do if the OS/library/driver programmers anticipated things well enough.

Yes, under Windows you don't have a direct memory location for altering (or reading!) the current hue of the extreme top-left pixel of an application's window (sans-border), and the rest, and there are some good reasons for this that I would not argue with, but what if I actually knew that I'd actually be able to render something efficiently with a minimum of fuss, but am forced to create a "pixel object" upon a "canvas" one, with a while host of inherited methods that I will never use, and have to trust that the precompiler and compiler will not generate (or indeed require) bloaty system calls far from the simple byte or three of a MOV x,y or whatever (with indirect operands, if necessary) that I might have preferred to use.

So I've a somewhat hunter-gatherer mentality in the modern world of Big-Agri, I realise. If I can issue a single instruction to process a whole chunk of memory across to a window-port it's better than having to ensure a looped sample of byte-by-byte transfer is sensibly dealing with resizing (or even minimising) and keeping track of interrupts. I know that combine-harvesters are best when you have to gather in a few hundred acres of wheat before the weather turns wet. But sometimes you're growing a bonzai plant needs careful pruning and yet it's so difficult to attach those tiny scissors to the back-hoe of the JCB, that is really more useful for fixing a bucket used in clearing a field-boundary ditch.

Even offloading straight to a GPU (to save CPU cycles for who-knows-what bus-to-cache-to-bus shuffling) isn't cheap, it just seems it because it's geared to high-speed mass-copying of flipped bits, enough to obscure the inefficiencies behind other system bottlenecks, etc.

It's a battle I've long lost, and didn't even intend to bother you or anybody else with it, I was really going to just tell LynXsh I'd try to find out what state of play I'm successfully using, and suggesting a generalised (non-trivial) workaround in case it inspired some other idea that might have worked for them.

(My MMX comment, BTW, was intended to say pretty much as the spirit you responded to it. Meaning I under-explained that allusion, as well as over-waffled the whole thing. Nothing changes.)

[the hawk]

Hello!

Sort of new to the forums, when I went to create an account I discovered I had one from 6 years ago but never posted anything.
Hope I'm in the right forum for this. I'm trying to create my own grid view based on the standard "roles" view, with custom roles. Most of it is working well, until a certain point.

I have a custom role made and saved with a unique name. Even after closing DT and restarting its still there to be edited. But when I edit my grid view and look for the role there, it doesn't show up. Weirdest thing is, it did show up once and was added to my grid view but then it gave all the dwarfs blanks instead of a number. Which is weird because I hardly changed anything (I gave the miner role "agility" to check as well and changed some weightings). After that I have not gotten it to show up at all. Any idea what I'm doing wrong here?

[Clément]

What system are you using? What is the exact name of your custom role? Can you export it and post the content of the file here?

[Clément]

I am trying to migrate the Dwarf Therapist builds from Travis CI to Github Actions. There are some test builds available here. I'd like some confirmation that there are still working for everyone (especially the macOS ones that I cannot test myself). Note that the Linux AppImage is built on ubuntu 18.04 instead of 16.04 previously, this may break compatibility with older distros (like Debian 9 stretch a.k.a. oldoldstable). For macOS, the qt 5.9 version is supposed to be targeting macOS 10.9, the qt 5.15 version is supposed to be targeting macOS 10.13 (no change here).

[Schmaven]

As awesome as linux sounds, I have yet to put much time into figuring that out, so I'm just using Dwarf Therapist on Windows OS for now.  Out of curiosity about the future, is it intended for Dwarf Therapist to continue in some form into the Premium Dwarf Fortress release?  I know some people are adamantly opposed to the "spreadsheet" approach to labor management, but I personally enjoy the flexibility offered by Dwarf Therapist when it comes to seeing who is capable of doing what. 

Though I suppose with the changes in the Premium release, some of the DT functionality is supposed to be included in the base game at that point, so to some degree we'll have to wait and see?

[PatrikLundell]

Since Toady seems to aim at reducing player control over labor (aiming at simplifying management, not out of malice) I'd say there will be an even greater need to get some of it back. Those who don't like a spreadsheet approach aren't likely to be DT users anyway.
However, a lot of things will get tossed into the air with the Premium release, so it will probably take some time for DFHack layout mapping to catch most of the parts DT needs. Since DT has its own UI anyway, the UI remake itself won't affect it, only the data changes that were driven by the UI changes.