LoneCrusader

Aha. "drivers integrated in the CD" Sounds like a slipstream gone bad. In my experience making unofficial INF files for Windows 9x for the various newer Intel chipsets I noted that for whatever reason Intel includes a "null driver" INF for newer USB chipsets that essentially does absolutely nothing other than name the controller. It doesn't even attempt to correctly load a driver. It sounds like in this case and what bluebolt describes that this "null" USB INF file has been included when slipstreaming Intel chipset driver packages. These "null" INFs should be purged from any slipstream, and then the normal default driver would be used as expected. If one really, really wants the controllers specifically named, then the VID & PID and name text string from the null INF(s) can be added to the original 2K INF, pointing to the correct install section of course!

Good point. From rereading the original post is sounded more like a text-mode problem.

This doesn't seem to make good sense. Both of those devices should point to the same install section in the USB (or USB2) INF file (and thus operate exactly the same way). Windows 2000 probably should not even have a reference to "Intel 7 Series/C216 Chipset Family" unless it has been modified. Are you using unmodified sources to do the installation? (Note the OP of this thread has been banned, so we can't expect more responses from him. But this is a strange problem that bears further examination.)

This is all very silly and has gone on long enough. Microsoft closed Windows Update v4 long ago and could care less whether any of us like it or not for that matter. Making vague threats about launching malware attacks against Microsoft is also ridiculous, and forbidden by the rules. I see the OP has just been banned for requesting warez in the 2K forum. Good riddance to this... locked.

The oldest driver package D-Link has listed for this device (1.00) of course contained only 2K+ files. However it uses DRT2860.SYS. I believe D-Link adds the "D" to the beginning of drivers, as the Internal file name for the driver is RT2860.SYS. For the heck of it I searched for "RT28609X.SYS" which led me back here to MSFN. Did we ever get a definitive answer as to whether or not the RT28609X.SYS file discussed in that linked thread works (and/or works for later RT2860 devices)?

