Shhh: The Undocumented DOS Commands (1999)(the-eye.eu) |
Shhh: The Undocumented DOS Commands (1999)(the-eye.eu) |
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.
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)
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.
With stable programs like DOS the hidden apis will be around awhile
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 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.
All that effort with no guidance whatsoever that could have been minimized with one extra line of documentation.
https://stackoverflow.com/questions/16632524/what-does-doubl...
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.
Cool list by the way. Bookmarked!
You almost had it, you just need two percents.
It is the same syntax as Windows cmd.exe currently uses
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.
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.
I didn't know it's undocumented, and many people I knew used it (as well as FORMAT /U) countless number of times.
I really miss the simplicity of MBR-based partitioning, still need to wrap my head around UEFI and GPT
These were some creative times!
I guess we'll probably never see this updated to include that, though!
A:\> DIR.EXE
instead of having to type
A:\> DIR *.EXE
IIRC, it worked for any extension, not just .EXE.
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.
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.
It's also worth remembering that DOS came with DEBUG, so if you had the time and patience you could dig about in anything
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.
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.
[1] https://stackoverflow.com/questions/28021862/echo-variable-s...
Thanks!