Strife source code

The Strife source code, the human-readable files from which the Strife executable could be produced, unlike the code to most other commercial Doom engine games, has never been released. According to James Monroe, the game's lead programmer at Rogue Entertainment, and his colleague Peter Mack, this is because all known copies of the code have been lost.

Attempt to release
James Monroe, by his own admission, contacted John Carmack shortly after Raven Software's release of the Heretic and Hexen source codes to see if following suit with Strife would be possible. According to Monroe, Carmack agreed to the release and he proceeded to travel in person to Rogue's offices to see if he could obtain a copy of the code (at that time, James was already now working for Raven in Madison, Wisconsin). Unfortunately when he arrived, he found that the old NeXT servers used for Strife's development had been sold off and no known backups of their contents were on site.

Early attempts at contacting Peter Mack made by Samuel Villarreal (Kaiser) were successful, and Peter thought he might still have a copy of the code on some of his old disks, but he was never able to locate it.

With both the developer and publisher of the game fully divested and dissolved as companies, and no known copies of the source in the possession of those who worked on it personally, it must be assumed the code has been irrevocably lost.

Recovery efforts
Multiple projects have been undertaken to reverse engineer the Strife executable, with goals varying widely in terms of fidelity and compatibility. To date, separate reverse engineering projects have been undertaken by source port authors involved with the Vavoom and ZDoom ports. Samuel Villarreal produced an early attempt at emulation of Strife in the form of SvStrife that did not involve direct reversing, and then later cooperated with James Haley (Quasar) on the Chocolate Strife project, which utilized cutting-edge reverse engineering tools to fully disassemble and decompile every line of code in the binary (including portions of libraries such as DMX where necessary). The stated goal of the Chocolate Strife project from its onset was to create a replica of the original code which was as humanly close as possible to perfect, given the inherent limitations in reversing compiled code (symbol names, to a great extent, and all comments are unrecoverable regardless of techniques employed).

In 2014, Stephen Kick of Night Dive Studios began an attempt to recover the source code from a backup of the Rogue Entertainment assets in concert with his release of Strife: Veteran Edition, but has so far been unsuccessful.

In 2022, a faithful restoration of the Strife source code was added to the gamesrc-ver-recreation project.

Structure
The structure of the Strife source code can be directly ascertained from observation of the binaries, due in large part to Watcom's lack of function-level linking capability - the modules are preserved in the binary in the exact same ordering that has been observed in the makefiles for Heretic and Hexen, and there is a 100% overlap with modules in the Doom source code with exceptions that follow below. Functions are preserved in the binary in mostly the same ordering as they occur in the Doom source code, excepting instances of inlining by the compiler, and functions which have been inlined are still retained in their original locations as well in all but a few cases. These qualities together make reversing of the code significantly simpler than it would be if the code were emitted by a modern optimizing compiler. Major differences that can be inferred to have existed on a source code module level include the following: All other modifications and extensions to the engine were made in-place by Rogue in their appropriate modules.
 * A region of new code between p_telept.c and p_saveg.c which implements the dialog system, starting at 0001:0002D990 in the 1.2 binary. This module was reconstructed and named p_dialog.c in Chocolate Strife.
 * A region of new code between p_user.c and r_bsp.c which implements the inventory system, starting at 0001:00030710 in the 1.2 binary. This code was folded into the end of p_user.c in Chocolate Strife, based on its close relationship to code in the preceding p_user.c module.
 * A region of new code between m_misc.c and am_map.c which implements the hub savegame system, starting at 0001:0001B078 in the 1.2 binary. This code was most likely in m_misc.c itself in the original code, but due to its independence from other m_misc code, and extensive additions that had to be made to it for portability and stability purposes in the Chocolate Strife project, this code was broken off into its own m_saves.c module in that project.
 * The wi_stuff.c module is entirely missing, as Strife has no intermission.

Curiosities
Several development artifacts and curiosities can be found in the Strife binaries:

Code not found elsewhere

 * The original video system is preserved from the DOS Doom code, including use of tweaked non-planar Mode Y, with a dirty rects refresh system which updates as little of the screen as possible each frame, and with a three-buffer page flipping system making use of most of the available VGA memory. Due to the fact that Heretic and Hexen use a different screen mode and rewritten refresh code, no released version of the Doom source code includes these features.
 * The binary includes and uses the optimized self-modifying assembly versions of R_DrawColumn and R_DrawSpan implemented in the tmap.S module. Additional routines have been added for drawing columns in 25% and 75% translucency.
 * The dialog system makes unique use of a feature in DMX which allows a sound channel to have absolute priority, by passing a different parameter to the DMX function SFX_PlayPatch which in Doom was always passed as the value 100. This ensures that voices are never cut off by other sounds, no matter how many might be playing.

Unused dead code

 * Code is included to implement a Doom II-style cast call which would have been started from the menus at will. It is unfinished and not functional in all released versions of the executable.
 * Code is included to draw a custom headered linear raw graphic format, but this code is unused anywhere in the engine.
 * The WAD file system is modified to tolerate files with a magic identifier of "RWAD", in addition to IWAD and PWAD, but no known files use this feature.
 * Code for the Doom-style screen melt effect is still present, and works if the executable is modified to call it.
 * The "Dave's Utils" code, included in a file that wasn't released along with the Doom source code called dutils.c, is present in the executable, but is unused. It implements two different types of linked lists.
 * A function exists to do a "time bomb" check for a beta testing release, involving the otherwise mysterious SERIAL lump. It is unknown if such a beta was ever distributed outside of Rogue or Velocity's offices.
 * Linedef type 666 activates an unused experimental push wall feature, causing a wall to move horizontally, somewhat similar to a polyobject, but without several necessary parts of the process. This often results in a hall of mirrors effect or clipping glitches. According to Peter Mack, this was a purely experimental feature which was abandoned early on when the programmers could not make it work.
 * A number of changes made between v1.2 and v1.31 seem to indicate a new demo version was planned for release which would use the same executable as the commercial release, but this apparently never happened due to Velocity's closure.

Artifacts of ancestry

 * Since the code is based on Doom 2 v1.666, certain bugs from that version persist, including most notably the fact that tracers are not cleared when loading a saved game.

Resurrection of unused code from Doom

 * The animated doors are a completion implemented in-place of the sliding door code that id Software left incompleted in the Doom source.
 * The crossfade screenwipe is an in-place reimplementation of an unused color-fading wipe which id attempted to implement in Doom, but did not code in a way that could possibly work with 8-bit palette restrictions. Rogue replaced the broken implementation with one which utilizes progressive translucent blending.
 * The ability of grenades to bounce was adapted from the then-non-working ability of Lost Souls to bounce on floors and ceilings.