LoneCrusader

Luckily, someone uploaded a copy of it. Check the last few posts in the thread. But @Acheron also posted the patch bytes in the thread here at MSFN, which appears to be more helpful at the moment unless one needs the other things provided by the original package. Could be another way of approaching the issue. I hadn't thought about it that way, assuming that all paths to solve it would be similar. Based on un user's next post and an examination of that section in the registry it looks like one might get at the issue from that direction... I think that the approximate same result is achieved with one of the patches listed by Acheron; I tested them and while XP x86 still recognizes whether or not a driver is signed, it does not "prefer" one or the other on its own anymore, which solves the issue at hand. Now I just have to find someone with the know-how to port them to x64. Interesting.. is there any available documentation on this? And, I assume since you specified that it works only after setup is complete, that an attempt has been made to add these entries to the source files prior to setup?

Hmm.. looks like our Russian friends have already solved this issue long ago. Digging through an old RyanVM thread for information on Signing/Certificates inadvertently led me back around to here, and then to a thread on the OSZone Russian forum. Unfortunately I can't speak or read Russian, but a Google translate of paragraph #3 of post #10 refers to "Patch in Setupapi.dll, turning off the lowering of the rank of unsigned drivers when choosing the most suitable driver for the device." Now the problem is sorting out what patch does what exactly, and if there are any differences in different versions of the DLLs involved, and how to port it all to XP x64. All things I know nothing about. Fun!

Sure, they don't change anything. It's just a personal preference, hence why I said above that "need is subjective." But I prefer to have them installed, and it's all the more annoying that Windows refuses to do so, so I am therefore more determined to find a solution.

Yes, I know. I don't care whether they are signed or not. But Windows does. Setup refuses to use my specific-device-ID specific-name driver because it isn't signed, and uses its signed MACHINE.INF generic driver instead. As you see in the shots, I can manually force my driver to be used after Setup is done. But that defeats the purpose of having it slipstreamed. It also could theoretically cause problems in a situation where Windows has a generic driver pointed to a given installation routine, and you want to add a specific driver that points to a different installation routine. For example an IDE controller*.. MSHDC.INF will send anything matching PCI\CC_0101 to the generic IDE install routine. You might want to send PCI\VEN_8086&DEV_1C02 to an AHCI install routine with a specific driver INF. But Windows would choose the generic signed driver over your INF because yours isn't signed. *Intel avoids this particular situation because the storage controllers report different DEV ID's for different modes (IDE/AHCI/RAID) but not all manufacturers may do this.

Need is subjective.. lol. Chipset drivers usually don't "do" anything other than correctly name and prevent unknown devices/yellow bangs under the Device Manager. But installing them is one of the first tasks to be performed every time a new system is set up, so it is preferable to have them integrated and dispense with this task. Signed manufacturer files might be used somehow, but Intel insists on giving you over a hundred tiny INF and CAT files for a simple task that could be done with 3 files (1 for System Devices, 1 for USB controllers, 1 for Storage devices). And this fileset does not include any newer system devices that are "unsupported" for XP - for those you either make your own or hope XP can use the files provided for NT6x. At any rate, I tried using my compiled INF file under XP x86 along with the SETUPAPI.DLL patch. It did not have any effect on the problem, so that looks like a dead end. Still need a fixed SETUPAPI.DLL patch for x64 though, as it does help with the other things I mentioned in the other thread. Not sure if SYSSETUP.DLL patches would have any effect - there is no warning box or error box, etc. I already prevented those with the relevant registry entries. The system just silently prefers its signed, generic MACHINE.INF over my unsigned, specific INTELSYS.INF. See pics below; this is what I see when I examine the Device Manager entries for the devices after reaching the Desktop. Error/warning dialogs are not the issue. The problem is the silent preference for signed over unsigned, even if the signed driver is "generic."

My apologies for the late testing.. every time I get a good start on a project of mine something happens to delay it. Unfortunately this patch doesn't seem to work, it triggers an endless loop at the beginning of the second phase of SETUP. The text part of SETUP completes, the system reboots and shows "Installing Windows" and "39 minutes remaining" - but it never loads the first dialog box to click to continue. After a few seconds the screen goes all light blue and the machine reboots. This repeats on each reboot. No error is displayed.

Sounds promising. Tried using that just now, but I'm currently working on the x64 version of XP. Apparently the patch for the x64 version of SETUPAPI.DLL needs further work, it triggers an endless loop. Will elaborate further in that thread. I put this topic in the main XP section since I meant for it to apply to both x86/x64, but It may need moving to the x64 section later if divergent methods are necessary.