Changing all of these locations unfortunately didn't help. I assume, as Trip mentions, that something else is used to determine the Service Pack level or there is some other problem causing the game to fail silently. Any suggestions for running such a trace? I've also encountered other XP x64 specific issues before that I keep meaning to find solutions to but there never seems to be enough time to spend on it. The most annoying example so far besides this current one involves HP Printer driver packages that provide XP x86 drivers and Server 2003 x86/x64 drivers but contains a specific artificial block against XP x64. Manually unpacking the drivers and trying to manually install any of the files for those other three systems fails to produce a working printer. ~ Backing up a bit to provide more info and add what else I have learned so far; I started this topic thinking that a simple SP level spoof would cure the problem because at that time I had yet to encounter anything else (other than the deliberate printer exclusion) that works on XP x86 SP3 that failed to work under XP x64 SP2. The game in question is League of Legends, and at least as of fall of last year it was working properly under XP x64 SP2 despite an occasional nag screen about updating to SP3. Hadn't played the game since then, and now it's broken. The game uses at least two .EXE files, one for player interaction, matchmaking, and other game content; and the other for the actual game itself. (They have been pushing a "new client" program for a while now and have now made it mandatory; I assume this is probably involved in the problem, but it's not perfectly clear which "client" EXE is changed or both.) The first of these two EXE's still works fine. The second, the game client, fails silently when a game is launched from the first "interaction" client. The EXE is listed as a running process in the Task Manager, but nothing happens. This process has to be killed manually, which will then cause the "interaction" client to reload and report that the game is in progress and give the option to rejoin it. Doing so reenters the same loop. I examined the offending game client EXE file with Dependency Walker. Three delay-loaded dependencies are listed as missing. Two of these are in IESHIMS.DLL and WER.DLL; which according to everything I can find with Google are irrelevant for Windows XP and programs reporting these dependencies are "expected" to be intelligent enough to not use these functions under XP. Searched for these files anyway and ended up on a long wild goose chase to nowhere. I suppose one could rob them from Vista or 7 if necessary; but I doubt this is the issue. The third missing dependency is in DEVMGR.DLL. Pulled a copy of this file from XP x86 SP3 and dropped it into the game folder. No joy here (this was with the reg spoof above still in place as well). After all of this failed to work, I wondered if it might be video hardware related since the machine I was using had a somewhat "older" video card. Loaded the game on my Core i7/X79 chipset/GTX980 system and had the exact same problem under XP x64 SP2. Set up XP x86 SP3 on this system and the game runs perfectly fine (with some annoying crashes from time to time, but I'll wager they have not been spending much time properly debugging under XP anyhow). So, the game does in fact still work under XP x86 SP3. Somewhere along the way a difference between it and XP x64 SP2 has become an issue.

Apparently I wasn't reading too clearly when I examined my registry. I'm not sure what happened, but the x86 and x64 values do indeed match at that location. These locations use the same "200" value in a DWORD format. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Windows HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Windows Also, at these locations HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion x64 has "Service Pack 2" as a string value. I suppose it's trial and error now to see if changing these will circumvent the problem... Thanks! I wish it were that simple. The program (a game I play infrequently) is already installed, and previously worked until they decided to change the base minimum specs and pushed an update that broke things. Not even sure this will cure the problem, as there is no error thrown, but it seemed like a good place to start since they specifically changed the prerequisites.

Has anyone here tried spoofing XP x64 SP2 to report SP3? I've encountered an issue with a program that defines XP SP3 as the minimum requirement for operation under XP. It makes no distinction that no SP3 exists for x64 XP (which should be defined as a BUG, but most of you here know how such people react and the response you will generally get if you criticize something that doesn't work properly on an older system), and demands an update to Vista in order to run under an x64 OS. I turned up some pages with Google that discussed spoofing x86 SP2 to SP3, but the values in the given registry locations did not match the original x86 values under x64.

Apparently the installer must be run in order to unpack the update. I'll investigate further on that later. But to answer your second question no, this update should not be used on your current machine. In general it's best not mix up other manufacturer's packages whenever you're setting up a system not using their components. Always start with installing the bare minimum of packages specific to your machine, then proceed to other solutions if and only if you have problems.

While such a game is definitely in very poor taste, I'm not certain "public outrage" should be a sufficient justification to suppress freedom of speech or more specifically the freedom to create content, however distasteful it may be. The appropriate response is simply not to buy it, as opposed to silencing whoever produced it. Banning a game will not bring back the dead nor prevent evil/sick people from doing evil/sick things. But this is OT for this thread anyway.

Why are you using a VIA update on a computer that doesn't have a VIA chipset? In any case please provide a link to this update and I will see what, if anything it changes that could affect USB. I have encountered at least one situation where an Intel USB1 controller on an MSI motherboard would cause Windows 95 to hang but did not affect Windows 98SE. The same VID&PID controller on a different motherboard did not have this issue, so it's possible the problem is purely hardware related. The few ATI/AMD chipsets I have encountered have not been 9x-friendly at all.

In general I would advise anyone to avoid "prefab" (Dell/HP/Compaq/eMachines/etc.) computers for any type of gaming build and especially for Windows 9x builds. From my experience with certain Dell machines that originally came with XP, Dell seems to make subtle undocumented changes to the motherboards which can cause the onboard devices to not always function as expected despite having 9x-compatible drivers. Also they frequently use garbage OEM BIOS'es which not only severely limit the options available to the user but can even cause wide incompatibilities and annoyances when trying to run Windows 9x. Also avoid any Intel-branded motherboard later than the D875PBZ for this same reason. Intel chipset-based boards by say Gigabyte, MSI, etc. are fine, just as long as they use AWARD BIOS or something else besides Intel. I personally like P4's and have a whole stockpile of P4-compatible hardware. But if you're going to do this, don't settle for anything less than 3GHz and 4GB of RAM, especially if you plan to dual-boot with XP.

Really? Good. Now, for the sake of posterity and to assist anyone else who might have trouble finding this information, please describe in detail: 1) what steps you took in your experiment(s), 2) what specific driver version(s) you experimented with, 3) which specific non-9x-supported ATI card(s) you tried modifying the drivers to work with, 4) what specific other hardware was used during the test(s) including motherboard, CPU, RAM, etc., 5) which specific version of Windows 9x you were using in your experiment(s), 6) what version of DirectX were you running, 7) what other drivers, if any, were installed on the system at the time of the experiment, 8) what other software was installed, if any, that might be relevant to the issue, and 9) any other information that could be helpful to someone to reproduce your results. When you have done this, then we will know just how thorough your input is on the subject. Even more interesting. Please provide some direct links to pages documenting experiments on the subject. I highly doubt the number will approach 20, much less 100. A bunch of people saying "can I do this?" to be answered with "no it won't work" does not count as an "experiment." Too young? Not likely, but irrelevant. So, "Omega Rad" drivers have been "really good at getting newer cards to run on 98"? OK, please list for us which specific newer cards they provide support for that Catalyst 6.2 did not and which specific version to look for? And, JFYI, Windows 9x can and does run just fine and "fully work" on plenty of motherboards with PCI Express chipsets with a few unofficial updates. Many games that came out just before everyone started dropping 9x support can very well benefit from more improved or more modern hardware, whether it be a newer video card or more than the standard amount of RAM. WarCraft III and Rise of Nations are two specific examples that I've played myself. I've seen both lag during big battles when running on a 3GHz P4 with 2GB of RAM. I could not imagine running either one of these games on such an antique as you seem to think is "adequate" to build a proper Windows 9x machine. And, also FYI, I can have 4GB of RAM "stable" under Windows 9x, and so can anyone else.

