Shhh: The Undocumented DOS Commands (1999)
the-eye.euNever realized INSTALLHIGH and LH were not documented. I recall using these, so I always assumed they were commonly known.
And :: for comments is just a creative trick based on how labels in batch files are parsed. It wasn't originally supposed to be used this way, so no wonder the documentation never mentioned it.
The difficulty in writing batch scripts was always that the best (or sometimes only) way of doing many things was to use a command originally intended for something completely different, in a completely non-intuitive way, and examples for such usage were never part of any official documentation. For example:
To display an empty line (instead of "ECHO is on"):
ECHO.
To create a file:
COPY CON FILE.TXT
Even now, the way to load the output of a command into a variable is to use FOR:
FOR /F %T IN ('TIME /T') DO SET TIME=%T
And the best way to empty a directory of all its contents is to use ROBOCOPY /MIR.
> Never realized INSTALLHIGH and LH were not documented. I recall using these, so I always assumed they were commonly known.
LH is documented in the MS-DOS 6.22 online help. "HELP LH" brings it up.
(The full name of the command is LOADHIGH, but LH is an acceptable abbreviation. The online help documents the LH abbreviation.)
(INSTALLHIGH by contrast wasn't documented... but LOADHIGH and DEVICEHIGH were. INSTALLHIGH is just putting a LOADHIGH in CONFIG.SYS instead of in AUTOEXEC.BAT)
> INSTALLHIGH is just putting a LOADHIGH in CONFIG.SYS instead of in AUTOEXEC.BAT
Yeah, and if anybody wonders what the point of this was: starting with DOS 6 you could have different boot profiles (menu items) in CONFIG.SYS. For example, depending on the program to run you'd want to have either extended memory (XMS via HIMEM.SYS), or expanded memory (EMS via EMM386.EXE) available.
INSTALL[HIGH]= allowed running different TSRs (roughly, background programs) for each profile from the same place (although in practice it was still common to have GOTO %CONFIG% in AUTOEXEC.BAT). Typical TSRs would include something like MSCDEX.EXE for CD-ROM support, SMARTDRV.EXE (disk cache), and a hardware-specific mouse driver (typically *MOUSE.COM).
If you had too many TSRs running at once there would be not enough base memory (the first 640 KiB) left, and some programs would refuse to start.
Writing this makes me realize we've really gone a long way.
I suspect ECHO. and COPY CON were in official docs, because I remember them quite well. I still have my old DOS 5.x reference manuals around here somewhere - I should check!
Back in the day there were several computer books in the r/The Undocumented .*/ pattern. That was super cool and I loved them, as if you were being revealed secrets that no one else knows. In retrospect they were mostly about unstable apis best avoided.
Great for exploit research.
With stable programs like DOS the hidden apis will be around awhile
https://the-eye.eu/, as a whole, is a very unique community, with a lot of goodies stashed in its vaults.
So 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, which is 1983).
debug.com shipped with the original MS-DOS and every subsequent version, so you automatically had a facility to disassemble and/or manipulate any running application essentially. We have easier tools now, but the tools available then were basically on every machine.
> Today I guess I'd try running strings on the executable or maybe straight-up opening them in a debugger or disassembler
Why today? I spent a fair amount of time during my childhood reading through "command.com" in a binary editor (zap-it), mostly for changing error messages to impress girls. It didn't really work, but I learned quite a lot in the process.
I remember using strings in the early 90s on DOS boxen, no recollection of where I got it from though, maybe a coverdisk, I could have implemented it myself, it's relatively trivial.
It's also worth remembering that DOS came with DEBUG, so if you had the time and patience you could dig about in anything
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.
> So how were these found?
Example usage for some of them could be discovered by going through the contents of .BAT files written by Microsoft, especially those that were a part of MS-DOS (and later Windows 9x) Setup (installer).
All the built-in commands appeared in plain text in COMMAND.COM, as did all the CONFIG.SYS parameters in IO.SYS. As far as I know there wasn't a UN*X-like strings(1) utility at the time but binary files could still be browsed with third-party tools.
DOS wasn't a very big program. Anyone with some time on their hands could go through the assembly dumps. And there were a lot of curious people with time on their hands.
Debug command.com
>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.
I don't actually remember much about config.sys, despite spending much of my formative years editing it in the attempt to claw back as much of that 640k as possible.
But I do remember "copy con filename.txt", which I'm hoping is the answer to the second part of your question.
I actually had to walk a coworker through some Windows and Linux and it was a bit stunning to realize that there are now highly technical people who didn't know how to do things like switch directories, print a list of files in the current directory, etc. My parents never knew they were doing me a favor by buying a computer that ran Windows 3.1 so poorly that I needed to do everything in DOS.
That was exactly what I was thinking of, though the rest of what I remember about config.sys revolves around battles with emm386. Ah, for the simplicity of the 286.
It's weird hos DOS perversity made it super-easy to pick up unix when Linux became available, but I've retained a loathing of unnecessarily short commands like 'cp' 'mv' and especially 'man', probably in proportion to the difficulty of guessing them.
It's not much different than using "cat > filename" on any modern *nix, which is very well used to this day.
Tangentially related: Freedos is close to 1.3 release, with a 1.3rc3 being prepared (partially out already).
I remember feeling angry when I learned about the undocumented MBR switch for FDISK. There I was, beginning to learn to spell words with 6 or more letters, thinking I had to use a hex editor to clean up the MBR.
All that effort with no guidance whatsoever that could have been minimized with one extra line of documentation.
Weird, FDISK /MBR was actually the only command I knew about.
:: is not quite a command, see here:
https://stackoverflow.com/questions/16632524/what-does-doubl...
Since very niche stuff there. Though it does bring back memories of using Alt+255 typed into directory names to hide our porn. (Thanks Joe!)
Small 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.
I 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 by the way. Bookmarked!
ECHO %BLASTER%
You almost had it, you just need two percents.
It is the same syntax as Windows cmd.exe currently uses
OK, so I tried this, but ECHO %PATH% just outputs %PATH%. I'm running DOS 6.22 on a 286. Same thing happens for any other variable defined in AUTOEXEC...
"In DOS I believe that %var% expansion only works in batch files, not at the command line directly."[1] That worked for me in an emulator.[2]
[1] https://stackoverflow.com/questions/28021862/echo-variable-s...
Confirmed. It doesn't work directly from the prompt, only within a batch file. I think might work on a DOS 7 prompt (Win95 >) though, not sure, I don't have a Windows machine hooked up atm. Maybe that's where my memory is from...
Thanks!
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.
It was % to indicate environment variables.
echo %PATH%
Should work, as long as that variable is in scope, which it should be on an old MSDOS platform with a single thread.
Environmental variables have scopes?
Its probably that variables defined in AUTOEXEC are "global" scope, i.e. can be referenced in any other batch file, but variables defined within a batch file other than AUTOEXEC only exist within the scope (context) of that batch file. But, I haven't tested this...
I think in DOS they were all global in scope. SETLOCAL appeared with Windows NT (cmd.exe), not sure which version (I didn't use the early ones).
When you created an in-memory drive (what the heck was the name for them in DOS?), for example to store temporary files on, the label FDISKFAKE was automatically given. If you tried to format the drive, format complained that an in-memory drive can't be format. If you changed the label, format happily formated the drive.
RAM drive? Ramdrive.sys
> FDISK /MBR Re-writes the hard disk drive's Master Boot Record.
I didn't know it's undocumented, and many people I knew used it (as well as FORMAT /U) countless number of times.
I remember learning about "FDISK /mbr" from a DEC support tech support line. I rescued several hard disks with that command that other people had deemed "broken".
That command saved me at least a dozen of times while playing too much with my partition table and the dual boot configuration with Linux. (Partition) Magic :-)
I really miss the simplicity of MBR-based partitioning, still need to wrap my head around UEFI and GPT
UEFI is actually a lot simpler than MBR-type partitioning as far as the user is concerned. The UEFI firmware partition is based on a FAT-like fs, hence it natively supports dual- and multi-booting and can provide a "Shell" that's quite comparable to DOS itself. There are ongoing problems with UEFI due to shoddy OEM implementations, but the basic idea is quite sensible.
After DOS 3.31, many undocumented commands and BIOS IRQs were removed. This broke some software but it is interesting to see these undocumented commands beyond DOS 4 still existing.
After 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!
Note: There was an MS-DOS 8.0; it did not come with Windows 98, but rather with Windows Me.
I guess we'll probably never see this updated to include that, though!
I remember using
A:\> DIR.EXE
instead of having to type
A:\> DIR *.EXE
IIRC, it worked for any extension, not just .EXE.
Middle school me had some fun with /autotest.
Dos4 still had commands to control a tape deck
GW-BASIC (which was included prior to DOS 5.x) had the MOTOR command to control the cassette motor. I don't know if it actually worked though. In Microsoft's released GW-BASIC 1.0 source, it is a no-op and just prints an error message – https://github.com/microsoft/GW-BASIC/blob/master/GIOCAS.ASM [EDIT: I just disassembled GWBASIC.EXE version 3.23, I can see the calls to the BIOS INT 15h cassette API, so it isn't just a no-op in the binary.]
If it worked at all, it would have worked by calling INT 15h functions 0-1, which was part of the BIOS cassette API. I believe in ROM BASIC on the original IBM PC and PCjr, the MOTOR command was actually implemented to call those BIOS routines, and the BIOS actually had code to talk to the cassette port. I think, on subsequent machines, the BIOS routines were stubbed out and just returned an error.
GW-BASIC was the only part of MS-DOS which had any reference to the cassette tape. The more core parts of MS-DOS (IO.SYS, MSDOS.SYS, COMMAND.COM) knew absolutely nothing about it.
As do many cloud instances. I'm not sure about other distributions, but Debian and Ubuntu ship `mt` with their cpio packages.
OP is not talking about the general concept of data storage on magnetic tape devices, he is talking about using music Compact Cassette Tapes to store data on DOS.