I've been told (and seen examples, i.e. Fernando's AHCI/RAID drivers) that one can self-sign files and/or obtain a certificate to do so, but I'm not sure that this method would necessarily work during a clean install, as "your" certificate would have to be imported and accepted as trusted prior to setup checking the files. Not saying it might not be possible, but I have no idea if it can be done in practice. I'm not aware of any way to "fix" a signature once it's been broken.. probably be hard information to find, even if it is possible, due to the possibility of using it for malicious purposes. Any of our "XP on Modern Hardware" gurus care to chime in on this? @Mov AX, 0xDEAD, @Dietmar, @George King, @pappyN4

Does anyone know if it is possible to force Windows XP (x86/x64) to treat signed and unsigned drivers equally, and not prefer a signed driver over an unsigned one? I know it is possible to disable signature enforcement and stop the warning popups and such, this is not what I need. I need Windows to stop automatically preferring a signed "generic" (device ClassCode [CC] INF entry) driver over an unsigned "specific" (device [VEN&DEV] INF entry) driver. I'm trying to manually slipstream motherboard chipset drivers into XP setup.. and the 250+ tiny INF and associated CAT files supplied by the OEM drive me nuts. So I decided to build a single compiled INF file, similar to what I did for my Windows 9x Chipset INFs. Which is fine, except that it is unsigned, while XP's MACHINE.INF is signed. So Setup refuses to use my INF for, say, the PCI-E Root Ports, because it has a generic Class Code entry for these in MACHINE.INF, and uses it with generic names. But it does pick up my INF for the SMBus controller and gives it its proper name, because no other driver matches it. This is maddening... Yes, I can manually force the use of the specific unsigned driver on the other devices through the device manager after the desktop is reached, but this defeats the purpose of having the driver slipstreamed to begin with. I can also edit MACHINE.INF with the new data and break its signature in the process.. but this leads to other dumb behavior, such as popups about "Terminal Server" device drivers during SETUP that require user interaction and break the unattended process.

+1 Have to disagree, XPx64 is in some ways the best of all worlds. It's been my actual daily driver for a long time now. Also, I can confirm the random crash on YouTube main page reported on GitHub on at least one of my machines (this machine is XP SP4 x86). All you have to do is go to the main page and "scroll down" for a while looking through what's available; sooner or later it will die. Haven't updated my XP x64 machine with the new build yet, but it's worth noting that several versions back I actually saw more crashes on the XP x86 machine than I did on the XP x64 machine. I don't remember them specifically now, they were fixed in a later build, but it was interesting that they did not happen under x64.

No matter the topic title from way back whenever, no GeForce 8xxx or higher card has proper working drivers for Windows 9x. Just because someone added them "hopefully" to the INF file and created a thread about it does not magically produce positive results. Discussion of flashing one card to another is generally off-topic for this thread, but I don't think anyone would have a problem with it as long as it involved cards that were actually 9x compatible, In this case, both cards in question are incompatible, and therefore very much off-topic despite the initial discussion of them being well intentioned and likely arising from not knowing they were incompatible in the first place. Enough of this.

Thanks for the info. For completeness could you also list the correct location for patching x64 version 5.2.3790.3959? I note that the same byte sequence occurs several times throughout the file.. how does one know which instance specifically requires patching? The SETUPAPI patch allows one to modify certain files on the installation source prior to SETUP.. some can be edited without problems (i.e. TXTSETUP.SIF, DOSNET.INF that are used by nLite) but others such as LAYOUT.INF cannot be modified without causing errors during SETUP. FDV's patch for this works on XP x86 but I had no way to port it to XP x64.

Patch is there for SYSSETUP.DLL but not for SETUPAPI.DLL. I've not been able to locate a patch for the x64 version of this file, and the byte sequence for the x86 version doesn't match even though they're the same build number. Anyone have information on this? Thanks!

Thanks, I looked over the updated .htm file. Looks like a lot of new additions. I assume a bunch of these came from the NT5.x Updates URL drop by abbodi1406. But I also am interested in the process (how and why) of what has changed; for example if one of the new updates completely supersedes/replaces a previous update that was in a previous version of the Update Pack. An old example from 5eraph's thread at RyanVM: Keeping track of all these things can be a pain.. I know all too well from doing my own slipstreamed builds of earlier Windows versions. But it's nice to be able to follow all the steps that lead to the finished product. Also, what do you mean by this? What was the limitation and what was the solution? Thanks!

Do you happen to have any documentation/changelogs for the updates you have made? It's always nice to know specifically what has been done.

It's been a long time since I've worked on these. (Wow, almost 8 years.. where does the time go?) I believe x79 was the highest chipset covered by the version of the Intel INF files I used as a base. I see some x79 references in the files, so this chipset should be covered. I never got around to working on x99 or higher. Virtually impossible to find the time for any of my projects these days.

