27

Why did Microsoft make DOSKEY a separate command, instead of integrating it with COMMAND.COM?

I don't think DOSKEY uses a lot of RAM or was useless in the '80s... Maybe there was another reason not to enable this command automatically?

Improve this question
4
  • 21
    I remember spending a lot of time tuning CONFIG.SYS and AUTOEXEC.BAT while rebooting over and over again. Trying to save every last bit of memory so I could load games that had a large base RAM requirement. Even though we had the ability to address upper memory every program needed a foot in the base RAM. Out of the 640KB I often needed ~500K free or programs wouldn't load at all.
    – HackSlash
    Apr 17, 2019 at 21:33
  • @HackSlash Hence the need for things like QMem and memmaker
    – Steve
    Apr 19, 2019 at 2:13
  • 2
    @Steve : Maybe you mean QEMM?
    – Eric Towers
    Apr 19, 2019 at 9:31
  • Oh yeah, that's what it was...
    – Steve
    Apr 19, 2019 at 13:24

4 Answers 4

Reset to default
41

I can think of a number of reasons:

  • DOSKEY isn’t specifically tied to COMMAND.COM; it provides history for any program which uses the same input functions as COMMAND.COM, and one could imagine wanting to run DOSKEY with another command interpreter (although the most popular alternative command interpreter, 4DOS, already included equivalent features);
  • DOSKEY was introduced late in MS-DOS’s life, in version 5 (1991); since it changed input handling (with its macro support in particular), the MS-DOS developers might have thought that some users wouldn’t want it, or that it could break things (backward compatibility was already very important for Microsoft by that time);
  • memory really was tight in DOS, even with the support for UMBs introduced in DOS 5.

The first reason is really sufficient from my point of view: input editing isn’t handled in COMMAND.COM, so improving it in COMMAND.COM wouldn’t have made much sense.

It turns out DOSKEY’s developers forgot one important feature of the DOS input routine (it’s supposed to handle the date change at midnight), so making it optional turned out to have been a good idea!

(There were a number of history-providing TSRs already available then, but that wouldn’t have been a consideration for Microsoft.)

Improve this answer
8
  • Stephen, you beat me again :)) And with a great answer. If there is any point in my writeup you find useful, feel ree to integrate it into your answer so I can delete mine.
    – Raffzahn
    Apr 17, 2019 at 14:54
  • Oh, I see. I initially failed to make the connection between that link at the top, and the paragraph towards the bottom. You mean that the interrupt service routine was modified to handle a global, system-level function, not that it did something like modifying dates in the command line that was typed. Thanks; removing my initial comment.
    – Cody Gray - on strike
    Apr 17, 2019 at 17:18
  • @Raffzahn thanks, I think your answer is useful too ;-).
    – Stephen Kitt
    Apr 17, 2019 at 17:32
  • 2
    Why would an input routine care about the date changing at midnight?
    – user253751
    Apr 17, 2019 at 23:40
  • 2
    @immibis there are a number of features which hang off the DOS idle routine, which is activated when waiting for characters in console mode; one of these is midnight handling. DOSKEY hooks the corresponding functions, but short-circuits them; it re-implements most of the short-circuited features, but not the midnight handling (or the wait handling for the PC Convertible, but I imagine no one cared about that when DOS 5 was released). This is discussed at the start of Geoff Chappell’s DOS Internals.
    – Stephen Kitt
    Apr 18, 2019 at 12:29
19

I wrote the DOSKEY that went into DOS5... I think it actually went into the win3.0 box too, but I can't find any evidence for that.

I was the new guy on the team, it was the first project they gave me before I started diving into cleaning up the existing code base. There was a program called DOSKEY that had source code published in one of the magazines. Microsoft wanted to include the functionality (possibly trying to match DR-DOS's added features) but didn't want to risk copyright issues by using the published code.

The published DOSKEY used fixed length 128 byte records in its command history, so it was extremely inefficient. I wrote code to use variable length records in a circular buffer, so it was much more efficient in terms of history size vs. memory usage.

The Macros were my idea if I recall correctly, as we were trying to figure out some "low-cost" feature to throw in. I actually used the macros quite a lot for a couple of years, including parameter substitution.

It was very well written and documented, as it was my "debut" to the DOS team, the first time they had seen my code. During my initial team meeting code review, DavidOls said it showed "a firm hand on the keyboard."

Why was it not integrated into COMMAND.COM? I think it was as others have suggested, to not force the memory usage on people who didn't want it. One of the big goals of the MS-DOS 5 project was reducing "Low 640k footprint". We added some kind of int2f hook to integrate it better into COMMAND.COM, I don't remember why now.

Improve this answer
1
  • Welcome on the site! Nice to see here such "big guns" here :-) Do you have some link or other reference?
    – peterh
    Jul 8, 2019 at 8:00
