4 ms·

Sorry, but the explanation for 2/ doesn't seem right. > why do so many modern operating system either come with DOS, have a DOS-style command interface, or pro

Sorry, but the explanation for 2/ doesn't seem right. > why do so many modern operating system either come with DOS, have a DOS-style command interface, or provide a DOS emulator? Neither Windows, nor Linux nor MacOS "come with DOS". And no, the command line in modern operating systems is not "DOS". I have not stumbled upon a "DOS emulator" in Windows or Linux after a "default installation"

mikestew 2y ago
Only two bullets in, and I was already questioning everything else on the page. A command line interface != "DOS". And after reading all the way to the end, I don't think I'm too far wrong with that opinion. A lot of the counter-arguments to the fallacies remind me of getting an Apple Newton onto the modern internet: yeah, it can be done with a lot of hacking and kludges, but you wouldn't want to use it for daily work. Some of the responses to the fallacies fall into the "well, technically..." category, but one or two of them I'm confident are just wrong. Take this one: DOS Cannot Multitask. In one sense, DOS has multitasked from the beginning. It is searching and writing in the background while the user or a program is doing something else. I'm pretty sure that's not true, but I would love to be corrected, if only to know how it worked. :-)
- yjftsjthsd-h 2y ago
  > It is searching and writing in the background while the user or a program is doing something else. I'm not 100% sure what this is meant to mean, but if they mean to suggest that DOS did some sort of async disk I/O, then... yeah, no, I'm pretty sure the way I recall that working is that your program did a syscall by calling an interrupt, which caused the CPU to stop running your code and start running DOS, which ran its own code (what you might today call a filesystem driver) that in turn passed execution to the BIOS (usually, at least), which ran its code to actually do the disk access, then returned execution to DOS, which returned execution to your code.

mikestew 2y ago

Only two bullets in, and I was already questioning everything else on the page. A command line interface != "DOS". And after reading all the way to the end, I don't think I'm too far wrong with that opinion. A lot of the counter-arguments to the fallacies remind me of getting an Apple Newton onto the modern internet: yeah, it can be done with a lot of hacking and kludges, but you wouldn't want to use it for daily work. Some of the responses to the fallacies fall into the "well, technically..." category, but one or two of them I'm confident are just wrong. Take this one: DOS Cannot Multitask. In one sense, DOS has multitasked from the beginning. It is searching and writing in the background while the user or a program is doing something else. I'm pretty sure that's not true, but I would love to be corrected, if only to know how it worked. :-)

yjftsjthsd-h 2y ago
> It is searching and writing in the background while the user or a program is doing something else. I'm not 100% sure what this is meant to mean, but if they mean to suggest that DOS did some sort of async disk I/O, then... yeah, no, I'm pretty sure the way I recall that working is that your program did a syscall by calling an interrupt, which caused the CPU to stop running your code and start running DOS, which ran its own code (what you might today call a filesystem driver) that in turn passed execution to the BIOS (usually, at least), which ran its code to actually do the disk access, then returned execution to DOS, which returned execution to your code.