LoneCrusader

You can try requesting the HotFixes through MDGx's HotFix Request Form. Just enter the MSKB article numbers that I provided and when you're redirected to Microsoft you can choose other languages if they are still available.

All versions of NUSB depend to some extent on Windows ME. As dencorso said, some files may never display any errors or messages, so their localization may not matter. NUSB 3.3 doesn't use the ME USB 1.1 drivers, but still uses USBSTOR, USBNTMAP, etc.

Here is a breakdown of the files in NUSB 3.5 and where they are collected from. Files that have been edited, downversioned, or otherwise changed are under (MODIFIED) sections. If a section is not marked (MODIFIED) or (UNMODIFIED) then the files from that update source are UNMODIFIED. Windows 98SE CABS (MODIFIED) NODRIVER.INF Friday, April 23, 1999 10:22:00 PM 242975USA8.EXE (MODIFIED) HOTPLUG.DLL 4.10.2224 SYSTRAY.EXE 4.10.2224 NTMAP.INF Monday, November 08, 1999 10:14:26 AM 242975USA8.EXE (UNMODIFIED) 1394.INF Wednesday, October 13, 1999 10:00:12 AM HARDWARE.HLP Monday, August 02, 1999 1:16:06 PM NTMAPHLP.PDR 4.10.2223 Q268064.EXE 1394BUS.SYS 4.10.2226 267304USA8.EXE NTMAP.SYS 4.10.2227 284837USA8.EXE OHCI1394.SYS 4.10.2228 311430USA8.EXE SBP2PORT.SYS 4.10.2227 239696USA8.EXE IOS.VXD 4.10.2225 IE4SHL95.CAB (MODIFIED) EXPLORER.EXE 4.72.3612.1700 Windows ME CABS (MODIFIED) USB.INF Thursday, June 08, 2000 5:00:00 PM DISKTSD.VXD 4.90.3000 USBMPHLP.PDR 4.90.3000 USBNTMAP.INF Thursday, June 08, 2000 5:00:00 PM USBSTOR.INF Thursday, June 08, 2000 5:00:00 PM Windows ME CABS (UNMODIFIED) OPENHCI.SYS 4.90.3000.1 UHCD.SYS 4.90.3000.1 USBD.SYS 4.90.3000.1 USBAUTH.SYS 4.90.3000.1 USBNTMAP.SYS 4.90.3000 USBSTOR.SYS 4.90.3000.1 Windows ME Q278289 (ME278289.EXE) USBHUB.SYS 4.90.3002.1 Windows ME Q304708 (ME304708.EXE) (MODIFIED) CDVSD.VXD 4.90.3003 Windows2000-Q319973 (USB2.ZIP) (MODIFIED) USB2.INF Tuesday, May 07, 2002 4:52:12 PM Windows2000-Q319973 (USB2.ZIP) (UNMODIFIED) USBPORT.SYS 5.00.2195.5652 Windows2000-KB838989-x86-ENU.EXE USBEHCI.SYS 5.00.2195.6882 USBHUB20.SYS 5.00.2195.6891 WindowsXP-KB945436-x86-ENU.EXE USBCCGP.SYS 5.1.2600.5585 291362USA8.EXE USER.EXE 4.10.2231 USER32.DLL 4.10.2231 UNKNOWN SOURCES / UNKNOWN IF OTHER LANGUAGES EXIST QFECHECK.EXE QFECHECK.HLP USBU2A.SYS WDMSTUB.SYS

Yes. Uninstall ALL USB devices, USB 2.0 and USB 1.1 both. NUSB3.5 adds the Windows ME USB 1.1 stack to 98SE which in turn allows greater functionality with composite devices, etc.

Alternate Link:

Looks like these are the correct offsets. Checked and they are listed as being the same offsets despite different file sizes in 3 different language versions at Dr. Hoiby's website. English German Russian name : explorer.exe size : 204288 version : 4.0.0.950 //------------ Offset 0x0C496 : 01 -> 11 Offset 0x0E6CF : 01 -> 11 Offset 0x1E86F : 01 -> 11 If you are uncertain, you could take a look at the English version and compare some of the surrounding bytes at those offsets to see if they are the same. English version and others downloadable from Dr. Hoiby at the link above. Here's a direct link for the English version.

What version of EXPLORER.EXE are you using? The 95-Shell version (4.00.95x) or the version installed by the Desktop Update (4.72.3612.17xx)? The links to the text file instructions at Dr Hoiby's website are a bit deranged and unclear. (For example, the link supposedly for 95A instructions goes to instructions for 98FE EXPLORER v4.72.3110.1) If you tell us what version you're using, we can sort it out. I started a text file containing specific instructions for each version during my slipstream project but I'm not sure where it is at the moment.