Well, I finally solved it about a year ago in one of those rare instances when I actually manage to find time to work on my long-suffering never-completed projects. You can stop the process that "deselects" these components by editing their respective .INF files and commenting out the "ValidateProc" line in each of their sections. Extract MOTOWN.INF and MMOPT.INF from precopy2.cab if they don't already exist in the main \WIN95 folder. Find the sections [media_acm], [Rec], [Vol], [media_clips], and [CDPlayer]**. Comment out (place a semicolon at the beginning of) the line in each section that begins with ValidateProc. (i.e. ;ValidateProc) Save changes. This should solve the problem. ** = I don't remember anything offhand about the [CDplayer] section; or whether or not this is required. I may not have looked into it further at the time, but just handled it similarly to the others once I figured out how to prevent them from being deselected.

Very depressing news.. I had feared for the worst for some time now, given that he had not been active here, and had not responded to messages I sent previously. Den was one of the few people "online" who I considered a true friend, and I will sorely miss his presence here. While I had not spoken much with him over the past couple of years (where does the time go? ), he was always helpful and always ready to give clear insight on whatever issue we discussed. He was very wise, and not only on the subject of computers. While not the subject of this forum, he understood historical and political nuances that befuddle most. I believe my first interaction with him revolved around problems with a flash drive.. and IIRC by the time it was over the discussion included rloew and jaclaz as well. Now of these greats only jaclaz remains with us. I never expected to become one of the "old ones" - yet here I am. My pitiful knowledge can never live up to the bar set by Den and others, and I will never be the "diplomat" that he could be when dealing with differing viewpoints and difficult members. I know that this forum and the collection of knowledge that it represents mattered to him, so let us all work to continue and preserve it in memory of him. Rest in peace my friend. You will not be forgotten.

I'd like to see something like this as well.. I hate the fact that every browser is trying to become Chrome, but unless some major player in the "industry" bucks against it, it will continue no matter what any individual user likes or dislikes. I'm no programmer, but I just can't imagine it is really that hard to produce a sane UI for a program. Worth mentioning, this Chrome derivative does seem to have some very small measure of UI customization support..

Done. You all should review the posts here and in the original thread for continuity and edit if necessary.

Also seeing this on Firefox 52.9.0esr; spoofing FF 68.7 on Win7 as the User Agent seems to fix it, for now.

There are no working USB2 or USB-HID (Keyboard, Mouse, etc) drivers for Windows 95 available in the wild (rloew and I spent many, many hours searching and testing to no avail); so this could place a major roadblock in your path if you have no PS/2 or other legacy ports.* As pointed out earlier, even if a device provides Legacy KB/Mouse emulation during boot, once USB1 controller drivers are loaded in 95 this is lost. You can circumvent this to a degree by not loading USB1 drivers, but if you wish to use removable USB drives with your installation then this is not a viable alternative. I once managed to get through the device detection prompts on a system with no PS/2 ports by overloading the keystroke buffer with "Enter" presses before the KB emulation was lost.. but this still is not helpful if one cannot control the resulting installation once the desktop is reached. * - But such things do exist. rloew managed to backport some of these things from 98 to 95 for me. I hope to eventually pack these things up with an installer to set everything up, but I never seem to be able to find the time to work on it (or any of my other computer projects) anymore.

NUSB (version 3.3 or 3.5 recommended) package will cover the USB2 drivers as well as add USB storage support. The rest should be here (including the original Intel provided USB2 controller driver if you prefer).

No, I can't claim that title. Or at least it was never given to me, lol. I suppose I can be considered as such for the 9x forum, but unfortunately I can't take on such a role for the older-NT family as well. I'm doing well to manage to keep up a daily check in on things.. RL issues are really taking a toll on all of my "computing" endeavors these days. - (And while I agree it may not be ideal to have so many "pinned" threads, I don't see the need to start changing things just for the sake of changing them. It's been that way for a long time and hasn't been an issue... Why the sudden "wave of discontent?" .. not to say that it could not/should not be improved, but just saying..)

Sorry for the late reply, and I can't really offer much help... IMO, it's probably a hardware-specific issue with your system. But... By chance, when you encountered this issue with XUSBSUPP were you attempting to shut down with a USB drive still attached to the system? If so, this may be the culprit.. I rather doubt it in a way as I believe it would have been manifested somewhere before during all these years. But I do know that most, if not all, of the "power management" code was stripped from the RLUSB drivers (originating from Microsoft UMSS sample source for 98) as a first step towards Windows 95 compatibility back when the project began. It would be interesting to see if having a USB drive connected or not makes any difference on your system. Also, if you wish to experiment you might try using other (older) versions of the USB driver stack files (USBD.SYS/USBHUB.SYS/UHCD.SYS/OPENHCI.SYS) from the other Microsoft HotFixes to see if any of them do not exhibit the issue. It's possible one of the "fixes" breaks something on specific hardware configurations...