LoneCrusader

Really? Not this argument again! I'll stick with MSCDEX until it fails me, which it has not. And MSCDEX should already be on the OP's system as opposed to looking for a 3rd party tool.

You can load MSCDEX.EXE to access optical drives. There are DOS USB Drivers, but having never used them myself, I will leave that one for others who have more experience with them.

Because NUSB 3.5 (and by extension the Service Pack) replaces all of the USB Driver stack files. That includes ALL USB devices, not just storage. If one installs either of these packages without first removing devices, it can lead to problems, such as those described by Drugwash in the NUSB thread.

The key word is Remove followed by the word (ALL)I believe the confusion arises from the differences between NUSB 3.3 and NUSB 3.5. NUSB 3.3 and EARLIER only require removal of USB2 and USB Storage Devices & Drivers. NUSB 3.5 and likely any FUTURE versions require removal of ALL USB Devices, period. @PROBLEMCHYLD Might help to quote maximus-decim on NUSB 3.5 instead of 3.3.

For the record I do sympathize with you on this. I have often been irritated by downloaded files not having their original file attributes, as it is useful for version control or to differentiate between different sets of files with the same name downloaded from different sources. (Example - recently I was searching for the absolute oldest USB2 driver stack that existed, with the hope of finding a stack that could be loaded on Windows 95. I found several older stacks on various FTP sites (files dated late 2001- early 2002) that I needed to keep organized by their original attributes, but when downloading, the dates were naturally set to the current date. Very frustrating, and an organizational nightmare! ) As you encountered file timeout errors, I would suggest setting your software to only download one file at a time, especially for "forensic accuracy." My FileZilla was set to download one file at a time, and I encountered no timeouts or errors of any kind. (Of course it is possible that there were unreported issues, as you pointed out.) If this does not prevent the errors and/or changed attributes, then I would suggest trying to re-download the affected files separately.

Confirmed as counted from the \Win98 folder. Confirmed as counted from the \Reskit folder. I also downloaded with FileZilla 3.5.3 under XP.

The fact that few people do this does not make the error less significant. That is all a matter of opinion. I don't use nVidia cards, so I can't address this specific issue. But if I encountered such problems with my ATI cards, I would certainly not be happy, and probably would not consider it "minor."

Hang on a sec, I think I may have misread. I thought you had found a newer Win2K "USBHUB20.SYS." If it is indeed just "USBHUB.SYS" it will replace a 98SE USB1 driver stack file. Not to say that it may not work fine under 98SE, just needs more extensive tests. Trust me, I've been seeing a lot of headache with USB driver stack files lately. Not as much as someone else I know, but enough.

The specific bug I saw mentioned in those links seems to only apply to a USB1 modem under Win2K. Windows 9x has it's own native USB1 driver stack and AFAIK does not use the USB2 drivers at all for USB1 hardware. Probably needs further/broader testing. EDIT: Misread. See next posts.

No Classic Start Menu! At least Vista has this You bet I'm doing it already. Just bought a pair of never-used A7V600-X motherboards (I love those boards) for a trifle (DDR, no SATAII, who, but one of us, would want them?)! Yes, I too have accumulated quite a stockpile of Windows 9x compatible hardware. Motherboards I think I have covered. (My girlfriend called me a "motherboard hoarder" the other day LOL ) High-end AGP video cards and RAM are my biggest concerns right now. Especially given the fact that Kingston DDR RAM is NO LONGER AVAILABLE from Newegg

Unforeseen Problems? Such as? What documentation do you have of this? I am well aware of discrepancies in various KB articles, but, until I see documentation stating otherwise, I will accept Q282901 at face value. Well, since Petr did not state that he didn't have the files in English, then I'm not convinced that he does not. :angrym: If I were Petr, I wouldn't send you any HotFix that I had after the "less than courteous" way you reacted to his solving the Q312108 issue. You were blatantly incorrect, as I have now proven.

Wow... I was just shooting in the dark with that. Almost didn't post it, I figured people would think it most illogical. Anyhow, you're welcome!

It may only be available in Japanese currently, but it was available in English. (I have also contacted MS about it to no avail.) Straight from the KB Article: Petr apparently had it at one time, but he is no longer active here and I have been unable to contact him.

No problem, glad you have solved the issue. Did you happen to test whether or not a specific one of those files causes this, or did you just replace them all at once? I actually need to try and find a system to run some tests of my own on this scenario. I went ahead and slipstreamed those files in my slipstream project, but I hadn't had any issues as I don't have that particular hardware. I wonder, if this issue only presents itself if you UPDATE the files, or whether it still surfaces if those files were ALREADY present when the driver was first installed...

I have a feeling this is an example of where the "latest" available files may not necessarily be the "best" available files. See this quote from MDGx regarding Q242937 / 269601USA8.EXE: I'll wager that you have included that HotFix in your USP. Try rolling back the versions of those files to the 98SE originals.

@erpdude8 I was wondering where you found CONFIGMG.VXD v4.00.1113 that is contained in your USP? I have been unable to turn up any KB articles or HotFixes that mention this particular version or what it was supposed to address I have found CONFIGMG.VXD v4.00.1112 in the PCCARD Update (IIRC ) as well as on the Windows 95C CDROM, and I have found documentation that a v4.00.1114 exists in the Q282901 HotFix that no one seems to have, or be able to find, except Petr, who apparently had it at one time, but he has now disappeared

Indeed, I have a Wdmstub.sys file in version 5.00.006. Working with the earlier version did not check, because Wdmstub.sys version 5.00.006 is installed by Maximus Decim Native USB 3.5. WDMSTUB.SYS does exist inside NUSB 3.5, but it is not used. It is not required unless one uses the Win2K USBSTOR.SYS. NUSB 3.5 still contains the WinME USBSTOR.SYS.

Regarding the VIA USB2 Controllers Issue - My suggestion on how to handle this would be to create a SFX installer package that contains the latest VIA USB2 stack, along with an INF, say "USB2VIA.INF" that contains ONLY the information for VIA USB 2 devices. You could take the USB2.INF from NUSB3.5 and simply edit out the information for all manufacturers except VIA, and see that this INF has a later timestamp than the one in NUSB. Then, when installed, this INF should be detected as an "Updated" Driver for the VIA hardware, rather than the older timestamped USB2.INF from NUSB. Care will have to be taken as to where the USB2VIA.INF pulls its driver files from though, as the VIA USB2 stack files have the same name as the Win2K files...

I'm glad to hear you're up and running at USB2.0 speeds. I'm not sure what you mean by this however Do you mean the drivers you just installed, or do you mean a Mass Storage Device driver?

I haven't heard of Xeno86 patched VCACHE.VXD, so I'm obviously not using it. I'm also not using rloew's patch either. In any case, SP3 shouldn't make assumption about what may be installed, and should just leave MaxPhysPage as-is. In that case I guess I've been using it; however, the MaxPhysPage setting still crashes the computer I'm current;y working on. Since this subject has come up, I feel that it is worth mentioning here that any fiddling with MaxPhysPage and such settings in regard to RAM ALWAYS produced unstable and unpredictable results on my systems. I tried several years back to change these settings in order to use 1.5GB of RAM. It never worked, period. I know some have had success in this area, but I believe it is very much a "YMMV" issue, and I agree that a Service Pack should not change these settings. This is one of the main things that makes me "not a fan" of unofficial Service Packs.

If you find a source for these we need to create some sort of "archive" to preserve them. I have often searched for some older versions that still have Windows 95 Support, to no avail. At least I still have a drivers disc for the cards I use in 95...

Glad to hear it!

Never fear, lol, almost all (95%+) of my hardware is Intel Chipset based. We will get to the bottom of this! I thought you said you had Intel USB 2.0 Drivers, because you asked if you should uninstall them when you first asked about NUSB? If your Intel USB2 driver package works like the one I have, when you run the "installer" it doesn't really install anything. All it does is extract itself to C:\WINDOWS\DRIVERS\. This is, shall we say, less than helpful. If it extracted itself to C:\WINDOWS\INF\, it would be useful, but I digress. Go into your Device Manager and see if your USB2 hubs are properly recognized. If they show up as unknown devices, remove them, and reboot. When asked for the location of the driver, point the installer to C:\WINDOWS\DRIVERS\ or wherever your package has extracted itself.

I have not personally used that particular package, but I have many other packages and updates created by R. Loew. You can rely on anything he distributes to be high quality. This, combined with your Intel USB2 drivers you mentioned before, may be a working alternate solution if you are unable to localize NUSB.

I figured that you had probably checked. I was in the process of pulling that breakdown out of my slipstream notes when you posted, and once I had gone to the trouble of extracting it, I thought I would go ahead and post it, it may be of future use. Myself having never checked for other language versions, I figured sorbit4 could give it a shot...