Talk:DOS/Archive 2

Archive 1

Archive 2

Archive 3

Move January 2008

This page was moved, then moved back; see the discussion here: (old version of Wikipedia:Administrators' noticeboard/Incidents#DOS and MS-DOS Compatible Operating Systems). If you are concerned that DOS isn't real, but should be part of the MS-DOS article, see the arguments posted at the merge request and vote for deletion, as this was the main issue of these proposals. Thanks, 69.221.152.25 (talk) 18:44, 3 January 2008 (UTC)

those are either stupid arguments or made in stupid ways. DOS means Disc Operating System which is NOTHING specific to MS-DOS. —Preceding unsigned comment added by 69.125.110.223 (talk) 21:27, 8 January 2008 (UTC)

Indeed, in contrast to DOS - Disk Operating System, there are also:

(M)ROS Resident Operating Systems like for instance: Comodore's 4kB big operating system fo the THE PET minicomputer called Kernal. Also some of the Tandy 1000 family of personal computers featured a version of MSDOS loaded from ROM. Some other systems are the 1980ies RML 480Z micro computer runnsing ROS or Cambridge Z88 portable computer running OZ.

TOS - Tape loaded Operating System like for instance the early IBM 360 system with the operating system on tape called TOS/360, which later became DOS/360 loaded from ... a disk.

COS - Cassette Operating System like the TRS-80 KWICOS operating system

Tnimble (talk) 21:11, 29 September 2009 (UTC)

DOS in Vista

I think Vista is the first NT system to exclude any kind of DOS functioning, but I want to make sure before i say so in the article. Llama (talk) 07:04, 24 February 2008 (UTC)

At least as I read what Microsoft are saying in this FAQ entry, no, that's not the case:

Will my MS-DOS applications continue to run under Windows Vista without modification?

Yes, they will.

Not all DOS programs run on Windows Vista... SF007 (talk) 13:08, 20 May 2008 (UTC)

Vista isn't "DOS-based" in the sense that some might consider Windows 95/98/Me "DOS-based", but older versions of Windows NT (3.1, 3.5, 3.51, 4.0, 5.0 a/k/a Windows 2000, 5.1 a/k/a Windows XP) weren't "DOS-based" in that sense, either. Guy Harris (talk) 09:02, 24 February 2008 (UTC)

They use something called NTVDM.EXE (NT Virtual DOS Machine). In my own experience it works pretty badly. Example- Start -> Run, and tell it to run COMMAND. It will open the MS-DOS command interpreter in NTVDM; see how slowly the letters appear when you type. JeremyMcCracken (talk) (contribs) 18:48, 27 May 2008 (UTC)

DOS in Windows NT (all versions), is based on DOS 5.0. NTVDM is a third-party application based on Insignia Solutions Inc's SoftPC-AT version 3. (this is taken from a string in the binary in Win2K). The versions of ntio.sys and ntdos.sys are just io.sys and msdos.sys from DOS 5, hacked to work with ntvdm.

Keystroke in DOS is very frustrating, because of the way that NT (and OS/2), handle DOS emulations. This is a feature of DOS, which assumes it has control of the machine, and that it's OK to busywait the system, rather than go to HLT mode). The way that NT handles the keys is to starve DOS of the necessary cycles, which is why it appears sluggish.

One can look at tamedos, eg http://www.tamedos.com/docs/v50/TameFAQ.htm for some technical stuff. —Preceding unsigned comment added by Wendy.krieger (talk • contribs) 10:16, 1 July 2008 (UTC)

Remove Path Name using prompt command

Hiding this, since it's chat unrelated to improving the article, see WP:TALK
The following discussion has been closed. Please do not modify it.
Did anyone else know that it is possible to remove the path name and replace it with anything (or nothing) as the prompt? this picture illustrates what I mean [1] comment made by HermXIV (talk) 17:55, 4 April 2008 (UTC) who forgot to sign it --Enric Naval (talk) 21:53, 4 April 2008 (UTC) You mean the prompt command (I still have my MS-DOS 5.0 manual), pity that's it's all on spanish: C:\Documents and Settings\naval>prompt /? Cambia el símbolo del sistema de cmd.exe. PROMPT [texto] texto Especifica un nuevo símbolo del sistema. En el símbolo del sistema se pueden escribir caracteres normales y los siguientes códigos especiales: $A & (Símbolo de unión) $B | (barra vertical) $C ( (Paréntesis izquierdo) $D Fecha actual $E Código de escape (código ASCII 27) $F ) (Paréntesis derecho) $G > (signo mayor que) $H Retroceso (elimina el carácter previo) $L < (signo menor que) $N Unidad actual $P Unidad y ruta de acceso actual $Q = (signo igual) $S (espacio) $T Hora actual $V Versión de Windows XP $_ Retorno de carro y alimentación de línea $$ $ (signo del dólar) Si las Extensiones de comando están habilitadas, el comando PROMPT admite los siguientes caracteres de formato adicionales: $+ cero o más caracteres de signo "más" (+) en función de la profundidad del directorio de pila PUSHD, un carácter por cada nivel insertado. $M Muestra el nombre remoto asociado a la letra de unidad actual o la cadena vacía si la unidad actual no es una unidad de red. C:\Documents and Settings\naval>prompt $T 23:47:14,65prompt $A$A$A$A$D$F$G$N$Q$V &&&&04/04/2008)>C=Microsoft Windows XP [Versión 5.1.2600]prompt $S echo hello hello dir --Enric Naval (talk) 21:53, 4 April 2008 (UTC) Its so much easier than that. Just enter: PROMPT [prompt text][options ] Here's one example of an option you can use: To change the prompt to display the current drive and directory and a greater-than symbol, enter prompt $p$g You can also create more complicated prompts. For example, to use the same prompt as above, with two added spaces and the characters TIME= followed by a display of the current time, enter prompt $p$g TIME=$t The resulting prompt (if you are working in the DOS directory on drive C) will look like this: C:\DOS> TIME=11:07:54.23 --HermXIV (talk) 00:12, 7 April 2008 (UTC)

DOS was never called DOS

In spite of the title of this article, there has never been a microcomputer operating system called "DOS"; the only OS with this name was for the IBM 360 mainframe. It just became habitual to speak of DOS to group MS-DOS and PC-DOS, and later others. And the early versions of MS-DOS didn't only run on IBM-PC-compatible hardware but also on some significantly different x86 architectures (e.g., Sirius, Apricot) without the 640kB memory limit and with incompatible expansion cards.Pol098 (talk) 15:15, 25 April 2008 (UTC)

You're partly right, the official names were MS-DOS and PC-DOS. However "DOS" is a common generic term for these 2 IBM-compatible OSs: googling for "DOS games" will get you more hits than you'll want to see; I've even seen DOS games refered to as "dosser"s, mainly in discussions about how to get them to run on recent versions of Win. -- Philcha (talk) 13:13, 8 September 2008 (UTC)

Non-x86

A number of microcomputers had Disk Operating Systems, and it was habitual to refer to them as DOS. For example, if you read old Apple II literature, the use of DOS is often mentioned. This needs to be in an encylopaedia entry. Pol098 (talk) 15:34, 25 April 2008 (UTC)

Citations needed

I tagged this as needing citations. Specifically, it needs sources for these sections:

• DOS and Microsoft Windows
• Accessing hardware under DOS
• Reserved device names under DOS
• The DOS boot sequence
• Drive naming scheme (some of this is covered by citations in the main article)

I know from my own OR that much of this is correct, but it still needs citations, and I can't find any online. Does anybody have books about DOS where this is brought up? Maybe even "DOS for Dummies" would work. JeremyMcCracken (talk) (contribs) 19:43, 27 May 2008 (UTC)

I've managed to find web pages for all of this, with the exception of the hardware abstraction section, which I've {{fact}} tagged. Somebody please provide a cite for this if you have one. JeremyMcCracken (talk) (contribs) 03:10, 3 July 2008 (UTC)

July 2008

There are disagreements over this edit. Here are my issues:

1. "stands for 'Disk Operating System'" needs to be cited. I'd originally thought that this was backronymed, but have never found a source. I have no objections to inclusion if a source can be found.
2. "These were incompatible with DOS EXE files and the MS-DOS API" is there for readers who are at a novice computer level. People with little knowledge of older computer technology aren't going to know what this DOS is, or any of the other linked systems.

I also suspect this is part of the whole "rename this article to put MS in the title and move DOS (disambiguation) here, because DOS really means disk operating system" movement, because of this. Please don't go down this road again; consensus has always been keeping it in this format. This "DOS" family had a much wider usage than the others, and is the most common application of the term. JeremyMcCracken (talk) (contribs) 21:12, 11 July 2008 (UTC)

You can probably find a source for "disk operating system" from one of these printed books: http://books.google.com/books?q=%22disk+operating+system%22&as_brr=3. — Wackymacs (talk ~ edits) 08:34, 12 July 2008 (UTC)

Yep, there it is. Thanks, JeremyMcCracken (talk) (contribs) 00:42, 13 July 2008 (UTC)

Problems with references

The existing references are not good enough. Sources used should be both verifiable and deemed as reliable, per WP:V and WP:RS. We need to be sure that sources check their facts and have a certain standard of quality. That means, blogs are no-no. At the moment, this article relies on several unreliable online sources, when there are plenty of reliable printed books on the subject.

• this is not the best way to source the history—there are published books on Gates and Kildall:
  • Wallace, James; Jim Erickson (1993). Hard Drive: Bill Gates and the Making of the Microsoft Empire. ISBN 0-88730-629-2.
  • Freiberger, Paul; Michael Swaine [1984] (2000). Fire in the Valley: The Making of the Personal Computer, 2nd edition, New York: McGraw-Hill. ISBN 0-07-135892-7.
  • Evans, Harold; Gail Buckland; David Lefer (2004). They Made America: From the Steam Engine to the Search Engine: Two Centuries of Innovators. Little, Brown and Co. ISBN 0-316-27766-5.
  • Manes, Stephen; Paul Andrews (1992). Gates: How Microsoft's Mogul Reinvented an Industry—and Made Himself the Richest Man in America. Doubleday. ISBN 0671880748.
• What makes http://inventors.about.com/library/weekly/aa033099.htm reliable? The author doesn't seem to have cited any sources.
• And http://www.storagereview.com/guide2000/ref/hdd/bios/sizeGB8.html
• And http://www.winvistatips.com/dos-games-on-vista-a102.php

— Wackymacs (talk ~ edits) 09:16, 12 July 2008 (UTC)

I picked that history reference on purpose because it's a primary source from the co-founder of DR. That's Tom Rolander giving the interview, and it's very informative to listen to. As for the other web references, I don't own any DOS books, but I can try to glean something from the previews of g-books. Most of that I knew from my own OR, and was trying to find something through google that I can use as a source. If you know any book references right away that can replace these please do; it seems like the more technical references (like those that would inform us on DOS interrupts) don't have g-book previews. JeremyMcCracken (talk) (contribs) 00:51, 13 July 2008 (UTC)

I find that secondary sources are more appropriate. Who says Tom has got his facts correct, for instance? And you're also assuming people will want to watch a video (or indeed, that their computer/web browser are capable of playing it). I think the best book I know of for technical DOS details is Microsoft's MS-DOS Encyclopedia: http://www.amazon.com/MS-DOS-Encyclopedia-Versions-1-0-Through/dp/1556150490 — Wackymacs (talk ~ edits) 08:04, 13 July 2008 (UTC)

I see what you mean about the video. As for his facts, it's possible he's not 100%, but the circumstances surrounding DR's meeting with IBM has become almost folklore in the way it's retold (and there are a number of versions, the most common being that Kildall was "out flying"), so that seemed the best place to find the story. JeremyMcCracken (talk) (contribs) 14:48, 13 July 2008 (UTC)

Merge

Disk operating system should be merged here. Actually I would just leave a redirect, as that article has no verified content. It's also fairly ambiguous since one is an acronym for the other. Comments? Ham Pastrami (talk) 09:26, 19 July 2008 (UTC)

I'm undecided. The history section should definitely go. The bottom of the article is a good list explaining the difference between DOS and the OSes with "DOS" in the name, that weren't related to this DOS. However, DOS (disambiguation) also has a list. JeremyMcCracken (talk) (contribs) 20:48, 19 July 2008 (UTC)

Would it be too difficult to include the "other DOSes" as a section in a single article? If that cannot be done, we should still come up with a better way to disambiguate the two topics. Borrowing from the category structure, since this article deals with a narrower scope, it might be called something like DOS on IBM PC compatibles. Ham Pastrami (talk) 03:19, 20 July 2008 (UTC)

merge should be in the other direction. MSDOS is clearly a subset of disk operating system, whence the acronym originates. —Preceding unsigned comment added by petchboo (talk • contribs)

Changing the name has been brought up; consensus was always to keep it. While "DOS" has been used in the names of OSes unrelated to this group, these systems (and this use of "DOS") are the most-well known. That's why it's hatnoted to the disambiguation. For example, google "DOS". Past the Wikipedia entry and the unrelated stuff, you see "MS-DOS help and commands", FreeDOS' home page, and an info page about this DOS. Google "DOS program", and everything relates to PC-Compatible. I like how the disambig page has them grouped right now; I think it's a good setup. JeremyMcCracken (talk) (contribs) 18:25, 21 July 2008 (UTC)

I redirected it to the disambig. This will cover both this article and the others with "DOS" in the name. JeremyMcCracken (talk) (contribs) 02:34, 21 August 2008 (UTC)

GA Review

This review is transcluded from Talk:DOS/GA1. The edit link for this section can be used to add comments to the review.

I'll be reviewing this article. I'll add comments in a day or two, after I've read through the article and done a little reading around. -- Philcha (talk) 18:07, 7 September 2008 (UTC)

Gaps in coverage

It's a big subject, and I can see you've put in a lot of work! Unfortunately I think there are some significant gaps in coverage:

• .BAT files
• Differences between MS-DOS and PC-DOS:
  • Some command language differences, for example PC-DOS did not support the CHOICE command, and its absence made writing menus via .BAT files harder.
  • What's the difference between MS-DOS and PC-DOS? says IBM tied PC-DOS to their hardware - I know blogs are not usually considered WP:RS but Osterman is a long-term MS designer, so I'd defend it quite happily.
    • Having some doubts about this. I recall running PC-DOS on non-IBM hw back in the day. VG ☎ 17:12, 22 October 2008 (UTC)
      • I'm sure you did, as all the "clones" wanted to prove compatibility. It was all a bit grey, for example the 1980s MS Flight Sim was regarded as a good test of BIOS compatibility with the IBM PC. -- Philcha (talk) 17:26, 22 October 2008 (UTC)
