There's something to be said for using FreeDOS simply as a loader for a real-time control program. It's not doing anything in the background. There's no networking stack. There's no way to attack it without physical access.
There's something to be said for using FreeDOS simply as a loader for a real-time control program. It's not doing anything in the background. There's no networking stack. There's no way to attack it without physical access.
Also having no network stack or USB stack is pretty limiting these days. I'm sure FreeDOS can implement these, there are definitely DOS drivers out there for older network cards to get TCP/IP up and running and there was always serial modems which we used extensively in "the old days" (pause while audience cringes!)
Being cut-off from the outside world is of course security bliss but the PC still needed to be physically secure as there were no passwords/encryption and remote maintenance is not an option.
Also synchronous (and also often non-preemptible) disk/FS IO was for the long time the only way it was done. For example the reason that on Linux process that got stuck accessing NFS or removable drive that got removed was unkillable (in 'D' state) was to preserve illusion of such semantics to user processes (ie. that IO to filesystem and block devices will never fail with EINTR). And I would not be surprised if many deeply-embedded RTOSes do the same to this day.
A glaring omission is access to long mode. There's no DPMI for long mode. You can knock the PC into long mode, but DOS calls are no longer accessible in any fashion.