LoneCrusader

Even though I tried with Firefox 3.6.27 on XP, when I try to download that tool, my browser is blocked and demands an upgrade. I fixed it though. Changed the User Agent String to a set of less than complimentary expletives, and it let me in.

Is that in the system.ini file? Because I looked for MaxPhysPage/MaxFileCache entires in it after installing the pack and couldn't find any. Right now I just use a floppy to restore those 3 files (vmm, vcache, and esdi_506) after installing the pack. Is that sufficient or am I not fully restoring it? I'm fairly certain rloew is referring to the VCACHE.VXD v4.10.2223 that is installed by the uSP. It is an unofficial "workaround" version and would be incompatible with the RAM Limitation Patch. I would recommend you follow rloew's instructions for removing and reinstalling the RAM patch after the uSP rather than trying to restore it manually. The uSP updates VMM.VXD, which is a good thing, and it would need to be patched rather than the older VMM.VXD extracted from VMM32.VXD. Basically, if you plan to use the RAM Limitation Patch, you WANT the VMM.VXD installed by the uSP. You do NOT WANT the VCACHE.VXD installed by the uSP. I believe PROBLEMCHYLD removed the other RAM tweaks from the uSP.

Same here.

Rubbish.

Hmmm... What about using an IDE male-to-male converter/cable to plug the adapter into, instead of plugging it into the board? Then you could connect the master or slave connector of the IDE cable to the other connector/end of the converter/cable. Anyone ever tried this?

You will have to get the RAM to 512MB or less, or take your pick between: - "tweaks" (which will get you to ~1.2GB if they work; I personally have never been able to get them working) or - rloew's RAM Limitation Patch (which is not free, but worth the price, as it enables using up to 4GB without any other modifications). It doesn't matter if your HDD is IDE if it is connected to a SATA port. The motherboard interface is what matters. You will either have to: - set the SATA controllers to "Legacy" or "IDE" mode in the BIOS or - invest in another of rloew's patches. If your HDD is larger than 137GB, then you will also need a patch for that. Once you know the "must haves" for setting up a 98 system, it's not hard, but you have to know and understand the things you must do first, or you will have nothing but headache.

I don't think WDMSTUB is needed under ME. The Win2K USBSTOR.SYS has no missing functions with WDMCHECK under ME, but further testing may be needed. There's also no known advantage to using the Win2K USBSTOR.SYS... There are no problems with the ME version. The only rationale for using the 2K version is that "newer files must be better" - which is questionable, especially since the ME version was written for 9x, while the 2K version was written for NT. I have reverted to the ME version on all my systems.

Some "deep" investigation revealed that Microsoft made changes to how USB devices are enumerated at a point between 98SE and ME. "Files from that period" might possibly be usable, but would be purely experimental, still suffer from the removed CONFIG.SYS content that I mentioned, and would not have any of the fixes applied by later HotFixes. Personally I've written this off unless someone can figure out what Microsoft changed about the enumeration of USB devices and apply it to the proper 98SE HotFix version.

This is a USB 1.1 Controller. I think the "misunderstanding" here may be deeper than we originally thought.

Ok, we've still got some miscommunication/misconception going on here. USB20DRV.EXE does NOT provide external USB storage device support by itself. It was only intended to be an update/tweak of settings/files already applied by NUSB. MDGx probably should not have it listed for ME. Many of the files contained in NUSB already exist in Windows ME. They are addons and upgrades to 98SE, but several of the files require modifications to run under 98SE. These modifications are NOT needed under ME, and adding the modified versions may break the original ME versions under ME. Under ME, you will need ONLY the files I listed to achieve what you want. Any other files should be removed or reverted back to the ME originals. The USBSTOR.SYS you have is a Win2K file from one of the packages. Remove it and extract the original ME version from your Windows ME CDROM. It should be v4.90.3000. There is no 98SE version of USBSTOR.SYS. USB2.INF and USBSTOR.SYS are unrelated. -USB2.INF is for USB2 Hub & Port support ONLY and controls the 3 .SYS files I listed previously. -USBSTOR.SYS is used ONLY by USBSTOR.INF which controls external device support. As far as NUSB 3.5 vs 3.6 : there is nothing of any importance for Windows ME changed in 3.6 except the addition of a Digital Camera to USBSTOR.INF. This also requires another .SYS file. Unless you need that specific camera supported, then don't worry about it, and all of the other files I mentioned are the same in either version. Be sure to use the VIA .SYS files since you have a VIA chipset. Had you previously connected any of your storage devices to the machine before you tried to enable USB2 support? If so, entries for them may still exist in other places in the Device Manager. These entries would have to be removed before the devices can be recognized again. Check for entries related to your storage devices under "Disk Drives" and "Storage Devices" as well as the "Universal Serial Bus Controllers."