• The article mentions Terminate and Stay Resident programs, but does not convey a picture to a reader who wasn't there. I suggest you mention SideKick, which was very big in the 1980s.
• Graphical Environment Manager (DR GEM). In fact I'd be inclined to break out a new section on "ease of use". I remember that around the time DOS-based system became common in offices (1984 in UK) Apple introduced their "test drive a Mac" campaign to re-launch their GUI systems after the Apple Lisa was criticised for being expensive and slow. Usability for office staff and home users was a big issue at the time, see History of the graphical user interface. The Real History of the GUI may give you some points to check out, e.g. Amiga. Usability "features" on DOS machines included:
  • GUI: DR GEM.
  • Non-GUI: DOS Shell, DESQview (yes, I know it's mentioned later), GEOS (16-bit operating system) (also mentioned later).
  • Not exactly add-ons but some serious MS-DOS apps provided their own GUIs, e.g. early CASE tools.
  • I'd be tempted to include SideKick in this category.
  • And .BAT fles, especially the use of .BAT for menus.
  • Commercial significance of all this, e.g., Quarterdeck Office Systems went into decline after Win 3 and was swallowed, but Borland is still going (fairly) strong.
• The fundamental reason for all these limitations and work-rounds - Moore's Law, which, if you run it backwards, implies that early 1980s PCs were pathetic. Job_Control_Language #Complexity has some stats, with sources.
• I also remember an ex-IBM guy saying IBM didn't want the PC to become a threat to its larger ranges, and was quite happy for PC software to have severe limitations. You might like to see of you can find sources for this.
• There was a DOS version of MS Word (I used it) before Win 3 was released - same menu structure and ALT shortcuts.

General approach

While commenting on gaps in coverage, I've realised that we look at the subject quite differently - the article is technical / internals oriented, while I see the subject in user-oriented terms. I think for the "general reader" it would be best to explain how primitive / limited it was first, and then explain the technical causes of the limitations. I don't know what the consensus is at Wikiproject Computing about whether the dominant point of view should be technical or user-oriented, and would be happy to discuss this at Talk:DOS.

A sourcing issue

IBM's unhappiness about the licensing issue over CP/M is important, but I'm unhappy about the use of a video as the main source for this point: the sound is sometimes poor; the preamble is too long. Is there a text / HTML source that covers the same ground?

I'll produce more section-by-section comments after we've had a chance to discuss the ones above. -- Philcha (talk) 22:07, 7 September 2008 (UTC)

GA discussion

I just added a stub on batch files; of course, I hatnoted it as the main topic has some good detail. I'm not sure about implementing the MS/PC differences, as that would necessitate diferences between, for example, DR-DOS and MS-DOS, of which there are many (mostly because DR-DOS had the feature first). For example, while PC-DOS may not have the "choice" command, DR-DOS had a similar command earlier than MS-DOS, which was the "switch" command. "Doskey" in MS-DOS (and probably PC-DOS) was predated by the DR-DOS "history" command in config.sys. Basically, I worry about such a section getting way to large. Actually, I think an MS-PC comparison would be great to add to IBM PC-DOS, which is rather short.

You convinced me about not going into the MS/PC differences. OTOH I think the comparison stuff might be best in its own article, if ever. Thinking about it, there is a comparison article whose name I forget, but it's just a list of releases.

OTOH I'd regard .BAT files as an "ease of use" feature - especially as .BAT files were commonly used for menus in offices - so it's another UI improvement. To show how important menus were, this book (1991) has a section on .BAT menus. -- Philcha (talk) 23:37, 10 September 2008 (UTC)

Comparison of x86 DOS operating systems. A command difference section could definitely be put there. JeremyMcCracken (talk) (contribs) 00:36, 11 September 2008 (UTC)

An ease of use section is a great idea. I'm think two subsections: multitasking, where I'll put Sidekick. Later versions of DR-DOS had multitasking as well. (AFAIK MS and PC never had it, but not completely sure). Obviously, single-task was a big limitation from the user end. The second subsection will be the interface. I'll put some in about the CLI and later GUIs/TUIs that aimed to give users a more friendly experience: Geos, Desqview, Norton Commander, etc. I'll go ahead and pull the GUIs out of the software section and put them in the new section.

I agree about the 2 main sections of "ease of use section" being "multitasking" and "UI".

IIRC MS-DOS and PC-DOS never had multi-tasking. A purported MS doc form an anti-trust case backs this up, but may not be WP:RS. OTOH I think this SAMS book on Win XP is good enough. BTW remember to add page number(s) in the citation. -- Philcha (talk) 23:37, 10 September 2008 (UTC)

As for the source, I'll look. I would definitely like to use the interview for that citation. The peer reviewer was concerned with primary sources, but the whole IBM/DR thing has become almost folklorish in the way it's described, so a source so close to the event is a really good find. JeremyMcCracken (talk) (contribs) 21:26, 10 September 2008 (UTC)

Just Say No to Microsoft (book) looks good: non-disclosure issue; licensing issue; poss origin of "Kildall out flying" urban myth. BTW remember to add page number(s) in the citation. -- Philcha (talk) 23:37, 10 September 2008 (UTC)

I took the liberty of moving your response inside the review line. -- Philcha (talk) 23:37, 10 September 2008 (UTC)

Thanks; wasn't sure where the proper place for it was. JeremyMcCracken (talk) (contribs) 00:36, 11 September 2008 (UTC)

Ease of use section and book cite for the Rolander interview added. JeremyMcCracken (talk) (contribs) 22:21, 12 September 2008 (UTC)

Make this "main article" for MS-DOS and PC-DOS

Not strictly a part of the GA review, but it would be a good idea to avoid duplication of content and research. Since DOS describes the common features, it should do the heavy lifting.

Article structure

I keep having 2nd, 3rd, 4th etc. thoughts about this, because there several dimensions: historical development of MS-DOS and PC-DOS as stand-alone OSs; gradual absorption of MS-DOS into Win, which progressed at different rates in the home / client and business / server lineages of Win; add-ons to make stand-alone DOS more usable (1980s & 1990s); competitors (1980s & 1990s); continuing use of DOS-like environments (subtle wording of title to include e.g DosBOX, freeware desk-top DOS variants, embedded variants); internals. The current structure looks fragmented to me, but producing a better alternative isn't easy.

Here are my latest thoughts. Feel free to comment, criticise, object, tell me I'm missing things, etc.

• Built-in facilities (currently "Operating system structure")
  Hardware supported - with example of how pathetic it was by modern standards (only floppies; the IBM PC spec cited at Job Control Language#Complexity). Basic DOS kernel facilities. Files & sub-directories. CLI, preferably with horrendous example of file names including 2 levels of sub-dir. Batch files, including menus (they really were important in the 1980s and early 1990s).
  Link to Comparison of x86 DOS operating systems if you like, but I don't think that article lives up to its name and is just a list of versions.
• Origins (currently "History", but you've provided content to show that DOS's history is not over).
• Major applications that run on DOS.
  comment on increasing attempts by apps to provide easier UI (including but not limited to GUIs) and some multi-tasking in pre-Win apps.
  • Business applications
  • Games (PC games were huge before consoles got really good, see History of video games
  • Development tools
  • OS extenders / enhancers
  • etc.
• DOS and Microsoft Windows
• Continuing use of DOS-like environments
  • Emulators
  • Free and commercial desk-top look-alikes.
    Can you explain why HP & Dell provide FreeDOS? Why does anyone wan to run DOS these days, apart from gamers who think some mid-1990s games are still the greatest (includes me to a degree)?
  • Embedded
• Technical summary (currently "Operations")
  But move scripting / .BAT up to "Built-in facilities"

-- Philcha (talk) 14:28, 13 September 2008 (UTC)

I just did a massive rearrange and added a bit. As for FreeDOS being included as an OEM system, I couldn't honestly tell you why they would do that. JeremyMcCracken (talk) (contribs) 13:45, 26 September 2008 (UTC)

Hi, JeremyMcCracken, welcome back. Are you planning to do any more re-arranging? I ask because at present we seem to have very different ideas about the structure. I've written enough about my thoughts. Perhaps it would help if you could explain why you handle things in the sequence you prefer, and how each part connects to / supports later ones in that sequence. -- Philcha (talk) 16:08, 26 September 2008 (UTC)

I don't really have a good idea of how to flow this; I was just trying to put the relevant things together. JeremyMcCracken (talk) (contribs) 00:24, 27 September 2008 (UTC)

I appreciate that structuring the article's difficult when there are are so many inter-connections between topics - I'm about to restructure my contributions to Arthropod because I've just got hold of a text-book that makes it clear what the most important connections are in that subject.

I admit DOS still does not flow for me. The two most common ways to deal with that kind of difficulty are to add "sign-post" sentences at the start of each section to make the connections between adjacent sections explicit, or to re-structure.

Either way it might be easiest to create a "sandbox" sub-page of your user page in which to try things out, and then post links on this page to your sandbox versions - have a look at how busy my sandbox has been. I recently got Small shelly fauna to GA, and the reviewer said she hadn't realised how much easier using sandbox versions made it to try out alternatives. -- Philcha (talk) 07:12, 27 September 2008 (UTC)

• So does the article pass or fail? I noticed this article because of how long it's been on hold. Wizardman 01:46, 8 October 2008 (UTC)

I really don't have any new ideas on restructuring this. Unless anyone else has any idea, it's probably time to make a judgment call on it. JeremyMcCracken (talk) (contribs) 02:26, 8 October 2008 (UTC)

At present the article reads too much like excerpts from a programmer's guide, and gives little impression of what DOS was like from a user's point of view - and it was DOS' limitations from a user point of view that spawned other software, like TSRs (notably Sidekick) and early PC GUIs like DR's GEM.

It also overstates and oversimplifies the speed with which DOS was swallowed by Windows. Even Win 3.11 was effectively a co-operative multi-tasking GUI "skin" for DOS, and required a DOS-like OS underneath it. With Win 95 and 98 it was an OS in its own right (you could boot it up), and a loader and a collection of device drivers for Win. Even with NT and successors an emergency boot disk is a DOS disk. See What was the role of MS-DOS in Windows 95? - this is the blog of Raymond Chen, whose responsibility was backwards-compatibility of new Win releases.

There's a GA lurking in here, but it needs to be brought out. JeremyMcCracken has put alot of work into this already, and I'm willing to be patient. -- Philcha (talk) 21:45, 8 October 2008 (UTC)

- - - - - - - End of review - - - - - -

2nd Opinion

• Lead: remove references to Win9x since most people don't really consider them DOS, even if they included a DOS subsystem. Besides, you're not covering them at all (MS-DOS 7.x) in the rest of the article, although you do cover the newer NTVDM.
• Design section: seems a random collection of features; no discussion why these are important. Lacks fundamental design issues like multitasking (lack thereof actually), TSR, and driver model. As mentioned in the other review, you need some transition between sections; currently this reads like a checklist.
• Origins: fairly well written, and sufficiently comprehensive for GA. Almost reads like a different author wrote this section. The only problem is the subtitle. I would merge "Decline" with this section and call it "Timeline"; feel free to have subsections.
• Perhaps add MS compilers and QBasic to the "Software" section, and mention non-FPS games, like Falcon 3.0, Wing Commander series, and Ultima. Also add Norton Utilities as it became popular in later days. Give a few details about the major apps; the list approach is too dry.
• You need a section about built-in apps like the built-in editor (qedit IIRC). I know there weren't many.
• Windows 3.x needs to mentioned as the predominant GUI of this era.
• I would dissolve the "easy of use" section completely. Move "multitasking" into the design section, and the various apps like Norton-commander in the apps section.
• You need some basic coverage of internals, like TSRs, interrupt handling (without diving into programming details).
• A section on viruses (and anti-viruses) of the era would be nice.

Sorry if I used "you" instead of "the article" a lot, but I'm used to writing reviews like this in real life. Frankly the article on MS-DOS is closer to the GA standard than this article. VG ☎ 18:10, 22 October 2008 (UTC)

Thanks for the specifics. I'll be short of time for a while but I'll try to work on these whenever possible. For the built-in apps, there's currently List of DOS commands; would a hatnote suffice? JeremyMcCracken (talk) (contribs) 01:01, 23 October 2008 (UTC) -- Philcha (talk) 18:10, 7 September 2008 (UTC)

content moved inside review -- Philcha (talk) 23:38, 10 September 2008 (UTC)

Name of this article and package structure of DOS-related articles

Since OSs referred to as "DOS" appear on very different hardware and have very different architectures and feature sets, I suggest that:

• This article be renamed "DOS (PC operating system)"
• "DOS" should be the title of a disambiguation page, pointing to "DOS (PC operating system)", DOS/360 and any other OSs that were referred to as "DOS". If anyone finds refs that outline shared features of all these systems (which I doubt), a few paras can be added to the disambiguation page. --Philcha (talk) 12:47, 8 January 2009 (UTC)

Also "DOS (PC operating system)" should handle any "core material" is covered in MS-DOS and PC-DOS, leaving these articles to describe features to specific to these variants, how they came to diverge, and release history. --Philcha (talk) 12:47, 8 January 2009 (UTC)

It's been discussed a few times before (there's discussion here and at talk:MS-DOS). The consensus so far is that this "DOS" is the most common usage, enough so that the disambiguation should be at DOS (disambiguation) and have this hatnote there. JeremyMcCracken (talk) (contribs) 22:16, 8 January 2009 (UTC)

Need to mention BIOS

The article needs to mention:

• the dependence of MS-DOS and PC-DOS on a BIOS stored in the motherboard, how the BIOS became an issue in the spread of the "clones" (IBM-compatible PCs) and IBM's attempts to use claims of BIOS copyright infringements to slow down the clones' take-over of ther market.
• how much of the BIOS functions various versions of Win took over as they reduced the role of MS-DOS / PC-DOS.
• to what extent the BIOS is still important in the provision of DOS environments in Win XP ad Vista. --Philcha (talk) 12:55, 8 January 2009 (UTC)

Another push for GA?

Does anyone mind if I have a go a getting this to GA?

Disclosure:

• I GA-reviewed this a few months ago, and issued a "fail" after getting a 2nd opinion to be sure I wan't being over-demanding.
• If I do go ahead, you possibly won't recognise the article, as I tend to re-write from the ground up and cannibalise existing content as I go. --Philcha (talk) 14:09, 9 March 2009 (UTC)

Why is “DOS” being used to refer only (or primarily) to MS-DOS and related systems?

  The term “DOS” was around long before the IBM-PC, to refer to the disk-operating systems of a number of unrelated (to each other or to the IBM-PC) computer platforms.  I think it is incorrect for an article on “DOS” to refer only or primarily to those related variations of one such system developed for the IBM-PC, as if any of them have any more claim on the term than the DOSes that were around long before for such systems as the Apple ][, the TRS-80, and so on. — Bob Blaylock (talk) 08:21, 11 May 2010 (UTC)

A really good question. Many years ago (in the 80s), there was a lot of DOSes for a lot of 8-bit microcomputers. But the only that is remembered today is MS-DOS. I think this is wrong too. DOS is just Disk Operating System and not only an operating system made by Microsoft. So, I translated the old article about Disk Operating System (it don't exist anymore) from English to Portuguese and to Catalan. Today, the article exists only in three languages (aside that two, in French - but isn't a translation from the English original). - Al Lemos (talk) 12:27, 11 May 2010 (UTC)

王敏 —Preceding unsigned comment added by 123.80.123.239 (talk) 10:04, 12 June 2010 (UTC)

Because the young editors don't remember the days when disks were additional equipment that most systems didn't have. Heck, for years disks -- by which is meant floppy disks -- didn't exist. There were also Drum Operating Systems, and Tape Operating Systems, and then Rigid Disks, and Flex Disks, and Removable Disks, and ... and all manner of other ways to mount your operating systems. Just ignorance. There's not much in common between AmigaDOS and MS-DOS other than those three letters in a row. htom (talk) 17:35, 14 February 2011 (UTC)

DOS 7.1 (Unofficial Release)

Hi,

I think you should also add some information about DOS 7.1, because it became quite popular. It's used from the boot (as a real DOS), and includes some improvements for DOS. The official site of DOS 7.1 is no longer exists, but it spread on the Internet and can be downloaded from many other websites.

Galzigler (talk) 18:08, 4 August 2011 (UTC)

"In spite of the common usage, none of these systems were simply named "DOS" (a name given only to an unrelated IBM mainframe operating system in the 1960s). A number of unrelated, non-x86 microcomputer disk operating systems had "DOS" in their name, and are often referred to simply as "DOS" when discussing machines that use them (e.g. AmigaDOS, AMSDOS, ANDOS, Apple DOS, Atari DOS, Commodore DOS, CSI-DOS, ProDOS, and TRS-DOS). While providing many of the same operating system functions for their respective computer systems, programs running under any one of these operating systems would not run under others." To which systems the "any of these operating systems" does refer to ? x86 microcomputer disk operating systems OR AmigaDOS, AMSDOS, ANDOS, Apple DOS, Atari DOS, Commodore DOS, CSI-DOS, ProDOS, and TRS-DOS as well ? Where x86 microcomputer disk operating systems' software compatible ? I cannnot guess that from the article. Tom. — Preceding unsigned comment added by 91.207.68.2 (talk) 23:38, 16 December 2011 (UTC)

The DOS comingled into Windows 9x carries the message Microsoft MS-DOS Version 7 (or 8). The version of MS-DOS from the mentioned site is pretty much a utility package that is superimposed onto MS-DOS 7. MS-DOS 7 and 8 do boot, but pass the boot onto Windows 9x. PC-DOS 7.1 is basically PC-DOS 7.0 with fat32 support, and a small number of utilities of interest to system builders. Wendy.krieger (talk) 09:16, 21 April 2012 (UTC)

Design - Hardware Abstraction Layer - Pixel Graphics

Not sure if this would fit here, but all DOS compatible graphic programs (eg SuperCalc, Turbo Pascal, Harvard Graphics) used Virtualised/abstracted hardware-independent graphics.

In contrast, memory mapped graphics was used by programs written specifically for 100% PC compatibles (eg the PC version of Turbo Pascal).

All DOS machines had virtualised/abstracted graphics at the BIOS level, INT 10/AH=0CDh (read pixel), INT 10/AH=0Ch (write pixel). Virtualised graphics ran a lot slower, but on the other hand, was often much higher resolution than IBM PC graphics. IBM had very poor graphics capability, and a lot of the DOS compatible machines, which by definition had different hardware, often had different hardware precisely so that they could offer better graphics.

Pixel graphics reference: http://www.ctyme.com/intr/rb-0104.htm — Preceding unsigned comment added by 120.148.48.76 (talk) 08:45, 3 March 2012 (UTC)

I'm not sure about what's your point here. Most of the more sophisticated DOS programs could be configured to either use the System BIOS calls for video output or directly work on the hardware (if they provided "drivers" for the various graphics card standards available at the time). This holds true for both text and graphics modes, and is IMHO sufficiently described with phrases such as "bypassing the BIOS".

The point, that the BIOS (in general, not only for video) is a form of hardware abstraction layer is nothing new at all, this was a concept invented by Gary Kildall in the 1970s when he developed CP/M, a DOS pre-decessor long before the term "HAL" was coined with Windows NT.

The IBM PC BIOS INT 10h routines do not provide virtualization, though. If graphics mode higher than those available natively on a machine were offered, this was based on a software emulation inside the corresponding application. The BIOS had nothing to do with it.

By the way, the Computer Tyme reference you gave is actually an online version of Ralf Brown's Interrupt List. --Matthiaspaul (talk) 13:03, 3 March 2012 (UTC)

It's to do with MS-DOS compatable vs IBM compatable, an issue until AMI et al cracked the IBM Bios. Wendy.krieger (talk) 11:46, 11 May 2012 (UTC)

Rewrite

I've rewritten 'Limitations' and 'Multitasking' because what was written there was just plain wrong, misses more than it mentions, or not a DOS issue.

DOS, since version 2, was always a pre-emptive multitasker. That's what makes TSRs work in part. There's more to come, for example PC-DOS vs MS-DOS. It wasn't until the clone computers became IBM compatible that the MS-DOS computers (tandy etc), started to wain. Wendy.krieger (talk) 11:44, 11 May 2012 (UTC)

OK, but... where are your sources? - Al Lemos (talk) 00:07, 12 May 2012 (UTC)

The perverted gyrations "Sidekick" and company had to use to work under DOS are in no stretch of the imagination evidence of a "multitasking" DOS. Interrupt handling is not multitasking. This modern generation has no idea of just how many ways there were to hose an MS DOS machine! --Wtshymanski (talk) 01:00, 12 May 2012 (UTC)

Many of the modern generation would not understand things like Bloatware either. Windows Seven, sprawled over 5 GB of hard drive, and using 2 GB ram, is less bloatware say, Windows 3.1, at 15 MB disk and 4 MB ram. It is because (15+3)/80 is a bigger hunk of your disk than 5/1000, also, 4GB of ram now is far cheaper than something like an 8 MB stick back in 1992. The Windows 3.1 resorce kit has a little table of what files can be safely deleted to save hard disk. No such thing existed since then, when the fraction grew smaller.

It's not that DOS didn't multi-task. It provided a base for multi-tasking without much resource, but people could build multitasking, in much the same way they could build programs to join up to four fat16 disks into one, or so on. Windows 3.1 works, for example, because DOS multi-tasks: it relies on the same real-mode structures that DOS does, but hides these from the user software. Windows NT and OS/2 go through the same girations, since the trick is to create virtual 8086s in protected mode.

None the same, it is multitasking. It's just that DOS leaves it to sidekick to install the wake-up watcher, and sidekick still has to follow the various dos calls before it can start swapping into memory. Many windows programs were run under standard mode: Windows 3.0 standard mode is identical to DOSSHELL in vers 5.0.

Windows and OS/2 trap '0D'x with a plesent dialog box, or close down the machine. Wendy.krieger (talk) 08:07, 12 May 2012 (UTC)

DOS was not multi-tasking. DOS was not pre-emptive. You can hack DOS to provide primitive versions of those things, but they were not features of DOS and did not come with it. It could have been, but it was not. DOS was not re-enterent, either. Where do people learn these false facts? htom (talk) 05:02, 5 June 2012 (UTC)

DOS is not a multitasking OS

DOS has no native multitasking functionality in its API. There is no Int 21h equivalent to something like Windows CreateProcess or CreateThread functions which allows a new process or thread to be created which runs concurrently with other processes. DOS only runs one program at a time. When a program is executed via Int 21h function 4B00h that program retains control until it is terminated via Int 21h function 4Ch (normal terminate program function), Int 20h (original terminate function), Int 21h function 31h (terminate and stay resident) or Int 27h (original TSR function). Terminate and stay resident simply means the programs memory allocations aren't released. The way something like PRINT.COM (the DOS print spooler) or Borland's SideKick works is by hooking the BIOS timer interrupt (Int 08h or Int 1Ch) which occurs every 18.2065 times per second to do background processing. This is a function of the PC architecture not DOS. — Preceding unsigned comment added by 67.161.75.212 (talk) 04:37, 5 June 2012 (UTC)

Another note: the only way one could talk about true multitasking in DOS is if one is referencing the little known European MS-DOS 4.0 which was licensed to at least Siemens. This version of DOS was sone in 1986 and came between the official DOS 3.2 and 3.3 releases and should not be confused with the later PC DOS 4.0 which was done by IBM and later revved by Microsoft with MS-DOS 4.01. European MS DOS 4 did in fact support multitasking, it had extensions to the Int 21h API for this and supported device driver helper functions (DevHlp) and "NE" format executables. The DevHlp functions and NE executables were later used in OS/2 1.x.

Some info from Microsoft on this - http://blogs.msdn.com/b/larryosterman/archive/2004/03/22/94209.aspx

Again mainstream DOS (PC DOS 1.0 to 7.0, MS-DOS 1.0 to 6.22 and the MS-DOS 7.x components of Windows 9x) NEVER supported multitasking.

It's interesting that the above (who chooses to hide behind an IP number), supposes that DOS is not multitasking, and then turns around and gives examples of multi-tasking (background processing), based on fixed time slices (pre-emptive). In short allowing time-fixed background processes really is pre-emptive multi-tasking. Simply hooking an interrupt is not multi-tasking. You have to do something with the running task too. You have to wait for the INDOS semaphore to clear.

The timer interrupt is handled by the PC BIOS not by DOS. The InDOS flag only indicates that DOS is executing a system call.

Yes, DOS really does have something like a 'CreateProcess'. When a TSR runs, it stays active + returns control to DOS. In short it creates a fork in the running processes - or creates a new process. DOS, from version 2 onwards, really is a pre-emptive multitasker. You can write shells with standard DOS calls that can swap between different user applications etc, like back and forth, windows, or dosshell (windows 3.0 standard mode).

No mainstream DOS does not

• Int 21h function 4B00h - load and execute program - this loads and runs another program and control isn't returned to the caller until program termination.
• Int 21h function 4B01h - load program - this loads another program into memory but does not run it and returns its CS:IP and SS:SP
• Int 21h function 4B03h - load overlay - this loads a program overlay into memory.

The so-called European MS-DOS 4.0 does have a mutlitasking function: Int 21h function 4B04h (load and execute in the background).

Even when the machine provides the call, there are a number of other calls in the Int21, which is not a machine call, but a DOS call. Thus, DOS really is a pre-empting multi-tasking OS.

I never said Int 21h was a machine call, I said Int 08h and Int 1Ch are. Stop trying to twist what I said with your own technical inaccuracies. There is no Int 21h function which supports multitasking. I could list *every* Int 21h if you want but it would be a long list as there are functions ranging from 00h to 6Ch.

I restored what I wrote. Wendy.krieger (talk) 07:14, 5 June 2012 (UTC)

"DOS has no native multitasking functionality in its API. "

Your mistake is to equate this with having no multitasking functionality.

DOS multitasked. It didn't offer much control of this multitasking through the API, but that's not to say that DOS wasn't doing multitasking behind the scenes. It was hard to attach user processes to this, and DOS certainly didn't offer packaged API calls for doing so, but it's still wrong to stretch this as meaning "there was no multitaking". What on earth was the 18.2 timer tick doing if that wasn't multitasking? Andy Dingley (talk) 15:27, 5 June 2012 (UTC)

Your mistake is not having a good understanding what constitutes a multitasking OS. An OS like Windows, OS/2 or Linux has a built-in task scheduler which manages processes and threads and provides APIs for this. A multitasking OS will also have inter-process communications support like shared memory, named pipes and semaphores. DOS (except European MS-DOS 4.0) does not have any of this functionality.

You also don't understand the different between the PC BIOS and DOS: the timer interrupt (Int 08h / IRQ0) is a BIOS interrupt handler which is executed 18.2065 timer per second due to the programming of the 8254 timer chip. This has absolutely nothing to do with DOS, this is basically a function of PC architecture.

Please stop putting incorrect information in this article. As it stands the article is in serious need of a rewrite.

Also please read the article on Computer multitasking and also read some technical information about the PC BIOS and DOS before making any further changes to the DOS article. — Preceding unsigned comment added by 67.161.75.212 (talk) 15:53, 5 June 2012 (UTC)

Here's a LinkedIn profile of someone who worked on European MS-DOS 4 for ICL http://uk.linkedin.com/in/kevinraine

The relevant entry is at the bottom of his experience list: "Joint project with Microsoft to extend MS-DOS 4.0 to make it multi-tasking and use ICL's proprietary hardware features, involving working in Seattle for several months"

To make it multitasking, it was NOT before. Also it was not afterwards because none of these changes were carried forward into the mainstream DOS releases, they were specific to this one special release. Instead the ideas from this release were used in OS/2 1.0. — Preceding unsigned comment added by 67.161.75.212 (talk) 16:06, 5 June 2012 (UTC)

One additional thing, here is an old document on Microsoft's FTP site detailing a DOS bug in which Microsoft describes DOS as "a single-tasking environment" - ftp://ftp.microsoft.com/misc1/PEROPSYS/MSDOS/KB/Q82/2/16.TXT

It is pretty obvious that DOS is a single-tasking single-user operating system but there is your proof from Microsoft. 67.161.75.212 (talk) 21:10, 5 June 2012 (UTC)

Microsoft says things like "Windows 95 is an integrated system" and that there is no thunking down to 16-bit kernel. You can even find references to MS-DOS 5.02, and Windows 3.2 (not the chinese one). That IE is part of the OS etc. Many of these pronouncements are for commercial positions, not technical truths. As such, one should not rely so much on these statements. You can't believe their training, as i have seen of it. The training supposes that MSFT is the latest and greatest, even though they have generally been up to ten years behind the competition. It's all what we done, and compared to DOS, Windows is wonderful, etc.

That DOS runs pipes in a series is not proof of lack of multi-tasking. It's more to do with that DOS runs on limited resources, and loading several elements of the pipe at once would cause it to run out of memory. I had to do linear piping under windows nt to get around bugs in the piping.

Making it multitasking is more about making it easier to multitask. It's more about doing things like making calls available for multitasking, rather than having programs do it. DOS 2 is a major rewrite of DOS, including a directory tree and multi-tasking. Programs can run in background and wait for a variety of semaphores through interrupts. Once this happens, then they move into RTR mode, monitoring the INDOS flag, and then when the indos flag is clear, they can move in and swap memory etc to run their task. This is pretty much what happens in OS/2 or Windows, except that a different program does it.

I can't see how having a task scheduler equates to multi-tasking. It's along the lines of having fonts equates to being able to run word processors. Many of these things evolved because people (outside the vendors) wrote these things. You can have single-tasking operating systems, where you load one program, and you're in it until you unload it, and load the next. Pushing hotkeys to switch from say WP to SideKick or ScreenTheif is not much different to pushing hotkeys to switch from Word to Calendar or Paintbrush.

My point was not that dos was not multi-tasking, but that it ran in an environment where simply having several large tasks (under DOS or Windows or OS/2), was simply too much load on the system. DOS really did multi-task, it just that by the time enough memory appeared, Microsoft and IBM were pushing alternatives that did it a lot better.

The average windows 3.x user used to run two or three tasks at once, the apple macintosh was running six or seven. It's kind of like saying you're not multitasking until you have eight user processes in the task line.

Task managers could be written for DOS. MEM /P does a good job of listing running processes in DOS. You can write such things for OS/2 or NT (separate to the standard ones). The iPad was definitely a multitasking system with no user control over running tasks, until a release fixed this. Wendy.krieger (talk) 07:26, 6 June 2012 (UTC)

Would you please give it a rest already ? The fact that you do not understand that multitasking operating systems have a task scheduler and continue to incorrectly maintain that DOS is a multitasking OS makes it very clear that you do not have proper technical understanding. Nobody with any actual technical understanding would call DOS a multitasking OS. What you wrote about the MEM command also shows you simply do not know what you are talking about. Anyway please do not put this incorrect information in the DOS article again. If do you I will request moderation and quite frankly in addition to providing sourced information from Microsoft clearly stating that DOS is single-tasking, I have the background as a senior software engineer who worked on DOS and BIOS and can prove myself if I need to.

67.161.75.212 (talk) 15:08, 6 June 2012 (UTC)

"I have the background as a senior software engineer who worked on DOS and BIOS and can prove myself if I need to."

No you don't, you're just an IP address. I think you're a very small Perl script and no more than that. You don't get to claim personal reputation as WP:RS on Wikipedia, and certainly not if you don't even use an identifiable account to edit from.

If we're going to play "I invented bigger and better wheels than you did", then back in the late '80s I was writing real-time machine control code, and running it on DOS PCs (mostly 286 ATs) because they were cheap. Yes, multi-tasking under DOS sucked, and real-time sucked massively (Oh for QNX, when I could get it). However within the bounds of "sucky OS that weren't at all multitasking" and "sucky OS that could just about lay claim to multitasking at some theoretically arguable level, if not anything actually useful" then DOS came down somewhat remarkably on the side of multitasking.

Your editing behaviour and attacks on other editors is also way into the trollish and boorish. Please do "request moderation", but see WP:BOOMERANG beforehand. Andy Dingley (talk) 15:27, 6 June 2012 (UTC)

Now I am on an account, happy now ??. A Perl script ?? Seriously, I've written technical information about DOS and PC BIOS and I've provided links to Microsoft which you and the other editor have chosen to ignore so how could a script possibly do this ? Last time I checked AI hasn't reached such an advanced level. Anyway I've been a programmer for 25+ years and I have never heard anyone describe DOS as a multitasking OS until now because it is not.

Also if you really want to play the experience game then you're playing with the wrong person. I was the lead developer of PC DOS 7.0 at IBM back in the 1990s. I have also worked as a PC BIOS engineer. Anyway I saw blatant technical inaccuracies in an article I know something about and decided to correct them.

Asmpgmr (talk) 16:08, 6 June 2012 (UTC)

Thanks a lot for using an account. It goes a long way towards encouraging collaborative working.

I've forgotten more abut DOS than I have any substantial interest in remembering. When it comes to the details here, I'm sure you will be far more familiar with them than I am now, or even than I was then (and as it happens, I was a trainer for the early MCP program too).

We seem to have two points of disagreement. The first of these is what "multitasking" is, more than what DOS did. We have no dispute over precisely what DOS did (I simply can't remember the details), merely whether that entitles it to be counted as multitasking or not. IMHO, multitasking is based on having some minimal ability to schedule more than one thing at once. This is a very low bar. It does not require the API to support multitasking (multitasking entirely internal to an OS is still multitasking). It does not require a structured representation of a "process" or a "thread", merely that more than one "thing" goes one simultaneously. An OS that's restrictive in its multitasking and that makes almost none of the subtleties or control features available to application code might be restrictive, but it's still multitasking. It's a good question as to whether pre-emptive scheduling is required, but then the 18.2 tick was pre-emptive anyway, so that is moot.

I would hope that you might agree this much. If you do, then perhaps we can go forwards by you, with your detailed knowledge, expanding the description of just what was available, and how this was so very limited (which we certainly agree upon).

Secondly, an editing style of removing large blocks with a comment along the lines of "this is all wrong" is disruptive and unlikely to encourage cooperation, no matter what the details behind it. You did this for the partition issue, on the grounds that this was a BIOS matter, thus had nothing to do with DOS. Now without disagreeing over the BIOS aspect (and similarly the timer tick), it's far from the case that this makes it an irrelevance to the DOS layer above this. By all means clarify that this service is implemented through BIOS services beneath, but the point is that as far as the application coder or the eventual user sees, DOS appears to be offering features based on it. We might even reduce this section dramatically to little more than a forward reference to a BIOS article, but removing it wholesale like this is just bad encyclopedia writing technique, in terms of the article it delivers to the readers, according to their likely expectations of what the article will answer. Andy Dingley (talk) 17:23, 6 June 2012 (UTC)

Just in case this doc which was written by Microsoft and on Microsoft's FTP site isn't enough - ftp://ftp.microsoft.com/misc1/PEROPSYS/MSDOS/KB/Q82/2/16.TXT

There's this again from a Microsoft site - http://technet.microsoft.com/en-us/library/cc767884.aspx Scroll down to the "The Structure Of A Virtual DOS Machine (VDM)" section, a few paragraphs down you will find the sentence "Each MS-DOS application runs in its own VDM to mimic the single-tasking nature of native MS-DOS."

Here's one from IBM - http://www.redbooks.ibm.com/abstracts/gg244459.html Quote - "IBM PC DOS 7 has been designed for all types of users who need an efficient single tasking personal computer operating system"

I have provided links verifying that DOS is a single tasking OS from the two makers of DOS. Microsoft considers DOS to be single tasking and so does IBM. Whether you believe me or not I can guarantee you that no one at IBM considered DOS to be a multitasking OS. I was the lead on PC DOS 7.0 and I absolutely do not. Once again a multitasking OS has a task scheduler and provides functions for task management and inter-process communications. Other than the specific release of European MS-DOS 4, DOS has none of this. Also none of this functionality was carried over to later releases of mainstream DOS (it definitely was not in the source code that IBM had). The European MS-DOS 4 functionality was carried over to OS/2 1.0.

There is a difference between using the services provided by an operating system (in this case DOS) and using the services of the underlying architecture (PC BIOS and direct hardware access). Yes there were DOS programs like DoubleDOS, TopView and DesqView which allowed more than one well-behaved DOS program to run at once but they did not use DOS services to accomplish this because there were none to use. Saying that DOS is a multitasking OS because these sort of programs existed is like saying that DOS is a GUI-based OS because Windows 1.x - 3.x existed.

67.161.75.212 (talk) 17:43, 6 June 2012 (UTC)

I had forgot to login when I wrote the above. Asmpgmr (talk) 17:46, 6 June 2012 (UTC)

In the world of references, these just don't cut it.

• [2] Way below WP:RS. This is a trivial aside, not some ex cathedra statement from M$oft.
• [3] That's a ref about WinNT, not about DOS. It's not really trying to present DOS in its most sophisticated light.
• [4] Yes, DOS is a great OS for users who need an efficient (ie runs in a small footprint) single tasking OS. That's far from stating that it doesn't do multitasking, or a claim that DOS' processes are as fragmentary as Plan 9's.

No-one is claiming that DOS was some great multitasking OS. It offered almost no features for the multitasking of applications. It was certainly less capable than its competitor CP/M-86 (whether as the earlier CCP/M or as the eventual DR-DOS). However compared to CP/M, it was more advanced and did at least have the internal pre-emptive scheduler based on the timer tick. That's enough, little though it is, to count as "multitasking" within a taxonomy of OS capabilities. Andy Dingley (talk) 18:00, 6 June 2012 (UTC)

For crying out loud, I have provided references and you are choosing to ignore them simply because they do not support your incorrect position which is based upon a lack of technical understanding. Saying that DOS was less capable than CP/M is another patently ridiculous statement demonstrating even less technical understanding of DOS. Again I was the lead on PC DOS 7, there is no task scheduler in DOS, none, nada, zip. There are only program services to load a program, transfer control to it, terminate a program and terminate and stay resident. TSR means basically what is says: the program terminates running control to the caller but remains in memory. What a resident program does depends on the program. Once again the timer interrupt (Int 08h / IRQ0) is a BIOS function NOT a DOS function. Would you please do some research on this stuff before continuing to make these incorrect assertions.

Also it's Microsoft, saying "M$oft" is a bit immature and silly. — Preceding unsigned comment added by Asmpgmr (talk • contribs) 18:16, 6 June 2012 (UTC)

List of every Int 21h function in DOS 5+

Here is a quick list of every Int 21h function in DOS 5+ 21 00 Program terminate 21 01 Char input 21 02 Char output 21 03 Aux input 21 04 Aux output 21 05 Printer output 21 06 Direct console I/O 21 07 Direct console input 21 08 Console input 21 09 Display string 21 0A Buffered keyboard input 21 0B Get input status 21 0C Flush buffer and input 21 0D Disk reset 21 0E Set default drive 21 0F Open FCB 21 10 Close FCB 21 11 Find first FCB 21 12 Find next FCB 21 13 Delete FCB 21 14 Sequential read 21 15 Sequential write 21 16 Create FCB 21 17 Rename FCB 21 18 Unused 21 19 Get default drive 21 1A Set DTA 21 1B Get default alloc info 21 1C Get alloc info 21 1D Unused 21 1E Unused 21 1F Get default DPB 21 20 Unused 21 21 Random read 21 22 Random write 21 23 Get file size in recs 21 24 Set random record 21 25 Set vector 21 26 Create PSP 21 27 Random block read 21 28 Random block write 21 29 Parse filename 21 2A Get date 21 2B Set date 21 2C Get time 21 2D Set time 21 2E Set verify state 21 2F Get DTA 21 30 Get DOS version 21 31 TSR 21 32 Get DPB 21 33 Get/set BREAK 21 34 Get InDOS flag 21 35 Get vector 21 36 Get free disk space 21 37 Get/set switch character 21 38 Get/set country info 21 39 Create subdirectory 21 3A Remove directory 21 3B Change directory 21 3C Create file 21 3D Open file 21 3E Close file 21 3F Read file 21 40 Write file 21 41 Delete file 21 42 Move file pointer 21 43 Get/set file attributes 21 44 I/O control for devices 21 45 Duplicate file handle 21 46 Redirect file handle 21 47 Get current directory 21 48 Allocate memory 21 49 Release memory 21 4A Reallocate memory 21 4B Load/exec program 21 4C Terminate process 21 4D Get return code 21 4E Find first file 21 4F Find next file 21 50 Set PSP 21 51 Get PSP 21 52 Get DOS pointers 21 53 Create DPB 21 54 Get verify state 21 55 Create subprocess PSP 21 56 Rename file 21 57 Get/set file date/time 21 58 Get/set alloc strategy 21 59 Get extended error info 21 5A Create unique file 21 5B Create new file 21 5C Lock/unlock file 21 5D File sharing 21 5E Network 21 5F Redirection 21 60 Qualify filename 21 61 Unused 21 62 Get PSP 21 63 Get lead byte table pointer 21 64 Set wait for event flag 21 65 Get extended country info 21 66 Get/set code page 21 67 Set handle count 21 68 Commit file 21 69 Get/set media id 21 6A Commit file 21 6B Unused 21 6C Extended open/create

Not one of them deal with task scheduling or inter-process communications because DOS DOES NOT HAVE THIS SUPPORT. I can list all of the various subfunctions if you like. Asmpgmr (talk) 18:35, 6 June 2012 (UTC)

"Saying that DOS was less capable than CP/M "

Fortunately that's pretty much the opposite of what I wrote. CP/M-86 ~= CP/M. Andy Dingley (talk) 18:53, 6 June 2012 (UTC)

Not that it is relevant here but CP/M-86 was CP/M ported to the 8086/8088 by Digital Research. Even the Wikipedia article says this and that is correct.

Asmpgmr (talk) 19:09, 6 June 2012 (UTC)

CP/M-86 was CP/M ported to the 8086/8088 No. CP/M developed into MP/M, which developed into CCP/M (Concurrent CP/M, bit of a hint there) and that was ported as CP/M-86. Andy Dingley (talk) 20:28, 6 June 2012 (UTC)

Not true, not relevant. MP/M (the mulituser OS) was ported to MP/M-86 not CP/M-86. Are you going to stop making incorrect statements ? — Preceding unsigned comment added by Asmpgmr (talk • contribs) 20:41, 6 June 2012 (UTC)

While not actually relevant in regard to the topic of the discussion here, for the sake of historical correctness, MP/M certainly derived from CP/M, and while MP/M was ported to 8086 processors as MP/M-86, CP/M was ported to 8086 processors as CP/M-86. Concurrent CP/M-86 (CCP/M-86 with BDOS 3.0) emerged from MP/M-86 and CP/M-86 technologies. There also was a Concurrent CP/M 8-16 dual processor version to run 8080/Z80 and 8086 programs at the same time on the same machine, but out of my memory I am not aware of any Concurrent CP/M-80 version. With the integration of the PC DOS emulator (PCMODE) Concurrent CP/M-86 was renamed Concurrent DOS (BDOS 3.1), which could run 8086 CP/M and MS-DOS compatible programs at the same time. Over the years it was available in various flavours for the real mode 8086 (Concurrent [PC] DOS 86 family with BDOS 3.x) as well the protected mode 80286 (Concurrent DOS 286 family) and 80386 processors (Concurrent DOS 386 family). Concurrent DOS 286 later became FlexOS [286], and Concurrent DOS 386 became Multiuser DOS (BDOS 6.x), which evolved into REAL/32 (BDOS 7.x). Other derivations of Concurrent DOS included DOS Plus (BDOS 4.x and 5.x) and the huge DR DOS family of operating systems (BDOS 6.x and 7.x), which for a long time co-evolved with Concurrent DOS 386 and Multiuser DOS before they went into different directions and DR DOS had its own native pre-emptive multi-tasking support ("Vladivar") added with DR DOS "Panther", "StarTrek" and Novell DOS. --Matthiaspaul (talk) 18:02, 8 June 2012 (UTC)

Also here is a PhoenixBIOS Programmer's Guide - http://www.msc-ge.com/download/pc-system/ipc-produkte/isa96at96/BIOS%20Programmer%27s%20Guide%20v10.pdf

Look at the Interrupt Vectors section near the end of the guide and you will find "08 IRQ0 - System Timer Interrupt" - that is part of the BIOS not DOS. Asmpgmr (talk) 19:00, 6 June 2012 (UTC)

So what? The fact (which isn't disputed) that the BIOS provides some service doesn't mean that DOS ignored it. This is just the usual layering of any complicated piece of software. Maybe you as a DOS developer saw a strong separation between the two, but application developers working above both of these merely saw services that were available and cared much less about how they were provided. The question is, Did machines running DOS have pre-emptive scheduling involved? Andy Dingley (talk) 19:10, 6 June 2012 (UTC)

So what ? The PC BIOS is not DOS, that's what. When Windows XP first boots up NTLDR issues BIOS calls. When Linux on a PC first boots up it issues BIOS calls as well. The PC BIOS is an aspect of PC architecture, DOS is an operating system design for PC architecture. This is a distinction you don't seem to understand. The second part of what you said is very telling. Just because you and other application programmers don't understand this distinction is irrelevant to the actual facts. I will say this yet again: other than the specific release of European MS-DOS 4, DOS does not have a task scheduler or any sort of preemptive mutlitasking support in its kernel. This is an undeniable fact. It is absolutely pointless for you to keep arguing about this. Like it or not you are wrong unless you can provide source code or a verifiable code disassembly of the DOS kernel in any version of MS-DOS (other than European MS-DOS 4) or PC DOS proving otherwise which you can not since nothing of the sort exists. DOS is a single-tasking single-user operating system. Please end this. Asmpgmr (talk) 19:26, 6 June 2012 (UTC)

3rd opinion

Short answer: MS-DOS can not be called a multi-tasking operating system for any reasonable definition of "multi-tasking". Many books will give it as a prime example of a single-tasking operating system. Under a basic MS-DOS installation - that is without running DESQview, DOSSHELL or Windows - you will find it impossible to simultaneous run, say, XCOPY and FORMAT or WordPerfect and Lotus 1-2-3. I would even go so far as to that that any definition of multi-tasking that would include MS-DOS would included all operating systems, making it a fairly useless definition indeed.

Long answer: Clearly you can bend the definition of multi-tasking far enough so MS-DOS will fit under it. MS-DOS has some limited support to keep multiple processes in memory without them overwriting each other. This is important for device drivers and e.g. starting additional command shells from a word processor. However, MS-DOS's API did not offer support for any kind of pre-emptive or co-operative multi-tasking. Some applications, mostly so-called terminate-and-stay-resident utilities, made a very limited form of multitasking - but not time-sharing - possible by hooking directly into the interrupt vector table. However, that are effectively bypassing the operating system in doing so. Much of MS-DOS's kernel code is not reentrant, either, making these TSRs second-class citizens. MS-DOS 5 introduced a very limited form of "task switching" that was used by DOSSHELL. None of these features are commonly understood to fall under the definition of multi-tasking, certainly not under an unqualified use of this term, which generally implies background processes are allocated CPU time by a scheduler in the kernel (MS-DOS does not have a scheduler). —Ruud 19:04, 6 June 2012 (UTC)

I largely agree with what you said but I would say that DOSSHELL is just a DOS application program which came bundled with DOS. DOSSHELL did task switching itself but that support was not part of the DOS kernel. Asmpgmr (talk) 19:15, 6 June 2012 (UTC)

Skimming over my DOS programmer's reference manual it's not completely obvious whether the task switching API is implemented in IO.SYS/MSDOS.SYS or only available if DOSSHELL is loaded (I indeed suspect the latter). It does say "Task-swtiching is a feature implemented in version 5.0. [...] It is not a real multitasking-system." —Ruud 19:21, 6 June 2012 (UTC)

I've seen the source code, there's no such code in the DOS kernel. But don't take my word for it, have a look at Ralf Brown's Interrupt List - http://www.cs.cmu.edu/~ralf/files.html Asmpgmr (talk) 19:28, 6 June 2012 (UTC)

DOSSHELL API is at Int 2Fh function 4A05h and Int 2Fh function 4Bh. Asmpgmr (talk) 19:31, 6 June 2012 (UTC)

In your long answer section you should specify which interrupts that these sorts of TSRs hooked. Generally they hooked one of the BIOS timer interrupts, either Int 08h (IRQ0) or Int 1Ch which is called from Int 08h. If they used popup functions like Borland's SideKick did then they would hook the BIOS keyboard interrupt Int 09h (IRQ1). 20:12, 6 June 2012 (UTC) — Preceding unsigned comment added by Asmpgmr (talk • contribs)

I don't think that's very relevant. Device drivers would often hook into the IRQ handlers, a print spooler into the BIOS's LPT services, a virus scanner into 21h to intercept file system operations, and some provided services under e.g. 2Fh or 67h etc. —Ruud 20:37, 6 June 2012 (UTC)

What seems to make the discussion difficult is that the definition of DOS as operating system is a bit fuzzy. In my view DOS itself was never a multitasking OS because it was not even an OS. It was just one of many ways programs could use to access hardware facilities if they wanted. Programs could also choose to completely bypass DOS and even BIOS wherever they wanted. Multitasking was possible with - or rather in spite of - DOS but that does not mean DOS was a multitasking OS. However as every program was free to bypass DOS and BIOS on every occasion this also means that any real multitasking was prone to disaster if two multitasking programs choose to access the hardware directly at the same time. Richiez (talk) 23:03, 6 June 2012 (UTC)

Well that's certainly not fair. DOS is a very simple operating system by today's standards but it is most definitely an operating system. It provides file management, memory management, device management, program loading and termination services and an API for programs to use to access these facilities. 67.161.75.212 (talk) 23:10, 6 June 2012 (UTC)

It may not be fair but at the time it was sold it was a common statement among those who were used to using (and writing) mainframe operating systems. It provided a single (poor) file system, unprotected memory allocation, unlocked devices, ... it existed in the gray area between a system monitor and an operating system. It could have been a hard real-time multi-user multitasking operating system by version 6 on the 486 family but making it so would have broken a Himalayan mountain range of backward compatibility and so it didn't become that. htom (talk) 03:51, 7 June 2012 (UTC)

Re "not fair": I did not say it was all the fault of DOS. Programmers choose to program hardware directly instead of using DOS, that was part of the DOS culture. For this reason manufacturers advertised "100% hw compatibility" meaning you could bit bang bare hardware and still get same results as on a genuine IBM PC. As a result there was very little room for any OS improvement - this changed only after CPU virtualization techniques became widely available with the 386 line. But other OSes with similarly restricted hw did make it better. AmigaOS did have multitasking designed into it as an integral feature and as a result programmers "played the game" and programmed from the beginning so that it actually mostly worked. Richiez (talk) 18:59, 7 June 2012 (UTC)

I really don't understand what these people are demanding of an OS or multitasking. I have used far more primitive systems than DOS. I have even written to the bare metal. Something like the Atari 2600 or Tandy 100 is a single tasking system. In the former, you select the game you want to run, and stick it in the slot, and boot it. The game runs. On the tandy 100, you select the program or file from a menu of 32 options, and that's it. It runs, and you exit from it for the next task.

DOS multitasks. You can extend the servicability of the system, by loading drivers. You can, for example, load a stack driver in the style of VMS (stackmgr.com from Quercus). You can load a number of user tasks, all be it small ones, that will patiently wait in background until called. You can load programs that soak spare cycles to run things like Messerine primes or Seti. You can load a program to throw the system into idle (dosidle.com). None of these are options on the Atari 2600 or the Tandy 100.

Where multitasking comes 'undone', is not that it's absent, but the working desktop (memory etc) is tiny. You simply can't have too many books open on a table that's six inches square. Windows 3.0 became popular not because it multi-tasks, but because it overcomes the limitations of memory.

DOS is seen as single-tasking, not because it is incapable of multitasking, but because of memory issues. It's a great single tasker because it can multitasks, and every program does not need its own mouse driver, its own cdrom driver, file system driver, extended memory driver. Later operating systems extended the range of things programs don't need to provide: fonts, printer drivers, common dialogs, common user access, 'exit to dos' functions, clipboards. But that DOS does not have these additional services, does not mean that DOS.

And, thus, because DOS can run base and additional programs side by side, on a ready to run basis, DOS really and truely is a multitasking operating system, at least from version 2.0 onwards.

I don't know where these people get the fancy idea that hooking an interrupt equates to multitasking, and if that interrupt is in the BIOS code, it's not DOS. It's a semaphore. It's an indication that something is about to happen or has happened. You got to do something with the running code. That's what happens when you switch process. You have to wait for DOS to come to a point where the task can be stopped and a new task started. These are the DOS multitasking calls. It's hardly DosSwapTask, but the stuff is there, in DOS 2.0 onwards. Borland wrote Sidekick, based on what they found in PRINT.COM. You got to do all the bits yourself, because there is no DOS code string the bits together. But you can do it. DOS does provide code what you need to multitask. I've written programs on the Tandy 100 that expose APIs to new code.

In essence, The CALC.BA i wrote provided all sorts of system calls, so that the program only had to make things like place numbers in registers, and on exit, the main switch would act accordingly. The COS: routine did not have to expand numbers or error messages. The display manager did this. It did not have to fiddle the stack, because the core of the program did this. It just had to set variables like answer-good and stack=fall, to achieve the desired result. Wendy.krieger (talk) 08:38, 7 June 2012 (UTC)

Sorry, but none of the example you gave fall under what is commonly called "multi-tasking" (in particular, it's neither preemptive nor cooperative multitasking). TSRs and device drivers had to go to great lengths to program around MS-DOS. They could fake something that looked like multi-tasking despite MS-DOS, not because of it. They do little that could not have been done on say a Commodore 64. Regular applications like WordPerfect and Lotus cannot be run simultaneously, like they could under Windows or UNIX. (And starting Lotus from WordPerfect under DOS is not mulit-tasking, as you had to completely exit Lotus before you could return to WordPerfect again.) All the multitasking-like behaviour you could get under MS-DOS was explicitly implemented in the applications themselves, not in the operating system, as it was in Windows or UNIX. It's this difference between DOS and Windows or UNIX that the adjective "multi-tasking" describes.

But let's try to find some sources instead. I have a DOS programmer's reference manual that states it's not a multi-tasking operating system and have found an old copy of InfoWorld that states it's a single-tasking operating system. —Ruud 09:48, 7 June 2012 (UTC)

A good deal of what you need to make TSRs tick is undocumented, but guessed at by disecting PRINT.COM. You have to wrangle with a book of the nature of "Undocumented DOS" by Andrew Schulman et al. Because of this, there is a lot of 'all-elbows' programs that gave TSRs a bad name.

DOS does multitask, but provides no swapping API. So a program that wants to multitask, has to do this. 1. Set a semaphore. This is usually hooking a hardware or software interrupt. 2. Stop the foreground task safely, and park its registers and data. 3. Do what the program is meant to do. 4. Restore the processes and data. 5. Restart the process again. The hardware interrupt stuff may be bios, but the rest of the process is pure DOS.

Most programs are relatively large, and are written on the assumption that it's the only process running. WP, for example, busy-waits the keyboard (eg 10 I$=INKEY$(): IF I$="" GOTO 10), for example. DOS is not intended to run multiple programs of this nature. No O/S is.

If a program does not know how to move in and out of background, it isn't going to do it of its own accord. Large programs, or programs that uses lots of memory, don't figure themselves swapping in and out of memory.

It is possible to write a shell, which knows how to move itself in and out of memory in the manner above, that presents in its various instances, a command prompt that can run a different foreground process. This is how things like task-swapping (Windows standard mode), or parallel VMMs (Windows enhanced mode = protected mode) works. If there is memory, then it is possible for the task swapper to swap in and out different running foreground tasks.

DOS does not supply the necessary means for task-swapping, but the API to launch tasks that are pre-emptively multitasked in DOS exists, and DOS uses it to pre-emptively multitask some tasks. DOS does not manage these. These load and unload based on semaphores they monitor, and swap in and out on their own steam.

And therein lies the difference. Because DOS does not provide virtual machines on its own accord, it can not run several foreground tasks. But it will pre-emptiviely multitask background tasks, some of which can swap between different foreground tasks. And it is because of this, that Windows 3.x and 9x can multitask DOS and Windows machines. Wendy.krieger (talk) 10:45, 7 June 2012 (UTC)

You say "So a program that wants to multitask, has to do this." It is exactly this fact - that the program has to do this, as opposed to the operating system - that makes MS-DOS a single-tasked operating system. You cannot multi-task WordPerfect and Lotus. MS-DOS doesn't contain a scheduler that allows a background process to continue a computation (e.g. recalculating a spreadsheet), while a a foreground process (e.g. XCOPY) is blocked on disk I/O. These are essential for an operating system to be called "mutli-tasked".

DOS does not "pre-emptiviely multitask background tasks". TSRs can hook onto hardware interrupts, but they are complete bypassing DOS in doing so, no DOS code has to run for this to work. —Ruud 11:25, 7 June 2012 (UTC)

Wendy, you and Andy simply do not understand and/or refuse to accept the fact that DOS does not have a task scheduler in its kernel so it is not a multitasking OS. Windows 3.x and 9x use virtual 8086 mode to create virtual DOS machines (VDMs), this is a feature of the 80386 and later processors. You guys really have no idea what you are talking about. Asmpgmr (talk) 15:01, 7 June 2012 (UTC)

I've written programs on the Tandy 100 that expose APIs to new code.

Oh really Wendy ? Do you mean this - http://oldcomputers.net/trs100.html

This is not a PC compatible machine and it doesn't even use an x86 processor it uses a 80C85 so it couldn't possibly run DOS. You have just proven (actually proven again) that you do not have any idea what you are talking about. CALC.BA ? Is that BASIC ? A BASIC programmer is trying to talk about what does and doesn't multitask ? Seriously ? Asmpgmr (talk) 15:44, 7 June 2012 (UTC)

Yes, that one. Really, i never pretended it could run DOS. What i said is that it (and the atari 2600, which entirely escaped mention), were load and run machines, and real examples of 'single tasking'. CALC.BA is a program i wrote for BASIC. Well, even calculators have operating systems, and this is a very good modular emulation of an RPN calculator. It is a calcualtor O/S. You could add functions by adding a command in the file directory, and adding code where the directory points to.

BASIC is simply a programing language. It's main interest is, apart from the fact that that the Tandy 100 only offers it, is that you can use a text file with Knuth-style comments, and when loaded by basic, these comments disappear, and the lines are sorted. So you can write your code out to do something fancy, like have a FAT for the commands, and a pointer in the FAT for the actual code. Using EAs in the FAT, you can then do something like use the same code in different ways.

None of these operating systems MULTITASK. An RPN calculator can be written as a kernel, which manages the stack pointers, a console manager, a menu manager (ie a directory), and a mob of commands that the directory addresses. The kernel can be wrangled down to ten lines of BASIC.

Multitasking is a user experience. DOS does permit several active peices of code to be active at the same time, with user control to switch between these processes. DOS does not control the switching between these, so you can't really load more than one program that can't hide in background. I suppose that on the same argument, you would suggest that because a program calls COMMCTRL to save a file, that somehow it becomes Windows itself.

When for example, you load something like Sidekick, you don't really worry about the magic behind it, but that this happens in DOS. That DOS can load a number of such things means that the user experience of using Sidekick, screentheif and wp, is little different to using lotus organiser, snaggit, and amipro under windows. Each does its thing on the uer's call and beckon, and thus really is multitasking.

And there-in lies the difference: The user experience in multitasking in DOS is limited by other resources, and in true eighties fashion, nothing works with nothing. By the time the nineties came around, there were replacements for DOS in the works which makes it easier to create programs that multitask, and an operating system that does the multitask management. DOS had unmanaged multitasking, not no multitasking. Wendy.krieger (talk) 07:39, 8 June 2012 (UTC)

• Well, even calculators have operating systems
• Multitasking is a user experience
• you don't really worry about the magic behind it
• DOS had unmanaged multitasking

You clearly have no idea what you are talking about from a technical perspective. These are truly some of the most ludicrous statements I have ever heard in my 25+ years as a programmer.

If you want to continue to make the ludicrous argument that DOS is a multitasking operating system then you need to prove it by showing with one of the following:

• list of alleged DOS Int 21h API function(s) which support multitasking.
• disassembly of the alleged multitasking support code in the DOS kernel of any version of DOS other European MS-DOS 4 which is known to actually support multitasking.
• location of the alleged multitasking code in the DOS kernel (MSDOS.SYS or IBMDOS.COM) which can be independently verified by someone who is familiar with DOS internals and x86 assembly language.

Also explain why Microsoft and IBM, the developers of DOS both explicitly say that DOS is a single-tasking operating system. Additionally explain how someone like myself who was the lead developer on PC DOS 7.0 and saw all of the DOS source code somehow missed something as significant as a task scheduler in the code.

Enough is enough, stop arguing about this. You clearly do not have the proper technical understanding regarding DOS, operating systems in general or multitasking. Asmpgmr (talk) 15:18, 8 June 2012 (UTC)

Multi-tasking is something done by an operating system to (usually) user code. The user code has no control of the process of being multi-tasked (well, it can fork or exit, but that's all, at least in most such systems.) The process of being multi-tasked is invisible (or should be invisible, thanks, Intel) to the user programs. In the DOS environment, the user code was in charge of the hardware. In a multi-tasking system, the operating system is in charge of the hardware. That's why DOS never became a multi-tasker. htom (talk) 21:13, 7 June 2012 (UTC)

DOS is not a multitasking. If a TSR can multitask, that TSR is a multitasker, In the DOS environment the TSR code has to bendover backwards to prevent the whole environment from collapsing or exploding. If an OS handles the multitasking then a "user program" doesn't need to know about if it is safe to do some function, it doesn't have to directly access hardware features [ clock tick ] to run. If the OS lacks in handling all multitasking aspects [ solving concurrency issues ] and the user program needs to take care of it then the OS is NOT multitasking. If a user can do multiple things by selecting one active thing at a time then the user is the multitasker. On any decent multitasking OS you will see that user program actually don't care about anything like if it is safe to write a diskblock, or how to tap into a timer interrupt etc. The OS takes care of this, nothing new systems did this allready in the 1960's so multitasking isn't something new in 1980 + something when dos started. — Preceding unsigned comment added by 212.121.110.171 (talk) 15:52, 29 August 2012 (UTC)

BIOS Issues

While the BIOS issue is not part of DOS by itself, it is part of the DOS experience, and specifically, the main one that users would have to face.

A typical computer in the 1980's would run its whole life with the original OEM system on it. Whatever limitations might come from the file systems, the memory allocation scheme, and so forth, really did not have much effect on the user.

Instead, what you had to look out for was that the game you buy was for IBM or TANDY or something else. This is because DOS provides no graphic API, and that these were scheduled by direct calls to the BIOS. Because different vendors had different ways of getting the same effect, you had to look on the box for the right computer type, just as now you have to look for XBOX or Windows, even though these both run varieties of Windows.

So, it really was up to companies like IBM and TANDY to sponsor companies like SIERRA to make games for their particular hardware. A greater variety of applications meant that the hardware becomes more desirable, even if it were expensive.

Even though it's a BIOS issue, it is still a DOS issue, since a uniform DOS drives a uniform BIOS.

The thing regarding DR-DOS 5, is that it was the first retail upgrade. You can install it over something like MS-DOS 3.3 or whatever, and it provided better memory management, etc than the earlier DOS. Larger programs could be loaded etc. Even microsoft admitted that the 'best dos out there' was DR-DOS 5.

I restored the BIOS section accordingly. Wendy.krieger (talk) 08:03, 7 June 2012 (UTC)

Good grief ! DOS doesn't "drive" the BIOS. The BIOS (Basic Input/Output System) is PC firmware code which performs Power On Self-Test (POST) and provides basic services to access the PC hardware (i.e. video, drives, keyboard, serial ports, parallel ports). DOS is a single-tasking single-user operating system designed for the PC.

An encyclopedia article should be as clear and concise as possible without a lot of rambling on and more importantly it should be correct. Asmpgmr (talk) 15:17, 7 June 2012 (UTC)

Good greef. DOS does not 'drive' the BIOS. What happens is that users drive the market for different BIOS machines, based on the availability of software. IBM won because it was the first with the most. BUT in the early days, when you buy games, you had to make sure it was compatible with the BIOS. That's what I said, and that's what's in Chapman's book. Wendy.krieger (talk) 07:01, 8 June 2012 (UTC)

I don't know which sections were edited by Wendy, but on IBM PC compatible machines the term "BIOS" applies to both, the System BIOS (hardware initialization, POST, IPL, primitive hardware access routines, etc., typically residing in the ROM of the machine) and the so called DOS BIOS (IO.SYS, IBMBIO.COM, DRBIOS.SYS), which represents the "lower", machine-dependant parts of DOS itself (drivers and such). The BIOS contrasts with the BDOS (MSDOS.SYS, IBMDOS.COM, DRBDOS.SYS), which represents the "higher" parts of DOS, which are abstracted from machine-dependencies (file management (file systems), process management, memory management, user-level APIs, etc.).

In non-IBM compatible machines, the System BIOS differs considerably, and therefore the DOS BIOS of DOS issues for these machines were much different as well, whereas the BDOS could typically remain unchanged even on binary level. Talking about the DOS BIOS certainly belongs into this article as the DOS BIOS is a fundamental part of DOS, whereas we should discuss System BIOS topics in the separate BIOS article. --Matthiaspaul (talk) 19:03, 8 June 2012 (UTC)

On PCs the term BIOS (Basic Input/Output System) applies to the PC firmware in ROM. IO.SYS / IBMBIO.COM contains the DOS system initialization code (SYSINIT) and the builtin DOS device drivers for the disk drives, keyboard, video, serial ports, parallel ports (drive letters, CON, AUX, COM1, COM2, COM3, COM4, PRN, LPT1, LPT2, LPT3). MSDOS.SYS / IBMDOS.COM contains the actual DOS kernel. This separation was indeed done to abstract the DOS kernel from the machine-dependent parts of DOS (the builtin device drivers) but "DOS BIOS" is not a proper term. Asmpgmr (talk) 19:43, 8 June 2012 (UTC)

Facts about DOS

• DOS is a single-tasking single-user operating system for x86 PCs.
• DOS has no task scheduler in its kernel.
• DOS has no services to manage processes, it can only load programs, execute programs and terminate programs.
• Multitasking operating systems like Windows, OS/2, Unix/Linux have task schedulers in their kernels.
• Multitasking operating systems provide API services to manage processes (and usually threads).
• Multitasking operating systems generally also provide inter-process communications services.
• PCs have a BIOS, this is part of PC architecture and below any operating system.
• DOS makes use of the BIOS since it is a PC-based operating system.
• DOS programs can issue BIOS calls and/or directly access hardware as there is no hardware abstraction layer preventing this and DOS is not a protected-mode operating system.
• Since DOS programs have full access to the system, programs which remain resident can hook the BIOS timer interrupt and provide task switching themselves (e.g. DoubleDOS, DESQView, TopView) despite DOS not having any support for multitasking.
• Windows 3.x is an example of a complex software package which provides its own services and environment on top of DOS.

Hopefully this is clear now. If not then please do some technical research. Asmpgmr (talk) 16:45, 7 June 2012 (UTC)

I'd go farther. DOS has no concept of a task at all, multitasking or otherwise. Jeh (talk) 22:57, 8 June 2012 (UTC)

DOS Language

Yes, there is really a DOS language: this is a legacy or continued usage of DOS. It had a number of references, including the Windows 2000 help. I don't know why this was removed. It's the second time someone's hacked it out.

While I sort of get what the section was trying to say - and I do think some of it should be covered in the "user interface" section - the text you wrote really wasn't encyclopedic in tone (that is clear, concise and formal). Also the term "DOS language" isn't one I've encountered before. —Ruud 09:00, 8 June 2012 (UTC)

Did you try Google? There's plenty of references to "DOS Language", including several on the wikipedia List_of_command-line_interpreters, which interpret command languages. Really, you write scripts for a language, and scripts for command.com, cmd.exe are written in the same (DOS) language. That's the point i was making. It's a language that has features that is a legacy of DOS. It has entry space here. It's also called 'DOS batch language', or 'command line language', but there are other batch languages and command lines other than COMMAND.COM.

http://home.comcast.net/~dharter46/dos.lse line 1 = These are primary Templates for the DOS language. It's used by a VI implementation to select what words to highlight in a DOS/Windows/OS2 command-file. You would have for example, rexx.lse and c++.lse etc. DOS is then just a language you write scripts in. Wendy.krieger (talk) 08:48, 10 June 2012 (UTC)

Notice of Wikiquette Assistance discussion

Hello, DOS. This message is being sent to inform you that there currently is a discussion at Wikipedia:Wikiquette assistance regarding an issue with which you may have been involved. Thank you.

Raised at WP:WQA#Attacks_on_editors.2C_not_issues.2C_at_Talk:DOS.23DOS_is_not_a_multitasking_OS Andy Dingley (talk) 17:01, 8 June 2012 (UTC)

Perhaps we can just stop this discussion or continue it off-Wikipedia? As pointed out at #Rewrite, Wendy's changes will not be accepted back into the article due to a complete lack of citations. Convincing her that she's wrong (or vice versa) is not really the purpose of this talk page, either. —Ruud 17:38, 8 June 2012 (UTC)

I suppose there's 'undocumented dos' by Schulmann et al. It's used extensively in the discussion of multitasking etc. It quite clearly states in that book (and referenced in one of my deleted edits), that "DOS is a pre-emptive multitasking system". This is both not from vested interested, and conformes with my experiences with DOS.

I mean, the Windows help system has a 'differences between ms-dos and windows'. That means that Windows help is close enough for one to highlight the differences. This discusses what IBM liked to call "A better DOS than DOS", that is the DOS emulation in Windows enhanced mode, OS/2 and NT. DOSBox comes close to this. That's the reason i moved the DOSBox picture to that section: the Windows command prompt is showing a Win32 program running under a console created by KERNEL32. It belongs in the "DOS language" section, since it's a win32 program pretending to be DOS.

I never advanced that tandy 100 or the atari 2600 could run DOS. What i said is that they had a non-multitasking system. These are examplers of things that are more primitive than DOS. The tandy 100 basic is at the bottom end of the typical 8-bit operating systems. But even this is hardly anywhere near as potent as DOS.

When i suggested CALC.BA as an OS (since it is customary to call calculator systems as Operating Systems), the whole thing is that even things like file systems are feats of the OS, and that one could structure a program to emulate an operating system with a directory, system calls and an internal file system. From the system's prospective, this is what VPC does. It's a note about operating systems, not pre-emptiveness. I suppose it was derided because it was written in BASIC.

These are evidently much different to the DOS emulation in VMWare or VPC. Seen from outside these programs, it's one or two big files, not a file system. You have exactly the same sort of structure in things like ePub documents, or other programs that store that store things in zip files.

DOS does not multitask out of the box. In the same way, Windows 3.1 does not allow groups inside groups, whereas the DOS menu programs do. This is what i found when i got my first pc back in 1992. But these problems can be overcome: DOS can run multiple tasks, but it does not have the means to launch or swap them. That's why programs have to do this, and not all do. Wendy.krieger (talk) 07:47, 9 June 2012 (UTC)

Your last paragraph states exactly why DOS is not a multitasking OS: It doesn't multitask out of the box, and programs have to do all the work to provide that capability; DOS provides nothing. Nor can DOS "run multiple tasks" - it has no concept of a task, at all.

As a matter of fact, DOS doesn't really "run" anything - it is merely a program loader; once it jumps to the program's main there are no "supervisory" functions in operation, and DOS at that point becomes nothing more than a procedure library. When the programs have to do all the work, when you are achieving multitasking not because of the OS's facilities but in spite of its lack of them, you're not dealing with a multitasking OS.

For an analagous case, consider that DOS is widely understood to not provide a windowed UI. But, we could claim, we've seen them! Before Windows there were character-mode things like GEM, which was used perhaps most famously by Ventura Publisher. But DOS didn't have a single API, nor even a single line of code, to facilitate the implementation of GEM or any other such environment. So, DOS does not provide a windowed UI; it does not even provide for a windowed UI. It doesn't prevent you from running a windowed UI on top of it, but that doesn't make DOS a windowed UI OS... any more than the ability to run Ventura Publisher meant that DOS provided desktop publishing.

We could extend this to the function of every other program ever written for DOS. You can run terminal emulator programs like Kermit and Procomm on DOS, but that doesn't mean DOS is a "terminal emulator operating system." You can run a lot of different games on DOS, but that doesn't mean DOS has any support specifically for any of them. You can run orbital dynamics programs on DOS, but that doesn't make DOS an "orbital dynamics operating system." Functions provided by programs do not become attributes of the underlying OS.

In exactly the same way, DOS had utterly no support for multitasking, hence it was not a "multitasking OS". That you could run DesqView or similar on DOS does not change that.

As for Schulman, he does make that claim, but it's misleading. The only extent to which DOS provides multitasking is that DOS can load programs that do multitasking. If DOS was really a multitasking OS then there would have been no need for e.g. TopView or DesqView, and the Yield() API would have existed in DOS, not having to wait for Windows to provide it. Jeh (talk) 08:37, 9 June 2012 (UTC)

DOS is perfectly capable of windowing, since the essential element here is to restore the screen when the window is destroyed. EDIT can do this, for example. It's a matter of doing a save and restore the previous screen.

The Windows 3.1 operating system lies not in the user KERNEL/USER/GDI, but further down, in DOSX or WIN386. If you load Windows without loading the win16 programs, (kernel etc), you get a 32-bit DOS. The DOSX and WIN386 programs do support multitasking, but there is no way of starting this. The multitasking provided by DOSX is exactly the same in Windows (standard mode) as it is in DOSSHELL, which runs as Windows, even down to having grabber files.

The processor, like a 486 or 386, is a single-thread thing. The whole point of having a thread manager or task manager, is that you start and stop threads at the processor. You have things like priority, and ready-to-run and so forth. But that's a thread or task scheduler, not multitasking. It's akin to saying this is no road junction because it has no traffic lights.

You can (rather crudely) start and stop running processes to allow a different thread to run. DOS provides no thread manager as so, but it does provide the means for programs to set semaphores (hook interrupts), switch into and out of foreground and even to hook the timer interrupt to run in background. In essence this is a kind of co-operative (including preemptive) multitasking.

On the other hand, the typical 8-bit operating systems, like BASIC, RPN and such, provide no concept of swapping in and out the running task, or hooking semaphores to pop up. Wendy.krieger (talk) 09:33, 9 June 2012 (UTC)

Saving and restoring the screen may be a DOS function (I suspect it's just part of EDIT) but that's far from what's required for an OS to support a windowed UI. Does DOS support a concept of an active window region out of several within the display? A separate input queue for each window? Even the concept of a window? Of course not. Those things were all implemented within GEM.

There is no such thing as a "32-bit DOS". Are you referring to the command prompt window under the NT family? That's a command interpreter, cmd.exe. It is not an operating system. It does not use DOS functions to do its work. Even the 16-bit command prompt that's available under 32-bit versions of Windows (run command.com) isn't an operating system. It's just a command interpreter. It calls Windows native functions to emulate DOS APIs.

Pausing and resuming threads is an inherent aspect of multitasking. If you're not doing that, either as a result of Yield() calls from the programs (cooperative multitasking) or a preemptive scheduler in the OS, then the first program that runs is just going to execute from beginning to end... in which case, where's the multitasking?

Interrupts are not tasks, and interrupt service routines are not peers to tasks when we speak of "multitasking" in this sense. Interrupt-driven I/O is implemented in a great many OSs that are not considered multitasking, no way, no how. Your term "cooperative (including preemptive) multitasking" is an oxymoron. Cooperative multitasking does not include preemptive, although the opposite can be true.

DOS has no concept of swapping in and out the running task either. Interrupt handlers are called by means of what amounts to a procedure call. Interrupts under DOS are not tasks, interrupt service routines are not tasks, and calling an ISR and then returning to the interrupted code does not involve "swapping out the running task" under DOS.

BASIC is not an OS, it's the name of a programming language and the interpreter or compiler that implements it. RPN is not an OS, it's an arithmetic notation, an alternative to infix notation.

And while we're reviewing, I'll also note that there most certainly is a file system within the virtual hard drive files used by e.g. VirtualPC and VMWare. The virtual hard drive implements only an array of blocks, analagous to the function of a real hard drive at the interface connector. The partition and file system structure inside the VHD file are created and updated by the standard file system drivers that are part of the guest OS; the VM is not implementing or emulating these functions. The VM environment gets involved at the disk block level, nowhere higher. The VM provides the disk driver (one way or another) and when the file system driver in the guest OS tries to read or write a disk block, the disk driver in the VM sends I/O requests to the host OS to read or write the corresponding blocks within the virtual hard drive file. Jeh (talk) 10:35, 9 June 2012 (UTC)

At what point do these lengthy debates stop ? There is a clear lack of technical understanding on the part of user Wendy Krieger, for example:

On the other hand, the typical 8-bit operating systems, like BASIC, RPN and such, provide no concept of swapping in and out the running task, or hooking semaphores to pop up.

An operating system is software which manages the hardware and resources of a computer. BASIC is a programming language which was usually interpretive on older computers. Reverse Polish Notation (RPN) is a mathematical notation. Multitasking is a method by which multiple tasks (usually called processes) are run simultaneously via a task scheduler. A semaphore is a mechanism to control access to common resources by multiple processes.

Another example: DOS is perfectly capable of windowing

Constantly having to say "this is wrong" isn't an attack when the statements made are in fact patently wrong. These lengthy debates really aren't beneficial, aren't helping anything related to the actual DOS article and they're getting way off topic and frankly frustrating. This should be a page to discuss edits and improvements to the DOS article and possibly related articles, not a tutorial session. Asmpgmr (talk) 15:13, 9 June 2012 (UTC)

I don't see why this is such a debated topic (obligatory XKCD link: http://xkcd.com/386/), who cares? DOS is or isn't, it's not sweat off our backs. I'd normally say "it's not", but I really wish it was (esp. FreeDOS). There seem to be a billion minor issues with deciding this for sure, and I'm not sure it's worth worrying about (or at least arguing and getting mad is ultra pointless).

1). BIOS vs. DOS kernel vs. whatever -- so what, do we really care if the "kernel proper" includes the BIOS or is reentrant or whether it offloads everything to user? It's not Linux, it wasn't meant to be. If you (for example) think Linux is better and DOS is useless, fine, but why argue about how wimpy DOS was? With only 64k of RAM and an 8088, it had to be lean and mean and minimal.

2). Desqview 8086 multitasking -- so it was clearly possible, as we all know, but clearly you don't "need" multitasking for most things, and it eats more RAM, which was scarce.

3). TSRs vs. timer IRQ vs. task switching vs. cooperative vs. preemptive vs. multi-threading vs. multi-core -- too tedious to argue. Was task switching "multitasking"? Some say yes, e.g. the 286 was claimed by both IBM and Intel to multi-task, but clearly modern-day thinking disagrees with that terminology. Most people don't even consider Win 3.0 to multitask due to cooperative only (well, the DOS part was pre-emptive, right?). You're right, the DOS kernel proper didn't do any real scheduling nor use any instructions like CLTS (286+), but the official MS-DOS "install" did come with PRINT, (later) DOSSHELL, and obviously various 3rd-party screensaver TSRs and music or CD players existed and worked in the background. I know that's not the same as modern-day thinking, but hey, it did exist and work, somewhat.

4). DR-DOS 6 had some limited multitasking, and Novell DOS 7 (aka, DR-DOS 7) had both task switching (286) support and pre-emptive multitasking (386). It seems most people, even here, consider "DOS" to always exclusively mean "MS-DOS", which isn't true. DR-DOS was indeed compatible with 95% of MS-DOS software (minus a few bugs), even when multitasking.

5). Again, the terminology isn't standardized, but "most" people agree that Linux and WinNT "multitask". However, keep in mind that the original x86-based XBox 1 (allegedly) only supported one task and up to three threads. I don't know if you consider that multitasking either. Plus, when the whole multi-core boom hit a few years ago, all the ads were saying, "Finally, 'true' multitasking!" So, what, everything before that was "fake"? Are we going to argue about that?  ;-) Please don't, heh, just saying, clearly we all have our opinions. The kernel proper probably has to do some special stuff behind the scenes without explicit help from the apps in order to be considered multitasking. At least, that's what most people seem to agree upon. Yes, you can fake it with DOS in any app (almost, at least 90% of stuff), but overall it isn't done. Besides compatibility and limited design due to lack of RAM and 8086 legacy, I think the main limitation was the (non-reentrant?) BIOS. So, sure DOS "could" potentially multitask much much better than currently, even DR-DOS 7.03 ("best"??) could be improved, but whatever, it was "good enough" for most needs at the time of its main popularity and usage ('80s and '90s).

(Hopefully that barely helped settle things.) Armslurp (talk) 17:49, 12 June 2012 (UTC)

DOS article structure and related articles

After Ruud's updates the DOS article is much cleaner though the "DOS under OS/2 and Windows" section is still a mess and needs to be rewritten.

Also I really think that the related DOS articles for IO.SYS and IBMBIO.COM should be merged with one redirecting to the other since these are the same files but with different names depending on the manufacturer (Microsoft or IBM). The same is true of MSDOS.SYS and IBMDOS.COM.

Finally should the MS-DOS API article be extended with a more complete API listing akin to what is in the BIOS interrupt call article ?

Knowledgeable opinions anyone ? Asmpgmr (talk) 00:38, 9 June 2012 (UTC)

If they're actually the same files other than the name (are they? I don't know, not really a DOS/Windows programmer) the redirect makes sense, with a note somewhere in the opening paragraphs that this is the case and why it's been done. (Or if they're different but so close they could be used interchangeably, a note to that effect.) A complete list of the DOS API with the parameters and which versions they appeared in might settle a few old arguments. htom (talk) 01:44, 9 June 2012 (UTC)

