dencorso

Well, it actually IS possible to use NUSB 3.3 with other manufacturer-provided drivers. It gets easier to do in the case you don't have any files having the same names of any of NUSB's files. But, even when this happens, it can be made to work by careful renaming of the offending files and editing of the appropriate .INFs... Of course, Maximus Decim doesn't say so in the documentation but, then again, the documentation is aimed at the average user, and this is an advanced topic. And Maximus Decim is known for his terseness. I'd uninstall the current USB 2.0 and any third-party driver happening to have same-named files, solve this latter problem by renaming and editing, reinstall the third-party driver, install NUSB, use Add/Remove to remove the generic USB 2.0 stack, and reinstal my preferred USB 2.0 stack. From this point on, what driver installs for each new device detected can be controlled by masking/unmasking .INFs through their renaming (by changing their extension). It's not quite a pretty walk on the park, but can be done and, AFIAK, works OK. Of course, backup, backup, backup and backup again, before even thinking of starting this procedure. As always, here, my standard disclaimer applies: It works great for me, but YMMV and I can guarantee nothing whatsoever about this procedure, and about the use you make of it. So, by deciding to apply it you fully accept that anything you do is of YOUR SOLE RESPONSIBILITY... Hence, if after performing this mod your pc morphs into a purple mushroom and explodes, causing a 10-day worldwide blackout in the process, you know you can't blame me for it!

Give a close look into PassingBy's posts inside Maximum Decim's NUSB thread. If I remember right he was working on generic support for Win 95.

@Multibooter: 1) Yes, of course, I should have written /SCSI/ instead of /USB/... And a complementary experiment, say, for a drive at letter Q, for which you'll find an entry: CurrentDriveLetterAssignement='Q' add a new last entry: UserDriveLetterAssignment='QQ' And see if this prevents it to get detected anew (I doubt it'll make a difference, but it's worth to try it). There should be another entry, just one, for every known device, this one under /USB/, with key names like VID_04B4&PID_6830. The subkeys to these keys are multiple detections... 2) If cfgmgr32.dll made a difference, maybe adding NTDLL.DLL v. 4.90.0.3000 would also help. You are already using USBNTMAP.SYS v. 4.90.0.3000, aren't you?

Let me add my 2 cents... IMHO, it's too risky to use: 1) FAT-12 above 32 MiB (127 MiB is possible with patches), it's better to use FAT-16 instead. 2) FAT-16 above 2 GiB (8 GiB is possible with patches), it's better to use FAT-32 instead. Otherwise, sooner or latter, some program will trash the partition, at the worst possible time (Murphy's Law).

Just one: I) Backup your registry by copying SYSTEM.DAT and USER.DAT in a safe directory in the hard disk, preferably out of the system partition. And make a second copy in a SDHC card (and store it away from the computer, in a safe place). II) Detach all USB storage devices. III) Start regedit and clean by hand, by deleting, all devices related to the phoney drive letters under HKLM\Enum\USB, guiding yourself by their VIDs and PIDs. But let the entries for the real drives alone. IV) Reboot. V) Reboot again. VI) Reattach the USB storage devices. Let's see what happens.

You can switch it to APM instead, and see how it behaves... It's easy, just set: "ACPIOption"=dword:00000002, restart, redetect your hardware and restart. This may solve your duplicate drive letter problem and keep the auto turn-off working.

That's true. On the other hand, the patched io.sys (wme.zip) for Win ME is based on the original retail Win ME io.sys (110080 bytes 06/08/2000 05:00 PM) because they have the same size and just 82 differences between them (hence it's a patch), and not on the Win ME version of KB 311561 (110080 bytes 11/29/2001 09:29 AM), which has also the same size but 105963 differences from the file provided by Steven (hence they are completely different files, one cannot be a patch of the other). And no patched version of winboot.ebd (the bootable diskette version of io.sys, necessary to be able to use the "Real DOS-Mode Patch for Win ME" on it and make Win ME more bearable ).

Don't worry: Adobe offers a full collection of previous versions you can download (but it's a quite big file). So it's possible to fall back to the previous version of your choice (but don't forget to uninstall the current version before installing the older one). Find them here. Enjoy!

The classic multiple detection problem with Win 9x/ME is related to internal (ATAPI) Zip Disks: if one doesn't deactivate their detection by the BIOS, they get detected again by Windows all the same and one ends up with two different drive letters for a single Zip Drive... So I think you must've been witnessing detection at multiple software levels. Try removing the Orangeware drivers and adding NUSB's generic USB 2.0 stack (i. e.: reinstall nusb 3.3 again, then rename usbstor.inf) and let's see what happens. But do save a full system partition image before doing it, just to remain on the safe side. Good luck!

