Talk:DOS API

	This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.
	This article is supported by WikiProject Computing.

to-do

Should mention how it was radically revamped with DOS version 2.0 in 1983 (adding file handles, subdirectory support, and ASCIIZ strings, among other things)... AnonMoos (talk) 09:50, 26 October 2008 (UTC)[reply]

Done a while back... AnonMoos (talk) 19:22, 14 November 2011 (UTC)[reply]

correction

Int 21 Fn 02 under common functions states that AL holds the character code to print - I think that should be DL. —Preceding unsigned comment added by 58.110.245.134 (talk) 03:44, 10 February 2009 (UTC)[reply]

DOS API function list

Should this article include a list of DOS function calls akin to the list in the BIOS interrupt call article ? Also should such a list detail register parameters and return values ? The BIOS list does not, it only lists the functions.

Another note: this article should be named "DOS API" since it applies to DOS overall, not just MS-DOS. Asmpgmr (talk) 23:58, 21 June 2012 (UTC)[reply]

A comprehensive list would be quite long, and would duplicate work which has been done elsewhere (probably with poorer quality); a few selected examples are fine in my opinion. And it's called the "MS-DOS" API because everybody else is compatible with MS-DOS (and the acronym "DOS" by itself has a number of possible meanings -- we even have an article on it, List of DOS operating systems). Also, functions to manage expanded memory were introduced into base MS-DOS starting with version 4. AnonMoos (talk) 13:02, 22 June 2012 (UTC)[reply]

The Expanded Memory Specification (EMS) is a separate specification which uses Int 67h and NOT part of the DOS API in any version of DOS. Do not put that back in the article. Asmpgmr (talk) 15:08, 22 June 2012 (UTC)[reply]

Sorry, dude, but when it comes to you vs. Peter Norton, I choose to believe Peter Norton. The Int 67h functions were incorporated into base MS-DOS starting with version 4.0. Do not remove reliable references from the article based solely on your vague personal opinions... AnonMoos (talk) 18:59, 22 June 2012 (UTC)[reply]

The "vague personal opinion" as you say comes from being the lead developer of PC DOS 7.0. EMS is NOT part of the DOS API, it is a separate specification which uses Int 67h. DOS 4 allowed disk buffers to be placed in EMS using BUFFERS=nn /X in CONFIG.SYS - this is what is being referred to NOT any API additions. Asmpgmr (talk) 20:07, 22 June 2012 (UTC)[reply]

That's not what Peter Norton says in an official Microsoft-published book. AnonMoos (talk) 20:49, 22 June 2012 (UTC)[reply]

I just explained what any reference about EMS in DOS 4 is about. The DOS API is implemented by the DOS kernel (MSDOS.SYS or IBMDOS.COM). EMS is implemented by an Expanded Memory Manager (EMM) such as EMM386, QEMM or 386MAX. If you want to keep maintaining this incorrect argument then list specifically which DOS API (Int 20h - Int 2Fh) implements this. Asmpgmr (talk) 20:55, 22 June 2012 (UTC)[reply]

Why do your personal reminiscences take precedence over explicit and detailed statements by Peter Norton? -- AnonMoos (talk) 22:34, 22 June 2012 (UTC)[reply]

I'd say that being the lead developer on PC DOS 7.0 is more than a "personal reminiscence". Are you even a programmer ? Also the official references for DOS are the Microsoft MS-DOS Programmer's Reference - The Official Technical Reference ISBN 1556155468 and The MS-DOS Encyclopedia ISBN 1556151748 - I'm pretty sure there's no statement about EMS being part of the DOS API in either since it's not.

Again EMS is its own specification and NOT part of the DOS API anymore than the BIOS API or XMS is. Additionally EMS predates the release of DOS 4 by three years. DOS 4 added BUFFERS /X in CONFIG.SYS to allow BUFFERS to be allocated in expanded memory though this feature was removed in DOS 5. Also DOS 4 came with EMM386 and the PS/2 specific XMA2EMS.SYS - this is clearly what is being referenced by Norton which you don't seem to understand. Again if you want to maintain this incorrect argument then list specifically which DOS API. Originally Int 20h - 3Fh were defined as reserved for DOS, of those 20h - 27h are implemented by the DOS kernel, 28h is issued by the kernel to indicate it is idle (originally done for PRINT), Int 29h is handled by the builtin CON driver or a replacement like ANSI.SYS, 2Ah is issued by the kernel to communicate with MS networking software, 2Bh - 2Dh were never used, 2Eh is reload transient and is handled by COMMAND.COM, 2Fh was originally for PRINT but expanded to use by multiple programs (multiplex) in DOS 3+, 30h - 31h formed a CP/M compatibility call though 31h was later used for DPMI, 32h was never used, 33h was used for the mouse, 34h - 3Eh were used for floating-point emulation by Microsoft and Borland run-time libraries, 3Fh was used by Microsoft linker's overlay code. Asmpgmr (talk) 23:38, 22 June 2012 (UTC)[reply]

If the above isn't clear enough then consider that EMS services (Int 67h) are provided by an expanded memory manager (EMM) such as EMM386, QEMM or 386MAX. You do NOT require an EMM to run DOS and if you do not have an EMM driver loaded then Int 67h will not be initialized and will generally point to 0:0 though some BIOSes initialize Int 67h to point to an IRET. On the other hand the DOS main API (Int 21h) is of course ALWAYS available as that is an inherent part of DOS (implemented in MSDOS.SYS or IBMDOS.COM). Asmpgmr (talk) 01:50, 23 June 2012 (UTC)[reply]

That's nice -- the appeal to one's own personal importance is usually not all that relevant on Wikipedia unless you have a verified public confirmed identity. Meanwhile, I'm looking at ISBN 1-55615-131-4, p. 490 where it says "DOS version 4 supports expanded memory by incorporating the functionality of version 4.0 of the LIM (Lotus-Intel-Microsoft) Expanded Memory Specification, which consists of a set of function calls invoked through software interrupt 67h. Because DOS supports the LIM interface, you needn't install a separate device driver to use expanded memory in a PC or PS/2." and wondering why I should give much credence to anything you say which contradicts this... P.S. Wasn't DOS 7 a cut-down embedded subcomponent of WIN 95 through WIN ME? AnonMoos (talk) 05:00, 23 June 2012 (UTC)[reply]

Again this means DOS 4 came with EMM386 and XMA2EMS.SYS (for PS/2 systems). There was no EMM code in the DOS 4 kernel. The official reference for MS-DOS says nothing of the sort and neither does the actual EMS 4.0 specification [[1]]. Stop putting that incorrect sentence in the MS-DOS API. It is at best hyperbole. Also PC DOS 7 was based upon PC DOS 6.3 and had nothing to do with Microsoft's offerings at the time. Asmpgmr (talk) 15:36, 23 June 2012 (UTC)[reply]

Reference list of interrupts used by DOS (Int 20h - 27h) and Int 21h functions has been added. Hopefully this will end any questions as to what is and is not in the DOS API. These lists are similar to what is in the BIOS interrupt call article. Someone can look in the linked references for more detailed information regarding register usage and return values. Also added references to the Microsoft MS-DOS Programmer's Reference - The Official Technical Reference to MS-DOS and the Programmer's PC Sourcebook, both published by Microsoft Press. Asmpgmr (talk) 17:41, 22 June 2012 (UTC)[reply]