Tested with 95C OSR2.5 with all official USB updates installed (USB Updates contain a major KERNEL32 version change) And using the last KERNEL32.DLL for Windows 95, v4.03.1216. When I get a chance I will test again on an installation without USB (=v4.00.1112) Tested on Pre-USB OSR2. Result is the same. EDIT - Added Pre-USB 95 test results.

Nostalgic? No, because I still use Windows 98SE every day. And plan to keep doing so. And anything now or in the future that can't be done on 98SE will be done in Linux.

PROBLEMCHYLD, as you know, I am not a fan of unofficial Service Packs to begin with, as I like to pick and choose my updates. I know you have made a great effort with this, and made a lot of progress in making each update "optional," and all of us are grateful to anyone who spends their time working on things for the OS'es that we all love. So, for what it's worth, one "project author" to another, my advice is to finalize Service Pack 3 WITHOUT KernelEx and RP9. Sooner or later, you must be able to reach a "final build" of your service pack and be finished and happy with it, or you will be working on it forever. We all hope that further development of updates, KEX, and RP will continue, and if this is the case, you will be having to update your package every time some new advancement or workaround is discovered. SP3 needs to be a "milestone" rather than a "cure-all." For those who wish to install it, it can be the first step to having an updated system, and it certainly is a big step in the right direction. If these other packages are added, then a potential user could end up having an OLDER version of KEX or RP installed than whatever the current build is. As long as development has not ceased for good on these packages, then they should remain independent. If their development ceases permanently, I could possibly see adding them as an options.

You might be surprised what hardware works with Windows 9x Have a look at boards using the Intel 865 and 875 chipsets for example. See the last table on this page, and you should also look at these relevant threads: Compatible Hardware with Windows 9x Day-to-day running Win 9x/ME with > 1 GiB RAM Welcome, and good luck!

A few months before Windows Update went down for 9x systems, I visited it and tried to download all of the "recommended" updates for 95 OSR2, 98SE, and ME. I can't say for sure if I got everything, as I was just downloading packages, not actually performing the updates at the moment. But I have it backed up somewhere. Maybe I'll make a list of it if I can find the time...

SOYO P4 I845PE ISA SOYO's website no longer exists, but these are excellent motherboards. I have several of them in my own machines. BCM BC875PLG 875PLG Manual This is probably the "newest" motherboard that has an ISA slot.

All of the USB 2.0 flash drives I have encountered are backward-compatible and will work with USB 1.1 hardware & speeds. I suppose some may exist that are not, but I'll have to leave that on the table for others more experienced with such things. What filesystem are you using on your flash drives? If they are NTFS, Windows 9x will not read them without other modifications. FAT32 or FAT16 either one should work fine however.

Unless you have Win98 drivers for your USB Flash drives, you will need to install NUSB to get them working. Windows 98 has native USB 1.1 support for the controllers, but not for storage devices. NUSB Thread NUSB 3.3 English (Not the last version, but the links to 3.5 are broken and 3.3 will be fine for your project.) Here's a link to a Spanish version of NUSB 3.3. EDIT: Added link to Spanish version. I don't know where my mind was.

I have no personal experience with Windows 95 RTM or 95 A. I'll have to refer this question to RLoew, who did some work with those systems during the work on v. 7.0 of the RAM Limitation Patch.

Of course he shall have his wish respected. I propose the updated version, if and when we arrive at that, should be named "NUWDMST". Why not "WDMSTUBX" for "WDMSTUB eXtended/eXtender?" I think the name should be as close to the original as possible while fulfilling Oney's wishes.

The EXPLORER.EXE inside NUSB has only 1 byte changed from the original to allow 256 color tray icons. It remains version "1700." I believe the version running around here that includes the ME Icons was renumbered "1710" and it was used in the uSP. That would explain why NUSB didn't replace the version you already had, because it had a higher version number.

Yes. You can use up to 512MB of RAM with unmodified Windows 95 B. Beyond 512MB, modifications are required. See this thread for a complete list of collected info regarding larger amounts of RAM. That Microsoft KB article (KB181594) is very misleading. Windows 9x cannot use that much RAM without RLoew's RAM Limitation Patch, which will allow you to use up to 4GB with Windows 9x.

