LoneCrusader

PATCH137 does work with Windows 95 (OSR2.x at least, RTM and OSR1 untested); be sure you are using ESDI_506.PDR 4.00.1119, I believe one of the old manuals called for at least 4.00.1118. In any case 98SE ESDI_506.PDR 4.10.2225 can be used under 95 OSR2 as well. Over the years I was able to get rloew to port most of his patches to 95 OSR2.x. The one glaring exception was TBPLUS, as I never had a need for it. But since I already know the 98SE version of ESDI_506.PDR can be used that would theoretically only leave porting the patches from the other files to the 95 versions in order for it to work...

I see it listed in the last version made public which is linked on the site rloew's son put up with released files. Whether or not it is a full implementation or a stub I don't know. Also I'd have to read back through our old communication to see if there are any relevant notes. Needless to say though there were later builds of WDMEX. I just haven't had the knowledge, the time, or the heart to do anything else with them since Rudy passed away. It wasn't given up as impossible. The OP of that thread was not interested in purchasing WDMEX, so the thread just fell by the wayside. I will not debate the issue of free and paid software; it was his time and his knowledge to do with or not as he pleased. A moot point now anyway. Since I was already a customer of WDMEX and various other patches, I had the opportunity to ask for more support of this and other issues (HDA and USB3 were our primary targets). At some point after the discussion you referenced, we did succeed in successfully loading HDAUDBUS.SYS and having the HDAUDIO bus devices enumerated. See screenshots on this page. NOTE that the version linked there is the last version now made public, not the version this was achieved with. I wasn't thinking about that when I first created the page. However, we hit a brick wall after that point. The Microsoft provided HDAUDIO.SYS file would not produce audio output under 9x, even when run on a HDA device that was specifically listed in the original INF. Then we tried using specific HDA device drivers from Realtek, Sigmatel, etc. These always died in a series of BSODs when booting the system. Debugging efforts with SoftIce on my end and his own debugger on his end always ended in a bunch of power related functions where he said it appeared as if the driver had already failed and was shutting down. We were never able to get further on this before he passed away; and with him gone, I have no idea how to continue. Simply lack the knowledge, and the time to even attempt to learn.

MmAllocateContiguousMemorySpecifyCache is implemented in rloew's WDMEX. But it would have to be set up on a user's system prior to installing the driver. I know the goal here is to build a 9x-specific driver and that is probably the best path if it's feasible. But for the record, what role does HDAUDBUS.SYS play under 2K/XP for configuring the HDA devices? Would it help your efforts to have this "bus" driver loaded under 9x?

Yes, If I remember correctly the effect is the same. However the method of the .VXD is much more multiboot friendly; don't have to change BIOS settings before switching to a different OS on the system. It's been too long since I worked with any issues relevant to this. I never went so far as speed comparisons. Unless something has changed, WinXP USB2 driver files do not work under 9x, hence why NUSB uses Win2K files. I remember trying to substitute some XP files years ago, but I don't remember why now, just that they produced errors in the Device Manager and didn't load. (Possible exception for USBCCGP.SYS, but this is not relevant to your issue.) If I had time I would dig out my old 915 and 925 chipset testing systems. Haven't used these since back in 2017 when rloew and I were trying to backport HD Audio drivers. Work and real life have a way of always preventing me from spending time on any of my computer related projects these days.

No Discord and no Chromium derivatives here. Granted, as I said, I've not actually been redirected. But my Google search I described before still produces the same result.

Now you begin to understand... haha. Yes.. Dell only has an incentive to support their systems as sold, whereas component manufacturers are more likely to provide wider compatibility testing and push more fixes for less-common or "backward compatibility" issues to the public. Dell is not "wrong" or "bad" for this, but it's not "good" for us. Now, barring some weirdness like I described before, here are the only other ideas I have. First - the SATA issue I mentioned before. You said you had problems with the SATA patch.. how so? What steps did you take? It's been a long time since I've had to work with it on a running system, but I know it has a very specific instruction set. Second - I remember USB2 controllers used to be "switchable" - i.e. you could run them in USB2 mode or switch them to USB1.x. This is what "USB2STOP.VXD" does in my XUSBSUPP update for 95 - turns the USB2 controller off so that 95 can use the USB1.x controllers. I wonder if something similar is happening on your system - possibly the controllers are initially USB1.x by default and USB2 is not switching on (under 98) to take over? The problem is I have no idea how to investigate this, rloew wrote that driver for the package and he is no longer with us. One long shot - find a copy of the time-limited Orangeware USB2 driver mentioned by Petr here and see if it works for your controllers. This driver was specifically written for 9x, not 2K, and was used by Intel for the 865/875 chipsets. The version distributed by Intel for those chipsets is locked to their device ID's though, and would require a patch by someone with more know-how than me to bypass this.

