dencorso

I confirm xRayeR's results: In my experience, the last USBPORT.SYS to work OK in Win 98SE is v. 5.0.2195.5652, while for USBSTOR.SYS (in case one installs it with WDMSTUB.SYS v. 5.0.0.6 from NUSB30E) it's v. 5.0.2195.6773 (from KB823086). And for USBEHCI.SYS, the latest version that works is v. 5.0.2195.6882 (the latest available for W2k, check it here). Now, in what regards USBHUB20.SYS, it's more complicated: almost all chipsets work ok with v. 5.0.2195.6891, but VIA's don't. For VIA's chipsets, one needs VIA's own USBHUB20.SYS v. 4.90.3000.11 (findable inside VIA_USB2_V270p1-L-M), in order to avoid BSOD's on removing (hot-deplugging) USB 2.0 HUBs from the machine. Note that it must be substituted by hand, in true DOS, because NUSB3.3 contains v. 5.0.2195.6891, so it's really a downgrade. With all due respect, I really marvel at how PROBLEMCHYLD's machine can get to run those XP versions at all. 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. @MDGx: If you could create a downgrader just for USBHUB20.SYS, for VIA machines, that would be most welcome and handy. Since NUSB 3.3 installs OK even on those machines, it would just be a matter of running the downgrader after installing NUSB, but before using any USB 2.0 HUB.

Tommy James and The Shondells - Crimson & Clover

Windows 98, 98SE and ME does work with 3GB of RAM but you will need the Patch I wrote to support it. The only alternative is to limit the amount of memory that Windows 9X sees. RLoew is right! That's the way to go. It's possible to use 3GB or even more. See my > 1 GiB list, for which a link is in my signature. I use RLoew's RAM Limitation Patch and so does Dave-H, and we're both very satisfied customers. Then again, be advised that to boot Win 9x from USB is not a trivial task, either.

Thank you very much, Maximus-Decim! You do rock! Sadly, however, some mojibake found its way into the [strings] section, like: insted of: But that's easy to correct, so: I've restored the original text in the [strings] section, instead of the mojibake, and also made very minor corrections to the history log, so please find attached the corrected version usbstor110c.7z

Just one minor suggestion: get sticpl.cpl from your backup and put it back. It ought to just work.

Did you also see the usbvideo.inf it also has drivers. Did you guys add these updates? No, it adds a new class, USBSTOR_CBI_NR... I think it's better to leave that to Maximus-Decim, who knows NUSB much better than any of us, to add them, in case he finds it possible.

Aztec Camera - Jump

