The fan spun. The VGA controller retrained. The disk clicked. And then—the NT login prompt appeared, exactly as she had left it. Not a reboot. A resume .
She ran !acpi in the kernel debugger. The sleep state transition log showed:
S3 entry: PASSED S3 resume: PASSED Device power map: CONSISTENT She leaned back. The ghost in the power state had been tamed—not by fixing the firmware, but by building a driver that was smarter, more paranoid, and more patient than the hardware it drove. acpi driver for nt
And in late 1999, Acpi.sys quietly appeared in Windows 2000 Beta 3. Most users never knew its name. But every time a laptop woke from sleep without losing your open documents, a tiny piece of Lina’s paranoid, beautiful driver had just negotiated peace between the operating system and the lying firmware below.
That was the dirty secret. Every BIOS vendor implemented ACPI differently. Some forgot to mark the video card as a wake-capable device. Others embedded AML loops that would run for minutes if interpreted naively. One particularly cursed laptop from Compaq had a _BIF (Battery Information) method that called itself recursively. The fan spun
The new ACPI spec promised elegance: an OS-controlled power management stack, device hierarchy, thermal zones, and S3 sleep (the “suspend to RAM” that Apple already did beautifully). But NT was a dinosaur. Its kernel was built on the assumption that it , and only it, owned the hardware. ACPI required the OS to hand control back to a firmware interpreter—a tiny, bug-ridden virtual machine called the ACPI Machine Language (AML) interpreter.
Redmond, Building 27, the “Legacy Cage” And then—the NT login prompt appeared, exactly as
“It’s not a driver,” said Mark, her lead, tossing a 400-page spec on her desk. “It’s a theological crisis .”