Why wasn't DOSKEY integrated with COMMAND.COM?
19
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?
ms-dos
edited yesterday
Raffzahn
56.9k6139231
asked yesterday
user7710user7710
14615
add a comment |
19
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?
ms-dos
edited yesterday
Raffzahn
56.9k6139231
asked yesterday
user7710user7710
14615
14
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
yesterday
add a comment |
19
19
19
1
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?
ms-dos
edited yesterday
Raffzahn
56.9k6139231
asked yesterday
user7710user7710
14615
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?
ms-dos
ms-dos
edited yesterday
Raffzahn
56.9k6139231
asked yesterday
user7710user7710
14615
edited yesterday
Raffzahn
56.9k6139231
asked yesterday
user7710user7710
14615
edited yesterday
Raffzahn
56.9k6139231
edited yesterday
Raffzahn
56.9k6139231
edited yesterday
Raffzahn
56.9k6139231
56.9k6139231
asked yesterday
user7710user7710
14615
asked yesterday
user7710user7710
14615
asked yesterday
user7710user7710
14615
14615
14
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
yesterday
add a comment |
14
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
yesterday
14
14
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
yesterday
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
yesterday
add a comment |
3 Answers
3
active
oldest
votes
32
I can think of a number of reasons:
DOSKEYisn’t specifically tied toCOMMAND.COM; it provides history for any program which uses the same input functions asCOMMAND.COM, and one could imagine wanting to runDOSKEYwith another command interpreter (although the most popular alternative command interpreter, 4DOS, already included equivalent features);
DOSKEYwas 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.)
answered yesterday
Stephen KittStephen Kitt
40.8k8167175
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
yesterday
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
yesterday
@Raffzahn thanks, I think your answer is useful too ;-).
– Stephen Kitt
yesterday
I'd consider it a duplicate for most parts - but yeah, I'm not deleting it, as this would also remove the rather high quality comments made so far.
– Raffzahn
yesterday
1
Why would an input routine care about the date changing at midnight?
– immibis
23 hours ago
|
show 3 more comments
14
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.
edited yesterday
Wilson
12.8k658145
answered yesterday
RaffzahnRaffzahn
56.9k6139231
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.
– a CVn
yesterday
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
yesterday
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
yesterday
2
800 kb/second is still 25 times faster than a floppy...
– Thorbjørn Ravn Andersen
yesterday
4
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
yesterday
|
show 4 more comments
4
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.
answered yesterday
grahamj42grahamj42
47626
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
23 hours ago
COMMAND.COMkept 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
9 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9715%2fwhy-wasnt-doskey-integrated-with-command-com%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
32
I can think of a number of reasons:
DOSKEYisn’t specifically tied toCOMMAND.COM; it provides history for any program which uses the same input functions asCOMMAND.COM, and one could imagine wanting to runDOSKEYwith another command interpreter (although the most popular alternative command interpreter, 4DOS, already included equivalent features);
DOSKEYwas 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.)
answered yesterday
Stephen KittStephen Kitt
40.8k8167175
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
yesterday
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
yesterday
@Raffzahn thanks, I think your answer is useful too ;-).
– Stephen Kitt
yesterday
I'd consider it a duplicate for most parts - but yeah, I'm not deleting it, as this would also remove the rather high quality comments made so far.
– Raffzahn
yesterday
1
Why would an input routine care about the date changing at midnight?
– immibis
23 hours ago
|
show 3 more comments
32
I can think of a number of reasons:
DOSKEYisn’t specifically tied toCOMMAND.COM; it provides history for any program which uses the same input functions asCOMMAND.COM, and one could imagine wanting to runDOSKEYwith another command interpreter (although the most popular alternative command interpreter, 4DOS, already included equivalent features);
DOSKEYwas 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.)
answered yesterday
Stephen KittStephen Kitt
40.8k8167175
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
yesterday
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
yesterday
@Raffzahn thanks, I think your answer is useful too ;-).
– Stephen Kitt
yesterday
I'd consider it a duplicate for most parts - but yeah, I'm not deleting it, as this would also remove the rather high quality comments made so far.
– Raffzahn
yesterday
1
Why would an input routine care about the date changing at midnight?
– immibis
23 hours ago
|
show 3 more comments
32
32
32
I can think of a number of reasons:
DOSKEYisn’t specifically tied toCOMMAND.COM; it provides history for any program which uses the same input functions asCOMMAND.COM, and one could imagine wanting to runDOSKEYwith another command interpreter (although the most popular alternative command interpreter, 4DOS, already included equivalent features);
DOSKEYwas 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.)
answered yesterday
Stephen KittStephen Kitt
40.8k8167175
I can think of a number of reasons:
DOSKEYisn’t specifically tied toCOMMAND.COM; it provides history for any program which uses the same input functions asCOMMAND.COM, and one could imagine wanting to runDOSKEYwith another command interpreter (although the most popular alternative command interpreter, 4DOS, already included equivalent features);
DOSKEYwas 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.)
answered yesterday
Stephen KittStephen Kitt
40.8k8167175
edited yesterday
answered yesterday
Stephen KittStephen Kitt
40.8k8167175
answered yesterday
Stephen KittStephen Kitt
40.8k8167175
answered yesterday
Stephen KittStephen Kitt
40.8k8167175
40.8k8167175
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
yesterday
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
yesterday
@Raffzahn thanks, I think your answer is useful too ;-).
– Stephen Kitt
yesterday
I'd consider it a duplicate for most parts - but yeah, I'm not deleting it, as this would also remove the rather high quality comments made so far.
– Raffzahn
yesterday
1
Why would an input routine care about the date changing at midnight?
– immibis
23 hours ago
|
show 3 more comments
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
yesterday
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
yesterday
@Raffzahn thanks, I think your answer is useful too ;-).
– Stephen Kitt
yesterday
I'd consider it a duplicate for most parts - but yeah, I'm not deleting it, as this would also remove the rather high quality comments made so far.
– Raffzahn
yesterday
1
Why would an input routine care about the date changing at midnight?
– immibis
23 hours ago
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
yesterday
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
yesterday
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
yesterday
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
yesterday
@Raffzahn thanks, I think your answer is useful too ;-).
– Stephen Kitt
yesterday
@Raffzahn thanks, I think your answer is useful too ;-).
– Stephen Kitt
yesterday
I'd consider it a duplicate for most parts - but yeah, I'm not deleting it, as this would also remove the rather high quality comments made so far.
– Raffzahn
yesterday
I'd consider it a duplicate for most parts - but yeah, I'm not deleting it, as this would also remove the rather high quality comments made so far.
– Raffzahn
yesterday
1
1
Why would an input routine care about the date changing at midnight?
– immibis
23 hours ago
Why would an input routine care about the date changing at midnight?
– immibis
23 hours ago
|
show 3 more comments
14
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.
edited yesterday
Wilson
12.8k658145
answered yesterday
RaffzahnRaffzahn
56.9k6139231
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.
– a CVn
yesterday
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
yesterday
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
yesterday
2
800 kb/second is still 25 times faster than a floppy...
– Thorbjørn Ravn Andersen
yesterday
4
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
yesterday
|
show 4 more comments
14
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.
edited yesterday
Wilson
12.8k658145
answered yesterday
RaffzahnRaffzahn
56.9k6139231
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.
– a CVn
yesterday
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
yesterday
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
yesterday
2
800 kb/second is still 25 times faster than a floppy...
– Thorbjørn Ravn Andersen
yesterday
4
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
yesterday
|
show 4 more comments
14
14
14
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.
edited yesterday
Wilson
12.8k658145
answered yesterday
RaffzahnRaffzahn
56.9k6139231
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.
edited yesterday
Wilson
12.8k658145
answered yesterday
RaffzahnRaffzahn
56.9k6139231
edited yesterday
Wilson
12.8k658145
edited yesterday
Wilson
12.8k658145
edited yesterday
Wilson
12.8k658145
12.8k658145
answered yesterday
RaffzahnRaffzahn
56.9k6139231
answered yesterday
RaffzahnRaffzahn
56.9k6139231
answered yesterday
RaffzahnRaffzahn
56.9k6139231
56.9k6139231
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.
– a CVn
yesterday
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
yesterday
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
yesterday
2
800 kb/second is still 25 times faster than a floppy...
– Thorbjørn Ravn Andersen
yesterday
4
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
yesterday
|
show 4 more comments
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.
– a CVn
yesterday
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
yesterday
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
yesterday
2
800 kb/second is still 25 times faster than a floppy...
– Thorbjørn Ravn Andersen
yesterday
4
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
yesterday
1
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.
– a CVn
yesterday
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.
– a CVn
yesterday
2
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
yesterday
@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
yesterday
2
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
yesterday
"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
yesterday
2
2
800 kb/second is still 25 times faster than a floppy...
– Thorbjørn Ravn Andersen
yesterday
800 kb/second is still 25 times faster than a floppy...
– Thorbjørn Ravn Andersen
yesterday
4
4
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
yesterday
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
yesterday
|
show 4 more comments
4
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.
answered yesterday
grahamj42grahamj42
47626
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
23 hours ago
COMMAND.COMkept 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
9 hours ago
add a comment |
4
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.
answered yesterday
grahamj42grahamj42
47626
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
23 hours ago
COMMAND.COMkept 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
9 hours ago
add a comment |
4
4
4
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.
answered yesterday
grahamj42grahamj42
47626
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.
answered yesterday
grahamj42grahamj42
47626
answered yesterday
grahamj42grahamj42
47626
answered yesterday
grahamj42grahamj42
47626
answered yesterday
grahamj42grahamj42
47626
47626
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
23 hours ago
COMMAND.COMkept 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
9 hours ago
add a comment |
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
23 hours ago
COMMAND.COMkept 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
9 hours ago
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
23 hours ago
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
23 hours ago
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
9 hours ago
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
9 hours ago
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9715%2fwhy-wasnt-doskey-integrated-with-command-com%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
14
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
yesterday