IBM wanted names with "IBM" in them. When building DOS, a MAKE define determined whether to generate the Microsoft names and Microsoft copyright text or the IBM names and IBM copyright text. There are also some other minor differences depending on the MAKE define (e.g. the DOS boot sector code OEM ID is "MSDOS x.y" for MS-DOS and "IBM x.y" for PC DOS where x.y is the DOS version). You cannot mix and match them because the MS-DOS boot sector code will try to load IO.SYS which will in turn try to load MSDOS.SYS while the PC DOS boot sector code will try to load IBMBIO.COM which will in turn try to load IBMDOS.COM. Asmpgmr (talk) 02:13, 9 June 2012 (UTC)

I find it odd that they did that, esp. since DR-DOS copied IBM but not MS. FreeDOS does neither and consolidates both files into one KERNEL.SYS, but its SYS.COM has support for other DOSes, I think. I think even they switched to "FRDOS5.1" or such weirdness for ultra compatibility. But DR-DOS (7.03, at least) could potentially install those files anywhere on your disk, not necessarily beginning at sector zero like MS-DOS seemed to prefer (not sure about PC-DOS). So that kind of thing wasn't set in stone and mattered little to outside programs. You can use something like METAKERN to multi-boot various DOSes atop the same partition, I believe (but it's been a while since I actively tried). Armslurp (talk) 17:49, 12 June 2012 (UTC)

