Editing Dynamic dispatch (section)

==Further reading==
* {{cite book |title=Inside the C++ Object Model |author-first=Stanley B. |author-last=Lippman |author-link=Stanley B. Lippman |date=1996 |publisher=[[Addison-Wesley]] |isbn=0-201-83454-5}}
* {{cite newsgroup |title=GEOS/NDO info for RBIL62? |author-first1=Marcus |author-last1=Groeber |author-first2=Edward "Ed" |author-last2=Di Geronimo, Jr. |author-first3=Matthias R. |author-last3=Paul |date=2002-03-02 |orig-date=2002-02-24 |newsgroup=comp.os.geos.programmer |url=https://groups.google.com/d/msg/comp.os.geos.programmer/8NNPJ4VU23A/cucVV95kf9oJ |access-date=2019-04-20 |url-status=live |archive-url=https://archive.today/20190420111421/https://groups.google.com/forum/%23!msg/comp.os.geos.programmer/8NNPJ4VU23A/cucVV95kf9oJ |archive-date=2019-04-20 |quote=[…] The reason [[PC/GEOS|Geos]] needs 16 interrupts is because the scheme is used to convert inter-segment ("far") function calls into interrupts, without changing the size of the code. The reason this is done so that "something" (the kernel) can hook itself into every inter-segment call made by a Geos application and make sure that the proper code segments are loaded from [[virtual memory]] and locked down. In [[DOS]] terms, this would be comparable to an [[overlay (programming)|overlay]] loader, but one that can be added without requiring explicit support from the compiler or the application. What happens is something like this: […] 1. The real mode compiler generates an instruction like this: CALL [[segment:offset addressing (x86)|<segment>:<offset>]] -> 9A <offlow><offhigh><seglow><seghigh> with <seglow><seghigh> normally being defined as an address that must be fixed up at load time depending on the address where the code has been placed. […] 2. The Geos linker turns this into something else: INT 8xh -> CD 8x […] DB <seghigh>,<offlow>,<offhigh> […] Note that this is again five bytes, so it can be fixed up "in place". Now the problem is that an interrupt requires two bytes, while a CALL FAR instruction only needs one. As a result, the 32-bit vector (<seg><ofs>) must be compressed into 24 bits. […] This is achieved by two things: First, the <seg> address is encoded as a "handle" to the segment, whose lowest [[nibble]] is always zero. This saves four bits. In addition […] the remaining four bits go into the low nibble of the interrupt vector, thus creating anything from INT 80h to 8Fh. […] The interrupt handler for all those vectors is the same. It will "unpack" the address from the three-and-a-half byte notation, look up the absolute address of the segment, and forward the call, after having done its virtual memory loading thing... Return from the call will also pass through the corresponding unlocking code. […] The low nibble of the interrupt vector (80h–8Fh) holds bit 4 through 7 of the segment handle. Bit 0 to 3 of a segment handle are (by definition of a Geos handle) always 0. […] all Geos API run through the "overlay" scheme […]: when a Geos application is loaded into memory, the loader will automatically replace calls to functions in the system libraries by the corresponding INT-based calls. Anyway, these are not constant, but depend on the handle assigned to the library's code segment. […] Geos was originally intended to be converted to [[protected mode]] very early on […], with [[real mode]] only being a "legacy option" […] almost every single line of assembly code is ready for it […]}}
* {{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 mangled pointers […] 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 [[high memory area|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. […]}} (NB. Something similar to "[[fat pointer]]s" specifically for [[Intel]]'s [[real-mode]] [[segment:offset addressing (x86)|segment:offset addressing]] on [[x86]] processors, containing both a deliberately denormalized pointer to a shared code entry point and some info to still distinguish the different callers in the shared code. While, in an [[open system (computing)|open system]], pointer-normalizing 3rd-party instances (in other drivers or applications) cannot be ruled out completely on [[public interface]]s, the scheme can be used safely on internal interfaces to avoid redundant entry code sequences.)
* {{cite journal |title=C's Biggest Mistake |author-first=Walter |author-last=Bright |author-link=Walter Bright |date=2009-12-22 |journal=[[Digital Mars]] |url=https://digitalmars.com/articles/C-biggest-mistake.html |access-date=2022-07-11 |url-status=live |archive-url=https://web.archive.org/web/20220608050019/https://www.digitalmars.com/articles/C-biggest-mistake.html |archive-date=2022-06-08}} [<!-- https://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625 -->https://web.archive.org/web/20220711181007/https://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625]
* {{cite web |title=A Fat Pointer Library |author-first=Daniel |author-last=Holden |date=2015 |work=Cello: High Level C |url=https://libcello.org/learn/a-fat-pointer-library |access-date=2022-07-11 |url-status=live |archive-url=https://web.archive.org/web/20220711181009/https://libcello.org/learn/a-fat-pointer-library |archive-date=2022-07-11}}

{{DEFAULTSORT:Dynamic Dispatch}}
[[Category:Polymorphism (computer science)]]
[[Category:Method (computer programming)]]