I would like to disable these compatibility lists on Windows and to actually be able to report any issues and crashes to devs. But this might be a very Linux mindset thing for me to want.

▲

estimator7292 8 hours ago | parent [-]

The Linux kernel contains biiiig piles of hacks for individual motherboards, systems, devices. It's like this at every level everywhere, unfortunately. I mean, it was only very recently that your 64 core CPU stopped pretending to be an 8086 during initial boot

▲

codedokode 4 hours ago | parent | next [-]

Unlike Microsoft's hacks, these hacks do not include self-modifying code as I understand. I hope code with "detours" (a beautiful French-sounding euphemism for monkey-patching) is not accepted in Linux kernel and libraries.

▲

leeter 4 hours ago | parent | prev [-]

> it was only very recently that your 64 core CPU stopped pretending to be an 8086 during initial boot

Still Does[1]:

>> After a RESET or INIT, the processor is operating in 16-bit real mode. Normally within real mode, the code-segment base-address is formed by shifting the CS-selector value left four bits. The base address is then added to the value in EIP to form the physical address into memory. As a result, the processor can only address the first 1 Mbyte of memory when in real mode.

The UEFI hands off the boot CPU to the OS loader (GRUB/NTLoader etc) in long mode. But when the OS brings up any CPU that is not the initial bootstrap CPU via the interprocessor interrupt... that CPU comes up in 16bit* real mode.

[1]: https://docs.amd.com/v/u/en-US/40332-PUB_4.08 (the intel one says the same thing last I checked, Intel has discussed changing this... but AFAIK has not yet)

* This is a lie... note how the quote references EIP and not IP? That's because it's actually booting up in Unreal mode. Hence the initial instruction run is actually at 0xFFFF_FFF0 IIRC

https://en.wikipedia.org/wiki/Unreal_mode

▲

codedokode 4 hours ago | parent [-]

As I remember, for 10 or 20 years on x86 execution starts at 32-bit address like 0xffff_0000:0000, not 0xffff:0000 which was used in 8086, am I wrong? Stumbled upon this when tried to disassemble BIOS.

	▲	leeter 4 hours ago \| parent [-]
		You are correct, I need to edit my post because they both boot up in unreal mode. The 32bit Segment limit is an unreal mode thing.