The top sibling parent has the correct explanation, however, I'll expand a bit.
Games prior to Quake were bound to specific O/Ss and/or hardware components.
DOOM was still bound to DOS AFAIK, so it's not portable without significant changes.
Older games are even worse - not only they were bound to DOS, but also to the display adapters of the time (CGA/EGA), which required some sort of emulation (or translation, depending on the approach) in order to be ported.
Games based on the Build engine (written by Ken Silverman), like Duke Nukem 3D and Blood are... simply written in very poor form. Carmack is a tidy programmer, Silverman isn't. Quoting Fabien Sanglard:
> Looking at the innumerable ports that spawned Doom/Quake, I was always puzzled to see so few ports of Duke Nukem 3D. The same question arose when the engine was ported to OpenGL only when Ken Silverman decided to do it himself.
DOOM was definitely made with DOS in mind, but it also ran on NeXT from the beginning. It's pretty portable actually. Since you cited Fabien Sanglard, I guess I should mention that his book about DOOM's source code (Game Engine Black Book: DOOM) explains how the portability stuff (as well as almost everything else) worked in great detail.
Several of us would regularly play it in a Chemistry computer lab on SGI workstations. Annoyed the hell out of the students doing molecular simulations, regrettably.
Doom was literally developed on NeXT computers (the precursors to modern Macs, ironic considering Doom was single-handhedly responsible for turning the public perception of PCs from boring office machines to cool gaming systems):
> DOOM was still bound to DOS AFAIK, so it's not portable without significant changes
DOOM was always extremely portable, the DOS and PC specific parts are well separated from the other code (DOOM was actually developed on NeXT machines, so separating the platform specific parts probably came naturally).
Plugging a DOS game to an SDL(2) library won't "just work".
Some concepts are inherent to the hardware and the O/S.
Hardware example: EGA (not the case of doom, but of other, slightly older games) uses bitplanes, it's not just an array of byes; audio cards used specific drivers.
O/S: timers may need to be emulated, as the game may not have a straightforward game loop; due to this, even exiting cleanly may not be trivial to implement.
Games prior to Quake were bound to specific O/Ss and/or hardware components.
DOOM was still bound to DOS AFAIK, so it's not portable without significant changes.
Older games are even worse - not only they were bound to DOS, but also to the display adapters of the time (CGA/EGA), which required some sort of emulation (or translation, depending on the approach) in order to be ported.
Games based on the Build engine (written by Ken Silverman), like Duke Nukem 3D and Blood are... simply written in very poor form. Carmack is a tidy programmer, Silverman isn't. Quoting Fabien Sanglard:
> Looking at the innumerable ports that spawned Doom/Quake, I was always puzzled to see so few ports of Duke Nukem 3D. The same question arose when the engine was ported to OpenGL only when Ken Silverman decided to do it himself.
The answer is in his analysis: https://fabiensanglard.net/duke3d/code_legacy.php.