Interesting. Once the machine is up and running, would it make a difference to user code? Were there different versions of (say) WordPerfect or Sidekick needed, or did such code detect (was that possible?) which was being used and execute different code accordingly? I'm not even sure what questions I'm trying to ask, and don't even want to come close to asking you to break a NDA. htom (talk) 05:31, 9 June 2012 (UTC)

There is no distinguishable difference to user code between say MS-DOS 5.0 and PC-DOS 5.0, the DOS kernel code is exactly the same. It is technically possible via Int 21h function 30h to tell the difference as it returns the OEM ID byte in BH (00=IBM, FF=Microsoft) but there was no need to do this. There was a leftover from the days when PCs weren't 100% compatible and different OEMs had different OEM ID bytes to distinguish them from one another. Asmpgmr (talk) 14:55, 9 June 2012 (UTC)

I see where you said you worked on PC-DOS. But wasn't it true that MS-DOS and PC-DOS diverged after the split circa 1991? So while they were mostly compatible, they were far from identical in later versions (e.g. MS-DOS 7.10 and PC-DOS 2000 ... when did PC-DOS get FAT32, only unofficially in 7.1 ??? Even MS-DOS 7, aka Win95, only got it in OSR2 or such, right?). I know both had access to sources of "MS-DOS" 5.0, but later versions were worked on independently and sold separately, that's all I'm saying (in case that wasn't obvious to someone else.) BTW, due to undocumented data, as we all know, Win95 (Win32 and GUI stuff) wouldn't run atop either PC-DOS nor DR-DOS, at least not officially without unreleased hacks. But overall 95% of "DOS" software "should" run on all of them. Armslurp (talk) 17:49, 12 June 2012 (UTC)