Huh? What special "mode" is this that you're referring to? Rubbish. There is no such thing as a chipset "driver." There are no .VXD, .SYS, .PDR, etc. files in the Intel "chipset" drivers. They are only simple text .INF files that assign proper names to devices. They serve no other purpose. The system will run just the same without them. But for the record - yes. I had the correct chipset "driver." I always use these, and have even created my own compiled versions for slipstreaming and added "support" for later chipsets. Prefabricated. As in a complete ready-built computer system sold by a single company. Dell, HP, Gateway, Compaq, eMachines, etc. It is preferable to get various individual components directly from their manufacturers and assemble the computer yourself. This eliminates many "unknowns" and weirdness such as I described above. Obviously a Dell fan. I can only tell you what I have experienced. What you choose to do with that information is up to you. Have fun beating your head against the wall searching for a solution.

This may be the issue, in and of itself. It's been 15 years ago or more, but I once tried setting up one of these (or a very similar model) for someone with a multi-boot configuration using 98SE, XP, and Linux. Despite the fact that "official" 98 drivers (meaning by the individual HW device manufacturers, not Dell) existed for all of the hardware in the machine, it simply would not work correctly when running Windows 98. I got random crashes, errors, and instability that did not exist on similar non-Dell hardware. After many hours wasted trying to figure things out, I eventually chalked it up to the fact that it was a "prefab" Dell machine, and there must be subtle unknown differences in the hardware, or the configuration, or something to that effect. Whether this was intentional on Dell's part, or whether they simply never tested the hardware for 9x, I have no idea. Basically, avoid "prefab" hardware (Dell, HP, Gateway, etc) as much as possible unless you're planning on running the system as it came from the factory. A standard Intel, Gigabyte, MSI, etc. motherboard with a 9xx chipset will probably give you no problems. That being said; you should need only a vanilla 98SE setup and NUSB 3.3 or later (3.6 uses WinME USB 1.1 Stack; not "necessary") in order to get USB2 speed. You do not need other packages beyond this unless NUSB does not work. (And if it doesn't work, then most likely there is a deeper problem.) BIOS Compatibility Mode was mentioned at one point; I would install rloew's SATA patch and eliminate this just to be certain it is not somehow causing a bottleneck on filesystem related operations. Not likely, but try anything that makes sense at this point.

No. I do not "Search" in the Address Bar. Such behavior is foreign to an oldschool 9x user. I only Search in the Search field of the actual search engine webpage. In this case I searched for part of the direct URL because I do not have my Favorites/Bookmarks imported to this OS/browser, and a search for only "msfn" kept returning irrelevant junk or individual sub-forum links. I thought this was odd and put in the URL segment. I have not actually been "redirected" myself; I tried clicking "translate this page" just for kicks and it tried to translate the actual correct page.

I haven't seen this directly, but searching for msfn.org/board on Google yielded this. It seems to have propagated out into search results. This is Firefox 115.32.0esr under Windows 7.

Modern hardware, expecting ACPI compatible operating systems, lacks whatever older "trigger" that is required to trigger the detection of the PCI bus device and subsequent enumeration. After installation and booting to the desktop, simply manually install a "PCI bus" device in the Device Manager and it will trigger the detection of the other connected devices. Sometimes it's possible to overload the keystroke buffer with ENTER presses before PS2 keyboard emulation is lost when the OS USB drivers take over during boot. This may or may not get you through all the dialogs, depending on whether the default options will be successful. May have to do this more than once to clear all of them.

Given the lack of responses it appears I'm flying solo and blind here for the most part... Some updates. Solved the crash in nv4_mini.sys under XP x64; see this page. I advise any other XP x64 + NVidia users out there to grab a copy of this patched file and archive it. Many thanks to tal.aloni.il! NVidia Control Panel still crashes when the desktop loads; this is puzzling... If the machine goes to sleep and then is woken up again I lose USB mouse connectivity. I assume this is a shortcoming of the particular modified USB3 drivers that I'm using. Need to test other stacks... Unless someone with better Google-fu than myself can turn up some working drivers for these Killer Network devices under XP, I give up on these... I replaced the Killer WiFi card with an XP-compatible one and now have working WiFi. The wired NIC is not absolutely necessary in this configuration. The WiFi card in this laptop is very oddly placed, one must remove the narrow plastic cover on top behind the screen hinges in order to access it. Now If I can only find the time to test this setup to see if any other annoyances are going to crop up...

The thing that hath been, it is that which shall be. Been here before Dave, we covered this back in 2017. Simple fix with a Server 2003 version of USBPORT.SYS. daniel_k's solution appears to be the best of the various different packages that address the PAE limit.

