Motherboard-dependent code

At the very least, an OS needs to be able to talk to the motherboard's BIOS.

OS talks to BIOS, figures out at least what kind of unique hardware is present, then loads the drivers for that hardware.

The fact that the BIOS *could* be different between motherboards (even though it's usually pretty standardized) means that the OS contains motherboard-specific code.

Ok, I was confused because I thought: how does it talk to the BIOS? Calling the BIOS requires 16-bit real mode, while the HAL runs in 32/64bit protected mode at all times.

It turns out they actually wrote a 16-bit emulator in HAL.dll to deal with this :D

Though I still wonder whether they also deal with PIC/APIC stuff in the HAL. Are those things integrated into CPUs nowadays?

Yes, always. An operating system kernel is the bit that lies between application software and actual hardware; it must contain hardware-specific code. Hardware includes things like the PCI, USB, SPI, I2C, 1W and other buses which are used to interconnect various other peripherals to the motherboard like persistent storage, communications, video and audio renderers, inputs, sensors, and so forth.

Modern commodity computers use specialized software embedded on the motherboard to help identify and sometime control some devices (BIOS, EFI, UEFI) or shipped in boot ROMS (uboot, redboot, etc) but by and large once the boot sequence is complete these software are ignored and bypassed. Instead, the OS has subprograms called device drivers that deal with the specifics of the hardware on which the OS is running. Those drivers may be runtime loadable, like on Microsoft Windows or desktop GNU/Linux or they may be hardcoded into the OS kernel itself because the hardware is strictly defined at compile time like on Android/Linux or ChromeOS/Linux. In Linux, for example, there are PCI, SCSI, SPI, I2C, 1W, firewire and many other more obscure drivers for dealing directly with what's available on the motherboard (for desktops and servers) or the SOC (for everything else). Device drivers work in a hierarchical fashion become more specialized as you ascend the tree: a keyboard, for instance, might physically plug in to a USB port, and the keyboard driver talks to the USB driver talks to the PCI driver to get data from a clicky MX Cherry blue W key to the kernel HID driver, where it gets dispatched to my game and my avatar appears to walk north.