Why does the ‘Get Next Selector Increment Value’ DPMI call exist?

Question

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.)

Answer 1

I don’t have any insider knowledge on this topic, so this is purely speculation.

I suspect the call exists because there was potential variation in similar mechanisms available at the time, which turned out to be useful at around the same time as the DPMI specification was written (and before the first drafts were published). There’s a decent chance that Ralph Lipe, the original author of the DPMI specification, was aware of memory allocation rules in at least two contemporaneous operating environments, OS/2 and Windows 2.

OS/2 1.x ran in protected mode on 286s and supported allocations larger than 64KiB, in a similar fashion to what ended up in the DPMI specification. This can be seen in the Family API functions DosAllocHuge and DosGetHugeShift; native OS/2 applications also had access to corresponding variables (whose values were constant during any given boot of OS/2), DOSHUGEINCR and DOSHUGESHIFT (see Inside OS/2, section 9.2.2, for details).

Windows 2 didn’t run applications in protected mode, but it did provide a similar “API”, through the __AHINCR and __AHSHIFT variables in the kernel, and compiler writers used that to implement far pointer arithmetic. This famously helped the switch to running applications in protected mode in Windows 3, since correctly-written applications could run as-is in either real or protected mode even if they needed segment arithmetic. (This wasn’t new to Windows 3; OS/2 already allowed writing mode-agnostic programs, using the aforementioned Family API.) See also Why the DOS extender and DPMI were unavailable to DOS programs on 286 standard mode of Windows 3.0.

Significantly in the context of this question, OS/2 1.0 used a shift of 4, not 3 (it interleaved private and shared LDT entries), and OS/2 1.1 used a shift of 5 (it interleaved one private LDT entry for every three shared LDT entries). The Design of OS/2 section 6.2.4.1.2 explains this in more detail. This would have provided two reasons for allowing a non-constant selector gap in the DPMI specification: anyone familiar with 286 protected mode would have been aware that the minimum gap there is 8, not 16, so a DPMI host could conceivably want to use 8; and varying the gap had already been used, between OS/2 1.0 and 1.1.

(I haven’t checked the value returned by OS/2’s DPMI host in later versions of OS/2. OS/2 2.x and later used a flat memory model, so this might not be significant anyway.)