Eclipse Community

Hello! Recently I installed Windows Vista on an old Lenovo Ideapad 100-15IBY in the hopes of potentially running older games on this piece of hardware (even though OS might not be very era specific when you compare it with the release date of the laptop). A lot of people in my research said that Vista shouldn't even be running on such a piece of hardware and that it's a miracle it even boots, but installing wasn't painful.
Using a combination of the Extended Kernel, this forum (for the WIFI driver and USB driver) and headbashing, I managed to install most drivers or at least give devices a name in device manager (except Bluetooth which doesn't have any Vista compatible drivers from what I found, but it doesn't bother me because I don't plan on making use of it). Some were even compatible out of the box! like the audio driver, webcam driver and chipset driver.

Optional hardware functionality aside, the only very essential thing not functioning is the GPU driver. No amount of INF editing, installer fooling or patching attempts got me to a functional driver. Manual installation through device manager lead to either error code 39 or 42, and in some very rare instances a "succesful" driver install message that after a reboot returns back to the errors mentioned. Using the Extended Kernel gave barely any improvements here (besides allowing the Intel setup to launch), spoofing to Windows 7 lead to a straight up error message saying it couldn't install devices (see screenshot) and spoofing to Windows 10 made it look like it was installing but upon further looking at the log it was only copying the uninstall files (how ironic... check screenshots, one was skipped due to it just copying language files). Windows 8(.1) remains untested, but I doubt it'll give any better results. I must also stress that the driver provided on the Extended Kernel page DOES NOT work with this GPU, despite the device ID being there (PCI\VEN_8086&DEV_0166 if I'm not mistaken), it also applies to any driver that has said ID. Annoyingly, the setup also has it's own OS check, which means it doesn't rely on the INF like other drivers to determine if it is compatible or not. For most of this testing I have been using the latest version available for the driver as pinpointing older versions for this exact IGPU seems to be a bit challenging.

If there have been patch attempts somewhere deep on the internet that I haven't stumbled upon yet, I am more than willing to test them (including any others that are being made). I'm fine with any kind of control panel version and limited (if any) (modern) OpenGL support as most that I'm looking for is DirectX functionality. I have seen on this forum that NTOSKRNL Emu_Extender paired with the Extended Kernel can allow for installation of the modern driver with some kind of functionality, but this is not something I have tried on my system yet, although I am more than willing to do the necessary steps if this means I can get an actual driver installed. I have also read on different forums that some versions of the Extended Kernal are more stable than other versions, therefore I will also mention that I am using the latest version of it from March 9th 2023. To help the brainstorming that may occur, the BayTrail-M architecture seems to be based on Ivy Bridge, which coincidentally is the last stable type of CPU variant under Vista. Maybe that information could be used to discover a weakness or advantage!

Thanks in advance for any kind of information or help that will be provided!

I assume this is Haswell or later based, and I wish you good luck with that.

K4sum1 wrote: ↑07 Aug 2024, 08:36 I assume this is Haswell or later based, and I wish you good luck with that.

Damn, unfortunate. I researched the CPU more and ended up finding that it's based on Silvermont which means it is most likely Haswell. The IGPU seems to be based around Ivy Bridge (suggested by INFs too) but it isn't Ivy Bridge enough to fool anything. Nevertheless, thanks for the info! At least I wouldn't be wasting my time now.

Maybe, and it's a maybe, you can fool the installer with a fake CPUID using this utility:
https://falcosoft.hu/softwares.html#phenom2_tweaker

But there is no guarantee of any kind that the drivers will properly work afterwards.

Duke wrote: ↑07 Aug 2024, 13:03 Maybe, and it's a maybe, you can fool the installer with a fake CPUID using this utility:
https://falcosoft.hu/softwares.html#phenom2_tweaker

But there is no guarantee of any kind that the drivers will properly work afterwards.

Probably one of the best leads I got down the CPU spoofing route, but unfortunately no dice. I have tried 2 USBs formatted as FAT16 and 32, RMPREPUSB and manual partitioning of the USBs, 2 hard drives, one running Windows 10 and the other Vista and my own DOS boot disk, all of the aformentioned combinations leading to a neverending (I let this sit for around 20 minutes) blinking DOS cursor upon running TEST_CPU.EXE. Running the Phenom Tweaker utility under Windows gave me a paperweight due to nothing functioning, not even being able to change the CPU name. I think this avenue could have mild success on desktop chips, but I don't have a desktop platform to test on.

I decided to waste more time. Using driver version 15.33.35.64+a modified INF to install without Extended Kernel+NTOSKRNL Emu_Extender I got a driver with DirectX 11 and 10 support along with abysmal OpenGL support (version 1.2...). Installing the Extended Kernel takes away DirectX 10 support for some reason and I don't really care to investigate why at this point. User com.android.systemui on this forum already reported most of this though, but didn't mention anything about DX10. Intel driver provided on Extended Kernel website remains unfunctional with the installer crashing in the background when trying to install from Device Manager and I also haven't been able to locate another driver with the old control panel that should have better results (that works on this system anyways).

A bit of investigation later I have suspicion that the DirectX issues most likely occur at the user mode driver level rather than the kernel driver. Utilizing Steams system information tool on Windows 7 out of all things I managed to pinpoint what it calls the DirectX driver name to igdumdim32.dll. I believe this (along with other sets of DLLs that also make part of the user mode driver, like igd10iumd32.dll) could be what controls most of DX9 (in 32bit at least, there are 64bit counterparts located in System32) as there are DLLs that make references to DX11, DX10 and OpenGL too. I'll attempt to look into these DLLs more and maybe try to fix what it doesn't like, but this is where I hit the roadblock of my knowledge so I don't think I'll get far. This issue doesn't affect my hardware only, it also affects Ivy Bridge IGPUs on the latest driver version installed with NTOSKRNL Emu_Extender, so I very much believe that if anyone wants to help look into the user mode driver and restore DX9 without tweaks like WineD3D (which doesn't restore Aero or allow for demanding games to be played) that it'll be a easier process.