LoneCrusader

If anyone is interested, I'm looking for some assistance with making an updated (possibly final, more on this below) version of the INF package. With data from the newer Intel INF package xrayer found, adding another MACHINE6.INF will be required in order to contain all of the device data and keep the INFs below the 64KB limit. In the last version I split the collected data from the various Intel INFs up however seemed best in order to use the smallest number of INF files and still get all of the necessary actions performed during SETUP. Since I'm going to have to add another INF this time anyway, I would like to step back and attempt to organize all of the previous data in a "chronological order" according to when each chipset was released. Here's what I need: When the Intel INF packages are extracted, one ends up with a whole folder full of small INF files which are named either according to their Chipset family number, ICH level, or more confusingly the "code name" associated with the chipset or CPU intended for the chipset. I need someone to organize these file names into a chronological order from the oldest devices to the newest. Then I can use this to rearrange the data inside the INFs accordingly. (A detailed list of Intel chipset/CPU code names in chronological order might work here as well, depends on the detail.) I have attached a list of the file names to be organized. Obviously the first file would be "ich5core.inf" then the other "ich5*" files, then the "8xx" files, then the ICH5 server chipsets (E7xxx), then "ich6core.inf" and so on accordingly. It gets much more confusing as the devices get newer and the files are no longer named according to chipset or ICH level. Now, above I mentioned that this may be the final version of these INFs. This is due to the fact that the current Intel INF package 10.0.27 intended for Windows 7/8/8.1/10 etc is almost completely useless. I downloaded it and was forced to find a Windows 7 machine to extract it on (it wouldn't even extract under Vista!), and once extracted I discovered that it simply names anything and everything to "Intel Device" with no further description. Wow, just how far will the "dumbing down to the lowest common denominator" go? So, if anyone knows of other versions of the Intel INF's between the last one xrayer found 9.4.4.1006 and the 10.0.27 version I tried, please post links here to them. LIST.TXT

Might help to also ask them to give you the source code for the last 9x driver as Drugwash pointed out, especially since it's for an unsupported and outdated operating system. What would they have to lose by allowing others to work on it if they don't want to? Probably won't change their minds but at least you give them something to think about.