Welcome to MSFN! I know you asked specifically about Opera, but since you asked about "modern browsers" for 9x I'll add this. Firefox 2.0.0.20 can be run on all Windows 9x without KernelEx, etc. It's not quite as "new" as the last builds of Opera that supported 9x, but it's miles ahead of IE6. (Running FF2 under 95 requires manual deletion of 2 files before running Firefox, if you need to know more about that, I will elaborate, instructions elsewhere are confusing and take many unnecessary steps.) I don't use Opera and I'm not a fan of it, so I can't help you on that specifically.

No. Java 6u7 works without Kex.

What steps, if any, have you already taken? This is critical to know how to advise you. When you read about many of these packages, keep in mind that most are designed for Windows 98 SE, NOT Windows ME. Most can be adapted to ME once you know what you're doing though. My first advice is to FORGET USB20DRV.EXE, as it was designed for 98SE rather than ME, and has documented issues. If you want to enable strictly USB2.0 Hardware support (Hubs & Ports) NOT external devices, then you should extract these files from NUSB 3.5: USB2.INF USBEHCI.SYS USBHUB20.SYS USBPORT.SYS And place USB2.INF in the WINDOWS\INF folder, and the .SYS files in \WINDOWS\SYSTEM32\DRIVERS. IF you have a VIA Chipset based motherboard, get those 3 .SYS files from THIS package instead of NUSB. (Keep NUSB USB2.INF.) If you want to expand external device support, back up you current USBSTOR.INF and replace it with USBSTOR.INF from NUSB 3.5. Do NOT use USBSTOR.SYS from any of these packages! KEEP the ME version!

It's up to you guys. I've stated my case, and I maintain that if moved, the thread will quickly become irrelevant to 9x. But it looks like I'm outvoted.

Actually I had never really thought about it. I would think that this is more a "hardware" issue than a "software" one. Maybe rloew could give a definite answer... I know he has run 95 on SATA drives with his patch, and I have run 95 on P4/IDE ATA100 boards so I doubt there is actually a "software" limitation here, unless logically it would be the upper limits of IDE BUS speed.

Glad you got it straightened out.

There's another misunderstanding/miscommunication going on here. The VIA drivers you are referring to are for the internal USB 2.0 Hardware (hubs & ports) ONLY. VIA (or any other USB2.0 manufacturer) does NOT provide external USB Device support. NUSB provides BOTH USB2.0 hardware AND USB external device support. You MIGHT try this, to rule out issues from other sources and issues with the Microsoft USB2.0 drivers on VIA systems that seem to affect some users. (See the NUSB and USP threads for more info). Do a clean install of 98SE as previously described. Remove all USB and Unknowns from the Device Manager. Install NUSB 3.5. Once that is done, go into Safe Mode and remove all the USB Devices again, and then manually replace these files in the WINDOWS\SYSTEM32\DRIVERS and WINDOWS\OPTIONS\CABS folders. USBPORT.SYS USBHUB20.SYS USBEHCI.SYS With the ones from this package: VIA_USB2_V270p1-L-M When you reboot, be sure to direct any file requests to C:\WINDOWS\OPTIONS\CABS and NOT the 98SE CD. If you get any "Keep newer file?" prompts on THOSE THREE FILES ONLY, say NO. (The VIA files have an older versioning scheme than the Microsoft ones so are treated as "older" by Windows.)

True, I should have clarified that. I usually do not install more than 512MB of RAM until I have reached that point.

I SERIOUSLY doubt that NUSB is the root cause of your troubles. For the record, NUSB extracts copies of all the "new" files it installs to C:\WINDOWS\OPTIONS\CABS so if any files are requested during driver installation, the installer should be directed there. The version of EXPLORER you are using is irrelevant. If you had a "Network Adapter" show up during the installation of USB devices, then you must not have disabled it in the BIOS. If you insist on claiming that NUSB is the cause and refuse to entertain the possibility that the Sound Card and/or its drivers may be the problem, then there's not much more we can do to help you. If you want "no frills" external USB Drive support, you can check out RLoew's USB Storage Drivers. Scroll down to "USB" and download "USB.ZIP."

I don't know why the system would suddenly start behaving like that. Something else must have been altered or corrupted somewhere along the line. I'm suspicious of that point you noted about how the "Boot Sector" had been modified... I think that the filesystem may have been adversely affected by having to move the drive around so much and/or having to mount it under different OS'es. Sometimes that can cause "glitches" due to different methods of handling; I've seen odd behavior on FAT32 partitions that I had shared between 98SE, XP, and Linux before. At this point I don't know what else to try. If you ever want to take a crack at it again with a fresh Windows 95 install then I'll be glad to help you any way I can.

