The aforementioned cursor inconvenience

In the previous post, I mentioned an inconvenience with the cursors. Here’s the gist of it:

In Dark Seed II, the cursors are embedded into the resource part of the Windows 3.x (NE, “New Executable”) executable dark0001.exe. Specs are available on the Microsoft website, but they don’t quite match the executable, which claims that each cursor is only 32 byte big.

I did manage to extract the cursors in the end, with the help of the great tool “Multi Ripper” (a project that sadly appears to be dead). But when I then began to look for the resulting cursors in the Dark Seed executable, I couldn’t find them there, at least not directly: The headers are, only partly though, in the resource table, where you would expect them. However, the cursors’ data are at a completely different place, a place that I couldn’t construct with any of the offsets I read from the various tables. So I am completely at a loss.

Running Multi Ripper through a disassembler didn’t really help either, since it’s either deliberately obfuscated, or just completely unreadable due to it being written mostly in Clipper (yeah o_O). The link to a wine resource compiler Fingolfin send me didn’t help either (thanks again for looking, though); that compiler agrees with neither the specs, nor with the executable.

Since I was able to at least extract the cursors, I did what I had to do: hard-code the cursor data. So right now, the Dark Seed II engine comes with about 10kb of static cursor data. Not much of a problem, but certainly not as “nice” and clean as I’d like.

Well, if any of you happens to know a thing or two about resource tables in New Executables, please, pipe in and tell me what I did horribly wrong. 🙂