read this and then this, and the links pointed to in both posts. bear in mind that, while FDISK depends on the size of the disk, NDD, NDD32, DEFRAG, SCANDISK and SCANDSKW/DISKMAINT depend on the maximum number of clusters a partition is made of. FORMAT depends on both. The DOS programs NDD (from NU 2002), SCANDISK, FORMAT & FDISK (from DOS 8, i. e. the DOS part of Win ME), as well as SCANDKSW (from Win ME), are known to work ok with disks up to 500 GB. The LLXX ESDI_506.PDR is needed in windows to make it compatible with 48-BIT LBA. But that is necessary but not sufficient. I've used NDD32 (either from NSW 2003 or 2005) successfully with partitions up to 250 GB (7.6 millions of clusters), but it wasn't able to handle a 500 GB partition (15.2 millions of clusters , which I ended splitting into two 250 GB partitions, just because of this). The limit is somewhere between 7.6 and 15.2 millions of clusters for NDD32.EXE, but I don't know exactly where.

Well, don't worry! You missed it but it also has still another unresolved export "SHBindToParent" in shell32.dll... Those are some of the few unsatisfied dependencies know to be harmless to Win 9x/ME. HTH

Deeply heartfelt thanks to all members that responded to my post. I'm working on your suggestions... I'll sure keep you posted on the newer developments. You all rock!

Well, I, for one, use cpu-z and WBEM for a very long time and never had any issues of the kind. However, WBEM is one of those add-ons lots of people get to hate... YMMV, of course. But thanks for the heads up, anyway. Now, quoting myself: and here's what I get from my Corsair Flash Voyager 8GB, under Win XP SP3: ==================================================== Device Name: +[Q:]+USB Mass Storage Device(Corsair Flash Voyager USB Device) PnP Device ID: VID = 090C PID = 1000 Serial Number: A100000000000102 Revision: 1100 Device Type: Standard USB device - USB2.0 High-Speed Chip Vendor: SMI(??) Chip Part-Number: SM321/SM324 Product Vendor: Corsair Product Model: Flash Voyager ===================================================== @Multibooter: Of course, there are problems with Device name, product vendor and product model. But seems better than your results. Please do try a pen drive, so we can see whether I'm really getting better results or not. And, BTW, there are 3 hotfixes known for WBEM: Q260710, Q282949 and Q285895. They are findable at MDGx's, as usual (in the WMI section).

