rloew

My website with x10hosting was moved to rloew@x10host.com months ago. The company discontinued the x10hosting.com domain and forced everyone to choose alternate domains. Use my Web Redirect at rloew1.no-ip.com as it is updated th handle changes or down websites.

This is why I was asking. A script can be created to detect how much ram is on a system and add the necessary settings. I have already removed the settings in U98SESP 3.8 thanks to rloew. I would love to see a somewhat flawless build. As you all know, I can't do it by myself, I need help. Thanks again. As I mentioned before, not setting MaxPhysPage and MaxFileCache is probably best as they have to be already set, if needed, before your SP can be installed. If you choose to do so, I recommend the following: If not using my RAM Limitation Patch or Xeno86's VCACHE Patch, MaxFileCache=524288 will cover most people, except maybe a few with certain Graphics Cards. MaxFileCache=393216 will cover just about everyone. People with particular uses, as I described previously, can always manually reset the value lower. If you put in a script and detect more than 1160MB, don't set MaxPhysPage or MaxFileCache, as they are using my RAM Limitation Patch and shouldn't have them set at all.

So what is the ideal solution? As I said, there is no need to add it as it would already be there, if needed. Adding it in the SP would only be of value if someone added RAM AFTER installing the SP, or used some other RAM suppression method so he could install the SP. Looking at Dencorso's >1GB Thread, many people pushed their MaxPhysPage to "48000". A few went a little higher but that may cause problems on different systems.

So I need to either remove it or add the same value to SYSTEM.CB? True.

I have been reading all of these 1GB+ topics and they all have me going in circles. The reason I asked because SP adds System.ini,386enh,,"MaxPhysPage=40000" and if there is no general/default setting, then it can be removed in the next release. I noticed the setting. That combined with your VMM.VXD update, breaks my RAM Limitation Patch. Since you did not add the setting to SYSTEM.CB, my Computer crashed when I went into Safe Mode after installing the SP. Since Windows 98 will not boot if the setting is not there or the RAM Limitation Patch is used, there is no need for you to set it. In addition, many people set it a little higher, closer to the actual limit around ~1150MB. The actual limit can vary a few MB depending upon configuration.

Are there any objections in using these settings? I don't understand how there can so many different setting for 1GB of ram. There should only be one ultimate setting. Not true. The optimum setting depends upon how you use your system and what Graphics Card(s) are present. For general work, you want the highest setting that leaves room for all the DOS Boxes you might want. If you do a lot of transfers to USB Keys or cards, you probably want a low setting.

You can take your flames somewhere else. I guided people to the 5 step procedure in Post #1. This 30 step procedure is for people who do not have PS/2 Ports and cannot use a PS/2 device. My RAM Limitation Patch is compromised by the installation of the SP. I added instructions for people who already are using the RAM Limitation Patch. If you don't have the RAM Limitation Patch installed, you can ignore the steps listed. My WDMEX.VXD program is an alternative to WDMSTUB without the flaw mentioned. If you bothered to read the instructions, I give an alternative procedure that gets around the flaw but of course involves more work. If I was working for Microsoft, there wouldn't be any programs for Windows 98. You will have more room for those eggs when you take your foot out of your mouth.

I have determined that the USB Controller and Root Hub Drivers have the same Registry Configuration before and after updating from the Windows 98SE RTM Drivers to those in U98SESP3 Version 3.7. This means that they do not have to be removed. This is also true of the USB Mouse Driver except for the need for WDMSTUB. This makes it possible to install U98SESP3 without requiring a PS/2 Keyboard or Mouse. There appears to be a flaw in WDMSTUB that occurs when the Hardware Installer tries to run a new Instance of it while it is already running. For those of you who are desperate or enjopy Herculean tasks, here is the Procedure: 1. If using my RAM Limitation Patch, make a backup of WINDOWS\SYSTEM\VMM32\VMM.VXD if any. 2. Install U98SESP3 but do not reboot at end. 3. Unplug but do not remove USB Devices. Keep Keyboard and Mouse connected. 4. If using my RAM Limitation Patch Replace original VMM.VXD saved in step 1. If there was none, delete the new one. 5. Go to WINDOWS\SYSTEM\PRECOPY folder. 6. From SP3.CAB, extract USBCCGP.SYS, UHCD.SYS and HOTPLUG.DLL. 7. Put USBCCGP.SYS and UHCD.SYS in WINDOWS\SYSTEM32\DRIVERS folder. 8. Put HOTPLUG.DLL in WINDOWS\SYSTEM folder. 9. Go to WINDOWS\INF folder. 10. Edit the HIDDEV.INF File. Remove the text WDMSTUB.SYS and the following comma. 11. Edit the USBSTOR.INF File. Remove the text WDMSTUB.SYS and the following comma. 12. Edit the WINDOWS\WIN.INI File. At the end of the [windows] Section add the following line: SkipMouseRedetect=0 13. Reboot into Safe Mode. 14. Go into Device Manager. 15. Remove all entries in the Keyboard Section. 16. Remove the System and Consumer Control Devices in the HID Section. 17. Remove all Composite Device entries in the USB Section. 18. Remove all Mass Storage Device entries in the USB Section. 19. Remove USB 2.0 Root Hubs in the USB Section. 20. Remove Enhanced Controller entries in the USB Section. 21. Remove other entries in the USB Section except the remaining Controller and Root Hub entries. 22. Remove USB Devices in the STORAGE, SCSIAdapter, Hard Disk, Disk Drives and any Vendor Named Section. 23. Install my WDMEX.VXD (still Alpha but enough for this task) and skip to Step 27. Or run Steps 24-26. 24. Run REGEDIT. 25. Search for "usbhub.sys". Find the first one that is named NTMPDriver. This should be one of the USB Root Hub entries. 26. Replace the data with "wdmstub.sys,usbhub.sys". 27. Reboot. 28. You will probably encounter lockups as devices are loaded. If so reboot and try again. You may have to do this more than once. 29. Edit the WINDOWS\WIN.INI File to remove the SkipMouseRedetect Line added earlier. 30. If using my RAM Limitation Patch, remove the MaxPhysPage Line from WINDOWS\SYSTEM.INI and either remove or adjust the MaxFileCache Line. This procedure works on one of my Computers. There is no guarantee it will work on yours. It assumes that you are using the original USB Drivers that come with Windows 98SE for the Controllers, USB Keyboard and Mouse.

You are the second person who has had success using my suggestion. The same method works with an USB Keyboard instead. I am still experimenting with ways to do the install with no PS/2 devices at all, as this would also be necessary if the Drivers are refreshed.

That's what i read and understand also. I use himemx.exe, which does this via a commandline parameter - this way my W98SE sees 1 GB of 4GB RAM only, as well. This is why the program is of little value. This is interesting to know. So he hurt your commercial interest by pirating your software, you say. If he did so, and you can proove it, you are able to report him to the german police, as his name and location is easy to find out. It's easy to prove, in the case of BHDD31 he left an obvious gap in the code that no one would have intentionally put there. I don't speak German and am not familiar with their Law Enforcement System, so I have yet to contact them. This is a strong accusation, which suggests that you can identify malicious assembler code by looking at it, and have been training this skill for some time already. At this point, I am only suggesting the possibility. The large size and odd text strings are only suggestive. Good idea.

After running the documentation through Google translate, it appears that the program limits the available RAM that Windows can detect. The result is similar to what you get with MaxPhysPage. Lamp2222 is a known pirate so I wouldn't trust a program like this. He previously published a copy of BHDD31 is his own name using a Hacked Copy of my High Capacity Disk Patch instead of LLXX's Version. I was able to get many websites to remove it but not all. Although run from AUTOEXEC.BAT, it has a large Windows payload, and there are references to Polymorphism embedded in the Executable. This would suggest a possible Virus.