18

Well, first of all, isn't it best if an OS is configurable for each user the way he needs, instead of packing everything into one bloated package?

  • Basic DOS is supposed to run on small machines, thus a small footprint is a major reason. Making everything non essential (and user convenience is) optional helps
  • Not every User might like or even need it
  • There might be scenarios where DOSKEY is harmful
  • DOSKEY is - like many other 'comforting' add-ons - a late comer.
  • Did I already mention RAM size? Even with full 640 KiB (and UMB), DOS memory was quite challenged when DOSKEY became available.
  • Even if it's 'just' a few KiB, it could really be a drain.

Long story short, having a configurable system to be tailored to each job needed is quite an advantage worth paying the price of a few bytes wasted for headers and duplicate code plus a few milliseconds during boot.

Improve this answer
9
  • 1
    I would argue that loading DOSKEY probably took more than "a few milliseconds during boot". tomshardware.com/reviews/… suggests in the early 1990s, 800 kB/s was normal throughput for a PC hard disk; at such speeds, even just loading an unfragmented 10 KB sequential block of data would take at least 12 ms. On fragmented media, a lot more; seek thrice on that drive and you're looking at on the order of 100 ms, which is quite perceptible a delay already. That said, this does not negate the point you are making; probably quite the opposite.
    – user
    Apr 17, 2019 at 14:16
  • 2
    @aCVn Come on, even 100 is a few. These where the 90s, DOS was almost instant. A blink of the HD-LED. Windows and LAN made us wait. Now, DOSKEY is under 6 KiB file size (5883 bytes). A typical 40 MiB Disk of that time would use 2 KiB cluster size, at least when formated by DOS with default settings. And the file gets moved there right after format, so chances are good it's not only consecutive, but even on the same cylinder than the rest of DOS. No seek, just load. Instant.
    – Raffzahn
    Apr 17, 2019 at 14:51
  • 2
    "isn't it best if an OS is configurable for each user the way he needs, instead of packing everything into one bloated package?" That's a valid position to take, but it isn't exactly the position that Microsoft took in the '80s and '90s. They tended to produce highly integrated packages, for a variety of reasons. In that sense, the decision not to integrate Doskey was more of an anomaly than your answer suggests it to be.
    – Cody Gray - on strike
    Apr 17, 2019 at 17:01
  • 3
    800 kb/second is still 25 times faster than a floppy...
    – Thorbjørn Ravn Andersen
    Apr 17, 2019 at 19:56
  • 5
    Regarding the tightness of memory, I remember being really into PC gaming in the mid-90s and spending many, many hours trying to figure out how to save that last few hundred bytes of "conventional" RAM so I could fit the various combinations of drivers loaded for that one particular game I wanted to play. Even when EMS became more common there were still a lot of issues with early sound cards and CD-ROM drives and so on. A couple of kilobytes made a huge difference back then.
    – fluffy
    Apr 17, 2019 at 22:11
7

The early architecture of COMMAND.COM (based on detailed analysis of DOS 2.1 a long, long time ago) was that a program requesting maximum memory could overwrite all of COMMAND.COM except a tiny portion which would reload from disk on termination.

By the time DOS 5 was released, 1MB RAM was not uncommon, so this motivation had gone.

But Windows 3.0 was released before DOS 5 and Microsoft started pushing for everyone to run Windows all the time, rather than just loading Windows 2.1 runtime for Excel or Pagemaker.

Windows 3.0 loaded on top of DOS, and it was common to open a DOS box or run batch files within it. Any bloat in COMMAND.COM would be loaded multiple times.

So I suggest that integrating functionality to COMMAND.COM would have been an unwise architectural choice in those days.

Improve this answer
2
  • 2
    This is an interesting point that others don't seem to have brought up, but even in DOS 5 days most people would still run Windows in standard mode instead of 386 enhanced. In real and standard modes, you didn't have multiple DOS boxes each with their own COMMAND.COM because virtual-86 was only supported and used by 386 enhanced mode. Even having 1MB of RAM in the system wouldn't be enough for 386 enhanced, because each DOS session required a full meg assigned to it anyway.
    – Chris Charabaruk
    Apr 18, 2019 at 0:19
  • COMMAND.COM kept its split architecture, so that’s not really a factor. It’s been documented as such for a long time, in Microsoft’s documentation no less ;-). It was still useful with DOS 5 and later... Also, Windows’ DOS VM goes to great lengths to share memory as far as possible.
    – Stephen Kitt
    Apr 18, 2019 at 14:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .