LoneCrusader

I downloaded the old NUSB 3.3d Czech package from MDGx and compared it to the 3.5 English package along with the files you sent. Apparently there is also a localized IOS.VXD and a couple of other INF's but I have them now from the 3.3d package. I will need an original USB.INF from Czech Windows 98SE, and if you have localized versions of USB2.INF and USBSTOR.INF I will need them to include as well. I have everything ready to pack into a new installer once I have those INFs localized and fixed. A clean install might be helpful, but once the new NUSB files are in place I doubt that any leftovers from older versions are "different enough" to cause USB devices not to work at all. I discovered that the Automatic Skip Driver agent (ASD) had been triggered during my 98SE install on the X58 system, so it may be causing some problems. No further information yet. I had hoped that your problem would be similar but it seems to be different. X58 still includes USB1 and I can get USB disk access by Refreshing the Device Manager, but you have no USB1 and Refresh doesn't work. Here's the screenshot anyway.

I may have just encountered this issue on an X58 Chipset system. Try opening the Device Manager and clicking "Refresh" while a USB Drive is connected. It worked for me to detect the device, but file transfers are running ridiculously slow, like less than half the speed of USB1.1...

You may need to add more lines for GCDROM.SYS specifying which SATA controllers to probe for drives, especially if your SATA CD drive is not on the primary SATA controller. See the Examples section here. (I personally find this very annoying, I wish I knew how to alter the code so that it would automatically scan more than one controller by default...) Beyond that I'm not sure how to proceed. More information about your system and what methods you are using might help. Maybe some others members will join the conversation...

You will have to integrate it into whatever you are using to boot the system in order to run SETUP. This means you have to add it to your Boot Disk if you are using a Floppy, or you will have to extract the boot image of the 98SE CDROM and modify it like a floppy with a tool such as WinImage, and then burn a new Windows 98SE CD using the modified boot image. You use GCDROM.SYS by adding it to the CONFIG.SYS file. See the line already there referencing OAKCDROM.SYS for reference (the Microsoft-provided file that works for virtually every IDE PATA optical drive but not SATA). You can add a line for GCDROM.SYS after OAKCDROM.SYS and that way OAKCDROM.SYS will be loaded first for any drive that it does work with, and if it fails, then GCDROM.SYS will be loaded instead. If you are not familiar with creating your own Bootable CD's, modifying Floppies, or editing CONFIG.SYS, it might be best to read up some on this before you dive into this. I'm sure some other members can offer better insight, instructions, and links on this than I can. PS - I got your PM, but this is best discussed here on the open forum where others can help as well.

Interesting. The problem may lie deeper then, if USBD.SYS and the other files were present and your USB2 still doesn't work... You can manually install NUSB once extracted by right clicking "_nusb.inf" and choose Install.

I use and recommend NUSB 3.5. I believe NUSB 3.6 only adds SYSDM.CPL from Windows ME, which does allow USB Storage devices to be auto-installed without prompting for a driver (behavior like XP and later), but it also has some cosmetic flaws when used under 98SE. ("Windows Millennium Edition" shown in various places instead of "Windows 98"; a bizarre icon overlay bug on USB controllers in the Device Manager; "System Restore" controls being shown; and possibly other undiscovered issues) I tried some while ago to correct some of these but there are no "resource editors" which will properly handle the file since it is an NE executable. I made some progress but never fixed all of the issues. I think my last modified version ended up in PROBLEMCHYLD's Unofficial Service Pack. If you want to upload the CZ version files for NUSB 3.5 or 3.6 somewhere I will try to repack them when I get a chance. I've never repacked NUSB but if I can repack the original 95 USBSUPP, it shouldn't be too hard.

A G41 chipset system could work, but there are several factors that determine the level of 98SE compatibility. Since your system is a "prefab" OEM-branded one, Dell may or may not have made tweaks or other modifications to the motherboard BIOS that can cause conflicts and other oddities when trying to run an unsupported operating system. I have seen an Intel-branded DG41TY board that would not work with 98SE whatsoever unless it was installed with ACPI disabled (SETUP /p i). However third-party G41 boards by manufacturers such as Gigabyte, MSI, etc may never show any of these issues. Based on my experience so far I recommend avoiding any motherboard not running an AWARD BIOS, but there is no way to find out for sure whether a system will work with 98SE or not without trial and error. You will need a DOS SATA CDROM Driver such as GCDROM.SYS to access the Windows 98SE CD, or you will need to copy the SETUP files to a folder on the hard drive using a different machine. With no IDE, you can check whether or not your BIOS can set the SATA Controllers to Legacy IDE mode. If not, you will need rloew's SATA Patch. With more than 512MB of RAM, you will need to experiment with the various RAM tweaks floating around; or, you will need rloew's RAM Patch as well. I recommend the RAM patch as the tweaks never worked for me.