Doh! You're right! I completely forgot about SmartDrv, thanks for the memory jogging. I'll run that CREATION again soon. "... Just when I thought I was out, they pull me back in! ..." P.S. if you patch REGEDIT, and run it in Windows ( making it think it is in DOS ), how can it output the DAT files? The Patched REGEDIT will create the DAT files the same way as the normal REGEDIT does in DOS. Use the /L: and /R: arguments to specify the Destinations. I just ran some experiments that showed with a more complicated import structure a limit of 9-10MB in the size of each of the created or expanded SYSTEM.DAT and USER.DAT Files using 16-Bit REGEDIT in DOS or WINDOWS. I did find a way of compacting a larger Registry using REGEDIT in 32-Bit Mode, but it is rather complicated. I built a 23MB SYSTEM.DAT and a 17MB USER.DAT. I was able to boot with them as my machine has the RAM Limitation Patch /M Option installed. In the process of my experiments they grew to 27MB and 22 MB Respectively. I was able to rebuild them leaving a 22MB SYSTEM.DAT. I didn't check the USER.DAT.

A tiny Patch to REGEDIT makes it think it is running in DOS. I have been able to export and import from arbitrary files while in Windows. The VFAT Error is the most probable symptom of DMA memory starvation. The Registry and NIC Drivers use this memory and them VFAT can't get enough. I built even larger Registries to test out my fix for this problem. As I commented in a post years ago, you need to run SMARTDRV when running in DOS or you could end up waiting TWO DAYS for REGEDIT to complete.

These would not have worked. DRMK.SYS 5.1.2600.0 from XP RTM already has the problem dependencies. I found a DRMK.SYS File in Windows ME which does not have the dependencies but the USB Headset still does not work with the newer USBAUDIO.SYS.

So far I have used few if any of the Hotfixes. Mostly I use the WU and some official updates related to my projects. Outside of 98SE I use the ME SCANDISK and some ME USB Files plus the USB 2.0 stack from NUSB. The rest are custom mods. I have created a Preinstalled CD with my Mods and a WU only Service Pack (SP0) for new installations.

USBAUDIO.SYS 4.1.2222 suits me just fine. If it isn't broken, I don't fix it. Choosing the newest and shiniest is a prescription for unintended consequences as occured above. Backing off on the USBAUDIO.SYS version would probably be a better solution than trying to get DRMK.SYS to work. There is no guarantee that you can use any version of DRMK.SYS. I used the SP to test the Installation issue with USB Keyboards and Mice. I threw in the Headset and Lexar Driver to determine the impact of a Controller Driver replacement. The question of what needs to be removed when updating the Controller Drivers has been mentioned a number of times in relation to the SP, but no one seemed to be interested in actually testing it. I decided to kill two birds with one stone.

I updated KS.SYS and copied DRMK.SYS from Windows XP SP3. The KS.SYS was fine but the DRMK.SYS has unimplemented dependencies on NTOSKRNL.EXE I replaced USBAUDIO.SYS with the Windows 98SE Version and the USB Headset worked.

Was everything fixed after you installed the latest DirectX? I didn't try. Without DRMK.SYS it would not have been enough. I don't know if the DRMK.SYS in my XP System is useable or not. Do you think this solution can be use in the Service Pack? Right now it is rather messy and involves many manual steps. I suspect there is a better way. A silent install similar to what happens during Windows Installation would probably be the best solution.

This won't work either because all updated files resides in the SP3.CAB. If a user installs a new USB device, the files from SP3.CAB will be installed causing the same issue(s). This is considered the default instead of the Win98 cd cabs. I will also have to remove each file one at a time, just to be safe avoiding other mistakes, making sure I don't break anything else in the process. Tampering with the Main Updates option is serious. This would explain your reluctance to add options and some of the things you have said before that others did not understand. I noticed the many references to SP3.CAB, even after a complete device reset. It is a limitation of the your design. You may want to consider a different design for SP4. I repeated my earlier experiments using the original instructions. I was able to get my USB Keyboard and Mouse to operate, the USB Audio is definitely broken. The USBAUDIO.SYS has dependencies on KS.SYS that requires KS.SYS to be updated. U98SESP3 does not update KS.SYS. Windows Update did this in the Directx update. There is a dependency on DRMK.SYS which is not in Windows 98SE, Windows Update or U98SESP3. The File does exist in Windows XP. I did find a way to reinstall USB without a PS/2 Keyboard or Mouse, but it was a long involved procedure using a Script and a Mouse Click Generator I wrote.

