Life After MS-DOS: FreeDOS Keeps On Kicking 255
angry tapir writes "FreeDOS — the drop-in, open source replacement for MS-DOS — was started after Microsoft announced that starting from Windows 95, DOS would play a background role at best for users. Almost two decades later, FreeDOS has survived and, as its creator explains in this interview, is still being actively developed, despite achieving its initial aim of an MS-DOS compatible OS, which quite frankly is somewhat amazing."
Not surprising (Score:5, Insightful)
Good for embedded systems (Score:5, Insightful)
Why not? For embedded systems, when you need more than a boot loader, don't want all the excess baggage of Linux, and don't want to pay for one of the embedded OSs like QNX, it's a good option.
You also know that FreeDOS doesn't have a "phone home" feature, a HTTP server, a mail server, or something else on an open port running in the background without your knowing about it.
Re:Dosbox or freedos (Score:5, Insightful)
Last I looked, FreeDOS couldn't slow down the environment to emulate old hardware. This is basically a requirement for many old games, and is the reason I use DosBox.
Re:Good for embedded systems (Score:4, Insightful)
Exactly. For an embedded system, a MS-DOS variant with FAT32 is good enough [1] for a lot of tasks. Done right, it can be close to a realtime OS as one would need for most tasks, with very little overhead, especially with hardware saving every CPU cycle can be important.
Security? The OS doesn't even have a TCP/IP stack unless explictly loaded. No finding ports open that shouldn't be.
Malware? Within the realm of possibility (Stuxnet showed us that), but without physical access, highly unlikely, especially if there is no Internet connection. Done right, the embedded code could write via a serial port, and another machine (or a VM) could read that, making those files accessible to a TCP/IP network for audit purposes.
[1]: It would be nice to have ExFAT available as sizes of disks and other items get larger, but the IFS code to handle the complexities of a modern filesystem can be larger than the rest of the DOS kernel combined.
Re:That's cool, I guess ... (Score:3, Insightful)
Re:Good for embedded systems (Score:2, Insightful)
The said baggage probably refers to OS overhead like task switching, which for some applications, is probably too much even with linux/bsd and probably even realtime linux.
DOS is about as bare metal and real-time as you can get while still having filesystem access. There are probably people out there who need it to be that low level, unencumbered even by timer interrupts if desired. I'm not one of those people but I'll still speak in defense of freedos for that purpose.
Re:Not surprising (Score:4, Insightful)
Honestly, it's all about the ROI here. If you have 100 users which are affected by an obscure bug which has a workaround already, and at the same time have maybe 100 other more important bugs to fix, guess what's going to happen with the first bug?
A bug is a bug, and you can never be sure of all ramifications. If it is not important, remove the code. If it is important enough to keep, then fix it.
EPROMs, Flash, batteries, CMOS (Score:5, Insightful)
Not to be pedantic, but you are describing EPROMs above, not EEPROMS. EPROMs are the devices that you program using higher voltages, and erase using UV rays (they had a transparent window to the die to enable that). Nobody makes those anymore. There is a variation of that called MTP, where instead of the UV rays, one can apply the higher voltage to the VPP and a particular address line to erase it, and program it normally putting the higher voltage just on the VPP pin. These products, to the extent that they are made, are the replacements of EPROM. Then there are mask ROMs for the high end equivalents of these things: while EPROMs and MTPs were in the 1 mebibit range, mask ROMs are in the 1 gibibit range.
EEPROMs, otoh, are NOR flash memory devices. Flash memory works this way - while read operations are the same as static or dynamic RAM, depending on design, program operations are done in software - by sending a certain address/data combination sequence before a program cycle(s) can start. That is what is known as in-system programming, and that is what PCs use. So any software that tries to 'flash a BIOS' essentially has to first determine who the manufacturer of the flash memory is (since different manufacturers tend to use different algorithms - most JEDEC endorsed) and then accordingly, send the appropriate command cycles to the flash before loading it w/ the addresses and data to be programmed into it.
Batteries are needed to maintain the system clock. Every time you power down a laptop, how does the thing remember the time when it boots up again? The battery is how - there is no way a flash device, which simply stores the last state that was programmed into it, would be counting down the time. When the battery goes down, that's when one sometimes sees motherboard failures and the like.
CMOS has forever been the standard that's used to build transistors, due to their scalability - TTL was never used, and ECL was tried on occasion by 1 company called Exponential Logic to build high performance PowerPCs for Apple in the 90s, but they went bust. CMOS will stop being used when silicon stops being used.