3 ms·
Yeah. Basically, for most intents and purposes, any high-end MSDOS application is basically running bare-metal, as if no OS was installed in the system at all.
by ladyanita22 2y ago
Yeah. Basically, for most intents and purposes, any high-end MSDOS application is basically running bare-metal, as if no OS was installed in the system at all.
As close to the embedded world as possible.
I don't understand why is there so little documentation about MSDOS as a real-time operating system. I'd bet it would work beautifully for any piece of software that was developed with such use-case in mind.
- mixmastamyk 2y agoYou’d have to write your own scheduler.
- mr_toad 2y agoWith no memory protection a wayward process could easily overwrite the schedulers data structures, and probably hang the system.
- xxs 2y ago(ms)dos has just a file system (it's the D in the name). It has no protected memory or scheduling, or any ability to "talk" between processes. It can load executable images .exe(MZ) or sub 64KB .com. ANd yes, it's possible to reserve memory and stay resident (TSR) I have some experience repurposing 8259 (the interrupt controller), and if you hook on the timer (8), there is nothing else to return the execution back to the 'OS'. In short I'd disagree about the real-time.
- kevin_thibedeau 2y agoFAT is not well suited to embedded use. The TFAT hack was patent encumbered and not widely supported outside of MS products.