This means, I will have to remove USB drivers altogether.Making them optional is not an option because users would still have this problem if they don't have a PS/2 Mice/Keyboards. I'm still working on it. Even now I think the majority of Motherboards have at least one PS/2 Port although I saw some with none. By switching from Gigabyte to Asus, I got a 2 PS/2 Port Motherboard in December 2011. Another problem I found is that I could not get my USB headset working again. I am going to repeat my experiment using your Instructions as the beginning point rather than trying to preserve existing Registry entries to see what difference it makes.

I created a temporary Partition on one of my Computers. Installed an original Version of Windows 98SE. Installed an USB Keyboard, Mouse, Headset, and an USB Key using my Generic Lexar Drivers. I installed U98SESP3, rebooted into Safe Mode, removed all USB Host Controllers, and USB Root Hubs, and rebooted into normal mode. After the Controllers were reinstalled, only the USB Key reconnected without being redetected. The other three were reinstalled and none worked. All were duplicated and had errors on at least one copy. This indicates that USB Keyboards and Mice cannot be left installed while the USB Controllers are being replaced. This means that a PS/2 Keyboard or Mouse is Mandatory at least temporarily. At present I do not have a solution for people who are using a Motherboard with no PS/2 Connector.

Deleting the Enum Keys works but leaves a lot of clutter in the Class Key. Your file will need a list of every USB Controller ID in existence. I have a .REG File that deletes both Keys entirely and replaces them with a bare minimum set of non-discoverable entries. It comes in handy when moving Windows 9x from one machine to another.

These 5 also need to be deleted for a more complete cleanup: 1. [HKEY_LOCAL_MACHINE\Enum\SCSI] 2. [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\HID] 3. [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\SCSIAdapter] 4. [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Storage] 5. [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\USB] A program will be needed to recurse the PCI keys to identify the USB Controller Drivers. In addition, individual Driver Manufacturers create their own Keys in Enum and Class for their IOS Drivers as well. This approach, like the one in USESP3, will be problematical for USB Keyboard and Mouse Users. A more selective approach is needed.

I'm not sure the instructions I listed are suitable for the SP. They were intended to help recover after the damage was done. It may be OK not to remove the USB Keyboard and Mouse Drivers themselves, just the Controllers. This needs to be tested. It would be a much better solution than the ones I posted.

@ReK67: There is a problem when Installing USB Keyboards and Mice. Initially the BIOS uses SMI to emulate a PS/2 Keyboard and Mouse, allowing the USB Keyboard and Mouse to be used in DOS and during Boot. When the USB Controller Drivers are started, they take over, telling the SMI to stop Emulating. The Compatability Drivers for the Keyboard and Mouse only recognize PS/2 Devices. This disables the Keyboard and Mouse until the Windows Keyboard and Mouse Drivers are loaded. Unfortunately, as you have discovered, you are unable to Install the Drivers without access to the Keyboard and Mouse causing a Catch 22. You were able to Install them initially because the Windows Installer suppressed the Dialogs that you are getting hung up on. There are a number of options. A partial list follows: 1. Attach a PS/2 Keyboard and/or Mouse, in addition to the USB Keyboard and Mouse, either is enough. Use the PS/2 Device to reply to the Dialogs. 2. Manually Disable, not remove, all of the USB Controllers in Safe Mode. Make sure your USB Keyboard and Mouse are not connected to the same Controller. Reboot, you should have access again. Enable one Controller and reboot. Repeat until you get an Installation Dialog. Either the Keyboard or the Mouse should still be working. If not you have to move one and start over. If one is working you can use it to install the Driver for the other. You should then be able to reenable all of the Controllers, reboot, and install the remaining Driver with the other Device. Although I can't say for sure, I don't think it is the SP that caused the problem. More likely it was the Driver refresh. The Instructions don't take into account USB Keyboards and Mice. I would have Posted this as a reply but the original Thread is locked.