Editing Intel 8259 (section)

=== DOS and Windows ===
[[Image:NEC D8259AC.jpg|thumb|NEC D8259AC, used on the original [[IBM Personal Computer|IBM PC]] motherboard.]]
Programming an 8259 in conjunction with [[DOS]] and [[Microsoft Windows]] has introduced a number of confusing issues for the sake of backwards compatibility, which extends as far back as the original PC introduced in 1981.

The first issue is more or less the root of the second issue. DOS device drivers are expected to send a non-specific EOI to the 8259s when they finish servicing their device. This prevents the use of any of the 8259's other EOI modes in DOS, and excludes the differentiation between device interrupts rerouted from the master 8259 to the slave 8259.

The second issue deals with the use of IRQ2 and IRQ9 from the introduction of a slave 8259 in the PC/AT. The slave 8259's INT output is connected to the master's IR2. The IRQ2 line of the ISA bus, originally connected to this IR2, was rerouted to IR1 of the slave. Thus the old IRQ2 line now generates IRQ9 in the CPU. To allow backwards compatibility with DOS device drivers that still set up for IRQ2, a handler is installed by the BIOS for IRQ9 that redirects interrupts to the original IRQ2 handler.

In the PC/clone family of platforms, the BIOS (and thus also DOS) traditionally maps the master 8259 interrupt requests (IRQ0–IRQ7) to interrupt vector offset 8 (corresponding to INT 08–INT 0Fh), and when present, the PC/AT’s slave 8259 is mapped to interrupt vector offset 112 (INT 70–INT 77h). This was done despite the first 32 (INT 00-INT 1F) interrupt vectors being reserved by the processor for internal exceptions.

This meant that, on later chips, handlers for lower-numbered vectors needed to differentiate between three causes:

* faults, exceptions, and traps caused incidentally;

* interrupts caused by IRQ or NMI, potentially including spurious IRQs; and

* deliberate calls from software executing INT, breakpoint, or indirect far CALL/JMP instructions, as might be used to interact with the BIOS, operating system, or device drivers.

Because of this, most operating systems that don’t make use of the BIOS will configure the interrupt controller(s) to avoid the reserved vector range entirely. In protected mode, the OS can restrict use of INT instructions to specific vectors only (e.g., Linux exposes INT 80h for system calls), and any attempt to use a disallowed vector will raise a protection fault.

This avoids some of the need for cause determination in interrupt vector handlers, although spurious interrupts and IRQ-sharing can still complicate matters. Fortunately, most peripheral devices can be queried with regards to outstanding IRQs, and if no source can be found an interrupt can be treated as spurious or ignored altogether.