Forum moderation is not up for public debate (Rule #8), as you know. Thread closed.

Yeah, USBSTOR_BULKNO is dummy that allows you to install other drivers without having to disable USBSTOR.INF. Using this setting, you might be able to use NUSB for all slots but the one that NUSB cannot handle, and then add another driver just for that slot.

Update, by hand, in true DOS means out of Windows. Here's one of the many ways to do it: (i) while in Windows: Create a temporary folder and extract USBSTOR.INF to it; Rename USBSTOR.INF to USBSTOR.NEW; Move USBSTOR.NEW to C:\WINDOWS\INF; Delete the temporary folder you created just for this procedure; Click on Start and select "Restart in MS-DOS mode". (ii) in DOS, issue the following commands, at the prompt: cd \ cd \WINDOWS\INF <Enter> ren USBSTOR.INF *.OLD <Enter> ren USBSTOR.NEW *.INF <Enter> exit <Enter> (iii) Windows will restart, and your update is done.

There are still two more attempts to be made: USBSTOR_CBI and USBSTOR_CBI_U2A. In case neither works, set it as USBSTOR_BULKNO, and we proceed to add a new driver for it. If so, one of theseXP drivers may be of help, but no one will install directly, so I do hope we'll not need to try that. Wow. I had missed that one! Sure. Attached is the new, consolidated, USBSTOR.INF, incorporating MD's mods and mine. So this one is the most updated version of the USBSTOR.INF for NUSB, as of today.Thanks a lot, ElectricString, you do rock! USBSTOR.7z

Try to set it as USBSTOR_BULK or as USBSTOR_CB instead of USBSTOR_BULK_AUTH. Let's see what happens. Looking at the INFs in 2k driver may be instructive also...

I bet avgabout.dll v. 7.5.0.24 is good enough. If you save a copy of it in a secure place, you may then update it from the internet until it nags you. Then point the update system to a file, reboot into true DOS, and rollback just the avgabout.dll to the one you saved. That'll give you the most updated binaries of all the other components. But, as long as you keep updating the AVI and IAVI regularly, AVG 7.5.524 is good enough, so this update procedure I just outlined is optional.

I'd not bet on it. MD was thinking that Win ME files are not for the NT-family OSses, of course. But you may install it by hand, taking care to omit any file for which a newer version already is in the system, and see what comes of it. If it works, it'll be worthwhile to search for the correct xp files (probably from sp1 or sp2) to upgrade them afterwards. Worse that can happen is to trash your system completely. But nothing that falling back to the backup won't solve...

True! You're right Charlotte! I had noticed that uncommented comment some time ago and also corrected it in my own version of it, but somehow forgot to post about it. It in fact does not break the .INF, but I don't know why... Probably the .INF interpreting engine just drops out uncomented meaningless (for it) lines, instead of barking at 'em. Be as it may, since we're discussing it now, I've decide to release my current version of the USBSTOR.INF, for what it may be worth. It corrects the error you mentioned and adds one more floppy (Citizen X1 USB FDD = IOMEGA USB FDD), one more camera (Samsung Digimax 220) and a commented out line that installs wdmstub.sys, for use with the Win 2k usbstor.sys, as per our discussion some posts above, for those interested in it. So, for use with the default Win ME usbstor.sys, leave everything as it is: and for the Win 2k usbstor.sys, invert the comment before use: Of course, USBSTOR.INF must be updated by hand, in true DOS... Enjoy!Later edit: I removed the attachement that was here, because it's been superseeded by usbstor110c.7z, findable in post # 543, below.

@Charlotte: Please post both the different lines, and I'll tell you. Update to explorer 4.72.3612.1710 from MDGx's and you'll have it all. @Philco:It must be a leftover of Maximus-Decim first experiences with wdmstub.sys If you add it to update.sys, it becomes permanently loaded, so there maybe would be unnecessary to add it to usbstor.sys... but afterwards MD decided to add it directly to usbstor.sys. So either adding it to update.sys doesn't work, or it does work, but MD preferred to use wdmstub.sys in the way it was originally intended for use by its author, Walter Oney. You may leave it there, or you may delete it.

A quick member search with (Post count > 2; Last post > 01-01-2009; OS = 95) returns eight members!!! So that, in fact, would be 9, because BenoitRen doesn't list any OS in his profile... Add Nathan Lineback and we have 10! Who'd imagine there still would be so many 95 users!

I confirm that rolling back avgabout.dll to v. 7.5.0.556 eliminates the nag, with no adverse effects.The further rollback of avg7US.lng is not necessary however, because avgabout.dll v. 7.5.0.556 works ok with the avg7US.lng intended for the later avgabout.dll v. 7.5.0.560 (the nagging file). I also confirm that the manual updates continue to work OK. I'm now using AVI 270.14.113 and IAVI /2572 (u7avi181845.bin and u7iavi257245.bin). You do rock, sleffing! BTW, are we the last two users of AVG 7.5? If more of you all are using it, please let us know.

Hi, Dave! Yes, I think you should try it. If it ever works, you can then update the new files it adds to XP versions and test again. If it doesn't, you can always fallback to the backup and then we begin to study what are the differences between the XP and 98 WIA structures, in order to be able to give it still another shot at making it work. Good luck!

Sorry, jaclaz, I don't want to argue either, but there is more to be said. RLoew and me are far from being the only ones that consider MSCDEX an IFS, or to say that there are IFSs in DOS. I could have stated it better, though, so I'll amend my original statement to: IFSes in DOS are implemented either as TSRs or as device drivers (in form only), either standalone or, preferably, using the network redirector (as fictitious remote filesystems). See: (i) Andrew Schulman, Raymond J. Michaels, Jim Kyle, Tim Paterson, David Maxey and Ralf Brown, UNDOCUMENTED DOS, chap. 4, p. 153-259, 1990, ISBN 0-201-57064-5, and (ii) Andrew Schulman, Ralf Brown, David Maxey, Raymond J. Michaels and Jim Kyle, UNDOCUMENTED DOS 2nd ed., chap. 8, p. 401-540, 1993, ISBN 0-201-63287-X. MSCEDEX.EXE is a good example of IFS: You can think of how it's used: [PATA CD/DVD writer] --> oakcdrom.sys (the true device driver) --> MSCDEX (the ifs) --> DOS kernel --> UI [uSB CD/DVD writer] --> usbaspi.sys + usbcd.sys (the true device drivers) --> MSCDEX (the ifs) --> DOS kernel --> UI While one cannot read the source to MSCEDEX.EXE, one can read sources of various versions of shsucdx.exe (found here and here, which is even more full-featured than MSCDEX), a truly interesting reading. Your examples are very apt, Note, however, that the best version of Phantom is in ref. (ii) and in its companion diskette: it's implemented as a fully usable XMS ramdisk (with source, of course).... Now returning to ext2, I've still not found a DOS IFS for it, but there are reader programs for DOS: dft, EXT2TOOL and LREAD10 (findable in the very interesting page Filesystems-HOWTO). Here there is more on EXT2TOOL

No, it's not! IFS in DOS are implemented as device drivers or use the network redirector. MSCEDEX.EXE just comes to mind as the more widely known example. I think there's a definite possibility that someone just may have written some ext2 driver, too. Let's search a little for it and see what do we find. For what''s worth, here is a comparative pendrive test I've conducted, in as similar conditions as possible: (link).

I've merged all scattered threads I was able to find about 7200.12 in the present consolidated thread. It seems they also have a problem, much like the 7200.11, but the reports are still very few. Maybe the problem is less common, maybe there's still just a few people using them. However, I feel we should keep alert to it. Did any of you all find other reports about it elsewhere?

Here's a real-word comparison of SLC vs. MLC using pendrives, and with the same (or almost) controller to make things easier. Bear in mind that the attached table was created with the objective of comparing pendrives, not of comparing SLC vs. MLC, so the Kingston pendrive is there just to show your average el-cheapo performance, as a reference. The Corsair Flash Voyager GT 8 GB and the OCZ ATV Turbo 8 GB are SLC, while the the non-GT Corsair Flash Voyager 8 GB and the Kingston are MLC. As a side note, only the Corsair Flash Voyager GTs of 8 GB or less, all dicontinued by the manufacturer at present, are SLC, while the 16 - 128 GB Corsair Flash Voyager GTs are MLCs, albeit very fast ones at that. So, the OCZ ATV Turbo 8 GB is the only commercially available high-performance SLC pendrive at the moment, AFAIK. Then again, good MLCs perform very near the performance of SLCs, or, at least, that's how I interpret the results of my test in the attached .pdf, so this issue far from being such a big deal as it's advertised. @CoffeeFiend: all four pendrives were brand-new, except that I repartitioned them to have a single active primary 4th partition (Zip100 standard) and reformatted them with FAT-32, using 4 kiB clusters (half the MS recommended value), so they have about 2 million clusters, each. Pen_Drive_Performance_Tests.pdf

Is it possible a later version of these functions could be implemented with KernelEx or a similar compatiblity-layer type application, thereby bypassing the need to patch a bunch of different software? I think it's not possible. They're too low-level and deep inside the core of the OS. Sorry.

Well, it's a RunCore... Consider it's SATA I (the Eee PC 900 southbridge is ICH6-M), so it performs very near the max. 150 MB/s allowed by the interface (and performs almost on a par with the Gigabyte i-RAM, which also is SATA I, but uses DDR SDRAM, and hence is a good indicator of what the realistic maximum for SATA I truly is)!