CP/M had a bunch of syscalls in the first 0x100 or 256 Bytes of memory. These syscalls were identical on a Z80 or an 8088 PeeCee. In PL/M you just simply call CP/M to do something.
Generating the relocation map was made by compiling the program for an offset of 0x100 (256) and another location. The two were then compared to build the relocation map. The binary with the offset of 0x100 (256) was used.
MeS-DoS was based on QDOS (Quick and Dirty "Operating System") or 86-DOS which was based on CP/M-86 binaries hacked in complete ignorance of what an Operating System should do. The resulting MeS-DoS was 100% dependent on PeeCee BIOS and hardware. In fact BIOS is closest thing to an Operating System on a PeeCee.
The CP/M driver interface did have hooks for re-entrant drivers, but these were not useful with the slow Z80 and 8088 CPUs used at the time. As MeS-DoS moved to 80386, 80486, 80586 and Pentium for Windows versions up to ME, Microsoft never used re-entrant drivers even though BIOS provided a call back interface.
The Windows kernel ran as a single MeS-DoS application, but it too used busy-waiting and pre-emptive multitasking.
Windows NT since NT 4 also does a lot of busy waiting processes spinning and making your CPU hot so it must slow down to avoid failure.
When a process is ready it must run along with all the other spinning processes on a hot slowed down CPU. This is a bit like slowing your car down by riding the clutch. It is a dam silly way of doing things.
Better systems use co-operative multitasking with a process timer to protect the CPU (in a similar way that an MMU protects memory). An expired process timer can either function as a watch dog and terminate the errant process in the same way as segment violation would. Otherwise, it may change the processes priority so it only runs on the CPU in low power mode and do a pre-emptive context switch. That way co-operative processes will run at full speed on a cool CPU and only when the co-operative have completed will the pre-emptive processes run on the CPU at low speed.
An Operating System controls access to system resources and may do so in a hardware independent way to enable software portability.
Compare the 4-bit CPU in a pocket calculator which does run an actual Operating System.
The pocket calculator has static registers to hold display values and circuitry reverse the current flowing through the LCD. This low power circuitry remains powered up by a toy solar cell.
In Unix or POSIX systems you have a pipeline of processes waiting for proceeding process in the pipeline. These waiting processes are not spinning their wheels, using system resources. They will only be marked as runnable if the IO on which they are blocked has become ready. This results in a ordered sequence of events as data is processed through the pipeline.
Even the Apollo Guidance Computer (AGC) which was not much more than a programmable calculator had an Operating System. That was why it did not crash when overloaded during decent by the rendezvous radar. I.e. it managed its own limited CPU resources.
Unix also provides portability and security.
The Open Group Single Unix Specification and IEEE POSIX standards provide for portability in the same way that CP/M did. I.e. Unix program will run on any Unix system.
This was meaningless on a single user non-networked CP/M machine. To secure such a machine you only need keep it in a lockable room. For the same reason Microsoft PeeCees should be kept in a lockable room and never connected to a network.
Unix provided access to devices via device files. In order to be able to access such devices you needed have the matching supplementary group.
This also means that the same Unix API open(2), select(2), (pselect, poll), read(2), write(2), close(2), etc. can be used to access both files and devices.
The design of the Unix security model was based on the US DoD TCSEC.
Files can be protected by directory permissions in Unix. (This does not work in Windows NT.) Note that a Unix user must have execute or search rights for each directory in addition to desired access rights for the terminal node. This provides for layered access controls.
Supplementary Groups can be regarded as Mandatory Access Control Roles.
Ownership can be regarded as Discretionary Access Control.
The Login Group is used for the general user class or specific to the user and is used to protect files in the user home directory where Mandatory Access Control is desired.