The Windows ME USB1 stack is a slight improvement over the 98SE version. I actually proposed that NUSB be updated to include it so that USBCCGP.SYS would be available to 98SE, based on a report by another member that he was able to get a newer "USB Composite" device to work under 98SE by adding this file from XP. (The ME version of this file is apparently bugged and 98SE/2K do not use it while ME/XP do). There is no benefit to using the 2K USBSTOR.SYS over the ME version. The ME version has no problems and does not require WDMSTUB.SYS like the 2K version does. Only the 3 USB2 driver files are needed from 2K. Apparently the problem here is that USBD.SYS, a USB1 driver file, is also required by the USB2 driver stack. On a USB2-controller only system, USBD.SYS (along with some other files) is not being copied to the system and therefore not fulfilling the requirements on the USB2 stack. These files just need to be in their proper places, they do not have to be manually "linked." Look through the USB.INF CopyFiles sections and copy all of the files to their proper locations. For example put USBD.SYS, USHBUB.SYS, UHCD.SYS, and OPENHCI.SYS in WINDOWS\SYSTEM32\DRIVERS and SYSTRAY.EXE, HOTPLUG.DLL and USBUI.DLL in WINDOWS\SYSTEM and so on. If you are using Intel then you most likely do have UHCI controllers, not OHCI.

Sounds like the USB issues are related to the lack of USB1 files discussed in the "modern motherboards" thread. I didn't release an updated USB.INF for the newer systems, simply because at least 2 different INFs would be required depending on what configuration the user has. -One handling method is required if one is using the standard 98SE USB1 driver stack and/or NUSB 3.3 or earlier. -A different method is needed if one is using the ME USB1 stack (+XP USBCCGP.SYS) with 98SE (NUSB 3.5 or later). Which version of the USB1 stack and/or NUSB are you using? However neither of these INF methods would directly address the lack of USB1 driver files on a USB2-controller only system. You may need to copy all of the files referenced in the Copy sections of USB.INF to their appropriate locations on your system if they are not already present. If this helps, it may be necessary to merge USB.INF and USB2.INF for future setups on such systems. If not, I'm not sure how to proceed. EDIT: It may also be worth noting that I have seen unexplainable problems with USB2 controllers and drivers on certain "newer" systems before. I have an Intel DP43TF ICH10 motherboard that absolutely will not even boot 98SE if a USB2 driver is present. This is both with and without ACPI enabled. If I remove the USB2 driver, 98SE will boot and work. But if I put it back, it refuses to boot again. This behavior is the same with both the Microsoft 2K USB2 stack and with the OrangeWare USB2 stack. However, a Gigabyte GA-EP45-UD3LR ICH10 board does not have this problem.

You're welcome! I'll be looking forward to your report. Please do post it in my INF thread so I can keep track of all the reports and testing related to the project in one place. I know what you meant about removing the older INF since you are upgrading but for the record my INF's are completely cumulative and should cover the older P3x chipsets as well; so no data or functionality for the older system would be lost by using the newer files. Please let me know if you see any VID&PID combinations that do not exist in one of my INFs, whether they are older or newer.

More than a guess.I preloaded USBD.SYS on my Z87 so I didn't see this problem but I was missing SYSTRAY and HOTPLUG which is also missing from the USB2.INF File. By "preload" do you mean just copying the file to the system so it is present or does it need to actually get "loaded" by NTKERN along with one of the USB2 drivers? I have debated merging USB.INF and USB2.INF before. I decided against it then but it may be time to reconsider since one could do this and set it up to copy all necessary files by default to avoid the issue at hand.

@ragnargd, xrayer Here you go, thanks for the interest and prompting me to finish! Here's an updated version that handles all devices up to the Intel Chipset Identification Utility version 9.4.0.1017. It requires different handling than the original package described here; see the README inside. I will leave all of the older links intact because the older version is still fine unless you need support for an ICH10 or later chipset. Please post any test results, bug reports, or comments here.

Yes, I was learnt that USB 2.0 hub contains also speed translator so it can connect USB 1.1 devices. The main difference is that now all ports (and connected devices) goes through the hub and not directly to EHCI. BTW DOSUSB driver should handle this, it also detected mass storage device but failed later on acessing the drive letter. OK, this gives me a hope. I'll try to clean old nUSB and reinstall again. I'm just confused that there's no "!" mark in devmgr on any USB controller but it silently ignore plugged devices. I see only a short flash from LED on USB stick when plugged in. No new device detected, neither unknown device in devmgr... Just a guess... If a motherboard has only USB2 controllers then no USB1 driver files would get loaded on that system. Since Windows 9x and Windows 2K handle USB1 and USB2 devices with different driver stacks it may be necessary for USBD.SYS to be loaded with the USB2 driver (or at least copied to the system) in order to provide complete functionality. If I remember correctly the USB2 stack still uses some calls to USBD.SYS, which could be absent if no USB1 controllers were detected. I believe I saw blackwingcat say something to this effect over in the 2K forum but I don't remember where offhand. PS - I'm getting ready to post the newer Intel INFs over in my other thread.

It's already "finished" for the most part, I just haven't had the chance to write a README on how to use it. An earlier version is here that goes up to ICH9. I simply added all of the Intel device data to the existing MACHINE.INF and MACHINE2.INF, therefore these updated files can be placed in the 98SE SETUP folder and they will automatically be loaded instead of the older version in the CABs. Using this method from my first version works, but soon MACHINE2.INF grows too large and causes errors during SETUP. I had to find a workaround for this so basically I expanded the "MACHINE.INF, MACHINE2.INF" structure based on the multiple MONITORx.INFs. A new MACHINE3, MACHINE4, and MACHINE5.INF are added. One can place these in the 98SE SETUP folder as well as the previous version, however 98SE does not know to automatically copy them to the /INF folder during SETUP. This means they will need to be either; a)manually copied to the /INF folder after the first phase and before the second phase of SETUP, or b)other SETUP INF files such as COPY, PRECOPY, SUBASE, etc will need to be edited to force SETUP to copy them like MACHINE.INF and MACHINE2.INF. I am running a fully slipstreamed build of both 95 OSR2 and 98SE these days so I have not tested them with a "vanilla" installation. All of the "chipset" INFs I consider finished. I have also expanded the USB, USB2, and MSHDC INFs to include newer devices, but these are not so simple to make "generic," for example the USB.INF would depend on whether the target system is using NUSB 3.3 or earlier or 3.5 and later and the MSHDC.INF would depend on whether or not the target system will use rloew's SATA patch or whether all SATA devices will be set to Legacy Mode, etc. My "project building" computer has been down for a couple of weeks, I had to have the motherboard recapped (capacitor plague struck), but I have it back now and I should have it back up and running soon. I will try to work up a README and get it released or if I don't get to it in a few days I will just send you the files. As rloew mentioned I was referring to the patches for 512MB cards. But also we found situations where spurious Option ROM's were causing resource conflicts and causing video cards not to work properly. Sometimes these can be handled with patches as well.

I've been working some with newer Intel boards but I haven't made it that far yet. I've been stepping up bit by bit, looking for issues and solutions. The last board I tried with was a P45/ICH10 chipset board. I have 98SE up and running on it just fine, but for some reason 95 OSR2 doesn't load on this system with the same video card (7950GT) that it worked with on the previous X48/ICH9 system. I am using rloew's RAM and SATA patches and would not even make them attempt without them though... SETUP /P I as mentioned is very useful in eliminating ACPI-related issues and random conflicts in the Device Manager, especially ones on "Motherboard resources." rloew has also recently developed some patches for the 7xxx NVidia graphics cards and we also identified some situations where other patches are needed to handle system-specific conflicts. I have an Intel P67 board but haven't experimented with it yet. Other experiments are on hold until I can devote some more money to the project. I did also create a set of INF's for 9x that is equivalent to version 9.4.0.1017 of the Chipset Identicfication Utility (the last for XP I believe??). They differ from the older ones you created in that they are designed for "slipstreaming" rather than installing with an installer. I have not released them publicly because I haven't gotten around to writing a README to explain their use in a non-slipstreamed setup.

No.. Firefox does have that option. "Save Link As" = "Save Target As"

Read my post #2 in this thread, same applies to your question. Also of note, as far as I know ASUS uses AMI BIOS, which can be very unfriendly to Windows 9x depending on the application. I know Intel uses a modified version of AMI BIOS, and it causes a lot of issues for 9x on Intel-branded boards where 9x was not officially supported. These issues vanish completely on virtually identical hardware (3rd-party boards with Intel chipsets) when an AWARD BIOS is used.