It just removes the Universal USB 2.0 Stack (cf post #1), probably to give people the chance to uninstall it before installing either Sis or VIA USB 2.0 Stack. It does not remove the core NUSB files. You can remove NUSB from DOS by hand. But most of the files not directly related to USB don't need to be removed in any scenario I can envisage. Then again, YMMV.

Read NVidia drivers 8269 (post # 211), for a start, then the whole thread. If that's not enough, then proceed to read my sugestions in post #2 of this thread, above. HTH. BTW, what does the ideogram in your avatar mean?

To create a patch that works (unless one is so incredibly lucky that turning to a lottery ought to be much more profitable), one must be a knowledgeable programmer and/or reverser. It involves long hours of effort and dedication. And many more of plain bitter failure! It's not as difficult to document what the patched file does. Some patchers do it better than others... And there is always room for improvement, of course. But to think that a malware/virus developer would turn to the 9x/ME community to use it as a test bed is akin to propose using bicycle races to test tyre rubber formulations for use in Formula 1! It makes no sense! A malware/virus will be targetting the XP/Vista machines, because that'll enable the malware/virus its maximum spread. We are less of a target than the Linux/Free BSD users, for the single reason that we're, by now, less than 1% of the total computer user community. Worrying about unintended virus/malware presence in some patch is very paranoid, but tenable. But to dream about scenarios of a deliberate spread is just ludicrous. While I agree that, in Andy Grooves' words, "only the paranoid survive", I think too much paranoia paralyses one completely. Moreover, in my experience, the origin of 95%, at least, of all problems faced by computer users has its origin between the keyboard and the chair. And every client always tells you: "I did nothing unusual..." Well, I'd better stop here. I guess I'm entering the ranting mode. I intended no offense to anyone, so please don't read what I wrote as any type of it. You all rock!

I've searched high and low throughout the net, but am unable to find anything able to perform a detailed boot profile like BootVis used to do, and BootVis itself refuses to work on my Win XP SP3... I'd be very grateful to anyone able to point me to a working alternative, even if shareware. My system works well, but it has an annoying feature: every time I boot it, after it already loaded the desktop and is loading the auto-start programs, it'll breifly flash a black screen, just before starting the network, which is usually the last thing to load. There is no lag, so it's more a harmless annoyance than a problem, but I'm willing to catch what's causing it, if I can. My attempts to do it using the bootlog alone have led me nowhere, up to now... Then again, I'm much less experienced with XP than with 9x/ME, it can be my fault, of course. BTW, how can I cause NTBTLOG.TXT to record not just the loads and failures, but its times as well, like in the 9x/ME family BOOTLOG.TXT? It sure would be of help. Please advise, and thanks in advance!

Welcome to MSFN, rldelrosario! Visit and read this topic, Day-to-day running Win 9x/ME with more than 1 GiB RAM, follow and read the links, all your questions will be answered. And you'll be able to get your Win ME working!

Yes. But it does kill the fly.

Sorry, Bug_zs! I misspelt it. It's MDDACU. Find it here: http://www.msfn.org/board/Maximus-Decim-Da...ess-t93448.html BTW, even before Googling, always look here: http://www.msfn.org/board/Important-Stickified-P-t95815.html, where you'll find out that there is also the MDIE6CU, for IE6, by Maximus-Decim, which may be of interest to you.

That's normal. Mine also says that and it's running OK. Guess it's a bug in the Component Checker. Don't worry. Yes. Let it be as it is or, even better, apply Maximus-Decim MDACCU while you're at it.

Well, the installer won't overwrite same or higher version files with same or lower version files, but you can do it by hand, from a true DOS session (not a DOS box). I believe NUSB3.3 will work quite contently with the .SYS and .PDR files from the MSI StarReader driver and vice-versa. Now, the .INFs are another story altogether... But, then again, they are just plain text ASCII files, which you can switch from a DOS box at will, and that you may consolidate into revised .INFs, working for both drivers, if you find it worth the effort. I've downloaded the MSI Win 98 driver and shall take a look at the files asap, and report back. Meanwhile, and quite off-topic, let me recommend to MsiX.EXE, a fantastic command-line tool, able to extract files from .msi, .msm and .msp installation files. Find it here: Heath Stewart's Patch Files Extractor

I hadn't thought about it before, but since the versions of all the files Multibooter is using are the same as the ones I'm using, as far as dependencies detected by DW go, the problem must lie elsewhere... and I think Multibooter just hit jackpot: the problem may be the underlying drivers. I'm using VIA's USB 2.0 EHCI driver, not the generic one from NUSB, nor Orangeware's. We need someone else using a VIA chipset and VIA's driver to test whether this is it. I can think of no other explanation right now.

Mine is just an MSI MS-8817 V1 nVidia GeForce2 MX400 PRO32S (32 MiB; AGP 4x)... B) If you visit this topic, Day-to-day running Win 9x/ME with more than 1 GiB RAM, you'll find out about the video cards used by some other members as well.

Hi, Multibooter! Here are the versions I'm using of all files detected by Dependency Walker for ChipGenius: Primary Dependencies: CHIPGENIUS.EXE 2.0.0.64 KERNEL32.DLL 4.10.0.2226 MSVBVM60.DLL 6.0.98.2 Secondary Dependencies: ADVAPI32.DLL 4.90.0.3000 * GDI32.DLL 4.10.0.2227 OLE32.DLL 4.71.3328.0 * OLEAUT32.DLL 2.40.4520.0 USER32.DLL 4.10.0.2233 I bet you're using a much earlier version of MSVBVM60.DLL, do get the above from MDGx's and try again. And if that's not enough, I'd go for the ole files, from unofficial OLEUP. The files marked with * are from Win ME, but I sincerely doubt they are the one(s) that are critical. Good luck! As a sample of what I see, here's what I get from my Corsair Flash Voyager 8GB: ==================================================== Device Name: ++USB Mass Storage Device(USB Disk) PnP Device ID: VID = 090C PID = 1000 Serial Number: A100000000000102 Revision: 1100 Device Type: Standard USB device - USB2.0 High-Speed Chip Vendor: SMI(??) Chip Part-Number: SM321/SM324 Product Vendor: USB Product Model: Disk =====================================================