I've mentioned this in passing elsewhere, but I'm working on getting XP up and running on a MSI GT80S Laptop; trying to have the "ultimate Windows XP Laptop" so to speak. Picked this one specifically because of the dual GTX 980M video cards - last known working graphics with XP (unless some laptop is packing a Titan-X, lol). I've had some success so far; I've been able to load the INF-edited 368.81 NVidia driver under XP x86. (It's currently crashing under x64; "STOP: 0x00000050, PAGE_FAULT_IN_NONPAGED_AREA in nv4_mini.sys," more experimenting required there.) The NVidia Control Panel also crashes when the desktop loads, but I believe this is a minor issue to address later. I've got working audio using the last Realtek driver package for XP, and I've got working USB3 ports using the drivers @Dietmar provided. However I'm hitting a brick wall with the LAN and WLAN drivers. Unfortunately this laptop uses "Killer" network hardware, which seems to be unfriendly to XP. I have read several places that it is possible to use Qualcomm Atheros drivers for these chips, as they are simply rebranded versions. But to this point none that I have tried have worked. Almost always result in a "Code 10" "Device Cannot Start" error. Has anyone had success getting these Killer network chips to work under XP? Since it's a laptop, it's not absolutely essential for the wired network card to work, but I do need working WiFi. Worst case scenario I can try to change the WiFi card to a more compatible one... LAN: VEN_1969&DEV_E0A1 = Killer e2400 Gigabit Ethernet Controller WLAN: VEN_168C&DEV_003E = Qualcomm Atheros QCA61x4 Wireless Network Adapter Note that I've been trying to get this done for months and I keep having to drop it and come back to it when real life permits. Too many RL responsibilities and not enough time for projects. So there may be extended periods of time between experiments. Thanks in advance for any assistance.

LIMITMEM

Hello and welcome to the forum! Always nice to see some interest in 95, although I'm not able to give the level of attention that I used to give to my projects, and it's been a long time since I actually installed an unmodified version of Windows 95 to any system. Long ago I built a slipstreamed version that bypasses the need for FIX95CPU, XUSBSUPP, etc. to be installed manually and saves so many headaches such as these you are facing. So, fair warning, my memory may be a bit rusty! A few initial thoughts - I can see problems arising from trying to accomplish all the tasks in one pass so to speak... First - I would not attempt to fix the SATA issue until after the other issues are sorted. As SweetLow suggests, try using any available Legacy modes for the board storage controllers, or even leave them in compatibility mode until the rest is fixed. If I remember correctly, the SATA patch should work with the last 95 version of ESDI_506.PDR, but if not, it is possible to simply use the 98 version of this file.** (**may require "downversioning" hex-edit!) Second - XUSBSUPP, or the official MS USB updates, will replace VMM.VXD. This will break any previous installation of PATCHMEM and require repatching. Another reason to sort issues one by one. Third - The 98 INF files could definitely cause some weird issues as there are differences between them and the ones for 95. I may be able to provide a matching set specifically made for 95, but I can't promise a timeframe on this. It may be a simple copy, zip, and publish, but I'll have to go back and compare old notes and see whether the ones in my slipstreamed copy are affected by any other changes I've made. I just never expected interest for 95 on these honestly; pleasantly surprised! Fourth - MS set a hard limitation in ESDI_506.PDR that you cannot use an optical drive as the Primary IDE Master. Are you using a SATA HDD and a PATA ODD by chance? I encountered this problem before. rloew was able to patch out this issue, but I'm not certain that this patch exists "by itself" anywhere; it may only exist as one of many changes inside one of his larger packages, such as TBPLUS, which of course was only specifically made for 98. It's possible to use the 98 driver as I mentioned, but this would require a lot of time digging through our old emails for me to find a definitive answer. The meaning of "Projects" seems to vary among members; some of them see it as a place to discuss their "projects" as in patches, fixes, updates, guides, etc. While others see it as a place to discuss "project machines" they are working on. It's not really an issue either way as far as I'm concerned.. not like we get a lot of new members or posters these days, haha.

These had no effect on the issue. Same result, Code 39 error. Thanks again! These USB3 drivers are working properly with the USB mouse on the laptop. So far I have XP x86 and x64 up and running with the patched ACPI files and USB3 files. NVidia drivers 368.81 load under x86 with a couple of error boxes thrown when the desktop loads; but under x64 I get a BSOD, STOP: 0x00000050, PAGE_FAULT_IN_NONPAGED_AREA in nv4_mini.sys. (Given the CPU is Skylake I guess it's time to throw in the other patches... ) Not sure if anything else special needs to be done since these are "980M" cards rather than desktop 980's. If this gets much deeper I will probably create a separate thread about it; don't want to get too far off topic.

Good to see XPx64 getting some love. I keep finding things that have been fixed in x86 but not fixed in x64. Thanks for the package. I'm a little rusty on what all has been done; tried to follow it all however long ago before the original Win-Raid thread got messed up and changed hands but lost track of it since. Too many real life issues since then.. work, people passing away, etc. Only now getting (still limited) opportunities to experiment with XP and my newer hardware. (When are the HAL.DLL and intelppm.sys patches needed?) Using the last ACPI.SYS got XP x64 up and running on the laptop (MSI GT80S), but now I have another problem. I added the backported USB3 drivers from @George King's v24 package linked here to both XP x86 and x64 on the laptop. The USB controller and hub seem to be installed and working properly, but when I connect a USB mouse to the system, it doesn't work and shows a yellow-bang "Code 39" error under the Device Manager. Any ideas?

@Dietmar Could you please re-upload the latest versions of ACPI.SYS? All of the older links are no longer working. I'm working on a laptop where your ACPI 7777 for XP x86 dated April 6, 2023 works, but I don't have a matching version for x64 and the older ones I have aren't working. Thanks!

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.