[go: nahoru, domu]
Jump to content

Talk:DOS API

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

to-do

[edit]

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

[edit]

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

[edit]

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), it said nothing about EMS being added to the DOS API. 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]
Also can you point out exactly where in the DOS 4 kernel (IBMDOS.COM or MSDOS.SYS) this alleged EMM code can be found so that it can be verified ? If not then stop making this invalid argument and stop putting incorrect information in the article. Asmpgmr (talk) 15:41, 23 June 2012 (UTC)[reply]
Notice you haven't given any good answer yet to either of the two main questions: 1) Why should I believe you over Peter Norton? 2) Why do you feel entitled to remove a reliable source reference from the article in violation of Wikipedia policies? -- AnonMoos (talk) 18:53, 23 June 2012 (UTC)[reply]
Frankly why should I care what you think ? Whether you choose to believe me or not I was the lead developer of PC DOS 7. On the other hand you do not appear to be technically versed in the subject matter so I have to wonder why you are even posting in an article for which you do not have sufficient knowledge of. Also you persist in taking one sentence out of context from one book which is NOT the official technical reference. Note that one sentence does NOT mention the terms "application programming interface" or "API", you have decided to apply your own false interpretation to it. Additionally I have provided technical explanations as to why EMS [[2]] is its own specification and not part of the DOS API, whether you choose to ignore this or simply don't understand this is irrelevant. You are entitled to your own opinion however incorrect it may be but you are not entitled to your own facts. Again can you point out exactly where in the DOS 4 kernel (IBMDOS.COM or MSDOS.SYS) this alleged EMM code can be found so that it can be verified ? You can not because it does not exist and I seriously doubt you have the technical understanding to do so even if it did. Another thing: I added official books to the article as references which you also choose to ignore likely because they don't support your flawed argument. Just because something is written in a book does not make it automatically correct. Consider there are books out there (e.g. bible) filled with nothing but BS and people saying otherwise doesn't make it any less false. Finally I'm tired of arguing with you about this. The facts are that EMS is its own specification which was developed in the DOS 3.x era and while certainly important to DOS programming, it is NOT part of the DOS API anymore than the BIOS API, XMS, VCPI or VDS are. Please end this and please do not put this incorrect statement in the article again. Asmpgmr (talk) 19:37, 23 June 2012 (UTC)[reply]
The Expanded Memory Specification is certainly an API in the pool of DOS-related APIs, but not the (MS-)DOS API. It is optionally provided by drivers in the DOS package - either by hardware drivers for real EMS memory expansion boards or EMS-capable chipsets (f.e. NEAT) or via EMM386 for paged (or even virtual) memory. EMS is an external "raw" interface located at BIOS level (or slightly above it, depending on implementation) and for the most part operating-system independent (except for some install check/calling conventions).
There were third-party DOS operating systems such as Concurrent DOS XM, which took full advantage of EMS for their memory management and multitasking, however, normal single-user DOS operating systems such as MS-DOS/PC DOS or DR-DOS did not take advantage of it, with two known exceptions: the buffers logic in MS-DOS/PC DOS 4 (with BUFFERS /X), and (semi-permanent) memory tiling from the EMS memory pool in DR DOS 5.0 and higher in order to backfill unused real mode address space with memory, which could then be used to expand the conventional memory area to 640 KB (and beyond) on machines with lesser memory, or provide upper memory in the (locked) 64 KB EMS page frame (and beyond, depending on hardware support) even on XT and 286 AT machines. In this case, the EMS memory was occupied by the XMS driver typically residing in HIDOS.SYS or HIMEM.SYS (and - under DR-DOS - also in EMM386.EXE), which in turn was utilized by the DOS kernel (since DOS 5.0) for its own DOS memory management. Lots of DOS drivers, TSRs and applications also took advantage of EMS by directly talking to the EMS INT 67h interface.
So, there were optional drivers in the DOS package which could provide the API, and there were clients in the DOS package, which could optionally take advantage of it. The DOS kernel itself, however, never provided EMS memory by itself, and either ignored it altogether or only used it optionally as a client.
I see that it can be difficult to draw the line somewhere with a term as vague as "DOS". It's all down to what is meant by "DOS", the kernel, the kernel plus disk-related drivers and memory managers, anything provided with the package, or even the pool of wide-spread APIs provided by some drivers in the DOS world? EMS would certainly belong into an article on DOS memory management, but in my opinion does not belong into an article on the DOS API. --Matthiaspaul (talk) 12:21, 24 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]

Oh, I did not notice this before. But still, WP:NOTEVERYTHING applies, especially point 8: "[Wikipedia is not a] complete exposition of all possible details". For the same reason the system call article does not list every Unix syscall number either. And we have had a pretty similar discussion on Talk:Blue Screen of Death and the consensus was to move the list of error codes to Wikibooks (I do not think Wikibooks is a good place for that either, but that is another matter; the important thing is, this project is not a place for such lists). Keφr (talk) 08:56, 12 July 2012 (UTC)[reply]
I reverted your bold deletion, because you should have discussed this first on the talk page, not afterwards. I do think this list of functions absolutely belongs in an article about the MS-DOS API, because that's the very core of the subject, and it is required to understand the basics of what the MS-DOS API is about. Actually, the list of functions should even be expanded and some illustrative examples given at some later point in time, so it becomes useful also to people who need more than a novice's very first look at the subject and an overview of what the MS-DOS API is about. WP:NOTEVERYTHING does not apply here because the article is VERY far away from listing every possible detail, it is just the opposite, the tip of the iceberg. For a comprehensive list you would need several hundred, and to list every possible detail of these functions you would need several thousands of pages. RBIL may give you a feeling how much more information is actually required to use these functions reliably on a professional level. --Matthiaspaul (talk) 09:50, 12 July 2012 (UTC)[reply]
WP:NOTEVERYTHING states that "an article is a summary of accepted knowledge regarding its subject". Dumping a list of numbers with descriptions is far from summarising. I pointed to some previous consensus on the interpretation of WP:NOTEVERYTHING in a similar situation - that list of STOP error codes probably did not enable anyone to do any serious troubleshooting either. Comments? Keφr (talk) 11:21, 12 July 2012 (UTC)[reply]
Stop going around putting overly detailed tags on articles which by their nature are technical and definitely do not make a mass deletion like that again. Just because you do not understand something does not mean it is overly detailed. If I was to truly detail the Int 21 API then that list would easily triple in size at the very least. Asmpgmr (talk) 15:08, 12 July 2012 (UTC)[reply]
[edit]

Hello fellow Wikipedians,

I have just modified 2 external links on MS-DOS API. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:31, 29 May 2017 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:DOS_API&oldid=1201624880"