Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Paul <nospam@needed.invalid>
Newsgroups: comp.os.linux.advocacy,alt.comp.os.windows-11
Subject: Re: Dimdows Decay Syndrome Continues
Date: Mon, 2 Jun 2025 23:27:46 -0400
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <101lq3k$3pljv$1@dont-email.me>
References: <vnm582$9u05$1@dont-email.me> <vra4mg$vo6i$2@dont-email.me>
 <101la0o$3ihfc$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 03 Jun 2025 05:27:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b1002a92ad0ea8b2cdeb52d6f38fdf60";
	logging-data="3987071"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Uo84ZhdNs0FgcOLzJ6sd+wuGG0uttdTA="
User-Agent: Ratcatcher/2.0.0.25 (Windows/20130802)
Cancel-Lock: sha1:NYRijwnJfIebecBPPKF3TVnXpmk=
In-Reply-To: <101la0o$3ihfc$1@dont-email.me>
Content-Language: en-US

On Mon, 6/2/2025 6:53 PM, Lawrence D'Oliveiro wrote:
> This time, the bugs in the update are so bad that Microsoft has had to
> issue an emergency, unscheduled update to fix the update
> <https://www.computerworld.com/article/4000386/microsoft-issues-out-of-band-patches-for-windows-11-startup-failure.html>.
> 
> There are all kinds of lovely excuses in the article about how testing
> can never cover every real-world possibility. But the fact remains
> that the the frequency of this problem on Windows is way greater than
> on any other comparable platform.
> 

Gee, it looks like it has happened before.

https://answers.microsoft.com/en-us/windows/forum/all/recovery-error-acpisys-your-pc-needs-to-be/42cf8731-6775-4ab4-ac8e-c2db82aaf2bf

A Reddit thread says:

   "ACPI.sys is the AML interpreter. The AML code is part of the BIOS, try updating the BIOS"

https://en.wikipedia.org/wiki/ACPI#AML

   At the BIOS development time, AML bytecode is compiled from the ASL (ACPI Source Language) code.[8][9]

   [8] "ACPI in FreeBSD"   http://www.usenix.org/events/usenix02/tech/freenix/full_papers/watanabe/watanabe.ps
   [9] "ACPI in Linux"     https://www.kernel.org/doc/ols/2005/ols2005v1-pages-59-76.pdf

That at least hints that ACPI.sys would have to deal with
the quirks in various released computer hardware (some kind of
table passed by the BIOS).

And you also happen to know, that the BIOS emulation in virtual machine hosting,
is a "shell" of a BIOS. The implementation is incomplete. Just yesterday I got
a taste of this while installing Windows 7 in a VM, to take pictures. The
legacy BIOS install worked OK, but when I switched on UEFI in the VM,
the install disc basically crashed. And that's the interaction with
an incomplete UEFI design. When I switched to physical hardware (4930K), the
UEFI install sequence completed with no problem at all.

That's an actual frictional area on all OSes.

When you buy a Lemon Laptop with bad AML code in it, you are constantly
dealing with shit issues like that. Usually, the laptop company did not
make the laptop themselves, they got it from an ODM, and the ODM does
not provide continuing maintenance contract. The OEM is supposed to provide
maintenance to end customers.

Maybe in a Linux thread, you would see a reference to "you should install CoreBoot"
when it looks like the laptop has bad code in it.

It means that some amount of "quirks code" would be in ACPI.sys.
And in a VM with an incomplete (and *never* gets fixed) UEFI,
there is always the possibility of a bad ending. The people who
write hosting software, they only work on their skeletal UEFI
code, until "something booted, lets go for lunch".

So while we could have a discussion about complexity, this
is an area with a "history", and nobody is immune to getting
rough treatment. It's pretty hard to predict in advance, what
products have bad code in them, until someone among end users
tests the hardware.

Who knows, maybe the article would be less eventful, if it
contained details, instances, A vs B, so we can see what
percentage of users might be affected.

   Paul