Maybe not. But if everyone here had always taken that attitude about experimentation then many of the things we now know to be working would have remained hidden. Don't be so ready to rule out things before they have been tried. Now yes, in this particular case I doubt that any ATI cards newer than the X850 XT PE can be used. However I also don't know how much effort was ever put into changing that either. If no one had taken the time to try with nVidia, then we would have no 7xxx card support. Don't be surprised if few here share this opinion. My opinion is that there is no good reason to artificially limit your hardware. Why slow any computing experience down on purpose? Most all of these "older programs" will benefit from higher performance, other than maybe some DOS game that requires slow CPU cycles. DOSBox is the answer for this.

Palladium Lunaris

Despite claiming compatibility, the newer versions of CPU-Z are missing the VXD file that is required for the program to do anything under 9x. I recently tried to use the newer version of CPU-Z + the VXD from an older build and if I'm remembering correctly I got a BSOD. I don't remember offhand what the system specs were, but it was a "newer" machine.

You can add the Streaming Proxy manually in the same way you added PCI Bus to your setups. In my experience it always gets reinstalled when a new Audio device is installed anyway but I don't have any USB Audio devices, only add-in cards.

No. As far as I know there are no .VXD drivers for anything USB. And no .VXD drivers for anything HD Audio either; hence why we need a permanent solution to the 98SE WDM Audio problem.

Issues when using an audio device with WDM (.SYS) drivers as opposed to 95-style (.VXD) drivers seem to have been around for a long time. I turned up this old thread elsewhere where they were having trouble getting audio output to be produced and volume control to be available when using WDM drivers. Despite the title it is hardly "resolved." Anyone else here experienced issues with WDM-driver audio devices? Did you find a solution? I've seen some issues myself but found no immediate solution other than to use the 95 ,VXD drivers when available. We need to find a solution for this, not a workaround. (especially if any "newer" audio devices are ever to be backported )

I understand completely. I'll always prefer Windows 95 OSR2 over any later version. I didn't have good experiences with 98FE so for a long time I resisted using even 98SE; but once I was forced to use it for something I wanted to do I found that 98SE works well for the few things that 95 won't do. You're lucky that you've been able to get these systems to run with so much RAM. I have never been able to get a 9x system to boot with more than 512MB no matter how many tweaks I tried. The only time I saw 98SE boot with more than 512MB was when I experimented with an older version of the Unofficial Service Pack. It booted with 1GB but it was really unstable and crashed after a few minutes. This issue seems to vary widely across different hardware configurations.

