Re: Restoration of a few games' EXEs versions
Posted: April 9th, 2017, 3:29 pm
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).
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).