Middle school me had some fun with /autotest.
Shhh: The Undocumented DOS Commands (1999)
51–57 of 57 posts
Re: Shhh: The Undocumented DOS Commands (1999)
#52So how were these found? Today I guess I'd try running strings on the executable or maybe straight-up opening them in a debugger or disassembler (I assume command-line argument parsing is a very obvious, easy-ish to read block of code right at the start of the program), but I'm not sure how much of that was available (or at widely accessible, at least) back when DOS was a big deal (this list talks about DOS 2.x, whic…
When DOS was a big deal, it was both a big enough deal and a small enough program to be fully dissected, disassembled, studied, documented, patched, outright reimplemented, etc. It's probably harder to find some technical detail about DOS that outsiders didn't figure out.
DOS is small relative to modern OSs, but don't let the binary size (few dozen KB) of the kernel fool you --- being written in Asm, it is very dense code, basically no bytes wasted. There's probably more dead code in a "Hello World" binary compiled with a modern language than there is live code in the DOS kernel.
Re: Shhh: The Undocumented DOS Commands (1999)
#53After being frustrated with limitations of xcopy i wrote my own program on C++ (bxcopy) which became my business for a few years paying my mortgage :)
These were some creative times!
Re: Shhh: The Undocumented DOS Commands (1999)
#54Earlier quoted context omitted.
When DOS was a big deal, it was both a big enough deal and a small enough program to be fully dissected, disassembled, studied, documented, patched, outright reimplemented, etc. It's probably harder to find some technical detail about DOS that outsiders didn't figure out.
DOS is small relative to modern OSs, but don't let the binary size (few dozen KB) of the kernel fool you --- being written in Asm, it is very dense code, basically no bytes wasted. There's probably more dead code in a "Hello World" binary compiled with a modern language than there is live code in the DOS kernel.
Sure but it's still tiny. If every single byte of it were a full line in a high level language it would still be still a tiny, fully externally-analyzable program. I don't need to make that kind of theoretical argument, though - the entire late stage of serious DOS software was completely dependent on DOS having been taken apart and understood, bit by individual bit.
Re: Shhh: The Undocumented DOS Commands (1999)
#55>Last updated on Friday, January 1, 1999. This is a walk down memory lane, but not in a good way. I'm very, very glad to no longer have to remember anything about config.sys.
But I bet you do, including how to create it on a system with no editor.
It's not much different than using "cat > filename" on any modern *nix, which is very well used to this day.
Re: Shhh: The Undocumented DOS Commands (1999)
#56I have been revisiting the DOS eco-system lately and I have run into a problem. I can't remember how to ECHO a variable set in AUTOEXEC.BAT. E.g, to ECHO the BLASTER variable, I've tried ECHO BLASTER, ECHO $BLASTER, ECHO $BLASTER$, ECHO %BLASTER, etc.. But nothing. Somehow a Google search didn't turn up anything. I'm starting to wonder if it was it even possible to do this and that my memory is incorrect? Cool list b…
SET BLASTER
No “=” — `SET BLASTER=` will erase the variable, and of course `SET BLASTER=f00` will set it to “f00”. N.b., `SET FOO` will display all variables beginning with “FOO” and remember that DOS/Windows vars aren’t case sensitive.
Re: Shhh: The Undocumented DOS Commands (1999)
#57Small anecdote, fdisk /mbr once saved my database class project at the university, thanks to it I was able to rescue a PC that everyone though it was dead and thus was able to secure a terminal for our set of teams.
Alternatively, we would have had to wait endlessly for a free one, while we had a fixed deadline regardless of the students assigned to the class, and no the software wasn't available elsewhere beyond our computer lab.