Talk:DOS memory management

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology 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.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is supported by WikiProject Software.

Generalize

This article needs to be generalized to include memory managers used in systems with automatic garbage collection. Also, the detailed explanation of the memory management interfaces for C and C++ should either be removed, or moved to a subsection.-- Doug Bell (talk/contrib) 10:04, 13 January 2006 (UTC)[reply]

At the very least the Memory Manager page should NOT be redirected to "DOS memory management", but maybe to "Memory management". 88.161.162.107 (talk) 16:12, 21 January 2011 (UTC)[reply]

I believe the (nothrow) variants of new, new[], delete, delete[] are non-standard, but I cannot find much info on them anyway besides MSDN. Someone who is more knowledgeable should clarify the sentence or remove those functions. —Preceding unsigned comment added by 80.131.229.247 (talk) 20:34, 4 January 2009 (UTC)[reply]

Browsers that have trouble with 64 kb pages would be practically unusable on the Wikipedia now anyway; this is a very old limit (and I thought it was 32k that used to break old browsers?) I'd have to mock up a cut'n'paste with all the duplication cut out, but 64k is nearly 20 pages of text - even the Wikipedia should be able to explain something in less than 20 pages. --Wtshymanski (talk) 20:17, 10 February 2011 (UTC)[reply]

Suggest merge - Closed as: No merge

We have :

Shouldn't we put an end to the 20+ years of suffering and lump these all into one article, instead of giving several partially overlapping and contradictory explanations customized to each of these concepts? One weeps for the trees that have died for printed explanations of all this. --Wtshymanski (talk) 00:36, 12 December 2010 (UTC)[reply]

Fortunately Wikipedia is not paper. I'd prefer to see this article turned into an understandable overview of the subject, but some of the details are better to the individual articles. —Ruud 02:51, 12 December 2010 (UTC)[reply]

To be complete VCPI and DPMI should probably be included as well. but even merging the existing articles into one would already result in quite a large article, while all the articles have potential for expansion by going deeper into the API details. —Ruud 03:02, 12 December 2010 (UTC)[reply]

Wikipedia is not paper, true; but human being still have to *read* this stuff and understand it, and a more comprehensive overview here would help, and would cut down the repetitive explanation in the sub articles. Documenting dead APIs is probably not a mission for a general encyclopedia. --Wtshymanski (talk) 05:20, 12 December 2010 (UTC)[reply]

For a readable overview you will necessarily have to sacrifice some interesting and useful details. But I don't see why the two would be mutually exclusive? It's quite common to have an overview referring to more detailed articles with {{main}}. Furthermore, simple merging the article by copying and pasting them together will not result in anything more readable than the current separate articles, this will require rewriting this article mostly from the ground up anyway. —Ruud 13:55, 12 December 2010 (UTC)[reply]

Oh, agreed, but many articles need rewriting, and a simple merge of all that lot would probably lose 75% of its length after all the repetitions were cut out. --Wtshymanski (talk) 15:52, 12 December 2010 (UTC)[reply]

I think if we put all in one article, this would be far larger than 64 KiB - the upper limit for some browsers of systems with low memory. If this is not a problem, I would welcome a merger, too. Sae1962 (talk) 09:04, 10 February 2011 (UTC)[reply]

Whoa, merge half a dozen or more articles? Sounds a bit too ambitious. I'd start with just merging two. There is some overlap between this article and Expanded memory. I suggest a manual edit to weave non-redundant content on this page into that one, then this page could become a redirect to Expanded memory. Right now, Expanded memory manager actually redirects to that page, not this one.

I think what would be nice to make sense of all of these somewhat complicated memory schemes would be to create a new article titled, perhaps, "History (or timeline) of x86 DOS memory solutions". For someone too young to remember the era, or who was mostly on mainframes at the time (like myself) it would be helpful. I've contributed to the article Timeline of x86 DOS operating systems, read that for starters (still a work in progress). Here's what I have so far in a nutshell:

1. IBM PC and PC/XT w/ 640K are all there is and DOS memory management is fairly clean
2. PC/AT (286) introduces extended memory but only for RAM disks (not used much, I think)
and uses a BIOS service to avoid switching to protected mode
3. Intel produces an expansion card so Lotus 1-2-3 can have bigger spreadsheets, uses expanded
memory bank switching so it will run on 8086/8088 as well as 286, drivers supplied by board
manufacturer
4. MS-DOS 3.2 adds RAMDRIVE.SYS driver, supports RAM drives in expanded memory
5. Compaq Deskpro 386 has built-in hardware support for expanded memory, no expansion card needed
6. Phar Lap introduces first 386 DOS extender to use extended memory (but it's buggy)
7. Compaq DOS 3.31 introduces first (386) expanded memory manager which uses software to
simulate expanded memory using extended memory.
8. IBM finally supports expanded memory (DOS 4.0), but new version is buggy (paging problems)
9. Microsoft uses bank switching (expanded memory) for early versions of Windows
10. Lotus 1-2-3 release 3 uses extended memory via a VCPI-compatible 16-bit 80286 extender
11. DR-DOS 5.0 includes the MemoryMax "memory manager", the first memory management system to
allow loading TSRs, device drivers and the operating system into upper memory blocks, and the
operating system to be loaded into the high memory area.
12. Windows 3.0 supports DPMI, first widely adopted Windows, developers start writing for Windows
instead of DOS, to avoid memory management issues.
This article is mostly about items 7 and 11 on the above list.

64.128.111.166 (talk) 01:46, 27 February 2011 (UTC) 64.128.111.166 (talk) 16:49, 28 February 2011 (UTC) 99.168.79.236 (talk) 05:09, 7 March 2011 (UTC)[reply]

Strongly oppose. This is an encyclopedia, not a summarized research page. Merging them into one will result in information getting condensed instead of the detailed articles we have right now or the merged article will become too long. - xpclient ^Talk 07:52, 1 June 2011 (UTC)[reply]

Well, the "detailed" articles explain the *same* details over and over again.It would be a little more rational to explain the details in one place. --Wtshymanski (talk) 16:26, 1 June 2011 (UTC)[reply]

Now that the discussion has stalled for more than two years and the merge proposal saw no support at all (except for by its proposer Wtshymanski), I have removed the merge proposal templates from the articles.

What I find worrysome, however, is the fact, that despite the rather clear outcome of the discussion above against a merge, two articles, High memory area and A20 line, were redirected into DOS memory management by Wtshymanski after the discussion, anyway ([1], [2]), and two attempts by other editors to recreate the articles after these bold changes were reverted by this editor as well. I am therefore restoring the old contents of these articles again now. --Matthiaspaul (talk) 12:07, 13 August 2013 (UTC)[reply]

When people say Wikipedia is outdated...

they usually refer to how it looks, but I couldn't help notice that Windows memory management is red link. Since I can't even add the following informative (and mildly amusing) talks to any article-space page, I'm gonna list them here:

HTH. JMP EAX (talk) 18:30, 1 September 2014 (UTC)[reply]

And for Win8 there's this, which could probably go in one of the articles dedicated to Metro apps. JMP EAX (talk) 18:45, 1 September 2014 (UTC)[reply]

Global EMM Import Specification

Global EMM Import Specification redirects to this article. But the term is not mentioned in the article at all. What is it? --RokerHRO (talk) 09:09, 21 October 2015 (UTC)[reply]

@Matthiaspaul:? Wbm1058 (talk) 12:05, 21 October 2015 (UTC)[reply]

The Global EMM Import Specification (GEMMIS) is an for the most part undocumented interface provided by protected mode DOS memory managers like EMM386 etc. giving access to internal data describing the various kinds of memory blocks already allocated through various APIs in the system. Its main purpose is to allow a seamless handover to the Windows 3.xx/4.xx memory manager (and back). It is also known as Windows 386 Paging Import Specification and V86MMGR Paging Import. If the DOS memory manager does not support it, Windows may not be able to reliably detect prior memory usage, to varying effects ranging from "missing" memory in virtual DOS boxes to crashes (when Windows makes wrong assumptions on memory utilization).

GEMMIS was important and is complex enough to warrant an article on its own, that's why I added the "R with possibilities" tag. I have changed the link to point to EMM386 for now, as it has a short description on it already.

--Matthiaspaul (talk) 22:53, 21 October 2015 (UTC)[reply]

Binary Prefixes

Can we get rid of the binary prefixes (mebibytes, etc) scattered throughout this article? No reference materials written about the PC architecture in its contemporary development ever used these, and they don't make sense used in this article. Denverite (talk) 16:54, 25 December 2015 (UTC)[reply]

I support this request. I don't like distracting revisionist newspeak at the best of times, least of all when I'm trying to learn things established as an important foundation of what happened in many later systems. Anyone who knows that a byte is binary, and understands the importance of base 2 and binary multiples in computing knows that a kilobyte is, and always WILL be, 1024 bytes. Anyone who arrives late to this long period of computing development insisting on new methods of description when it is the original context we need to understand, is guilty of dangerous revisionism. By forcing EVERY example they find to re-speak it their way, and ONLY their way, is 'cancel culture' at its worst. 81.187.19.110 (talk) 03:21, 29 December 2020 (UTC)[reply]