Interesting that ABCDEFG's system appears to be 98FE, not 98SE. I wonder if 98FE somehow better handles more ram? Doesn't make sense, but...

Did you install the RAM patch using the /M switch? This switch is specifically to address issues with Gigabit Ethernet cards and may help...

I used to prefer AMD back in the days of Super Socket 7 and K6-II (I even have an ultra-rare 570MHz one of these), but once I stepped up from them to Pentium 4 I never looked back. I've not had a lot of experience with AMD systems since then, but a friend of mine had a prefab Compaq machine that was AMD and it was junk (very slow, but to be fair I don't remember what the CPU specs were). Also it seemed that when multi-core CPU's became mainstream AMD relied too much on multiple cores instead of raw clock speed (which to me is more important, especially for 9x) and at least for a while did not keep up with Intel. I've tried only three AMD systems since then myself and they each have at least one weird, annoying problem or another under 9x (but they're all nForce chipset based as well, so that may be part of the issue). So I'm not much of an AMD fan these days. To each his own I suppose. YMMV.

SETUP /p i is virtually mandatory for any new system and also for those going back a few years now. Windows 98 supported ACPI to a point when it was introduced but modern systems are using newer implementations of ACPI that are completely incompatible with 9x. There is no way to fix this short of writing a new ACPI.SYS driver from scratch. The 2K version uses NTOSKRNL.EXE functions for memory allocation and such that cannot be backported to 98SE in any reasonable manner, if at all. ACPI is pretty useless anyway; APM will handle things just fine in most cases. At most you might get the "It is now safe to turn off your computer" screen and have to switch power off manually when you shutdown, but this is just like the old AT days when 9x was young. The /p i switch should be usable with other switches with the correct syntax, but I've not tried this. If the INF's have the 1-06-2015 date then it didn't pick up the newer ones I linked for you during install. DO NOT mix USP3 files with NUSB! They do not share the same approach and use different selections of files. If you wish to use USP3 then you should add this later after other things have been sorted out. USBD.SYS should be extracted to \WINDOWS\OPTIONS\CABS or something like that by NUSB. If not you can manually extract it from the NUSB package. NUSB3.6 uses the Windows ME SYSDM.CPL which is known to have some minor cosmetic bugs under 98SE. Other bugs may be lurking undiscovered this is why I recommended 3.5 for now. Not sure about having to change the IRQ or about the freeze. I haven't seen this but it may depend on your BIOS/hardware. ACPI, not AHCI. ACPI = power management. AHCI = disk controller mode. Yes, this is the reason for no automatic power shutoff at shutdown as I mentioned above. You will just have to deal with this on newer systems where ACPI is incompatible with 9x. Leaving ACPI enabled brings on far worse problems. I have an old Intel G41 chipset board where 98SE will not even boot if it is installed without the /p i switch. (This gives you an idea how long ACPI has been incompatible.) I have that too. Windows 9x doesn't know what DMI2 is. Probably no fix for it, but it remains to be seen whether or not it causes any actual problem besides an error in the Device Manager Don't worry about this for now. USB Composite Devices are somewhat unexplored territory. Not sure how to solve this. Simply removing them and reinstalling them might help. What are these devices so we can see if anyone has successfully used them before with 9x? Overwriting or renaming the older INFs to some other file extension such as .TXT should work. If the new INFs were not picked up and copied during installation you may have to manually put them in \WINDOWS\INF. As rloew said that is the HDA controller. No working 9x drivers (and it keeps defeating all our efforts to backport one from 2K, so it doesn't look promising.) The USB3 controllers also have no working drivers of course. I added a generic do-nothing entry to my USB.INF to move them under the USB section and prevent them from showing up as Unknown Devices.

Yes; I have an nForce4 Chipset AMD system that literally takes that long to boot because HIMEM.SYS makes a wrong assumption. Adding one line to CONFIG.SYS solved this. All you have to do is not use HIMEM.EXE and add a line to CONFIG.SYS specifying the option for HIMEM.SYS. If it solves the problem, then great. If not, switch back and you've only lost a few minutes.