Wolf3D/SOD/BSTONE/S3DNA EXE versions restoration

UPDATE (Dec 25th 2015): This is a generic notice stating that this post does not have to be edited after any update to the repository or this topic; And so, possibly mentioning in this post for the last time, the update for today is the addition of versions 1.0 and 2.0 (1 and 6 episodes releases) of Blake Stone: Aliens of Gold.

UPDATE (August 28th 2015): The "wolf3d" subdirectory has been renamed "w3d_plus", now that the same codebase can be used to recreate (ignoring debugging information differences) the EXE for the DOS port of Super 3-D Noah's Ark, v1.0. The same applies to the .diff file. Other than this edit, I haven't touched the original post.

UPDATE (June 27th 2015): Blake Stone EXEs can be recreated as well now, with another post added to here on this topic. To summarize, versions 2.1 and 3.0 of Blake Stone: Aliens of Gold, Shareware and Registered, as well as versions 1.00 and 1.01 of Planet Strike, can be rebuilt using Borland C++ 3.1 and LZEXE 0.91. The rest of this post is untouched.

Hey there, I think it's a good time to link to the following repository (you may be interested in the "wolf3d" subdirectory): https://bitbucket.org/NY00123/gamesrc-ver-recreation/

The topic's description should briefly tell what is this, so it may be good to tell how did I get to all of that.