I think he got the "Safe Mode" point from one of my posts in another thread. I told him to remove all instances of his USB HDD in Safe Mode (because installed devices not currently connected don't show up in Normal Mode, but do in Safe Mode.) This is the order that I use when setting up a new system; it may be no better or worse than anyone else's here. REMOVE ALL add in cards (except Video of course) and DISABLE ALL onboard Audio, LAN, Modem, etc in the BIOS. Install Windows 98SE. Install DirectX 9.0C. Install Motherboard Chipset Drivers. Install Video Card Drivers. Install IE6SP1. Install WMP7.1 (or WMP9 if you prefer, or ignore this step if you don't use WMP). Install NUSB. Install any other Official or "Unofficial" Updates you plan to use at this point. In my case RLoew's RAM Limitation Patch for example. (As you can see I prefer to update various pieces of the OS BEFORE introducing 3rd party software/drivers as much as possible) Install Sound Card (insert add on card or re-enable onboard in the BIOS, whichever you're going to use). Install Sound Card Drivers. Install/enable LAN card..... and continue the process. Installing/Enabling new devices one at a time decreases the chances for conflicts and allows you to pinpoint where & when issues arise.

Ok, things are looking up. I believe we have successfully removed the Demo RAM patch and XUSBSUPP. There should not be any more files left with .O20 extensions, and you should remove any remaining files we have used/altered such as VMM32.ERR, and leave only a backup copy of the 2005 VMM32.VXD, named VMM32.ORI. (Be sure to use that name, as XUSBSUPP uses the .O20 extension, and the RAM patch uses .BAK, so .ORI leaves us with an extension that will not be altered, deleted, or overwritten by any update.) Does the computer still hang now that we have reached this step, or have we stopped that? Now, as you encountered errors while the HDD was still in the "new" machine, and had to transplant it again, it is probably a good idea to go into Safe Mode and remove all of the devices from the Device Manager again to ensure that no devices detected on the "new" machine are still present. Then Reboot, and allow the machine to install drivers for the older hardware. If you get any prompts about missing files, try manually directing the installer to C:\WINDOWS\OPTIONS\CABS or C:\WINDOWS\SYSTEM, if the required files are still not found, try other "logical" locations under C:\WINDOWS. If any are still not found, make note of what files they are and what device was requesting them if possible. Hopefully this will correct the MS-DOS Mode issue and get you back to where you were. Let me know the results. I must go soon for tonight though, as I have to work in the morning.

I do have some ideas about the other issues you're having, but we need to get "back to where we were" so to speak before they can be addressed. If the things we're doing don't fix it, the MS-DOS mode may be caused by all of the devices being removed and/or drivers not being reloaded. Also, if the HDD is in the "new" computer, then BIOS settings with regard to the SATA ports on your motherboard might cause it. Also, the loading of EMM386.EXE may be contributing to you not being able to access Normal Mode with the Demo RAM patch on the new machine. (I will leave that for others more knowledgeable to comment on, but I remember seeing others describe issues with it.) Note all of this is conjectural at the moment.

Ok, is the hard drive currently in the "new" computer or the "old" computer? I'm so confused... It needs to be back in the old computer in order to get everything straightened out. Once that's done, then you can make another good backup and we can try again if you want to. Having the HDD in the new computer for this has been a disaster. Right now we need to get all traces of XUSBSUPP and the Demo RAM patch removed. (I'm going to assume that the VMM.VXD was from the RAM patch judging by its date. Delete it.) Did the Uninstall of XUSBSUPP from Add/Remove programs work properly after you had done the manual part? (It should have asked you to restart?) So now you should have: C:\WINDOWS\SYSTEM\VMM32.VXD dated 2005, VCACHE.VXD extracted from the HotFix, and there should NOT be any VMM.VXD under C:\WINDOWS\SYSTEM\VMM32\ Does all that check out?

Ok, I don't know how these things have gotten "derranged" from their original configuration, but it may explain why you had problems with XUSBSUPP. From the dates of the files, it looks like the VMM32 and VMM files still on your system were the "patched" copies used by the Demo RAM patch. I don't know how these files remained there if you had it uninstalled it when you first ran XUSBSUPP, but nonetheless they remained. The RAM patch must be removed from the system first, as XUSBSUPP will update files patched by the RAM patch, and break the RAM patch. (And apparently itself in the process.) Copy VMM32.O20 and VMM.O20 from your backup to your Windows 95 machine. See if VMM.O20 has a "Version" Tab under Properties. (Note this only shows under 9x, .VXD files' Version Tab doesn't work under XP.) If it doesn't then you can simply delete it. If it does, then tell me the file version. Now, under your other OS, rename the current VMM32.VXD dated 11/27/12 to VMM32.ERR and replace it with the VMM32.O20 dated 7/5/05 from your backup. EDIT: Also delete any VCACHE.VXD, VCACHE.BAK, or VCACHE.xxx files and replace it with a copy of the one from the HotFix that we directed you to when we started work on this. See if this stops the hangups and the MS-DOS mode issues. Second EDIT: If VMM.O20 from the backup, and VMM.VXD currently on your machine do NOT have Version Tabs under 95, then Delete BOTH of them. (Note VMM.VXD not VMM32.VXD, VMM32.VXD will NEVER have a Version Tab.)