Windows® Internals, Sixth Edition, Part 1

On ACPI systems, you can obtain this information in a slightly easier way by reading the extended output of the !acpiirqarb command introduced earlier. As part of its output, it displays the IRQ to IDT mapping table:Interrupt Controller (Inputs: 0x0-0x17 Dev: 0000000000000000): (00)Cur:IDT-a1 Ref-1 edg hi Pos:IDT-00 Ref-0 edg hi (01)Cur:IDT-81 Ref-1 edg hi Pos:IDT-00 Ref-0 edg hi (02)Cur:IDT-00 Ref-0 edg hi Pos:IDT-00 Ref-0 edg hi (03)Cur:IDT-00 Ref-0 edg hi Pos:IDT-00 Ref-0 edg hi (04)Cur:IDT-00 Ref-0 edg hi Pos:IDT-00 Ref-0 edg hi (05)Cur:IDT-00 Ref-0 edg hi Pos:IDT-00 Ref-0 edg hi (06)Cur:IDT-00 Ref-0 edg hi Pos:IDT-00 Ref-0 edg hi (07)Cur:IDT-00 Ref-0 edg hi Pos:IDT-00 Ref-0 edg hi (08)Cur:IDT-71 Ref-1 edg hi Pos:IDT-00 Ref-0 edg hi (09)Cur:IDT-b1 Ref-1 lev hi Pos:IDT-00 Ref-0 edg hi (0a)Cur:IDT-00 Ref-0 edg hi Pos:IDT-00 Ref-0 edg hi (0b)Cur:IDT-00 Ref-0 edg hi Pos:IDT-00 Ref-0 edg hi (0c)Cur:IDT-91 Ref-1 edg hi Pos:IDT-00 Ref-0 edg hi (0d)Cur:IDT-61 Ref-1 edg hi Pos:IDT-00 Ref-0 edg hi (0e)Cur:IDT-82 Ref-1 edg hi Pos:IDT-00 Ref-0 edg hi (0f)Cur:IDT-72 Ref-1 edg hi Pos:IDT-00 Ref-0 edg hi (10)Cur:IDT-51 Ref-3 lev low Pos:IDT-00 Ref-0 edg hi (11)Cur:IDT-b2 Ref-1 lev low Pos:IDT-00 Ref-0 edg hi (12)Cur:IDT-a2 Ref-5 lev low Pos:IDT-00 Ref-0 edg hi (13)Cur:IDT-92 Ref-1 lev low Pos:IDT-00 Ref-0 edg hi (14)Cur:IDT-62 Ref-2 lev low Pos:IDT-00 Ref-0 edg hi (15)Cur:IDT-a3 Ref-2 lev low Pos:IDT-00 Ref-0 edg hi (16)Cur:IDT-b3 Ref-1 lev low Pos:IDT-00 Ref-0 edg hi (17)Cur:IDT-52 Ref-1 lev low Pos:IDT-00 Ref-0 edg hi

As expected, IRQ 1 is associated with IDT entry 0x81. For more information on device objects, resources, and other related concepts, see Chapter 8, “I/O System,” in Part 2.

The ISR’s address for the interrupt object is stored in the ServiceRoutine field (which is what !idt displays in its output), and the interrupt code that actually executes when an interrupt occurs is stored in the DispatchCode array at the end of the interrupt object. The interrupt code stored there is programmed to build the trap frame on the stack and then call the function stored in the DispatchAddress field (KiInterruptDispatch in the example), passing it a pointer to the interrupt object.

Windows and Real-Time Processing

Deadline requirements, either hard or soft, characterize real-time environments. Hard real-time systems (for example, a nuclear power plant control system) have deadlines the system must meet to avoid catastrophic failures, such as loss of equipment or life. Soft real-time systems (for example, a car’s fuel-economy optimization system) have deadlines the system can miss, but timeliness is still a desirable trait. In real-time systems, computers have sensor input devices and control output devices. The designer of a real-time computer system must know worst-case delays between the time an input device generates an interrupt and the time the device’s driver can control the output device to respond. This worst-case analysis must take into account the delays the operating system introduces as well as the delays the application and device drivers impose.

Because Windows doesn’t enable controlled prioritization of device IRQs and user-level applications execute only when a processor’s IRQL is at passive level, Windows isn’t typically suitable as a real-time operating system. The system’s devices and device drivers—not Windows—ultimately determine the worst-case delay. This factor becomes a problem when the real-time system’s designer uses off-the-shelf hardware. The designer can have difficulty determining how long every off-the-shelf device’s ISR or DPC might take in the worst case. Even after testing, the designer can’t guarantee that a special case in a live system won’t cause the system to miss an important deadline. Furthermore, the sum of all the delays a system’s DPCs and ISRs can introduce usually far exceeds the tolerance of a time-sensitive system.

Although many types of embedded systems (for example, printers and automotive computers) have real-time requirements, Windows Embedded Standard 7 doesn’t have real-time characteristics. It is simply a version of Windows 7 that makes it possible to produce small-footprint versions of Windows 7 suitable for running on devices with limited resources. For example, a device that has no networking capability would omit all the Windows 7 components related to networking, including network management tools and adapter and protocol stack device drivers.