Appears to use AWARD BIOS. That's good for starters. My Slipstreamable INFs will handle the chipset. I recommend rloew's RAM patch to allow you to improve performance by maxing out the RAM on this board. I advise purchasing and using rloew's SATA patch to have fully functional SATA drive support. As MrMateczko pointed out there may be hope for the Network card. No drivers for the onboard video. Does have PCI-E slot for a 98-compatible card. No drivers for the onboard HD Audio. NO PCI SLOT to add a 98-compatible card. I have no experience with USB Audio devices. Intel ICH7/8/9 Chipsets can be handled with my Slipstreamable INF's. The last video cards known to work with Windows 98SE are the NVidia 7950GT and 7950GX2. If the 7950GT is a 512MB version it may require rloew's NVSIZE patches to work properly. The 7950GX2 is a 1GB card and would definitely require the patch but it is currently unknown if the card can be used to its full potential under 98 (as it is essentially a "dual GPU" card). I used to have a couple of SB Live! X-Gamer cards in my older systems. I believe they did implement EAX.

PCI Express works with 98SE in most cases. You will need to use a video card that has 98 compatible drivers though, such as an NVidia 6xxx/7xxx Series or ATI X7xx/X8xx Series card. I haven't looked into ITX boards so I really have no knowledge of them specifically, but I have recently experimented with various post-98 ATX boards. I would recommend that you find one that uses an Intel ICH7/8/9 Chipset BUT is NOT Intel branded! (third party manufacturer such as Gigabyte, MSI, DFI, etc) Be sure that it uses an AWARD BIOS NOT an AMI BIOS as well. Once these conditions are met then you will want to hopefully find a board that uses onboard devices that are friendly to 9x as well, such as the Network card chips and so forth. No HD Audio drivers are available for 98, so you will need a PCI slot to add a 98 compatible sound card. Keep in mind that if the onboard devices have no 98 drivers then you will need more PCI slots to add compatible cards.

Does the power light on the floppy stay on continuously? If so this usually indicates that the FDD cable is plugged in upside down...

One can also simply place the BIOS update files on the hard drive and boot 9x to DOS to run them by pressing F8 at startup and choosing "Command Prompt only" - this is much safer than using a floppy or USB drive IMO...

I don't have any experience with that specific NForce chipset, but I do have two boards with NForce3 chipsets and one board with an NForce4 chipset that I have run some limited experiments on. All 3 have at least one "major" bug with 9x OS'es. The NForce3 and NForce4 boards will not load a driver for a USB Storage device under 98SE if there is more than 2GB of RAM present and a USB2 driver is loaded. This bug does not affect 95, most likely because no USB2 driver exists (without a major backport of 98SE files). ME unknown, but probably the same as 98SE. XP and presumably 2K are unaffected. The NForce4 board has problems with 9x and the old "Gate A20 line" causing very long hangups during every 9x boot (to the tune of you walk away and come back 30 minutes later to see if it's booted yet). This can be fixed with another patch from our good friend rloew. But, once you get past that, I also saw some anomalies using a 7200GS and the 82.69 graphics drivers under 95 with this board. 98SE may not suffer this. My advice would be to avoid NForce for 9x system building, but YMMV.

I stand corrected. Apparently an ICH4CORE.INF for 95 does not exist in the Intel INF packages. Other INFs are present that get used under 95 when installed on an ICH4 system, but the one containing the device you need is apparently 98 and up only. Your system will run fine without any specific driver for this device, but I know it can be annoying to have Unknown devices show up. For a "quick and dirty" solution: -extract ICH3CORE.INF for 95 from the last 95 compatible package -extract ICH4CORE.INF for 98SE from a 98SE compatible package -copy the contents of the [iNTEL_SYS] section near the top of the file from the ICH4 file to the same place in the ICH3 file, example: %PCI\VEN_8086&DEV_24C3.DeviceDesc%=NO_DRV,PCI\VEN_8086&DEV_24C3 -then move to the bottom of the file (bottom of [strings] section) and copy the ICH4 device identifier strings under INTEL_MFG to the same location in the ICH3 file, example: PCI\VEN_8086&DEV_24C3.DeviceDesc="Intel® 82801DB/DBM SMBus Controller - 24C3 " -save the modified ICH3CORE.INF and point your Device Manager to it to update the 24C3 driver. I don't believe any 95 drivers exist for Intel's Gigabit Network cards. I checked the files I have for 95 and no mention of that Device ID.

Export a registry file of HKEY_LOCAL_MACHINE\ENUM\PCI on your Windows 95 Setup and attach it here so I can see what device ID's are in your laptop and compare them to my INFs.

Hmm.. I just looked at the version displayed on the top of the Properties tab. Apparently their "version control" is lacking. lol