Bay 12 Games Forum

twbt-6.42-win.zip is missing twbt plugin, it only has mousequery.

Edit: also the description says "Support for DF/DFHack-0.44.09-r1" but the tag is the patch for 0.44.10.

As for GetModuleFileNameExW function, although you use this name in your code, apparently MSVC2015 forces the kernel32 version instead, unless explicitly told not to do so. That's probably because of MS policy and assumption that you want to compile for Win7+ (in future this assumption will change to Win10+, I'm sure).

I could not find what changed with PSAPI v2, it seems to be an ABI-only change. It is not clear if there was a technical justification, or if it is just a way to push users to update Windows (older application working on newer Windows is important to Microsoft but not the other way). I wonder the same about the optional winxp compatility, all the differences I read was about debugging. But I only make release versions with MSVC, I am more used to GDB for debugging.

I've noticed other difference. The programs store settings (Dwarf Therapist.ini) in different places. XP 32-bit version and older versions (like 39.0.0 or 37.0.0) store it in "\AppData\Roaming\UDP Software\", while XP 64-bit in "\AppData\Roaming\Dwarf Therapist\". At first I was baffled why the different settings, because until now they were preserved across the years. Incidentally, I like the new settings better than my old ones

This is not DT 39.3.1, it is an almost 40.0.0 version with the file paths changes and preference columns merged (like the links above). The settings file format did not change, you can move the old file if you want to keep your previous settings.

Yes the compiler was changed from GCC to MSVC2015.

As I said before, it is a matter of using an older version of Qt (5.6 works with XP), and the right compiler. And I've just discovered there is an optional MSVC2015 component for XP support.

MSVC2015 (v140_xp) 32bits build with Qt 5.6

Tested in a WinXP VM.

I expect this should work with vista too, but it is 32 bits.

I don't know what I should do for vista 64, I did not see any "vista support" package in MSVC. And it is not a Qt version issue since 39.0.0 was already using Qt 5.9.

Edit: Try this. I used the same parameter than the xp build but with 64 bits. I don't know what are the disadvantages of this kind of build. Or why Microsoft make it so hard to find it if there are none.

Appimage and apple bundle are actually disk images. In this case the application directory is actually inside the appimage (it will be mounted in a temp directory), not in LinuxLNP directory.

More test builds:

• Linux 64 portable, run with the dwarftherapist script in the root directory, not the executable in bin. There may be some issues with the bundled libs.
• Windows 64
• Windows 64 portable

Hi, I am the maintainer of Dwarf Therapist. For solving an issue with where the updater saves the downloaded memory layouts. I need to change how DT look up for data files. The simplest solution is to rely only QStandardPaths to get the directories to search (and write to).

This will particularly affects the LinuxLNP as QStandardPaths does not contains any path relative to the application directory (only XDG_DATA_DIRS + XDG_DATA_HOME). I propose two solutions:

• Use the XDG environment variables. Add DT path inside the LNP in XDG_DATA_DIRS. Updated memory layouts will be written in XDG_DATA_HOME and settings in XDG_CONFIG_HOME.
• I am thinking about adding a portable mode (enabled at run-time or build time) where, instead of using QStandardPaths, DT would only look for (and write) files in its own directory. It would require DT directory to be writable.

Would any of this fit LinuxLNP use case? What would you prefer? Do you have any recommendations?

I also posted about this in DT thread.

No reaction to that? Proposed changed are in this pull request

I would also like to know if any of these solutions would be acceptable to replace the launcher script that uses (gk)sudo and does not work very well.

For solving ptrace_scope issue on Linux, I thought about making DF ptraceable by anyone instead of adding a capability to DT. It allows for making DT works when ptrace_scope is set to 1 without needing root access. The required syscall is available since Linux 3.4. I see two way of implementing that.

1) A DFHack plugin:
#include "PluginManager.h"

extern "C" {
#include <sys/prctl.h>
}

using namespace DFHack;

DFHACK_PLUGIN("set_ptracer")

DFhackCExport command_result plugin_init(color_ostream &out, std::vector<PluginCommand> &)
{
if (-1 == prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0))
out.printerr("Failed to set ptracer: %s.\n", strerror(errno));
}

DFhackCExport command_result plugin_shutdown(color_ostream &out)
{
if (-1 == prctl(PR_SET_PTRACER, 0, 0, 0, 0))
out.printerr("Failed to reset ptracer: %s.\n", strerror(errno));
}
Loading the plugin will allow any one to ptrace DF. Unloading restore to default.

2) A library preloaded when running DF:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/prctl.h>

void set_ptracer_any() __attribute__((constructor));

void set_ptracer_any()
{
if (-1 == prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0))
perror("prctl");
}
Compile with "gcc set_ptracer_any.c -fPIC -shared -o set_ptracer_any.so", then run DF with "LD_PRELOAD=set_ptracer_any.so ./df" (or add "export LD_PRELOAD=set_ptracer_any.so" in the df script). It does not require dfhack, but it does require to modify the way DF is started. Maybe it can be used in LinuxLNP.

Now, I wonder if something similar is possible for macOS.

I get these I get a 'creating SSL' Memory Layout Error and Version Check Error. I'm using a lightly modded DF 44.09 install. Everything seems to be working fine. Any ideas why and if it is a problem?

A firewall issue? You can disable the updates in the options if it annoys you. I am publishing new releases for memory layouts anyway.

thanks Clément!! this one works on XP, but it gives an error that I'm running mulltiple DF processes, which I'm not... asks me to select an instance: 5636 or 4564, selecting neither does anything the later gives some memory layout errors... I'm running DF 44.09

Do you have another window whose title is "Dwarf Fortress" (e.g. a file explorer window with your DF directory)? I remember having this issue with win7 when I started fixing the 64bits support but it supposed to be fixed.