Comment by rasz

1 year ago

From my 20 year memory it was other way around:

There is a specification.

Taiwanese hardware OEMs suck at programming, make mistakes.

Windows ACPI implementation is build to detect and work around those bugs. Think Win 3.x version of SimCity 2000 read after free bug and Microsoft hardcoding workaround in Windows 95 https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

>Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.

Everyone else stumbles on those badly implemented ACPI Tables which seemingly work just fine in Windows land.

3 comments

rasz

Reply
keep_reading  1 year ago

FreeBSD in 2023 is still masquerading as "Microsoft Windows NT" in order for things to work correctly. It has been this way since 2004. It works fine in "Windows Land" because the hardware is literally special-casing behavior for Windows!

  /*
   * OS name, used for the _OS object. The _OS object is essentially obsolete,
   * but there is a large base of ASL/AML code in existing machines that check
   * for the string below. The use of this string usually guarantees that
   * the ASL will execute down the most tested code path. Also, there is some
   * code that will not execute the _OSI method unless _OS matches the string
   * below. Therefore, change this string at your own risk.
   */
  #define ACPI_OS_NAME                    "Microsoft Windows NT"

https://cgit.freebsd.org/src/tree/sys/contrib/dev/acpica/inc...

  • mjg59  1 year ago

    _OS is basically irrelevant, _OSI has been used for over 20 years now. The right way to think about the values the OS presents to the firmware is in terms of a contract between the OS and the firmware in terms of mutual expectations. Windows effectively embodies a contract - the behaviour of any given Windows release will remain constant. There's no way to define an equivalent definition for Linux (because Linux's behaviour keeps changing to match hardware expectations), so it makes more sense for us to attempt to mimic the stable contract Windows provides (and it helps that that's the contract that the vendor has tested against in the first place). I went into this oh good lord over 15 years ago: https://mjg59.livejournal.com/96129.html