Print

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

[RadPanda]

I recently discovered Mono through dfma, which unless my noob eyes deceive me emulates the .net framework on unix systems.

It struck me that this could also be used to run dwarf manager, and Huzzah, I can get it to open.

However, there is the small issue of detecting the DF executable and plugging the correct memory offsets into it. (40d9 on OSX, in my case.)

As I mentioned before, I'm a bit of a newbie, and so don't know how to find these myself. Are there any kind souls out there who know how to do this, are willing to do it for the DFonsomethingotherthanwindows community, or point me in the right direction towards finding this mystical knowledge on my own?

I'm in the process of teaching myself C/Unix, and this looks like a cool project. That being said, though, I'm not very far past "Hello, world!"...

Thanks.

[corvvs]

I recently discovered Mono through dfma, which unless my noob eyes deceive me emulates the .net framework on unix systems.

It struck me that this could also be used to run dwarf manager, and Huzzah, I can get it to open.

However, there is the small issue of detecting the DF executable and plugging the correct memory offsets into it. (40d9 on OSX, in my case.)

As I mentioned before, I'm a bit of a newbie, and so don't know how to find these myself. Are there any kind souls out there who know how to do this, are willing to do it for the DFonsomethingotherthanwindows community, or point me in the right direction towards finding this mystical knowledge on my own?

I'm in the process of teaching myself C/Unix, and this looks like a cool project. That being said, though, I'm not very far past "Hello, world!"...

Thanks.

Short answer: Dwarf Manager will need to be rewritten, and even then it probably wouldn't be possible.

Long answer: For security reasons, programs under Linux/Unix can't touch each others' memory. Dwarf Manager would have to exploit some sort of security flaw/bug in DF. Even if one were to be found and the ethically ambiguous task of exploiting it in DM were to be undertaken, it still may not be possible due to two recent security innovations: 1) NX (non-executable) memory pages, which make security flaws harder to exploit (more likely DF would crash rather than giving up data access), and 2) randomized executable memory layout, which makes it impossible to determine where the data you're looking for is from the outside - it's in a different place every time you run the program.

I'm not certain whether or not OS X takes advantage of the last two, so it's possible that an exploit would work under that (although a Linux version has a surpassingly small chance of ever working), but I hope I wouldn't be alone in thinking that if a bug were found that Toady should be told about it and the hole would be closed.

Linux/Unix is far more secure than Windows, and a part of that security is keeping programs from interfering with one another, so DM will almost certainly never work under Linux or OS X. But it looks like Toady is implementing useful bits of it as he can while doing other coding, so you can take hope in that.

Addendum: of course, another way for it to work would be if Toady were to expose certain data structures via an API of some sort that programs could use to communicate with DF. But this would require a lot of work on Toady's part just to make some unsupported third-party utilities work -- possibly a post-1.0 endeavor.

[numerobis]

All this memory protection stuff just means you can't accidentally clobber memory, but even windows has that these days.  You can still purposefully clobber memory.

Probably the simplest way to make the utilities work for unix without worrying about making it run on both linux and BSD is to use gdb to attach to the running dwarf fortress process, and use gdb to do the requisite reads and writes to arbitrary locations in memory.  I somehow doubt that accessing memory like this is performance-critical (doing it via the intermediary of gdb will be terribly slow, but that probably doesn't matter).

[Baughn]

Don't use gdb for that. It'd be slow, and unreliable.

Instead use the ptrace syscall. That's what it's for.

[Quift]

What if you ise them all in Wine, then you should be albe to use only the windowsversions. I'm not doing this myself instead using the regular linux df and substituting dwarf manager with patience.

but that is not nearly as efficient.

[numerobis]

Instead use the ptrace syscall. That's what it's for.

man ptrace on my machine shows a man page from 1994 (which is, of course, utterly useless).  But the web provides; thanks.

[monolar]

ptrace on leopard is seriously crippled for this kind of usage. So currently i see no way to do this on OS X 10.5.x without kernel extension

[Baughn]

Yes, OS X really is crippled for this sort of thing, apparently for "security" purposes.

gdb somehow manages anyway, though. You might check its source code.

[monolar]

Hmm... this -> http://landonf.bikemonkey.org/code/macosx
may work. But as i said before this is a kernel extension and thusly not really user out-of-the-box friendly

[bhelyer]

which unless my noob eyes deceive me emulates the .net framework on unix systems.

Minor point: implements, not emulates.

[Martin]

Isn't this what Input Managers are used for? Or if you want to go outside of Apple APIs you can use APE (http://unsanity.com/haxies/ape) which should permit the same thing. APE has a reputation of being hackish/crashy so some people don't like to use it (raises hand, but relents when the need demands it) but I think this should be pretty doable.

Granted, this isn't what you're supposed to use input managers for, but since all it does is load code into memory for a given application, problem solved, no?

[Jay]

Nonetheless, the offsets for the 40dx versions have changed, and it's a pretty major pain to fix them.

[Jifodus]

Nonetheless, the offsets for the 40dx versions have changed, and it's a pretty major pain to fix them.

It doesn't matter if the offsets have changed.

Different platform = Different Compiler = Different Offsets.

All the work done on one platform will have to be done on each of the other platforms.  Sometimes offsets will be the same, but I wouldn't count on it.

[monolar]

Isn't this what Input Managers are used for?

Input Managers only work for Cocoa apps. Last time i checked the DF app is Carbon.

Ape could work but it's, like you said, really hackish ...

Ideally we should be able to do something that is simple for the end user and not require weird things and an installer

[Baughn]

How about preloading a library?

You could take the DFA approach and hook the OpenGL buffer switch function; that would allow you to run code once per frame. Or if you don't mind patching Toady's code, you don't need to override any library calls; any library can have a setup function that gets called anyhow.