5 ms·
The thing about DOS is that it leverages the IBM style BIOS heavily. Unlike Linux, it's not just a case of recompiling DOS so that it works on different archite
by mattowen_uk 5y ago
The thing about DOS is that it leverages the IBM style BIOS heavily. Unlike Linux, it's not just a case of recompiling DOS so that it works on different architecture. having DOS boot natively on a Pi sounds attractive but isn't feasible.
However, if low-energy x86 compatible SBCs (with compatible BIOS-a-like) ever become more than a niche thing, then having fast DOS booting into single purpose apps would be a nice addition to the space currently dominated by Linux and all those ARM boards.
I can't see it happening though.
- zozbot234 5y agoThe modern equivalent to DOS is just the UEFI shell. No reason why it couldn't be supported on the Pi too - AIUI, there's a free implementation of UEFI that can be loaded from uboot.
- rwmj 5y agoI'm using UEFI on my Raspberry Pi 4: https://github.com/pftf/RPi4 https://github.com/pftf/RPi4 Works pretty well.
- marcodiego 5y agoOn the other hand, wherever you had a compatible bios and processor it was easy to run DOS and CP/M on it. This made both systems very popular until ibm-compatible became the standard and apps wouldn’t run on anything else.
- Rerarom 5y agoyeah the x86 is a DOS machine the way Lisp machines are Lisp machines (or something like that, I admit I cannot find a properly slick way to express it)
- Koshkin 5y ago> x86 8086, to be specific.
- hnlmorg 5y agoDOSbox already flies on a Raspberry Pi. I think this is one of those instances where the technology in question (DOS) is so old that it makes more sense to solve it in software than it does in hardware.
- Koshkin 5y ago> is so old Indeed - looks like the older the software, the more efficient it is.
- hnlmorg 5y agoThat's a fun comment people like to quote but as someone who's been writing software since the DOS days, I can tell you it's not really true. - Older software might run less efficiently on newer hardware because they don't support newer hardware (eg CPU opcodes) and thus perform the same calculations in software. This is most visibly true with games that are software rendered in DOS rather than hardware rendered. - Older software might not take advantage of smarter algorithms that have been discovered more recently. This is best observed in the modern demo scene - Older software might run faster but that might simply because they don't support modern requirements (eg cryptography, memory protection, or even error / crash handling). This is probably the closest to the "efficient" argument but I'd counter by saying the code isn't "more efficient", it's "less functional". Sometimes less functional is exactly what you want (eg why spin up Microsoft Word if all you want to edit is a plain text file) but it's still not the same as saying "more efficient".
- csnover 5y agoThese are all great points. Something else I would add to the list is that older software would often run using a busy loop[0]. This was ‘fine’ on contemporaneous CPUs that didn’t have any low-power modes, but on a modern CPU it means that older software will use 100% of one CPU core and force it to stay running at its maximum frequency while doing no work at all. [0] https://en.wikipedia.org/wiki/Busy_waiting https://en.wikipedia.org/wiki/Busy_waiting