Editing High memory area (section)

==Further reading==
* {{cite web |title=Who needs the address wraparound, anyway? |date=2011-09-13 |author-first=Michal |author-last=Necasek |work=OS/2 Museum |url=http://www.os2museum.com/wp/who-needs-the-address-wraparound-anyway/ |access-date=2020-02-19 |url-status=live |archive-url=https://web.archive.org/web/20200219004644/http://www.os2museum.com/wp/who-needs-the-address-wraparound-anyway/ |archive-date=2020-02-19 |quote=[…] [[86-DOS]], and hence [[PC&nbsp;DOS]]/[[MS-DOS]], used a clever trick. The byte at offset 5 of the [[Program Segment Prefix|PSP]] contained a far call opcode (9Ah); the word at offset 6 of the PSP contained the appropriate value to indicate program segment size, and also the offset part of the far call. The word at offset 8, which served as the segment part of the far call, was crafted such that when combined with the offset, it would wrap around (a well understood feature of the [[8086]] CPU) and point to address 0:C0h, which contains interrupt vector 30h. […] the [[CALL 5 (DOS)|CALL 5]] interface works even in DOS emulation under Windows NT and OS/2, and those systems most certainly cannot run with the [[A20 line]] disabled. How does that work then? […] Rather than chopping off address bits, the system mirrors the five bytes at 0:C0h at 1000C0h. The same technique had been in fact used in DOS 5 and above running with <kbd>[[DOS (CONFIG.SYS directive)|DOS]]=HIGH</kbd>. In that case, DOS makes sure that linear address 1000C0h contains the appropriate far call. […]}}
* {{cite web |title=High Memory Area (HMA) |work=The PC Guide |version=2.2.0 |date=2001-04-17 |orig-date=1997 |author-first=Charles M. |author-last=Kozierok |url=http://www.pcguide.com/ref/ram/logicHMA-c.html |url-status=dead |access-date=15 October 2006 |archive-url=https://web.archive.org/web/20061016143339/http://www.pcguide.com/ref/ram/logicHMA-c.html |archive-date=2006-10-16}}
* {{cite web |title=Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1 |author-first=Matthias R. |author-last=Paul |work=freedos-dev |date=2002-04-11 |url=https://marc.info/?l=freedos-dev&m=101853130816682&w=2 |access-date=2020-02-21 |url-status=live |archive-url=https://web.archive.org/web/20200221130238/https://marc.info/?l=freedos-dev&m=101853130816682&w=2 |archive-date=2020-02-21 |quote=[…] in case of such [[fat pointer|mangled pointer]]s […] many years ago Axel<!-- Axel C. Frinke --> and I were thinking about a way how to use *one* entry point into a driver for multiple interrupt vectors (as this would save us a lot of space for the multiple entry points and the more or less identical startup/exit framing code in all of them), and then switch to the different interrupt handlers internally. For example: 1234h:0000h […] 1233h:0010h […] 1232h:0020h […] 1231h:0030h […] 1230h:0040h […] all point to exactly the same entry point. If you hook INT 21h onto 1234h:0000h and INT 2Fh onto 1233h:0010h, and so on, they would all go through the same "loophole", but you would still be able to distinguish between them and branch into the different handlers internally. Think of a "compressed" entry point into a [[A20 line|A20]] stub for HMA loading. This works as long as no program starts doing segment:offset magics. […] Contrast this with the opposite approach to have multiple entry points (maybe even supporting [[IBM]]'s [[IBM Interrupt Sharing Protocol|Interrupt Sharing Protocol]]), which consumes much more memory if you hook many interrupts. […] We came to the result that this would most probably not be save in practise because you never know if other drivers normalize or denormalize pointers, for what reasons ever. […]}}

{{DEFAULTSORT:High Memory Area}}
[[Category:X86 memory management]]
[[Category:DOS memory management]]