One source tree builds the versions. LORDSRC.ZIP has it, with BUILD.TXT.

The code that differs is inside {$IFDEF MSDOS}, {$IFDEF WINDOWS} and their {$ELSE}: the DOS side talks to a COM port (doordos.inc), the Linux side to stdin/stdout (doorunix.inc), the Windows side to pipes (doorwin.inc).

Tested on Ubuntu 24.04 (x86-64).

sudo apt install fpc make
make            # in the directory LORDSRC.ZIP was unzipped into

This makes bin/lord and bin/lordcfg. make clean removes the build. Copy them into the game directory.

1. Install the tools. FPC 3.2.2 for Linux is the starting compiler that builds the cross compiler; NASM is the assembler the msdos target uses.

   sudo apt install fpc nasm git make python3 unzip patch

2. Get the Free Pascal 3.2.2 source:

   git clone --depth 1 --branch release_3_2_2 https://gitlab.com/freepascal.org/fpc/source.git fpcsrc

3. Apply the RTL fix:

   cd fpcsrc
   patch -p1 < /path/to/rttidecl.diff

   Why: the compiler writes record field offsets in RTTI as PtrUInt, which is 4 bytes in the large memory model, but the RTL reads TRecordElement.Offset as SizeInt (2 bytes). Copying or freeing a record with two or more AnsiString fields then jumps to a bad address. The game copies such records all the time, so it crashes without the fix.

4. Build and install the i8086-msdos cross compiler and its units, large memory model (a few minutes):

   make all OS_TARGET=msdos CPU_TARGET=i8086 BINUTILSPREFIX= CROSSOPT="-WmLarge -CX -XX"
   make crossinstall OS_TARGET=msdos CPU_TARGET=i8086 BINUTILSPREFIX= \
     CROSSOPT="-WmLarge -CX -XX" INSTALL_PREFIX=$HOME/fpc-i8086

   BINUTILSPREFIX= (empty) makes it call nasm rather than msdos-nasm.

5. Build the game, in the directory LORDSRC.ZIP was unzipped into:

   sh dosbuild.sh
   # or, with the cross compiler elsewhere:
   FPCDIR=/somewhere/lib/fpc/3.2.2 sh dosbuild.sh

   This makes bin-dos/lord.exe, bin-dos/lordcfg.exe and bin-dos/LORDFP.STR. Copy them into the LORD directory as LORD.EXE, LORDCFG.EXE and LORDFP.STR. Built this way they are identical to the ones in LORDFP.ZIP.

Steps 1-4 are only needed once.

• An 8086 code segment is at most 64K, and so is the data group (DGROUP) that holds the global variables and constants. mkdos.py makes the sources in build-dos-src/: lordglob.pas (the globals, types and tables), lfp_*.pas (one unit per include file) and a small lord.pas that uses them all.
• String literals of 8 characters or more are moved to LORDFP.STR and read back with S_(n), which keeps the text out of DGROUP. Windows-only text is kept in the units mkdos.py doesn't scan.
• lsys.pas replaces FPC's SysUtils, whose exception and Format code pulls in the floating point formatter and fills DGROUP. The game uses no floating point; the clock helpers use integers.
• LORDTXT.LRD is indexed by file offset and read one section at a time.

The game is a line-by-line port of lord.js, so the lord.js function names are kept (sln, lw, lln, more_nomail …) and comments give lord.js line numbers. Internally the files keep their lord.js names (player.bin, state.bin, lognow.lrd, mail<n>.lrd); on DOS, dos_name in lordrec.pas maps them to the LORD 4.06 names.