I'll respond to this one point with a brief history of DOS:

• Seattle Computer Products created 86-DOS which was purchased by Microsoft and became MS-DOS 1.0 and licensed to IBM as PC DOS 1.0
• Microsoft did the primary development of DOS from versions 2.0 to 3.2
• IBM took over development of DOS for versions 3.3 and 4.0
• Microsoft resumed development with version 5.0 (1991)
• Up until this point MS-DOS and PC DOS were the same code base and the difference between the two was determined by a build option. Prior to this OEMs could license the DOS OEM Adaptation Kit to customize to device driver portion of DOS to their hardware but by DOS 5 the vast majority of PCs were 100% IBM PC AT compatible so this was no longer needed.
• Microsoft and IBM ended their working relationship due to various disagreements so the companies developed DOS separately after this. From this point the code diverges but the DOS API and internal data structures remain the same.
• Microsoft developed MS-DOS 6.0, 6.2, 6.21, 6.22
• IBM developed PC DOS 6.1, 6.3 and 7.0
• Microsoft considered a standalone MS-DOS 7.0 but decided to incorporate this into Windows 95.
• Microsoft added FAT32 support to DOS with MS-DOS 7.1 which is the DOS base of Windows 95 OSR2, Windows 98 and 98SE.
• IBM released PC DOS 2000 which is PC DOS 7.0 revision 1 with very minor changes to workaround Y2K issues in very old PC BIOSes.
• There was also a PC DOS 7.1 which has FAT32 support but I don't know much about this as it was done many years after I worked at IBM. From what I can gather it was done for Symantec and used in Norton Ghost.