Replacing them isn't the problem. It's simple using ResHacker or eXeScope. The problem is that on 95, the replacement banner MUST be gray, or it will look like the picture I posted. In 98, the banner is extended based on the color of the "top end" of the banner. - i.e, if the end of the banner is black, it will extend in black to the top of the menu. In 95, no matter what color the banner is, above it will always be gray. Either 98 auto-extends the 157 banner, or EXPLORER auto-extends the 157 banner. This does not happen for the 161 banner in 95. IMHO, there must be a "version check" somewhere in EXPLORER that chooses whether to use 157 or 161, based on the OS version.

While not related to the original "Duplicated Drives" issue this thread originated from, I thought this "question" would fit best in this thread, rather than hijack the 98SE SP3 thread. Some discussion was being made of replacing the Start Menu banner bitmaps contained in EXPLORER. Bitmap 157 is used for Windows 98, and Bitmap 161 is used for Windows 95. Quoted relevant posts below. FYI Bitmap 161 is ONLY used by Windows 95. Remember that the same version of EXPLORER is used on both 98 and 95 with the Desktop Update installed. If 161 is changed, then if that version of Explorer is loaded in 95 then the Start Menu will say 98. So Bitmap 161 should be a nice gray-to-black-to-gray Windows 95 banner. I found that gerislamico is correct in that Windows 98 will "auto fill" above the end of the banner bitmap (157) with the same color as the end of the bitmap. However, Windows 95 will not do so. Replacing Bitmap 161 will result in a "cutoff" at the end of the banner, and the rest of the menu sidebar will be gray. See below: (Screenshot is of Windows 95-Shell Explorer, but the result is the same in both) Does anyone know how to "correct" this behavior? Either by finding a way to change the color of the "autofill" from gray; forcing the autofill to be based on the bitmap; or changing whatever "version check" causes 161 to be used on 95 instead of 157 (then 157 could be edited to a 95 banner)??

If you prefer the original Icons (I agree with you about the Recycle Bin especially) then you can use the EXPLORER.EXE contained in NUSB (It has only one byte modified to allow 256-Color Icons in the System Tray), along with SHELL32.DLL from the Q313829 HotFix. EXPLORER.EXE contains the My Computer Icon, and SHELL32.DLL contains the Recycle Bin and Network Neighborhood icons. When you replace these files, you will have to manually delete the ShellIconCache file in your WINDOWS directory from DOS or another OS.

No, it can be modified. I'm not opposed to making it look better. Just pointing out that it is only useful on 95. Also, I had considered changing it earlier myself, but I haven't managed to create a banner that I think looks very good. More Info: In 98, if the Start Menu grows longer (taller) than the bitmap banner, then the "space" above it will be auto-filled with the same blue color as in the original bitmap to prevent having it just "cut off." EDIT: gerislamico is right below, 98 will autofill based on the color of the top of the bitmap. In 95, this "auto fill" color is gray, not blue. So if the banner is changed from ending (at the top) with gray, then there will be a line wherever the banner ends and it will continue in gray to the top of the menu. So, the 98 banner must end at the top in the same blue color as the original, and the 95 banner must end at the top in the same gray color unless someone knows what to edit to change the autofill colors. EDIT: Struck out incorrect information. The problem seems to only affect Windows 95. There must be some sort of "version check" in EXPLORER that causes Bitmap 161 to be used on 95, and Bitmap 161 is not extended based on the bitmap color. :angrym:

FYI Bitmap 161 is ONLY used by Windows 95. Remember that the same version of EXPLORER is used on both 98 and 95 with the Desktop Update installed. If 161 is changed, then if that version of Explorer is loaded in 95 then the Start Menu will say 98. So Bitmap 161 should be a nice gray-to-black-to-gray Windows 95 banner.

I apologize for bumping this topic, but I have done some further experimenting that is relevant to this subject. First, I retract my previous statement: I have finally had the opportunity to run some tests with the 3rd party drivers listed by jaclaz, and found that this one seems to work perfectly for a standard PS2 Wheel Mouse. The other versions of the same driver listed seem to be buggy on a test system. This solution may be the "quickest and simplest" for getting a Wheel Mouse working on 95. While IntelliPoint 4.0 will do the job and add some other features, it requires that IE5 be installed before the installer will even run. I have tested the above driver on a 95C system WITHOUT IE4 or later installed, and it works perfectly. As with IntelliPoint however, the driver will load an EXE file on StartUp and it must be left running in the System Tray to have wheel functionality. Based on my experimentation using 98 INF's and downversioned 98 files, there doesn't seem to be a way to have the functionality without this.