Shhh: The Undocumented DOS Commands (1999) - <AUTHOR> https://the-eye.eu/public/Software/Old%20Apps/DOS%20Resources/Undocumented%20dos%20tips.txt <comment><USER2> Never 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.

<comment><USER3> > 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)

<comment><USER2> > 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.

</comment></comment></comment><comment><USER4> 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.

<comment><USER5> Great for exploit research.

With stable programs like DOS the hidden apis will be around awhile

</comment></comment><comment> phoe-krk [https://the-eye.eu/](https://the-eye.eu/), as a whole, is a very unique community, with a lot of goodies stashed in its vaults.

</comment><comment> yjftsjthsd-h 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).

<comment><USER6> 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.

<comment><USER7> 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.

<comment><USER6> 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.

</comment></comment></comment></comment><comment><USER8> >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.

<comment><USER9> But I bet you do, including how to create it on a system with no editor.

<comment><USER8> 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.

<comment><USER9> 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.

</comment></comment></comment></comment><comment><USER10> Tangentially related: Freedos is close to 1.3 release, with a 1.3rc3 being prepared (partially out already).

</comment><comment><USER11> 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.

<comment><USER12> Weird, FDISK /MBR was actually the only command I knew about.

</comment></comment><comment><USER13> :: is not quite a command, see here:

[https://stackoverflow.com/questions/16632524/what-does- doubl...](https://stackoverflow.com/questions/16632524/what-does-double-colon- mean-in-dos-batch-files)

</comment><comment><USER14> 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!)

</comment><comment><USER15> 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.

</comment><comment><USER16> 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!

<comment><USER3> ECHO %BLASTER%

You almost had it, you just need two percents.

It is the same syntax as Windows cmd.exe currently uses

<comment><USER16> 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...

<comment><USER17> "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...](https://stackoverflow.com/questions/28021862/echo-variable- shows-variable-in-ms-dos-6-22)

[2] [https://jamesfriend.com.au/pce-js/ibmpc- games/](https://jamesfriend.com.au/pce-js/ibmpc-games/)

<comment><USER16> 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!

</comment></comment></comment></comment></comment><comment><USER18> 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.

<comment><USER19> RAM drive? Ramdrive.sys

</comment></comment><comment><USER20> > 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.

</comment><comment><USER21> 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".

<comment><USER22> 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

<comment><USER23> 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.

</comment></comment></comment><comment><USER24> 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.

</comment><comment><USER25> 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!

</comment><comment><USER26> 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!

</comment><comment><USER27> I remember using

A:\> DIR.EXE

instead of having to type

A:\> DIR *.EXE

IIRC, it worked for any extension, not just .EXE.

</comment><comment><USER28> Middle school me had some fun with /autotest.

</comment><comment><USER29> Dos4 still had commands to control a tape deck

<comment><USER30> As do many cloud instances. I'm not sure about other distributions, but Debian and Ubuntu ship `mt` with their cpio packages.

<comment><USER31> 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.

[https://en.wikipedia.org/wiki/IBM_cassette_tape](https://en.wikipedia.org/wiki/IBM_cassette_tape)</comment></comment></comment>


Are "shortr.co" Domains better than "thelonger.com" Domains?  - <AUTHOR>

Each time I watched This Week in Startups, Jason Calacanis would create a big fuss about .co domains and how one could get nice .co domains cheaply. As I wanted one for myself, I ended up searching some possible domains.
I was really shocked at the number of 4 letter domains still available. I got really addicted, and kept on searching until I had gathered more than 150 awsome domain names... I think some hoarding instinct had taken over me :).
Then I asked myself... what shall I do with this list?? I had spent some time and intelligence on this. I did not want to empty the cart and just forget it. These were domains like:
* opamp.co * scanr.co * printr.co
* buyr.co * editr.co
So I dumped this list on http://www.getr.co
The .co domains are supposed to be a substitute for .com. It is really tempting to get these instead of .coms. But is it really advisable?
Have any of u had negative experiences with .co domains by loosing too much traffic to the corresponding .com domain due to customer ignorance? Are there cases of Trademark violations and so on by the corresponding .coms? <comment><USER2> IMHO .co domains are not in any way _better_ than .com domain names. Also I feel that they are worse than .net or .org extensions in that .co will get easily confused for a .com domain name.

</comment><comment><USER3> I got <http://spu.co/> for the flash games development I've been doing lately. I think some traffic will be lost by people typing in spu.com or even spuco.com, but how much is anyone's guess. I think the more general-purpose your website (and therefore audience) the larger a percentage you're going to lose due to typos/unfamiliarity with the TLD.

Since my website is more of a collection of stuff I've made and I'm not going to be marketing it heavily, I think it'll be okay. The traffic it gets will likely be through links where the person doesn't have to type the domain in. An easy question to ask yourself: will you ever be putting the domain in print materials/advertising? If you can see yourself wanting to market your website in print, the .co will be more of an issue than if the only marketing you do is online, where the site will be linked and the visitor only has to click the link, not type anything in.

There are some people who absolutely refuse to use anything but .com/.net/.org, or even those who ONLY use .com, and there's valid evidence out there making their case -- del.icio.us changing to delicious.com, or the fact that microsoft has bought nearly every typographical misspelling of their brand that you can think of, for example.

And then there's the additional issue that .co is technically the ccTLD (country-code) of the Republic of Colombia, even though it's available worldwide for registration. With the .ly issue or non-issue, depending on which side you're on, that's arisen recently it could be argued that any ccTLD is potentially at risk.

Personal opinion? I think it works fine for what I'm using it and don't regret my decision. But then I love short domains (I also own <http://pzxc.com> and <http://6d7.com>, and used to own <http://ui.cx/> but gave it up partly for these reasons we're discussing here but mainly because I _had_ to use the Christmas Island registrar for that one instead of my normal registrar, which was annoying).

However if I was using it for a massive site trying to make oodles of money off of it, my opinion might change. I think if I was bit.ly right now I'd be at least a little worried, though of course I'd downplay it just as they are doing.

<comment><AUTHOR> I guess this means that a startup with a focus on online growth without much print advertising could choose a cheap .co which has a corresponding, not too popular or powerful .com, grow fast and then buy the corresponding .com when they are big enough.

</comment></comment><comment><AUTHOR> Link to the list of 151+ domains <http://www.getr.co></comment>