Both Microsoft and IBM can claim ownership of DOS and both of their versions can be considered true DOS since they both derive from a common codebase. Asmpgmr (talk) 19:46, 12 June 2012 (UTC)

Most user code is unaffected by DOS version, save those that are tied to a version, and those that make assumptions about the way DOS loads (software carousel).

You can mix and match a good deal of IBM vs Microsoft DOS. The IBMDOS 5.00 command.com and most of the utilities run quite happily under MS-DOS 5.00, or even Windows NT. I did a project to change the version of MS-DOS 6.22, (largely aimed as a fix for 'olddos' under windows 9x). You can make ms-dos 6.22 into 6.30, and it runs quite perfectly under PC-DOS 6.30 and vice versa. The DOS version number is nowhere to be found in MSDOS.SYS (the files are identical in 6.20 and 6.22).

The OEM ID thing is a horrible bug that has been perputuated since DOS 3.0. One of the reasons that Win9x VOLTRACK.VXD trashes so many diskettes, is because DOS expects to find a version at the end, not IHC. Apart from that no. See http://seasip.info/Misc/oemid.html and novoltrk.reg at freedos.

I think novoltrk.reg was the work of Matthias Paul, not specifically FreeDOS. AFAIK, he never actively joined FreeDOS and only contributed to them indirectly (though he did officially work on DR-DOS in the past). Armslurp (talk) 17:49, 12 June 2012 (UTC)

