In DPMI, interrupt 0x31 services 0x0000 and 0x0100 are capable of simultaneously allocating multiple protected-mode selectors in a single call. When that happens, both services return only the first allocated selector; the others are obtained by adding a fixed increment (repeatedly if necessary), whose value is obtainable from service 0x0003.
All the DPMI hosts I (somewhat superficially) tried this under — Borland’s, Windows 3.11, DOS/4GW and CWSDPMI — return the value 8 from this service, which means that descriptors are allocated in contiguous blocks (as the three least-significant bits do not index selectors, but determine the privilege level and choose between the GDT and the LDT). In principle though, nothing stops a DPMI host from using a larger multiple of 8.
The section of the DPMI specification describing the 0x0003 call (§8.4) does not explain at all why the DPMI host is allowed to do this or how it might be useful for the host to allocate descriptors non-contiguously. What purpose could this freedom serve? What does it afford implementations? Was there a DPMI host implementation that took advantage of it?
(I would prefer an official document or a statement from someone who worked on or was familiar with the development of the DPMI specification, but failing that, speculation may be enough.)
__AHINCR
...__AHINCR
seems to imply the value in protected mode is always 8 anyway, so it doesn’t really provide any justification for this call’s existence. Sure, you need to invoke it if you want to implement your own__AHINCR
portable to different DPMI hosts. But it might as well have not existed, with the DPMI contract specifying the increment as always 8. And yet it is there. What is it there for?DosGetHugeShift
did have varying results depending on the version of OS/2, so the API was useful even for protected-mode-only code.