I wonder if FreeDOS has anyl relevance in our modern cloud-based VM world, where a real-mode operating system could serve as a razor thin wrapper for running applications on virtual machines with minimum overhead.
In these scenarios, having another layer of memory protection and pre-emptive multi-process multitasking might be completely unnecessary.
Well, just yesterday I had to run FreeDOS from a USB in order to run a sas2flash utility that didn't run on Linux or directly via UEFI, so I could flash some firmware to a SAS controller. Seems at least some of us still need it :)
Btw, avoid getting a SAS controller if you can, and get a motherboard that directly supports as many SATA drives as you need. Few things have been as frustrating as dealing with this SAS controller thing.
When I have to deal with a SAS controller my go to is always to see if it's possible to flash it with IT (initiator/target) firmware so that it just becomes basically pass through disks for the OS to handle however it pleases.
Off-topic, but what SAS controllers are you having trouble with? Was going to get some for my NAS, would be good to get some insight on what to get and expect!
As mentioned in the other comment, the controller shipped with IR firmware, while I wanted IT firmware on it, so all drives shows up in the OS, instead of doing hardware RAID. I don't think this specific controller is more/less problematic than others, just that all the tooling around SAS seems to suck. At first I couldn't get sas2flash to work on Linux, so ended up trying to boot an UEFI shell with sas2flash.efi instead, which refused to work seemingly because of some motherboard/UEFI version/controller incompatibility.
So ultimately I used FreeDOS to finally be able to run sas2flash, so I could flash the IT firmware. Maybe I'm spoiled, but overall it's been a somewhat confusing journey.
And today I also started looking into getting LTO8 for long-term backups, probably will be even worse, judging by the docs I've gone through so far...
No, the technology serving what you're describing is microVMs, or taken even further, unikernels.
FreeDOS has no technical relevance other than its intended purpose of continued support for legacy DOS applications on modern hardware - which is perfectly fine.
Not anymore, it's either signed EFI binaries or handled live from user space (with LVFS covering the Linux side). Sometimes vendors still ship boot images, but nowadays it's likely a small Linux live ISO.
Real mode would not be an efficiency gain at all on modern CPUs.
Even if they were not the case I think it would only have any use between containers and full VMs when you want more separation than the former but less weight than the latter, and there are various existing microVM options that seem to have a handle on that space.
It depends on the task. E.g. FoxPro 2.6 is basically proto-RAD, complete with visual form and report designers and an online help system, but it's too high-level for systems programming. Borland Pascal 7.0 is probably the sweet spot of power and convenience - no visual designers, but you get Turbo Vision for TUI, a very nice integrated help system, and decently powerful object-oriented language. Better yet, early versions of FreePascal that targeted 32-bit DOS.
I don't think any of these would fit on a floppy, though; you'd have to unwind a little bit for that. Say, Turbo Pascal 5.5?
I wonder if FreeDOS has anyl relevance in our modern cloud-based VM world, where a real-mode operating system could serve as a razor thin wrapper for running applications on virtual machines with minimum overhead.
In these scenarios, having another layer of memory protection and pre-emptive multi-process multitasking might be completely unnecessary.
> I wonder if FreeDOS has anyl relevance
Well, just yesterday I had to run FreeDOS from a USB in order to run a sas2flash utility that didn't run on Linux or directly via UEFI, so I could flash some firmware to a SAS controller. Seems at least some of us still need it :)
Btw, avoid getting a SAS controller if you can, and get a motherboard that directly supports as many SATA drives as you need. Few things have been as frustrating as dealing with this SAS controller thing.
When I have to deal with a SAS controller my go to is always to see if it's possible to flash it with IT (initiator/target) firmware so that it just becomes basically pass through disks for the OS to handle however it pleases.
Yes, this is exactly why I had to dive into that rabbit hole, since the controller arrived with IR firmware and I need it to run IT...
Off-topic, but what SAS controllers are you having trouble with? Was going to get some for my NAS, would be good to get some insight on what to get and expect!
As mentioned in the other comment, the controller shipped with IR firmware, while I wanted IT firmware on it, so all drives shows up in the OS, instead of doing hardware RAID. I don't think this specific controller is more/less problematic than others, just that all the tooling around SAS seems to suck. At first I couldn't get sas2flash to work on Linux, so ended up trying to boot an UEFI shell with sas2flash.efi instead, which refused to work seemingly because of some motherboard/UEFI version/controller incompatibility.
So ultimately I used FreeDOS to finally be able to run sas2flash, so I could flash the IT firmware. Maybe I'm spoiled, but overall it's been a somewhat confusing journey.
And today I also started looking into getting LTO8 for long-term backups, probably will be even worse, judging by the docs I've gone through so far...
No, the technology serving what you're describing is microVMs, or taken even further, unikernels.
FreeDOS has no technical relevance other than its intended purpose of continued support for legacy DOS applications on modern hardware - which is perfectly fine.
Last time I wanted to run an old DOS game, I used DOSBox. (But it appears DOSBox isn't actively maintained)
DOSBox-X is actively maintained.
https://dosbox-x.com/
or DOSBox Staging, https://www.dosbox-staging.org
With how fast hardware is these days, full hardware emulation of old motherboards/CPUs/etc. is better, as in PCem
more for running oem firmware tools and such than dos games.
Not anymore, it's either signed EFI binaries or handled live from user space (with LVFS covering the Linux side). Sometimes vendors still ship boot images, but nowadays it's likely a small Linux live ISO.
Real mode would not be an efficiency gain at all on modern CPUs.
Even if they were not the case I think it would only have any use between containers and full VMs when you want more separation than the former but less weight than the latter, and there are various existing microVM options that seem to have a handle on that space.
What is the nicest programming environment which will run in this (and fit on a floppy)?
Some small programming tool (nicer than Q/QuickBASIC) which had a nice facility for creating a Text UI could be useful.
It depends on the task. E.g. FoxPro 2.6 is basically proto-RAD, complete with visual form and report designers and an online help system, but it's too high-level for systems programming. Borland Pascal 7.0 is probably the sweet spot of power and convenience - no visual designers, but you get Turbo Vision for TUI, a very nice integrated help system, and decently powerful object-oriented language. Better yet, early versions of FreePascal that targeted 32-bit DOS.
I don't think any of these would fit on a floppy, though; you'd have to unwind a little bit for that. Say, Turbo Pascal 5.5?
FreeDOS can also be put on a USB stick so you are not necessarily limited to the size of a floppy disk.
For nice, you might be interested in DJGPP/RHIDE. It's somewhat more than fits on a floppy disk though.
https://www.delorie.com/djgpp/.
Maybe Borland Turbo C? I also think Visual Basic for DOS had a text-mode UI editor.
Indeed VB for dos had a UI designer with buttons, forms, dialogue boxes etc.
Or Turbo Pascal...
Or the maintained open source alternative Free Pascal and its Free Pascal IDE.
Fasm comes with a cute small DOS IDE.
Or ditch DOS and embrace Wirth's Oberon (the OS and language).
There is a one-floppy build.
Somewhere, I have a printout of the (quite slim in terms of page-count) Oberon manual --- turns out there is a Pi build:
http://pascal.hansotten.com/niklaus-wirth/project-oberon/obe...
will definitely have to experiment with that.
EDIT: but it's apparently an emulated version?
Perhaps:
https://github.com/MGreim/ultiboberon
is better?
[dead]
[dead]