That WP and Sidekick run under many versions of DOS is because they're making DOS calls (rather than making assumptions about DOS), to achieve their results. The Software Carousel on the other hand does not. (See, eg 4DOS.HLP on this). Wendy.krieger (talk) 09:48, 9 June 2012 (UTC)

More largely incorrect stuff. You can NOT mix and match files between different DOS versions. In most versions of DOS the base DOS utilities have version checking code and will return Incorrect DOS version. The MS-DOS 6.2x versions are generally the same only because the difference involve the removal of DoubleSpace (6.21) and the addition of DriveSpace (6.22).

Also the DOS version is of course in MSDOS.SYS / IBMDOS.COM and can be found in the DOS data area, in DOS 5.0+ it is at offset 0D12h

If the DOS version wasn't somewhere in the file then how would the get DOS version function (Int 21h function 30h) possibly work ?

Asmpgmr (talk) 14:55, 9 June 2012 (UTC)

Well, for clarity, for example, even DR-DOS has the version hard-coded somewhere (ask Matthias, I forget, either in shell and/or kernel files), though of course 7.02 and 7.03 report the same, so you have to do other things to find out which is which, if it matters (rare). Also, it reports emulated IBM DOS 6.0 when you use standard int 21, 30h but you can call int 21h, 4452h ("DR") to get the DR-DOS version. However, the "ver" command just returns what the "VER=" environment variable says. So "set VER=3" and "ver" will say 3. (And that's disregarding SETVER and friends!) And BTW, in case it wasn't obvious, 95% of "DOS" [sic] software works across various versions of DOSes (FreeDOS, DR-DOS, MS-DOS, PC-DOS, ROM-DOS) minus a few bugs here and there. That's the point, nobody wants to target exclusively a single "DOS" (almost). The fact that MS-DOS 5 utils had a braindead version check (wouldn't even work on MS-DOS 6) and perhaps later XCOPY (?) was specifically quirky and/or used FCBs (old) doesn't mean that "overall" most DOS software can't be compatible, e.g. DJGPP or whatever, has been designed to work across various DOSes (though obviously "MS-DOS" has been the most popular). Sorry if that's useless or redundant trivia that you probably already knew (better than I do!), just trying to clarify. :-) Armslurp (talk) 17:49, 12 June 2012 (UTC)

