Some time ago I wrote about IBM PC XENIX 1.0 and why it won’t work on 386 and later processors. Thanks to a kind reader, I’ve been able to analyze the object files used to link the kernel, and I believe I now understand exactly how XENIX uses the reserved space in LDT descriptors and why my patched kernel doesn’t fully work. This problem is likely common to all early editions of Microsoft XENIX 3.0, not just the IBM-branded release.
What XENIX stores in the reserved word is the size of the corresponding segment on disk; the value for a given descriptor is returned by a kernel-internal function called dscrsw(). This is used when an executable file gets loaded and also when swapped out. The latter is likely the reason why the segment size on file is stored in the descriptor table at all.
Incidentally, why is the troublemaking routine called dscrsw anyway? The answer to that riddle can be found in /usr/include/sys/relsym86.h: The last word of the descriptor table structure is defined as d_sw, or “software defined word, unused”. If only. Continue reading