Back in September of 2014, following a campaign to acquire the rights to publish the "lost" episode of Commander Keen known as "Keen Dreams", original sources for this episode were made available. These include sources not just for one, but apparently all versions of Keen Dreams originally made in the 90s for DOS, with the possible exception of 1.93 (which isn't that different from 1.92 anyway and could also be reconstructed).

It looked to me like the sources were in a relatively good state, and that the released forms were not greatly different from the originals. It's also stated that Borland C++ 2.0 was originally used to build the EXEs, and it also looks clear that a lot of the EXEs were originally packed using LZEXE 0.91.

Therefore, I decided to have a little attempt, using Borland C++ 2.0 and LZEXE 0.91 to build and pack version 1.13 (Shareware release). Turns out, I got the exact same EXE as created in 1992, byte-by-byte. I also got such results with at least a few other versions.

This looks like the main motivation behind starting the "gamesrc-ver-recreation" repository above (although originally under a different location). I think that initially, I wanted to try and recreate the Catacomb Abyss v1.13 EXE. Eventually, this followed with the Catacomb 3-D v1.0 EXE and the Catacomb Abyss v1.24 EXE. To compare, the Catacombs sources as released on June of 2014 can be used to build the Catacomb 3-D v1.22 EXE, as well as an EXE *very* close to Catacomb Abyss v1.24. However, for some reason, in order to get exactly the original v1.24 EXE, STARTTILE8 has to be edited in GFXE_ABS.EQU, but not in GFXE_ABS.H (there's some function in ID_VW_AE.ASM which shouldn't be called but is compiled into the EXE, for which this has an effect). The exact same edit is also required for recreation of the v1.13 EXE.

Eventually, I decided to fiddle with the Wolf3D/SOD sources for similar purposes, gradually adding projects for recreation of certain EXEs over time. With a few exceptions, the right tools can now be used to build original EXEs from the sources above, byte-by-byte. The EXEs I refer to are these:
- Wolfenstein 3D Shareware v1.0+1.1+1.2+1.4, Apogee releases (with cheats). 
- Wolfenstein 3D Registered v1.1+1.2+1.4, Apogee releases (with cheats). 
- Wolfenstein 3D Registered v1.4, early GT Interactive release. 
- Wolfenstein 3D Registered v1.4, ID Software release (same EXE as in the early
GT Interactive release, except for a different logo in the signon screen). 
- Wolfenstein 3D Registered v1.4, late GT Interactive release
(no three-letter code is shown after completing an episode). 
- Wolfenstein 3D Registered v1.4, Activision release. 
- Spear of Destiny demo v1.0, FormGen release. 
- Spear of Destiny v1.0+1.4, FormGen releases (copy protected). 
- Spear of Destiny v1.4, Activision release (no copy protection).

It should be noted that the original SOD v1.0 EXE, as well as the originally released Activision EXEs (as currently available from Steam), appear to be a bit different. The former has the "LZ91" string from its first 32 bytes replaced with NUL bytes, while the latter two have "shifted" LZEXE signatures. In addition, the very beginning of the SOD v1.0 EXE has a couple of bytes differing from what you may currently get from the sources, implying an increased so-called "BSS section". The STRIPBSS tool included in the same repository wasn't made with this in mind, and I'm not sure about this. However, apparently it was very common to use modified EXEs in which the copy protection is skipped or removed, and this may further add some confusion.

There are also a few EXEs which are *not* reproduced by any project above, and there are great chances they won't be (but at least we have all of the above!):
- A release of SOD v1.4 made for FormGen, mistakenly labelled as v1.0 in the signon screen. (If it's just the v1.4 FormGen EXE, but with another signon screen, then it should be relatively easy to recreate it now.)
- Any translated release.

Unfortunately, there aren't exactly tools I'm aware of that can automatically compare two EXEs from different revisions of very similar source codes, given the EXEs and one source code revision as an input. Hence, the differences had to be manually located. There are still enough ways to ease the work, though. Obviously disassemblers can be used so we don't have to look just at machine code. Furthermore, Borland C++'s linker can generate a MAP file that shows the locations of most functions and variables in the EXE (as segment:offset pairs).

It's not just a matter of modifying the C/H/ASM/EQU files themselves, though. Project settings (like optimizations) had to be guessed for at least 2-3 projects, the ordering of a few source files to had to change in certain projects, there are files that should be removed from some projects (possibly most), and the GAMEPAL data has to be linked in different ways for different projects (either into its own segment, or as a part of the data segment).

Finally, these are still not exactly the original revisions of the sources, since we don't have access to them. However, what can be done now, is telling differences between versions as expressed in the compiled EXE files (e.g., the differences in secret elevator handling between Shareware versions 1.1 and 1.2, although these were basically known for a while).

I've gotten your message.  Just email me at stathmk (at) yahoo (dot) com because my Wolf3D Haven inbox is almost 100% full.  In the message tell me what username you want to use for Diehard Wolfers and what email address you will be using.  This is so that I can have Tricob or somebody whitelist it.

I've heard that it's areyep.com (RIP) because the South African webmaster is a family member or relative to a band member of Areyep (RIP).  It's been so many years that I don't remember exactly where I've heard of this.

Webmaster Brian of wolfenstein3d.co.uk has Parkinson's and doesn't type much anymore.  We wish him the best.  Do a search for Ersatz Wolf3d Dome News in the Diehard Wolfers Forum to find Andy's post of mods.  For no apparent reason, Andy stopped posting in February.  I hope that he's doing well.  So until Tristan becomes the webmaster of wolfenstein3d.co.uk, then email your finished mods to me.  I need to post them on wolfensteingoodies.com.  Hopefully I'll post 2 every Sunday.  I have a backlog of files.

On May 5, Wolfenstein: The Old Blood will be for sale.  I understand that it's a prequel to Wolfenstein: The New Order and takes place in the parallel universe timeline where it's 1946 and the Nazis still haven't lost.  While in reality, Hitler killed himself on April 30, 1945.  So maybe it's a parallel universe where the war continues on anyways after Hitler's death?

I need to comment another day about Wolf3D/SOD Exe versions restoration.

Heh, thanks for your reply. I shall do as you've suggested. As you've probably guessed or seen I'm not really that familiar with the differing Wolf3D-related communities/websites, at least not as much as others.

I've heard, though, that basically the admin of DHW (if not someone else) seemed to lose the interest and/or move on to other things, which should be a natural progress that tends to occur to a lot of individuals. I know it's kind of similar with pckf.com and keenmodding.org; I think that these days, while you may be able to create an account over any of these Keen-related forums, you need to wait for a moderator who's also able to activate new accounts, and I'm not sure how active are they these days (but at least one of them seems to be reading posts). The original admin of the sites, who also, naturally, seemed to move on, still took care to let the forums be up in a few occurrences they stopped working, though. (As a side note, my PM inbox at pckf.com is also quite full nowadays. Just a side-note, though.)

I also did heard the story about Brian Lowe. I guess one thing I can say for now is to hope for better.

Also, if this is what you mean, I'm afraid I don't really have any Wolf3D mod of mine to submit. The closest to that which I worked on is weirdly the "versions restoration" stuff.

Finally, it's interesting to see Tricob mentioned given that a related topic has already been started on DHW, in which he's replied: http://diehardwolfers.areyep.com/viewtopic.php?t=7098

Bump.

There is another update to the repository that at least some of you may be interested in. But first, while working on it, I think that I finally figured out how to strip the BSS segment (a bunch of zeros) from the end of an EXE file right from Borland C++, without using the STRIPBSS tool that you may find in the repository itself. Turns out you should open the Debugger settings window from Options -> Debugger, and then select "On" for "Source Debugging". I looked for a way to strip the BSS segment before and somehow didn't think to try here...

Note that I haven't yet changed the relevant Wolf3D projects to take this into effect. But there's the other update that I've briefly referred to. I've just added a new "bstone" directory today, with the restoration of some Blake Stone versions. This also includes Aliens of Gold. The exact versions that can be rebuilt are these:
- Blake Stone: Aliens of Gold v2.1+3.0, Shareware and Registered releases.
- Blake Stone: Planet Strike v1.00+1.01.

Like the way I grabbed and modified GFXV_APO.H from Wolf4SDL by Moritz "Ripper" Kroll, for the restoration of Wolfenstein 3D Apogee EXEs, I used GFXV_BS1.H definitions from the bstone port by Boris Bendovsky. I also "borrowed" a few song definitions in the very beginning from the same port. Regarding AOG restoration in general, most of the source code recreation was done using earlier research work by Braden Obrzut.

Not remembering a lot from the two Blake Stone games, I thought that I may encounter quite large differences and a lot of code pieces removed. Turns out this wasn't really the case. 3D_MAIN.C has a couple of AOG-specific functions related to player alignment, and the AOG implementations of ShowOverhead and InputFloor have great differences from the PS implementations, but a lot is really the same. There are also a few commented out AOG-specific code pieces in the released Planet Strike sources, like Vital sprite definitions. Interestingly, there are at least a few occasion in which AOG-specific line codes apparently has different indentation (when compared to similar codebases). Furthermore, this is probably known, but it looks like the vital was "transformed" into the rotating cube during the development of Planet Strike.

As expected, though, I think that Planet Strike was started as a separate branch even before Aliens of Gold v2.1 was released. As a hint of that, the implementation of CA_LoadAllSounds in Planet Strike is the same as in the Catacomb 3-D sources, while there are minor edits in Aliens of Gold (at least in versions 2.1 and 3.0).

Hey there, thanks for your interest in the restoration of the few games' versions!

Have you taken a look at Aliens of Gold v1.0? The shareware version can be found here and the registered version can be bought on ebay for $11.50. I think we will find the differences interesting (like how they managed to go from 591K to 540K). To tie your two posts together: It looks like all versions of Aliens of Gold and Planet Strike use Wolfenstein v1.2 as a base, not v1.4. I first noticed this when I changed the Screen Size and it still said "Computing" instead of "Thinking".

I haven't looked at any version of Blake Stone other than the ones you may recreate now.
It's good to see you finding a reference Wolfenstein 3D version. One thing I'm still a bit confused about is the implementation of VL_WaitVBL. You can see that for the restoration of the versions, I modified VL_WaitVBL as found in ID_VL_A.ASM to be the same as the WaitVBL function from WAITVBL.ASM. However:
- There are commented out reference to WaitVBL in ID_VL.C. All other mentions refer to VL_WaitVBL or VW_WaitVBL.
- Except for this, and ignoring the different compilation time and date (originally embedded into the EXEs using the __TIME__ and __DATE__ macros), the sources as released by Apogee Software, LLC were used as-is to recreate the Planet Strik v1.01 EXE. Furthermore, just about a couple of edits were required in order to recreate the Planet Strike v1.00 EXE (look for mentions of GAMEVER_RESTORATION_ANY_LATE in the current revision of the recreated codebase).
Hence, it isn't clear if the implementation of VL_WaitVBL in ID_VL_A.ASM was actually edited at any point. Maybe some symbol/object-code shuffling was done, but these are really just guesses.

POST EDIT: Just made a minor correction spotted by Blzut3 (had a misleading mention of SNES texture/sprite size, which may really apply to the Jaguar and Mac versions of Wolf3D).

All right, I think it's time for another update:

- To begin with, please note that the "wolf3d" directory has been renamed "w3d_plus", for a reason that should be quite obvious very soon. Similarly, the wolf3d.diff file has been replaced with w3d_plus.diff.
- For each project you previously had to use STRIPBSS, there's no need to anymore. While working on Blake Stone, a way to strip the BSS section right from Borland C++ was found: Disabling the addition of debugging information to the EXE.
- As in the Blake Stone tree, PREP.BAT can now be used for making a clean up, before a project is built in w3d_plus.
- The most significant update, though, is the recreation of code for the DOS port of Super 3-D Noah's Ark, a title which many may consider a Wolfenstein 3D mod with changes.

Now, there's enough to tell about Super 3-D Noah's Ark (i.e., S3DNA) which differs from previous restoration efforts. I should begin with a little introduction, being that S3DNA was originally released as a SNES title, using the SNES port of Wolfenstein 3D as a base. The latter port, known to belong to the so-called Mac Family of Wolf3D ports, has some clear differences from the original DOS title. These include variable-length episodes, enemies appearing to face the player for all time, two additional weapons (flamethrower and rocket launcher) and generally a different storyline and somewhat different maps. The SNES version also had some censoring.

As said before, S3DNA was started as a SNES game based on the port above. The original DOS codebase was then used as a base for a DOS version of S3DNA. It is more similar to the SNES version than the DOS and SNES versions of Wolf3D are, though. For instance, the two versions of S3DNA let you use an auto-map, and there's an arsenal of up to 6 feeders (weapons), including hand feeding. The most technically significant addition to the DOS version, though, may be MIDI music playback (still via an AdLib or Sound Blaster), using what appears to be the MIDI data from the SNES version.

Now, according to Braden Obrzut (aka Blzut3), developer of the ECWolf port of Wolfenstein 3D, which is also used as a base for a new commercial port of S3DNA, unfortunately the original source code for S3DNA is assumed to be lost. However, I figured out that S3DNA isn't that different from Wolf3D in many ways. In fact, it feels much more like Wolf3D than the Blake Stone games may be. For instance, it's now clear to me that each animal in S3DNA is basically just one of the Wolf3D enemies with a few changes. There are still some modifications, the largest possibly being the MIDI code, but otherwise it's more-or-less the same. And so, the recreation of the EXE has started.

It may be a good chance to tell that a disassembler known as IDA Pro has been in use (there are a few versions which can be used for free for non-commercial purposes). While it does not translate the code in the EXE back to readable C code, it can still be useful for many purposes, like an initial automatic analyzing of the code, locating functions, variables, string literals and more.

One thing it can't seem to do (at least the version in use), though, is reading debugging information appended to the original S3DNA EXE. I've decided that I initially skip this and make sure the actual code and data match with the original, which is most of the work (and further the practically interesting part) anyway, and also what I've been familiar with. Some earlier research work done by Blzut3 has also been very useful.

Let's take one step back. Debugging information? That's right, not only the original S3DNA EXE is not an EXE packed with anything like LZEXE, it still has intact debugging symbols. This includes names of functions, almost all variables and even some enum definitions (probably as long as there's a variable of the given enum's type mentioned somewhere). As said above, though, I've initially skipped these. Only towards the end, having a little problem in the compiled MissileTryMove function, I've decided to start the Turbo Debugger and inspect the function. Turns out, while the original sources may be lost, the EXE still has line numbers information. Surprisingly enough, splitting an "if" expression with an "&&" operator into 2 lines has solved the issue, and I've finally gotten the exact same EXE image as the original (ignoring the debugging stuff).

Afterwards, I've figured out that Turbo Dump can be used in order to dump the debugging information in a somewhat more readable way. The -v argument may be used control the way the output appears to be. With the help of this, and by comparing the output of the original EXE with a recreated one's output, I've assigned names used in the original codebase to all functions and almost all of the variables, as well as some enum values (in case of differences in the TDUMP outputs). There are very few (local) variable names which may be missing, but it isn't a great deal.

There are still a few differences in the Turbo Dump outputs, mainly with some type symbols. Missing function prototypes may be one cause, while there can be more. However, given that the actual EXE image has been successfully recreated, and original symbol names are now in use where found, I think this can be sufficient for now.

ok, this is more like a minor side note, but did anybody notice that some of the Noah tunes play in the DOS version with different tempos, compared to other versions (including the ECWolf-based re-release)?

Code:

diff -r 789c61553acd w3d_plus/ID_SD.C
--- a/w3d_plus/ID_SD.C   Fri Aug 28 16:36:20 2015 +0300
+++ b/w3d_plus/ID_SD.C   Wed Sep 23 00:40:22 2015 +0300
@@ -2126,9 +2126,9 @@
       {
       case 0x51:
          length = MIDI_VarLength();
-         tempo = ((long)(*midiData)<<16) + (long)((*(midiData+1))<<8) + (*(midiData+2));
+         tempo = ((long)(*midiData)<<16) + ((long)(*(midiData+1))<<8) + (*(midiData+2));
          midiTimeScale = (double)tempo/2.74176e5;
-         midiTimeScale *= 1.1;
+         //midiTimeScale *= 1.1;
          midiData += length;
          break;
       case 0x2F:

A directory with the same patch, an EXE built after applying the patch and the following description may currently be found in the w3d_plus/MISC subdirectory of the same repository: https://bitbucket.org/NY00123/gamesrc-ver-recreation/src/a57d87f5102aa9f378fefdbdf55d6160c37e9277/w3d_plus/MISC/?at=default

What I think that happened is this: Originally, the cast to long for the middle byte was done in the wrong place, leading to an integer overflow in case *(midiData+1), an unsigned 8-bit byte, had the value of 128 or greater. While (*midiData+1) may internally be casted to int, a 16-bit signed integer in this case, for the shift by 8 bits to the left, this isn't sufficient for the later cast to long, since a sign extension is done here.

Example: if (*midiData+1) is, in binary, the value of 11000100b, then after shifting we get the 16-bit value of 1100010000000000b. By casting from a 16-bit SIGNED int to a 32-bit signed long int (i.e. doing a signed extension to 32-bit), we get the bit pattern of 11111111111111111100010000000000b. This is not the expected result, though, as it should've really been just 0000000000000000100010000000000b stored in a long int.

The multiplication of midiTimeScale by 1.1 is probably an attempt to get the correct tempo, at least for certain musical tracks, as the actual cause of the bug was apparently not found back in the 90s.

Obviously this isn't exactly in the goal of recreating original EXEs' behaviors, including all quirks, but it may still be a bit relevant since this is a minor modification of the recreated S3DNA sources.

Hi again,

I think Dec 25 may be a good time for an update!

This time, it's about Blake Stone: Aliens of Gold again. With the possibility of a few really minor differences, you can now recreate the EXEs from the 1 and 6 episodes releases, versions 1.0 and 2.0.

To begin with, it's probably not a surprise that version 2.1 has very few differences from 2.0 in terms of code. The chunks definitions as given in GFXV_BS1.H are exactly the same for these. If I haven't missed anything, I think these are all of the differences in the code:
- The addition of destPath/tempPath handling.
- The new GS_TAB_ROTATED_MAP flag (you can decide if Tab shows a rotated map in-game, or Shift+Tab).
- The "flags" field of the gametype struct was changed from an unsigned to a long. By the way, this field's type is still unsigned in Planet Strike.
- Misc. changes in GetNewActor and PlayLoop (3D_PLAY.C).

Now, it's version 1.0 where things changed more significantly. I don't see myself bothering to list all of the differences, but I'll give a few examples, one of them possibly being the most significant. Let's begin with simple cases:
- Some ID_SD.C code was moved to JM_FREE.C, before being relocated back to ID_SD.C for v2.0. I really have no explanation for this.
- A few bits of ID_SD.C are closer to code from the Wolfenstein 3D sources in v1.0. This also applies to at least 3D_DRAW.C function (ScalePost).
- If you check out ID_PM.C from the released Wolfenstein 3D sources, or JM_FREE.C from the Planet Strike sources as originally released, you should find two mentions of the comment "AJR: bugfix 10/8/92" in PML_StartupXMS. While recreating different version of Wolfenstein 3D, I found out this was fixed before making any release of Wolfenstein 3D or Spear of Destiny with version number 1.4. Looks like this was similarly applied in-between versions 1.0 and 2.0 of Blake Stone: Aliens of Gold.

One known difference between versions 1.0 and 2.0, is that 2.0 requires less memory (required amount changed from 605k to 580k and then to 540k): http://litude.webege.com/apogee/version/blake.html#Version_2.0

It probably sounds a bit too silly to think that modifying the value of MIN_MEM_NEEDED is all that was needed: https://bitbucket.org/NY00123/gamesrc-ver-recreation/src/b899fb1e19a7bedc7bd037c8d18d7d724fd5e438/bstone/3D_DEF.H?at=default&fileviewer=file-view-default#3D_DEF.H-63

In this case, I think that 3D_SCALE.C may have the answer. Between versions 1.0 and 2.0, 3D_SCALE.C was mostly rewritten (possibly along with some related code pieces). In fact, for the recreation of v1.0, I simply copy-and-pasted WL_SCALE.C from the Wolfenstein 3D sources and modified it as required.

It should be known that version 1.0 missed some features, like the way lighting is done in later version. This is also a good explanation for differences in performance: v1.0 may feel much smoother than v2.0 and later on a given machine, unless you disable the lighting. That may be one reason for the changes to 3D_SCALE.C; I don't know.

But there's also the following point. Anybody sufficiently familiar with the Wolfenstein 3D codebase, or at least WL_SCALE.C, should be familiar with the function BuildCompScale, which is responsible for generating scaling code in runtime. It's called as a part of a chain of function calls NewViewSize -> SetViewSize -> SetupScaling -> BuildCompScale on certain occasions, like changing the view size during gameplay. BuildCompScale is used in Wolfenstein 3D and AOG v1.0, but is not used in later releases of Blake Stone games. I can't say I get all the details, but it clearly feels like a rewrite to me.

To the few who may wonder: According to http://litude.webege.com/apogee/version/blake.html, versions 1.0 and 2.0 were also released as 3-episodes forms. In the case of Wolfenstein 3D, the 6-episodes EXEs were known to be shared. For each original 3-episodes build of Blake Stone: Aliens of Gold, I *guess* that MAPTEMP_CHECKSUM is all that's different from the value for the corresponding 6-episodes build. I can't say this for sure at the moment, though.

One final note: By looking at GAMEVER.H (or even just the raw EXEs, at least after unpacking), you can find out the 1-episode v1.0 EXE was built one month before the corresponding 6-episodes EXE. As expected, there are a few changes in the code between these versions (currently you may find these by looking for mentions of GAMEVER_RESTORATION_BS1_100), but these are really just a few.

Hey there,

While I don't have a lot of new actual contents to report about, there's still what to write.

1. To begin with, anybody who's been messing with the modified Wolf3D codebase from my repository should probably read this point. Not long ago, I've found out that Borland C++ effectively truncates too long identifiers behind-the-scenes. There's an "Identifier Length" option which tells the max. identifier length, and has to fall in the range 1-32 (at least under Borland C++ 3.0).

So it's been a good chance for me to not just shorten identifier names, but also do some other changes. A significant one is the usage of a new GAMEVER_WOLFREV macro for covering different ranges of Wolf3D codebase revisions.

Also, the project file names have been renamed. In particular, note these renames: WL1APO12.PRJ -> WL1AP11.PRJ, SODFOR14.PRJ -> SODFG14B.PRJ. There is indeed a new "SODFG14A.PRJ" project, see below.

Finally, VERSION.H and VERSION.EQU now internally used "EXEDEF" macros that match the corresponding project files. These macros are *never* directly used in any other source file (on purpose). GAMEVER_WOLFREV should be used for this, combined with macros like UPLOAD and GOODTIMES, as well as the new GAMEVER_NOAH3D macro.

2. I've added a project file for another EXE, named SODFG14A.PRJ. This is the "v1.4" release mistakenly labelled as "V1.0" in-game, which was apparently released on 1992-11-12, according to Litude. To compare, SODFG14B.PRJ (previously named SODFOR14.PRJ) is assumed to be released on 1993-01-12.

In terms of actual code found in the C and ASM sources, SODFG14A.PRJ and SODFG14B.PRJ are exactly the same. Furthermore, both EXEs were originally built using Borland C++ 3.1. However, in other ways, SODFG10.PRJ is more similar to SODFG14A.PRJ. This includes differences like the order in which objects get linked, as well as the "V1.0" sign-on screen. In fact, ignoring my addition of the "EXEDEF" macros, the exact same project file can theoretically be used for SODFG10 and SODFG14A altogether, with a bit different VERSION.H/EQU definitions.

3. For some weird unknown reason, the instructions for building SODFG10.EXE (previously SODFOR10.EXE) have changed a bit. After building the EXE, you now have to remove WL_PLAY.OBJ, re-open the project with Borland C++ 3.0 and then again press on F9 to build the removed code. Only then, LZEXE91 may be used. I really don't know why this is the case, especially since it's not required in an earlier revision of the codebase (I've verified this). It might be related to source file(s) layouts and/or the way a table of definitions internally used by the compiler is structured.

4. I've also updated the notes regarding the compression of the Activision EXEs. To summarize, you can use LZEXE 0.91e, rather than 0.91, to faithfully recreate the EXEs from 1998. These two versions of LZEXE seem to differ, a little bit, by the contents of the decompressor stub as embedded in the packed EXEs (0.91e appears to add a "push ax" and a later "pop ax", if there's no other change). Since UNLZEXE8 checks the first 232 bytes of the decompressor stub, this should explain why it fails to unpack any of the Activision EXEs, while UNLZEXE7 can do so. Of course, if any of you attempts to hide that "LZ91" string (found in the first 32 bytes of the EXE), then UNLZEXE7 will fail, too.

I'll also add a few bonus points here:

5. So now, I don't exactly have the means to build this as-is, but let's continue anyway. The file http://www.freewebs.com/choksta/wolflist.txt lists a "WOLF3D_J.EXE" executable, which comes from a Japanese localization of the game made for DOS/V (not to be confused with the PC-98 port i.e., WOLF98.EXE). It is reportedly 254046 bytes long. Well, it turns out, that when you modify WL6GT14A so the JAPAN macro is defined instead of GOODTIMES, Borland C++ 3.1 outputs an EXE with the exact same size. Again, though, I cannot confirm it's the exact same EXE. In fact, I'm quite sure it isn't, given the presence of the (wrong) GT sign-on screen, heh.

6. One may be wondering if WOLF3D.EXE, as originally bundled on 1995 along with the Wolfenstein 3D sources, can be re-created? In fact, maybe it can simply be built from the sources as released back then? Well, it turns out the answer is "yes", under a few conditions. First, you should use Borland C++ 3.0. Secondly, make sure all files have their original modification dates, not older than 1995. Otherwise, expect to get a few minor differences between the 1995 EXE build and your build.

Can the same be done from my repository? Well, if we ignore differences in debugging symbols, then again the answer is "yes". Basically, you should begin from (a copy of) WL6AC14.PRJ, then replace the Activision SIGNON.OBJ with the GT one, select "On" for "Source Debugging" in Borland C++ 3.0 (under Debugger Options) and finally make sure that GAMEVER_WOLFREV is the same as for WL6GT14B. You may wish to modify the output directory to something other than OBJ\WL6AC14, and possibly also update the Include and Library directories (so files from BC30 are used instead of BC31). Watch out, though, in case you also want to replace the GAMEVER_EXEDEF_WL6AC14 macro. Reason is, not only you should edit it under "Compiler -> Code Generation", but it also has to be manually changed for a few ASM sources (under params passed to the assembler).

OK, I want to correct a few mistakes of mine. Afterwards, I'll ask about the new macros used in the sources recreation repository.

1. First, about Blake Stone: Aliens of Gold, I mistakenly mentioned in DHW and RGB that demo no. 3 is the first to be played in version 3.00. In fact, this is the case only in the registered version. The LastDemo variable is still initialized to 3 in shareware v3.0, but the actual demo number is calculated mod 3.
2. Secondly, about the projects SODFG14A.PRJ and SODFG14B.PRJ, I mistakenly hinted that there are differences between term, in the orders objects get linked. This is incorrect. In fact, these two projects are almost identical (and hence are both similar to SODFG10.PRJ, ignoring Borland C++ version originally used). Basically, the only real difference (other than SIGNON.OBJ) is that Source Debugging is toggled "On" in SODFG14A.PRJ and "Off" in SODFG14B.PRJ.

Now, I'm wondering if my choice of new macros (like GAMEVER_WOLFREV) is not favored by some of you? Maybe there's a better approach?

I'll say that I still want these points to apply:
- Macros shouldn't be as long as they used to be (or else the compiler may trim some of them).
- There should be one EXEDEF macro per EXE, mentioned *only* in VERSION.H and VERSION.EQU. I basically think it's (somewhat) better in terms of maintenance. It's also a good way to clarify that shareware v1.1 isn't of the the same revision as registered v1.1.

The thing is, maybe I should've used names like "GAMEVER_WOLF3D_PREREG" for shareware versions 1.0 and 1.1. But then, GAMEVER_WOLFREV can be used to (roughly) describe a range of code revisions, and not necessarily specific game versions.

There's also the special case of GAMEVER_WOLFREV being compared to 19921007L in ID_PM.C. (Yeah, I could use 19921008L, but I tried to be consistent, so I always used "<=" in comparisions, rather than ">"; Admittedly a bit of an imperfect situation.)

Think it's time for another update. Let's begin with a few initial notes:

- It turned out the Blake Stone codebase had a silly typo specific to AOG. In the AOG versions of the enemy_t enum, en_goldmorphshot was mistakenly defined instead of en_arc_barrier. It was also used instead of en_arc_barrier in AOG-specific code pieces, but luckily it didn't occur that much.
Interestingly, the EXEs *still* built as expected! Thanks to Aryan_Wolf3D for reporting this.

- Following some feedback, I've changed some stuff with the Wolfenstein 3D game versions *yet again*. Basically, instead of comparing GAMEVER_WOLFREV to mere numbers, helper macros are used, prefixed with GV_WR (e.g., GV_WR_WL1AP10). Note that there's still an exception to this rule in ID_PM.C (with the AJR bug-fix).
Sorry if this has caused more mess for anybody, but hopefully it won't happen that much start.

Now, hopefully these points will be more interesting:

- I suppose at least a few users have wondered about this, especially after an earlier reference of mine in DHW. Thanks to some assistance, you can now recreate the DOS EXE from the Wolfenstein 3D 6-episodes Japanese version!
As expected, there wasn't really much code to add, since it's already found under the "JAPAN" ifdefs. I did used that old recreated FOREIGN\JAPAN\GFXV_WJ6.H file I previously referred to.
It was almost there, *really*. Only the value of CONTROLS_LUMP_END had to be corrected. Other than these points, and the different sign-on screen, WJ6IM14.PRJ is essentially the same as WL4GT14.PRJ, just with JAPAN defined instead of GOODTIMES.

- Next, there's basically a bonus. Usually, I wouldn't cover such game's versions, since they're generally not intended for public usage. However, he following version of Wolfenstein 3D apparently started to get widely accessible even in 1992, and may even be considered another "semi legitimate" shareware release (although I won't link to it here).
That's right, I'm talking about recreating the EXE from that Wolfenstein 3D March 1992 alpha/beta build! Recreated code is now in my repository. One surprise to mention is the various occasions in which S3DNA and the alpha are grouped together. There are also a few cases in which S3DNA and v1.0 (and possibly also the alpha) are grouped, but don't recall that many of these. Also, there's a somewhat(?) interesting name for some unused variable in WL_TEXT.C (present in the alpha only); Leaving for you too see it, heh.
In addition, there's this empty stub, which I originally added to ID_VH.C under the name of VW_NullStub, while recreating v1.0. Turns out, it was (almost surely) named VW_SetDefaultColors. Reason is that is called from MM_ShowMemory in Catacomb 3-D, and the code is almost the same in that Wolf3D March 92 build. Furthermore, except for VW_SetDefaultColors, this implementation of MM_ShowMemory is also present in Keen Dreams, albeit access to it from KD_MAIN.C was originally disabled in the sources (using FRILLS). There are also other cases in which some alpha code is similar to Keen Dreams and/or Catacomb 3-D code piece.

- Finally, I've added a new "HOWTO.md" file, partially describing some points about the process of recreating EXEs built with Borland C++ 2.0/3.0/3.1.

LATE POST EDIT (June 7 2017): Looks like I've forgotten to mention one more thing. Did you know that I originally started this codebase as a git repository hosted by GitHub? Well, this is what happened, basically hosting the Catacomb Abyss sources, modified to recreate CATABYSS.EXE from shareware version 1.13 (QA [0]). Just a week later, though, I moved to a Mercurial repository hosted by BitBucket, and added a few Wolf3D and SOD versions (Wolf3D shareware v1.4, SOD demo v1.0 and the Activision versions).
I did get rid of the original git repository as originally hosted on GitHub. Luckily, though, I've still had a local copy of this repository. It is now up on BitBucket in the following link (note it's still a git repository, *not* a Mercurial one): https://bitbucket.org/NY00123/game-srccode-ver-recreation-git-legacy/

Time for something new(er), although I guess my announcement has been postponed by 3.5-4 months!

OK, I shall first say the following is *not* an example of perfect recreation - There are still a few unresolved differences. However, I have a feeling it's sufficiently close to be mentioned.

That's right, we're entering Watcom C / 32-bit territory, with Rise of the Triad!

To be specific, the releases currently covered are the Shareware, Commercial/Registered, Super CD and Site License Apogee v1.3.
Note that most of the code changes were not to ROTT itself, but rather to the audio library, named Apogee Sound System (i.e., ASS) and also known as AUDIOLIB (based on a directory name).
The guessed version of ASS in question is 1.04.

Watcom C 10.0b, as well as Turbo Assembler v3.1 (the one from Borland C++ 3.1), shall be used.

Note that the builds you'll get do *not* include the built-in DOS4GW loader from the original EXEs. Furthermore, as already mentioned above, there are still differences in the outputs.
For more details, check out the "audiolib" and "rott" directories in my repo. In addition, something in the "misc" directory may assist for comparing IDA's LST outputs of LE files.

For any possible future update, please check any of the following forum threads:
- For Wolf3D-related updates (For most): http://diehardwolfers.areyep.com/viewtopic.php?t=7098
- For whatever fits Duke4.net: https://forums.duke4.net/topic/10026-restoration-of-a-few-games-exes-versions/
- For more general updates: https://www.classicdosgames.com/forum/viewtopic.php?f=3&t=1410

Continuing with this post:

Time for an update, although most of it is probably off-topic in these forums. I guess that I can still mention it due to the small presence of ROTT, though.

I shall first mention that, while not yet perfect, I've added two more (late) versions of ROTT. These are the Lasersoft Deluxe Edition ones, from May and July of 1995. As it turns out, the July release is the same as shareware Apogee v1.3, just with the "DELUXE" macro defined to 1. The May release has just a few differences from the July one.

Secondly, there's the following somewhat bigger update. Note that I consider this code recreation *partial*, hence you'll find it in a "bonus" subdirectory. In particular:
- This covers game code only.
- This does *not* cover engine code, audio library code* or closed-source libraries. Original binary OBJ and LIB files are used for these.

To summarize, I'm talking about the game code (and no other code piece) of Duke Nukem 3D!

Now, here's the thing. The Duke Nukem 3D sources as released by 3D Realms on 2003 are of a revision somewhere in-between versions 1.4 and 1.5. However, Hendricks266 gave me the (very great) hint of looking into the Enhanced Duke (i.e., EDuke) 2.0 sources, released by Matt Saettler later that same year. The assumption was that they should have all of the 1.5 code with very few differences, provided that macros like NAM, WW2 and EDUKE are *not* defined.

As it turned out, he was right. In fact, it's not just about the code, but also the make file. Matt's MAKEFILE as originally released must be much closer to what was originally used for v1.5 than MAKEFILE from 3DR's sources. This covers the optimizations toggled for the Watcom C compiler, as well as the EXE originally being named GAME.EXE. The latter applies for Duke3D v1.5 as well as the EXEs Matt made using the code.

Matt's sources are of EDuke 2.0 build 21 i.e., EDuke 2.00.21, though, while the original EXE is 2.00.23. I used the EDuke 2.1 sources (one of the archives) as a reference for the changes.

Additionally, I still had to copy the MACT library's headers from 3DR's sources, as these were missing from Matt's original release of the EDuke 2.00.21 sources. (I know there was a second release, but I eventually started from the first.)
I further had to copy MAKEFILE.LNK from there and adapt it. Figuring out that the EXE was originally named GAME.EXE, rather than DUKE3D.EXE or EDUKE.EXE (or anything else) was one thing, but I were also left with minor diffs of 3 bytes from the original EXEs of Matt. Eventually (thanks Watcom), adding "segment type code lo" and "segment type data lo" to MAKEFILE.LNK turned out to be the solution.
Another thing that was figured out earlier, is the usage of "file" instead of "library" for the LIB files in the LNK file. This leaded to some changes, like a different (original) order of AUDIO_WF.LIB symbols, as well as a forced presence of BUTWCD4.LIB in Matt's EXEs, even though it's unused.

These EXEs are covered in my repository:
- Duke Nukem 3D: Atomic Edition v1.5, up to differences to be described soon.
- The following EXEs originally built by Matt (recreated byte-by-byte): NAM/NAPALM Full Version 1.0, WW2GI Full Version 1.0 and EDuke 2.00.23 (the original binary EDuke release from the year 2000 mostly known as "EDuke 2.0").

Note that for any comparison you might be making, there should *not* be any (originally) unofficial patch applied, like the removal of copy protection. Digital releases (e.g., Steam and GOG.COM) may be impacted, too.

All of Matt's EXEs can be faithfully recreated byte-by-byte, provided that you're using Watcom C 10.6a. As usual, using the correct version is *very* important here. Any other version can lead to a different EXE layout!

Regarding Duke3D v1.5, well, there are a few differences. I've been a bit stuck with this for a while, initially assuming that a version of Watcom in-between 10.0b (as used for ROTT v1.3 and the Apogee Sound System v1.04) and 10.6a (Matt's EXEs) was originally used for the game code. Sadly, though, it didn't seem like Watcom 10.5 assisted here. Not being entirely sure which wcc386 parameters were originally used, and/or if I'd missed anything in the code, didn't really feel helpful.

Surprisingly, though, it turned out the README file from 3DR's release of the code was right. Watcom C 10.0 was used. Yes, this is an EARLIER version than what was reportedly used for ROTT. As for the optimizations, they're the same as in Matt's MAKEFILE.

Note that v1.5 won't be *exactly* the same as the original. There are two reasons for this:
- The original EXE has a copy of DOS/4GW Professional. The tools can be used in a similar manner for the newly recreated EXE, but there are good chances you'll still get (another) minor difference from the original, say of 6 bytes.
- Additionally, as previously occurring with ROTT and the Apogee Sound System, some unused data gaps in the binary EXE/LE data section/segment (mostly between C strings) differ from the originals. The exact contents seem to depend on the environment in which the compiler was ran, or at least on the *exact* contents of the compiled source files. I suspect this is related to the v10.0(x) series of Watcom C, since this was not reproduced with Matt's EXEs (built with 10.6a).

Further note that some binary object and library files were used. These were made available with the sources as released by 3DR and Matt altogether. I also have *guessed* versions of Watcom originally used for some objects, based on modification dates of Watcom headers. Here's a list:
- A.OBJ, CACHE1D.OBJ, ENGINE.OBJ, MMULTI.OBJ: The Build Engine, probably built with some variant of Watcom C 10.5.
- AUDIO_WF.LIB: Apogee Sound System v1.1. I'm more-or-less convinced it was built with Watcom C 10.0b.
- MACT386.LIB: The MACT lib., with another mention of 10.5.
- BUTWCD4.LIB: The Total Entertainment Network (i.e., TEN) lib., also presumably built with 10.5.

* In fact, this isn't entirely accurate. I've modified the Apogee Sound System sources so you can more-or-less recreate v1.1. However, you'll still prefer to use the existing AUDIO_WF.LIB file, if only due to unused gaps between C string literals and more being filled with contents differing from the original. As in the case of the game code, this might be related to the Watcom C v10.0(x) series.