Changing dos versions have been around since DOS 3.x as far as i recall. You run it through a hex editor, and search for a string, and change the bytes accordingly. These have even been in pcmag, for instance. Some of the dos checks are a bit different (fc.exe tests for high and low byte of the version separately). I think the term used for doing this was 'diddling edlin'.

MS-DOS 6.21 is MS-DOS 6.20, with a few files changed. Int 21 func 30 gives '0614' in both cases.

In MS-DOS 6, the file msdos.sys are identical between 6.20 and 6.22, even though int 21h func 30h gives 0614 and 0616 for these. The actual bytes that define the DOS live in IO.SYS, in the first four bytes. The bulk of utilities differ only in two strings ('6.20' vs '6.22', in the dosver tested for '0614'x vs '0616'x, and in the copyright string '1993' vs '1994'. SYS.COM has a further difference in that it looks for DRVSPACE.BIN rather than DBLSPACE.BIN.

     infile = 'cvmod.dat'
     dvstr = '16 14' ; dosver = '031F'x
     cpstr = '34 33' ; cpdate = '1995'
     cnstr = '32 31' ; cpname = '3.31'

Files like setver.exe differ greatly, but this is because of the pre-loaded version table. FC.EXE had a fancy version check. Generally, gsar or rexx's 'charstr()' is pretty much suffice to do most of it.

You will probably find that this feature (check version) is a DOS 5 hangover. The new utilities in DOS 6 (deltree, move, interlnk, intersvr) do not have this limitation, and the limitation was removed on interlnk/intersrv from vers 5.02. Scandisk and Defrag test for version .ge. 6.00.

Regarding RPN as an operating system. This came up on google on 'rpn operating system' without the quotes. By the way, there are significant differences between RPN operating system, and the mathematical form, just as there are significant differences between the mathematical '=' sign (which equates to C '=='), and the programming '=', which is an assignment of LHS becomes RHS. In the algebraic system, the RHS is assigned the value of the LHS. So algebraic "5+3= StoA" equates to RPN "5~3+ StoA" equates to programming "A = 5+3".

         Reverse Polish Notation
         users.ece.gatech.edu/mleach/revpol/
         The operating system for Hewlett Packard scientific calculators is called "reverse Polish notation," or 
         simply rpn. In talking to students who have HP calculators, ...

It is not however, a disk operating system. Implementing RPN in Basic can be quite an instructive exercise. You do something pretty much like machine language, of moving values to registers, calling a function (GOSUB nnn), and then fetching the results. You can load as many parameters and outputs as needed, and then pull values, rather like having every C function return a structure. A line like

   [subtract-key]:  P1 = S(3) : S2 = S(2) : P0 = [drop flag] : call [subtract] :  return
                   (set pointers to arguments) (default action)  (call function)  (value in S(0))
.  
   returns P1-P2 into A(0), and returns.  An errorcode flag is always cleared before the switching, since it is assumed that it
   works unless it fails, in which case, the [subtract] routine sets the error message (or alternately, the P0 value).  
   The actual value is returned in A(0), and it is up to the stack manager to resolve P0, (which is the error set), and then do 
   something with A(0).
.
   IF P(0) < 10 then gosub [function to draw the A(0) string - it's a multi-base calculator]
   IF P(0) = 1 or P(0) = 2 then call [save-last-x]    'equates to A(1)=A(2): A(2)=A(0)
   IF P(0) = 3 then call [drop-stack]  'equates to A(3)=A(4): A(4)=A(5)
   etc.

It's not a multitasking OS. But it is an OS, none the same, and a good deal of notions from writing this are seen in DOS interrupts and pre-loading values into the accumulators.

Regarding technical issues. It's not one of technical issues but of terminology. It has not been denied that a TSR can load as a background task, listen for interrupts, and bring itself to foreground when it is called. It has not been denied that a task swapper can run on DOS, which provides in essence, virtual DOS sessions which might be swapped in and out. It hasn't even been denied that these don't generally happen with DOS out of the box. These are 'technical facts' regarding DOS.

The issue is more 'does running TSR programs that do things in background, and wait for calls, constitute multitasking'. And rather, does 'multi-tasking requires management in the OS'. At least, by the second call, it boils down to 'what is the OS'. You can run Windows NT with no Win32 layer (CMDCONS or BLUECON). You can pretty much get a DOS32 by putting the line 'command.com' into a batch file named WINSTART.BAT, and running windows. You can run a minimal NT with SETUP, but this does not multi-task. None of these programs will run in the Win32 layer, except when they're bound (like the OS/2+DOS family programs) [autochk is an example]. Even though multitasking is implemented in the NativeNT layer, the control manager is in Win32 application that runs on top of it. So by the arguments presented, is Win32 a multitasking system, or does it call down to NativeNT or DOS32 that runs under it.

I could point out your latest technical inaccuracies but I'm tired of this. The bottom line is any technically incorrect information you post in the DOS article will be removed, particularly since your claims are based upon your own opinion with no valid sources to back them up. I would also recommend that any of your edits to other related technical articles (like the Command line interface article) be thoroughly checked for technical accuracy, lack of brevity and a tendency to stray off topic. Asmpgmr (talk) 16:09, 10 June 2012 (UTC)

TSR. Terminate and Stay Resident. It's not multi-tasking. It terminates. RPN. Reverse of Polish Notation. Older HP calculators operated with this scheme of data manipulation. Enter one operand, (if needed, press "Enter", enter the second operand), press the desired operation, see the result.) I suppose in a way it's an operating system for the calculators. Forth systems use variations of RPN, and in that they are sometimes also operating systems, they might be called RPN operating systems. (APL uses a variation of Polish Notation.) LHS=RHS In mathematics, expression = expression means that the LHS and the RHS have the same value. There is no assignment of value. htom (talk) 23:19, 10 June 2012 (UTC)

Wendy, you said

It has not been denied that a TSR can load as a background task, listen for interrupts, and bring itself to foreground when it is called. It has not been denied that a task swapper can run on DOS, which provides in essence, virtual DOS sessions which might be swapped in and out. It hasn't even been denied that these don't generally happen with DOS out of the box. These are 'technical facts' regarding DOS.

TSRs load into memory, establish themselves in the interrupt chain, and quit. They don't "listen for interrupts", or at least they shouldn't! When the interrupt occurs, the chain of people wanting it is executed, one after another, until it's "filled". It does not bring itself to the foreground; it is brought there by the interrupt handler. A task swapper can be loaded and started by DOS -- and it usurps DOS's control (well, what little control it had) of the system. DOS is not running the task swapper, the task swapper is running DOS. That DOS does not have control of the hardware while user code is nominally running is one of the reasons that in some ways DOS is not an operating system.

For what it's worth. Open-source things work best because there are people who understand the issues, are not necessarily the best to implement them. I raised a number of issues i thought have place here.

The DOS language, eg batch or script, is a language. Google shows sufficient reference to it. The Windows NT cmd.exe picture belongs in this discussion, since it's not a dos program, but one that behaves like a dos program. OS/2 and Windows still use it, and that is a continuing legacy of DOS.

The DOS sessions raised in Windows and OS/2, as well as DOSEMU and DOSBox, do not use a virtual disk, so the file systems and services are accessed by the host. This is why i tried to move the DOS Box window to this part.

Google shows mixed results about Multitasking, but generally the line that DOS does not multitask as such. However, TSRs exist, and they do give the illusion of multitasking. "listening to an interrupt" is meant to indicate an unknown process, since the process of continually looking for interrupts is 'busy-waiting' it. WP busywaits the keyboard. DOS does have things like USER-ID field in the sysvar table, which are used when DOS tasks are multitasked (undocumented dos).

TSRs may well terminate when loaded to memory. But a stopped program needs to be woken up to look at the interrupt that is fed to it. Sounds like multitasking to me, but that's a matter of how one reads jargon. It's like, (interrupt happens). It is passed to A. A wakes up and looks - no - not me - goes back to sleep. Passed to B - yes that's me. Let's park the process and get going. It sounds horribly like a re-enterent system and multitasking to me, but that's my opinion. (See comment below, about X and Y)

DOS 32 or 32-bit DOS does exist, according to google etc. It usually is taken to mean that a DPMI server is loaded, and 32-bit addressing can occur. This is the usual meaning for it.

What calculators run has always been called 'operating systems', and both the RPN and Algebraic OS are significantly different to the mathematical forms, even from the user interface prospective. I've written a calculator that can change the base in mid-operation, and worked with bases as high as 360, and modify the number of units in a circle or radian. It's not whether something uses an RPN system on a compter, the terminology of what runs on calculators is 'operating system'. It's like your 'multitasking', it means what different people think it should.

The argument that 'DOS is not an OS' is in the same line as 'DOS does not multitask', are based on exactly the same basis that DOS does X but not Y, and UBeaut MULTIX does X and Y, so DOS can't be a real OS. The lower bar is X, the upper bar is Y, the choice is a matter of opinion. Wendy.krieger (talk) 10:15, 11 June 2012 (UTC)

Because something "sounds like X" or "looks like X" or "seems to be X" does not mean that it is, indeed, X. What are the characteristics and consequences of "re-enterent code" in the context of computer code (system and user)? Yes, people have different ways of expressing precise definitions of terms used -- but your definitions seem to be far from those I was taught, that I taught, that I read in other publications, and that I used as a systems designer and programmer. htom (talk) 18:06, 11 June 2012 (UTC)