My go-to solution to booting an older Linux version on a newer GPU is `nomodeset` and possibly other flags that force-disable the use of device-specific drivers. I don't see how this is different on Windows.
That wasn’t a hypothetical, and yes, I looked for simple kernel cmdline parameters before hacking away at the VGA and UEFI framebuffer drivers in the kernel.
I’m not talking about KMS, that’s another ballgame altogether. You ship a fixed image starting up on unknown hardware that could have any card from 1999 to 2020 in it. You can’t load all drivers at startup because a) that’s crazy talk, b) many can’t be loaded simultaneously anyway. You can manually identify the VID and PID and create a database but it’s a monumental task, and you’re bound to miss some (and what about new releases?). You don’t want to ship with every driver under the sun anyway, because that’s huge, there are licensing issues, and many are buggy or error prone on recent kernel releases. All you want is a basic driver to give you a software-accelerated framebuffer and use the generic VGA/SVGA/XVGA/whatever standards to init the hardware, give you a workable resolution for GUI mode applications, query the monitor and use the EDID database to select a resolution and refresh rate supported by both the hardware and the attached display device, use the correct aspect ratio, avoid overscan or unnecessary scaling, etc. and give you an abstraction supported by your desktop environment including the window manager and your applications, without needing to hack away at every program you ship with to get them to support the sw framebuffer.
Xfree86 was such an effort but a) it’s long dead, and b) never really got there.
