Restoration of differing revisions of games' execuables

General discussion for all topics related to DOS, Windows, Linux, consoles, etc. Anything to do with games.
Post Reply
NY00123
Newbie
Newbie
Posts: 5
Joined: Sun Nov 01, 2020 3:42 pm

Restoration of differing revisions of games' execuables

Post by NY00123 »

Hi all,

Let me write about a collection of repositories, found here: https://bitbucket.org/gamesrc-ver-recreation/

What you can find in these repositories for most is reverse-engineering of code related to DOS games. However, rather than reversing a whole DOS game, what I usually do here is reverse different versions of games which were already open-sourced.

This idea came to me after the open-source release of not just one, but multiple DOS versions of Softdisk's Keen Dreams title. To be more specific, I downloaded the git repository and then had a look at the revision matching shareware v1.13. Using what I assumed to be the exact process for making the EXE, I got precisely the original EXE from the 90s, byte-by-byte. This process included usage of the right compiler version, as well as packing the EXE with LZEXE 0.91.

As for the above-mentioned repositories, the success rates greatly change, depending on the game in question, and especially the compiler in use (including the compiler version).

A more successful example is Wolfenstein 3D. Here, the executables from multiple versions of the game, including differing Apogee versions, can be fully recreated byte-by-byte, if done with the right tools and the right steps. It's possible that some luck might also assist, due to unintentional dependencies of the compiler and/or any other tool on the environment.

In other cases, there may still be differences in the output files. For instance, due to the way certain versions of Watcom C32 (v10.0b and older from what I know) behave, it may fill gaps between C string literals with data which depends on the environment, and/or on the textual contents of the input source code. This applies to the game code from Duke Nukem 3D: Atomic Edition v1.5, just for the example.

My most recent work is on the Heretic and Hexen sources; This only covers id Tech 1 code, not DMX. I did technically use DMX files in order to build the exes, but that's it; The changed code was from id or Raven.

For Heretic, this covers shareware and registered v1.0, which are quite similar. Another covered version is 1.2, which isn't very different from 1.3. The open source release itself turned out to match 1.3 in behaviors.

For Hexen, the open-source release basically matches one of two versions identified as "1.1". It's the latter out of the two, and the only practical difference between them is the addition of two checks to A_SoAExplode before spawning a monster, with one of them being a check of the boolean variable "nomonsters". The VERSION_ID string in the MAKEFILE was also changed from CBI to BCP.
Most of the work was actually in reversing version 1.0, or as it was later found out, two very similar variations of it again. The only actual difference between them is that the latter build had the addition of a check of the boolean variable "i_CDMusic" to P_SetupLevel, before calling S_StartSongName.

Regarding sound effects and music, back when Nuke.YKT was working on his PCDoom port, he made a wrapper over DMX, which is actually using the Apogee Sound System. While it obviously sounds different from DMX, it's a GPL-compatible alternative.
Therefore, I decided to add this wrapper under its own git submodule named "apodmx", with a few modifications. It can be built as a .LIB file which can be used with the Heretic or Hexen sources. You also need a compatible AUDIO_WF.LIB file from the Apogee Sound System.
NY00123
Newbie
Newbie
Posts: 5
Joined: Sun Nov 01, 2020 3:42 pm

Restoration of differing revisions of games' execuables

Post by NY00123 »

Hey there,

I've gotten another addition for the Hexen repository. To make this short, it should now cover code which is more-or-less fully equivalent in behaviors to the 4-level beta (Oct 2 1995).

I also forgot to mention here earlier, that before working on Heretic 1.0-1.2, I also covered a later 4-level demo of Hexen (Oct 18 1995).

Regarding the 4-level beta, there's probably too much to write about the code itself, so I'll simply mention the following examples of information:
- This revision has code for the removed fly creature (https://doomwiki.org/wiki/Fly).
- The 4-level demo from Oct 18 1995, previously named HEXDMO10 in my repository, was renamed HEXDM10B, while the earlier demo was named HEXDM10A.
- I considered renaming HEXDM10B back to HEXDMO10, while HEXDM10A would be renamed using (a subset of) the EXE's original modification date; Reason being, the latter is identified as a beta in-game, and I already did a similar thing with a Wolf3D proto. beforehand.
- However, both versions are referred to as demos in the README.TXT files from 1995. I also don't currently recall any mention of a version number, like 1.0. For now, I just keep using the names of HEXDM10A and HEXDM10B.
- I originally started to inspect the 4-level beta as a possibility after finishing with Heretic 1.0-1.2. I eventually returned to the beta more recently. What's clear is that it required more work to recreate the code than the previously covered versions of Hexen; Maybe even more than all previously covered versions of Heretic and Hexen, combined.
- In addition to the previously known issue of global variables not being fully ordered as in the original EXE, there are also a few functions that I couldn't get their compiler-generated layouts to fully match. Unless I missed anything, they should still match in behaviors. The functions in question are A_Quake, P_XYMovement and P_ZMovement. The latter's C code was actually not changed by me at all.
Post Reply