I originally decided not to include MSHDC.INF with the latest package because of the various issues with 9x and SATA, AHCI, or RAID controllers. (I build two sets of the INF's for my own use, one for 95 and one for 98SE. There are additional issues that rloew and I discovered that apply to Windows 95 and not 98 that caused me to consider not bothering to update MSHDC.INF further.) I suppose however since 98 is unaffected I could release an updated version that behaves like the last version in which it will only load a driver when the controllers are set in Legacy PATA mode. I'll consider adding this when I update the package with the newer INF data you found. Apparently I'm not following this discussion... The 8168 device is commented out in the Tenda package but is not commented out in the latest package available from RealTek which is newer by version and by timestamp. According to the INF in the RealTek package up to RTL8111D is supported, but rloew said previously that "D" and "E" devices don't work with it...

Did you ever get an answer? Maybe we should all email them with the same request... lol

I was referring to the other device when I said it was ASUS-specific. rloew's SATA patch patches the existing IDE driver to support SATA and provides an INF file that properly recognizes the Native Mode controllers and allows them to be used exactly as if they were regular PATA controllers. I've been using it during all of my "newer Intel" testing. Basically you install it (or preload it into your SETUP source if starting from scratch) and never worry about SATA issues again. My updated MSHDC.INF you were referring to will only recognize the controllers when set to Legacy PATA mode. If they are set to Native SATA mode it will report "No Support" for them and they will remain in DOS Compatibility Mode.

Apparently Intel does not differentiate between the 82801 and 82802 Firmware Hub device since it is identified by *INT0800 rather than VID&PID. My INFs are not designed to handle devices enumerated under ACPI, in fact I have seen some problems with this on my X58 system where devices will be treated as "unknowns" despite having a corresponding entry in the original 98SE MACHINE.INF. In any case this seems to be an ASUS specific device and therefore would never be handled by a specific Intel package. The issue with the I/O port is normal. Remember these INFs only provide specific ID's for each device, not any special resource configurations. Looks like otherwise your system is working as expected. Interesting, although I'm not bothered by having to switch off. I used AT-powered computers long after ATX beacame the norm so I'm "used" to it I guess. Also I'm in the habit of switching off the main PSU switch after Shutdown, so either way it gets done.

Every NForce chipset system I have experimented with has some bug or another under Windows 9x. I'm surprised any of you had good results with them. I'll quote myself from another thread where I discussed the issues: Hopefully your experiences are the norm and mine were just bad luck...

I haven't used ICH6 boards much, as the two I did experiment with exhibited undesirable behavior. So I'm not intimately familiar with ICH6; I have more experience with ICH7 and ICH8. I'm not sure about the Firmware Hub discrepancy, it may be that Intel did not differentiate the PID between the two versions which would cause the same string to be used for both. Use REGEDIT to export a .REG file of the HKEY_LOCAL_MACHINE\ENUM Key from the registry and attach it. With this I will be able to see the VID&PID of the Unknown Device and the Southbridge. Resource conflicts are the "normal to-be-expected" behavior for post-9x supported motherboards. I've seen the "Motherboard resources" conflict on almost every such system I have tried. I even tried removing the "Motherboard resources" install routine from MACHINE.INF once, which only resulted in an unknown device which still showed a conflict. I have no idea what the problem "resources" are, but they are virtually impossible to get rid of unless one installs 98SE using "SETUP /P I" to disable ACPI. This usually clears such problems, but may cause you to have to manually switch off your machine after Shutdown similar to an older AT-powered machine (you will get the "it is now safe to turn off your computer" screen).

Never tried. It's almost impossible to use Windows 9x online these days unless you're OK with completely disabling JavaScript and other annoyances. Your best bet may be to ask Andrew T or wait for him to notice this thread; I would say he has probably pushed 95 further online than anyone else here.

I see no advantage to changing from the ME USB1 stack to the 2K USB1 stack. The fact that the files are "versioned higher" is the only logical argument for doing so, and even this is irrelevant because the 2K files were designed for 2K and the NT codebase while the ME files were designed for ME and the 9x codebase. Just because a newer versioned file was issued as a fix or update for 2K does not guarantee that the newer file is "better" for Windows 9x. In fact, the opposite is likely. But all of that aside, I decided that I would give your method a try, just to see what happens. I removed all of the USB devices from the Device Manager and ran the USBSTACK.EXE file from inside your latest uSP 3.51 which updated all of the USB files accordingly. Not only did the exact same behavior with the BSODs remain, I also noticed that the USB Storage device did not trigger the HOTPLUG/Safe Removal tray icon as it should. I'm glad all if these newer files work as expected on your system, and I hope they also work for others, but apparently yours is the exception and not the rule.

I may be wrong, but I assume that the USB Legacy Storage Support function must be intended to "trick" operating systems into running from a USB Storage device as if they were running from a standard internally connected drive. I remember rloew mentioned somewhere before that Windows 9x would run from a USB Flash Drive up until the point where it detects the controller where the drive is connected, at which point it will crash. I don't know what the "rules" are for this situation on newer systems, but "masking" a USB Storage device from being automatically detected as such might help in this specific case. Apparently XP is not affected (or helped if so intended) by this setting.

I set up a test using USBPORT.SYS 6941 along with the other two USB2 driver files which were already at their latest 2K version. I removed all of the USB2 controllers and hubs from the Device Manager in Safe Mode. (BTW, removing a USB2 controller under Normal Mode will trigger a BSOD even with the oldest USBPORT.SYS so this issue mentioned before is present no matter what) I then rebooted the machine and allowed the USB2 devices to be reinstalled from scratch, using the updated USBPORT.SYS. I rebooted again after this for good measure and then connected a USB Flash Drive. To my surprise it worked without a BSOD and was detected and installed properly. I was able to access it and then safely remove it using the tray icon. However, as soon as I connected a second USB Flash Drive I got a BSOD immediately, as before. I had to manually reset the machine and I was able to reproduce the issue exactly again. So it appears that if the controllers are originally installed using 6941 then once can successfully connect, use, and remove ONE USB storage device without triggering the problem. But when one connects a second flash drive, the old behavior resurfaces. I can only assume that there is some slight difference (maybe in the registry?) made by using the later file during installation. It does change the behavior from that of simply directly replacing the one file, but in the end the result is the same because the BSODs still resurface. This test was done using the ME USB1 stack. I don't know what effect using the 2K USB1 stack may or may not have. All part of the plan.. haha. I've been stepping up incrementally with newer Intel systems, mainly looking for the point where using 9x becomes "more of a problem than it is worth," but as a second benefit I will eventually have a "high performance" system for XP as well. Next system on target after the X58 is the X79.. but I'll need to save some more money for that, lol.

I don't get it : http://www.msfn.org/board/topic/91336-usb-20-stack-for-win98me/#entry617413 and following ... jaclaz I can only assume that Tihiy never was aware of or tested 6127 when he made that post. That specific version was never mentioned in the thread by anyone. I had to do a significant amount of digging to find it myself, as it was buried in an old list of post-SP3 2K Hotfixes and apparently it was superseded because of some issue with it, IIRC. But it does work like the previous 5652. Apparently you're the lucky one if you're able to use 6657-6941 without problems. No one else has reported success with any version greater than 5652 that I am aware of, other than my 6127 report. I've run the same experiment with all of the USBPORT.SYS versions multiple times now on multiple machines. Every time, all versions later than 6127 cause BSOD's when I plug in a USB Flash Drive. I wonder if there is something different in the methodology used. Did you originally install your USB2 controllers using the later USBPORT.SYS versions? Or, did you manually update it after installing them with the older NUSB version? If the former, are you able to do the latter and still not get a BSOD? This issue mentioned by Tihiy is precisely the one due to USBHUB20.SYS v. 5.0.2195.6891 and VIA chipsets. While one can recover from the BSOD, the only sensible thing to do at that point is to restart or shutdown the machine. With time passing, I got convinced at least some of the issues with USBPORT.SYS occur only on machines using AMD processors with VIA southbridges (as is the case of my Asus A7V600-X with an Athlon XP 3000+). That seems to explain the difference in the results obtained by xRayer, Tihiy and myself vs. those observed by LoneCrusader and ProblemChyld. Intel machines apparently are much more forgiving than AMD/VIA, regarding whatever changed in USBPORT.SYS. Of course, these are just my 2¢... N.B.: I never tested v. 5.0.2195.6127, so I cannot say anything about it. Unfortunately, my 98SE machine is out of commission (and belly-up) at the moment, so, for the time being, I cannot volunteer to actually test it. Sorry! I've seen BSOD's when trying to remove a USB2 device from the Device Manager under Normal Mode as well. The best thing to do is remove or disable them in Safe Mode when necessary and avoid the problem. If this thread keeps going like it is, I may have to get you to move it into the 9x forum, lol.

Windows 98 (or later) USB drivers of any kind will not work under Windows 95, period. They depend on WDM functions that simply do not exist under 95. No amount of INF tweaking or wishful thinking will fix that. Trust me, I have tried. The only way to solve this is to backport several files from 98 to work under 95, thus creating a Hybrid system. rloew managed it, but unless he wants to further explore the issue I wouldn't get my hopes up.

I have found two versions that work. The original that is used in NUSB version 5.0.2195.5652, and one other comes from Q811011, version 5.0.2195.6127. Versions 5.0.2195.6657 and up all cause a BSOD on device connect. I don't know if any versions exist between 6127 and 6657; if anyone here knows of any please let me know.

You're welcome. I may have also solved this bizarre issue. It seems to have been caused by a BIOS setting, "USB Storage Function" which one would logically assume should be set to "Enabled" based on the less-than-informative BIOS Help text "Enable Legacy USB Storage Function." I set it to "Disabled" just to see if it made any difference and the issue seems to have disappeared. Strange... EDIT: Probably more informative in our 9x forum, but I also attempted to use some XP USB files under 98SE before I found the above. They did NOT work. USBEHCI.SYS would not load even though it wasn't missing any imports. USBPORT.SYS and USBHUB.SYS are missing several imports.

I downloaded the files you linked and examined them. I will update my INF's with the new devices soon. The ME USB1 stack should be equivalent to the 2K stack. ME was actually released after 2K. Yes, 2K saw updates for a longer period but probably any changes were specific to 2K issues while the ME stack was specifically designed for the 9x codebase. I also think it's significant that only one USB1 driver file out of the ME stack had a HotFix issued, while virtually all of the USB1 stack under 95, 98, and 98SE saw multiple HotFixes issued. I believe PROBLEMCHYLD's Service Pack uses all of the 2K USB1 stack if you want to experiment there though... I may have found a cause for the problem on my system. Check your BIOS for a setting to Enable/Disable "USB Storage Function". Set it to DISABLED and check to see if the problem still exists. My BIOS gives less-than-helpful text "Enable USB Legacy Storage Support" which one would logically assume should be turned on; but turning it off seems to have solved the problem on my machine.

I see. Here's the output. Hopefully it will shed some light on the issue you're investigating. i7_930.zip

Only the 3 USB2 driver stack files are common to both 98SE and 2K on my testing machine, so the problem must lie within them. I'm also using the ME USB1 stack files under 98SE as you are, but these files are all different under 2K. I have already ruled out the storage driver by the fact that it does not enumerate devices when they are connected, it only takes over once this is done by the controller driver. Also I ruled it out by testing with the ME USBSTOR.SYS, rloew's generic USB driver for 98, and with rloew's RLUSB9X, all of which behave the same. I haven't tested USB1 functionality with the USB2 controllers disabled, but this would defeat the purpose anyway. Well, while I've been unable to help you in this case, you may be able to shed some more light in another issue we've benn investigating... In case I'm correct, your machine has a i7-930 processor, which is a Bloomfield, a very early i7. Would you please be so kind as to run coreinfo (on XP or 2k) on it? Sure. What is coreinfo? lol

Unfortunately that's the only one I know of that is confirmed. And even that being said, I have never tested it. We only have RetroOS's old post about using it successfully, and no reports of it not working. The ME version of this file is actually known to not work under 98SE, but I assume that is because it is missing a WDM function. Very odd that the ME version is missing a function while the XP version is not, but I digress. This problem lies somewhere within the 3 USB2 driver stack files USBPORT.SYS, USBEHCI.SYS, and USBHUB20.SYS. We can narrow it down to those 3 files because the same issue is present under both 2K and 98SE when using them (actually seems to be worse under 2K). If I had to hazard a guess, I would say that the issue lies somewhere in the "device connect notification" subsystem; or there is some kind of "timing" fault with newer controllers. But I'm no programmer and have no idea how to debug the drivers.

I was hoping for a solution that fixes the native Windows 2000 files rather than having to use XP files. Those of us running Windows 98SE/ME depend on being able to use the 2K files, the XP ones won't work under 9x. Thanks anyway though!

Hello my Win2K friends! I have encountered a strange problem where USB2 storage devices are not automatically being recognized when they are plugged in. I have to manually "Scan for hardware changes" in the Device Manager in order for the USB drive to be detected. And then, the system seems to lock up before the drive is mounted and the driver installation sequence never completes. Unplugging the drive at this point will unlock the system, but an empty "ghost" Removable Disk is then mounted in EXPLORER. I originally discovered this problem while running under Windows 98SE using the Windows 2000 USB2 drivers. I found that I had to manually Refresh the Device Manager there to get the USB drive detected, and once detected, access and file transfers are ridiculously slow. Nothing I tried seemed to fix this, so I decided to install Windows 2000 and see if the problem still persisted there. It actually seems to be worse under 2K than under 98SE... The problem does not exist under XP SP3. System specs: Gigabyte GA-EX58-UD5 motherboard Core I7 2.8GHz CPU 4GB RAM NVidia GeForce 7950GT 512MB video card all onboard devices disabled in BIOS except USB Windows 2000 SP4+UR1 clean install with no other modifications whatsoever Any ideas?

Good advice, but note that Windows 2000, like 98, does not use USBCCGP.SYS natively like Windows XP and ME. In order to have it used under 2K some slight INF modding would be necessary. Compare the original 98SE/ME or 2K/XP USB.INF's for more info. Also there's this from Microsoft. Maybe more helpful... Also if I remember correctly (I've never dug into it, just read about it), there were actually 9x-compatible MTP drivers "provided" from Microsoft, but they were all left in a state requiring command line operation. No GUI was provided or any way to facilitate using the drivers with the existing GUI (EXPLORER, mounting devices, etc). So I imagine that at least this state exists for 2K as well, if not further developed.

Glad the new package is working. Odd behavior with the USB2 hub, I had a similar problem with Windows 95 on an ICH8 machine a little while back. One of the USB1 controllers would cause Windows 95 to hang up solid, triggering a continuous system Speaker alarm from the motherboard until powered down or reset. Disabling this specific controller allowed everything else to work normally. The exact same PID number controller works fine with 95 on a different motherboard. I've not worked out any solution for the detection failure/slow transfer issue yet. We may need to try using later versions of the 2K USB2 driver files if available. I know there was some mention before that later versions caused BSOD's, but if one of the later versions fixes the current problem it might help narrow down what to fix. If you want to upload the newer package somewhere or link to it I will examine it to see if it contains any devices I have not already covered. It's not hard to create an INF set for 9x or any other OS, just very tedious and time consuming. Should be even easier for XP when the time comes, since the NT INF structure will not have to be completely restructured as it must be for 9x.

Here's the new NUSB35CZ, let me know if you have any problems with it. Unfortunately I don't know very much about the ASD either, rloew mentioned once before that I should check for it when I was having some problems. It looks like we're going to need rloew's help to sort out these USB problems.