LoneCrusader

Are you certain that your USB HDD is formatted with the FAT32 file system and not NTFS? If it is formatted as NTFS, then Windows 9x cannot read it and will not assign it a drive letter. Connect your USB HDD to your Windows 7 machine and check the hard drive properties. I'm not familiar with what the exact steps would be under Windows 7, but we need to know what file system the drive is using. A couple of third-party drivers for reading NTFS under 9x exist, but it would be risky to use these if you happen to have any files larger than 4GB stored on your HDD, since 9x cannot support files greater than 4GB without other modifications. If your USB HDD is formatted NTFS, then you would need to back up your data and reformat it as FAT32; or, if you don't want to do that my advice would be to grab a cheap Flash Drive and format it as FAT32 in order to transfer the files.

Good progress so far. Sounds like you probably had a USB.INF that was provided with the Intel Chipset driver from the factory. What is the error given in the Device Manager? Did you reboot again after the USB controllers and hubs were detected and before connecting your USB HDD? If not, this may have led to the error. I may need to make a note about this in the instructions... You will probably need to manually remove the USB HDD from the Device Manager before connecting it again. If the drive is not connected you will need to do this from Safe Mode, as installed devices not currently connected will not show up in Normal Mode. Once you have done this, it should work. If not, please post any error messages that are displayed in the Device Manager.

The unknown devices get listed under Other devices, my mistake for not being more clear but you figured it out. Since you uninstalled USBSUPP and XUSBSUPP and then subsequently removed the devices and deleted the INF's, then Windows 95 should not have been able to identify the controller specifically. Somehow an INF for the USB devices still exists. This is what is used to identify the controller and load the other drivers. It sounds like the INF still exists, but the actual .SYS driver files are missing or not where they are expected to be in order to copy. Did you maybe install an Intel chipset driver at some point that provided an INF for USB? Once you clear the rogue INF you should be able to Cancel all of the driver requests during boot, as 95 will not be able to identify the controllers. Then reinstall XUSBSUPP. USBSTR95 was an unfinished project by another member here, and it was part of my inspiration for this project. I wanted to see it complete, but its author vanished and took his knowledge and source code with him. Problem is, I'm no programmer, so I had to get my friend rloew to basically recreate the entire package from scratch. Then I repackged it integrated with the USB Supplement. The original USBSTR95 works for a small handful of devices, mostly Flash Drives, but most USB Hard Drives do not work with it. XUSBSUPP provides all of the necessary drivers for USB controllers and USB storage. Adding any other package such as the original USBSUPP or a package from Intel, etc, will only complicate things further. Another reason I created it. You're welcome. XUSBSUPP should provide a solution for you. Just remember that Windows 95 cannot read NTFS partitions or use files >4GB without other third party programs. I'm sure you can get it sorted out. Try to find the rogue INF file and eliminate it. If that doesn't work, I will try to provide some more thorough instructions.

Sounds like uninstalling the existing USBSUPP is not removing all of the USB related files, particularly USB.INF. This is why the USB devices get redetected every time the machine restarts. Uninstall USBSUPP (you've already done this) Boot into Safe Mode and remove all USB devices and Unknown Devices. While still in Safe Mode go to the WINDOWS\INF folder and WINDOWS\INF\OTHER folder and delete USB.INF if it exists. In the \OTHER folder it may have a different name such as "MicrosoftUSB.INF" (INF's are sometimes copied and recopied here each time a device is installed) - just be sure you eliminate any and all copies before you reboot. This should clear out the problem and the USB devices should not be automatically reinstalled on each boot. When you reboot you should be able to simply cancel the driver install requests and get to the Desktop in order to install XUSBSUPP. Let me know if this works or if you have any more problems.

You're welcome! Glad it helped you! You may want to check out rloew's homepage for other bits of software that may help you continue using Windows 95/98 machines with your manufacturing hardware.

Be sure to note the difference I pointed out between the third-party add-on SATA controllers that have 9x drivers as with the ICH4 boards, versus the ICH5 and up boards that have the SATA controllers integrated as part of the chipset. For the later ones you will have to run in Legacy PATA mode always or have rloew's SATA patch in order for them to work with 9x. I was confused for a few minutes by the folders inside the chipset INF packages myself. The folders you see inside are only containers for ".CAT" files, which I have yet to figure out any useful purpose for. Windows 95 does not use these, hence no Windows 95 folder. When you actually run the SETUP program it should unpack INFs to the Win95Cur and Win95Old folders you mentioned. The 845 chipset should have it's own properly named INF, but there may also exist an "ALMADOR.INF" and "BROOKDAL.INF" - these were some early code names for ICH4 development and contain the same data as the finished ICH4 INF if I remember correctly.

As far as I know there is no real difference between the variations of ICH4, although I have never tried to run 95 on a laptop, only desktop systems. Search for versions 2.90.009 and 3.20.1008 of the Intel Chipset Software Installation Utility. One or both of these I know supports 95 and contains the ICH4 INF's; I just can't remember which one I used. I've never tried to use SATA drives with a PATA IDE board. I've never had a need to do so, since I have a large stockpile of PATA drives. I know these boards have the necessary settings to place the drives in Legacy PATA mode, so what you're looking for should be possible. Some early onboard SATA controllers came with 9x compatible drivers until the SATA controllers became integrated into the chipset. See the Intel D845PEBT2 board for reference.

Technically no. The last Intel chipset with official 95 support was the 845 ICH4 Pentium 4 chipset. I have several 845 chipset based boards that have working 95 drivers for every single device except the USB2.0 conrollers. If you're just looking for chipset support, it is simple enough to create INFs (or modify those for later OS'es) to properly name all of the devices. The problem comes when other devices on the board no longer get along well with Windows 9x, whether it be integrated Audio or Network cards, or more obscure non-configurable things like the ACPI controller. I have successfully used Windows 95 without any such problems on an Intel 875 chipset board. Not all drivers were available, but there were no resource conflicts or other such annoyances.

Tested and verified this works with Windows 95C and the 81.98 driver. Not tested other versions yet. Windows 95 requires both Messages 4 and 32 like Windows ME in order to Shut Down properly. Message 32 by itself will prevent SCANDISK being triggered by having to manually power off or reset.

Glad you got it working! Although this project and its solutions probably should be in its own thread and not be directly in-line with this thread, which is really meant to be a "list" rather than a troubleshooting experiment. @dencorso Feel like thread surgery? haha

There's no need to get defensive. I know that the root cause is unknown, I was just making a point that I believe the root cause to be the same regardless of 9x version. To my knowledge this has not been disproved, so it is still a valid conjecture. I also know that rloew considers the code safe or he would not have posted it here to begin with. I disagree though that the missing screen is a "minor inconvenience" - yes, it is a minor inconvenience in the fact that it is not important or necessary that it be displayed, but the point is that I believe the absence of it is a clue that the problem lies deeper.

A "universal to 9x" solution may never be found, but I have a feeling that the root cause of the Shutdown bug is the same regardless of whether the driver is running on 98SE or ME or whatever. The current solution works around the problem on 98SE, but not for ME, and 95/98FE are untested. I may be wrong but I think the bit I noted about the "Windows is shutting down" screen not getting displayed is relevant, because I always see this screen on a normal shutdown, even if only for a split second. The 98SE solution allows the machine to achieve a clean shutdown/power off, but I believe something is being "bypassed" to do so.

Use Catalyst 6.2 unless you are able to find an X600-specific package that was explicitly designed for Windows 9x. Windows 9x video drivers MUST be in .VXD format; yes Windows 98 and ME support WDM drivers like 2K/XP but video drivers are the exception to this. if the 2K package you found does not contain a .VXD file it will not work. As for where to put your device in the INF, you will need to "study" the organization of the INF and be sure to direct your device to the correct install section for it's particular GPU "family" (R360, R420, etc etc, Wikipedia may be useful for this if you are not familiar with it, search "List of AMD graphics processing units"). The best thing to do is find the "closest" device to yours that IS listed in the INF and follow the methodology used for it.

It's been a long time since I actually used FDISK to partition a drive, but I did use it a lot back in the day. Now I use System Commander in most cases and rloew's RFDISK or Partition Magic for certain specific purposes. If a drive is larger than what FDISK can properly display you will have to do the partition sizes by "percentages" of the entire disk rather than MB count. Try this, or use a different program to partition and format your drive and set the partition active. Then run your experiment from the beginning, setting Legacy Mode in the BIOS and disabling onboard devices. Note that it is possible for even a PATA IDE controller to be running in Native SATA mode if SATA ports are present as well (rloew correct me if I am wrong!), so be sure to check for "Legacy/IDE/PATA" settings. The size of the HDD should have no bearing whatsoever on compatibility with RAM.

I probably can't even begin to address all of your issues, but you need to concentrate on one problem at a time for starters. First of all it appears that laptop uses an Intel 915 chipset. Prepare yourself for resource conflicts that may or may not be fixable. The 875 chipset is the last chipset that truly gets along properly with Windows 9x. Second if the laptop has more than 512MB of RAM and you are determined to use it, don't rely on "tweaks" to fix it. I was never able to get any of these "RAM tweaks" to work on any system of mine. I purchased rloew's RAM Patch and never looked back. Third, if the hard drive or optical drive in the machine are connected by SATA, you will either have to hope that the BIOS will allow you to set "Legacy IDE" mode for the drives, or you will need rloew's SATA patch as well in order for them to function properly and not run in "Compatibility Mode." Fourth, when installing your OS of choice, always disable any and all possible onboard devices in the BIOS, then once you have your OS set up, re-enable them one at a time, installing drivers for each separately. This should help you narrow down problem devices. Use the last 9x version of the ATI Catalyst driver, 6.2 I believe. If that doesn't work verify that your Device ID is listed in the INF file for the driver. If not, add it.

If and when Rloew decides that his solution is "complete," and gets it working for all flavors of 9x, and is reasonably certain it has no adverse side effects then I think I can repack the driver package with the patched file included. I'm confident that is what MDGx did originally when he expanded the INF's anyway.

As far as I know no such things exist for Windows 95. Only USB Storage and the small handful of older devices such as scanners that originally came with 95-compatible drivers are known to work when connected by USB under 95. It may be possible to support such devices but they would require the ultra-experimental Hybrid 95/98 system that rloew and I developed.

Definitely trash the Celeron. Celerons are garbage. But be sure that you do not need to update the BIOS on your motherboard in order to have support for the P4 3.06GHz before you attempt to change the processor out. I would highly recommend rloew's RAM patch, and by all means either max out the RAM on the board to 3GB (or use 2GB if you want it to run in Dual-Channel mode). You can never have too much RAM. If you plan on playing any games that run in DOS or in a DOS Box inside Windows and use more than 2GB of RAM be sure to mention this to rloew when and if you get the patch, because an additional fix is needed to limit DOS Box DPMI memory to 2GB in order to run certain games, especially those that launch with DOS4GW.EXE, such as WarCraft I and II. I've always been partial to ATI cards over NVidia, although I have been experimenting with NVidia lately. The 9800 XT is a very good card that can handle anything that was ever made to run under 9x. There is also the X850 XT Platinum Edition, although this card sometimes does not get along with WarCraft II and possibly other DOS games. A GeForce 6800GS is supposedly better than a Radeon 9800 XT, but a Radeon X850 XT PE is supposedly better than the 6800GS. Later 7xxx NVidia cards will work with the 82.69 driver found here, but many of them may not play well in your small case. There is no need to disable Hyper-Threading in order to run 9x, but unless you plan to multi-boot with another OS that can use it it will make no difference.

I tested both the 81.98 and 82.69 patches. The 81.98 patch works fine on a SOYO 875 Dragon 2 Platinum with a 6200GS. I did notice that the "Windows is shutting down" screen never appears, it just goes black from the desktop and then shuts the machine off after a second or so. The 82.69 patch works fine on an Intel D875PBZ machine with a 7950GT. Same notation about the "shutting down" screen. I have also seen the "blinking DOS cursor" screen before, along with a screen that reports "unable to write to device AUX" or something like that. Both of these situations kept the machine from shutting down, but neither of them left the system "dirty" or caused SCANDISK to run on the next boot.

Can you upload that version somewhere if you have it? I have been looking for it but all of BFG's old links are dead and not saved on the Wayback Machine, and rloew may not have it to examine. Thanks!

You're welcome. Glad you found it useful!

this is odd, i have a working windows 95 build that works with acpi support, computer automatically shut downs when selecting shut down option without showing the "it is now safe to turn of your computer" message. i believe windows 95 osr 2.5 was the first to implement this function, im not sure why other people had problems with acpi, even with windows 98 which should have better support. No official version of Windows 95 has any ACPI support, you must be confusing it with APM. It is purely unrelated that Windows 95 turns off the machine and does not show the "It is now safe to turn off your computer" message when shutting down; this is a difference between older AT-powered machines versus newer ATX-powered machines. It has nothing to do with ACPI, it is simply a normal function of an ATX motherboard and power supply.

Someone correct me if I am wrong, but it seems that the point of this project was only to update the Windows 95 Shell (i.e. the NON-Desktop Update/IE4/98 shell) to include functions that were added to the Desktop Update/IE4/98 shell so that the 95 shell could be used under 98 and/or with things like 98 Lite, etc... So for anyone already running the Desktop Update/IE4/98 shell under 95 it would actually be a downgrade and be incompatible with the newer shell if installed. WarCraft 3 incompatibility with Windows 95 was one of several factors that forced me to move from Windows 95 to Windows 98SE several years ago. Oddly enough the other factors that forced the decision at the time have now been remedied, but I digress. I never got past the "unsupported operating system" part on 95 back then, but admittedly at the time I didn't have the first clue how to begin to circumvent it. WarCraft 3 and the Frozen Throne do work properly under Windows 98SE though, I played them for years that way. However one of the later Blizzard patches (1.24B) breaks the game under Windows 98. I reported this to Blizzard tech support but of course they never gave any meaningful response, they never even bothered to try to tell me to upgrade or the like, they just acted like they didn't comprehend what I was saying. I don't know if it was ever corrected later or not. So, you may need to verify that the version you are installing is prior to 1.24B, and I would be very careful about the digital version, which may introduce this or other incompatibilities.

You are telling a SATA (Native) IDE controller to limit its functions to only those functions available to a PATA (Legacy) IDE controller. Both SATA and PATA are IDE. SATA is Native, PATA is Legacy. Legacy vs. Native are the key terms of importance here, not IDE vs. SATA. SATA is IDE, but a more advanced type not supported by the original ESDI_506.PDR. This is why rloew said that terms used in various BIOS'es are ambiguous - they don't clearly establish Legacy vs. Native and don't always use the same standard terminology for a given mode setting. Again SATA is IDE - Native IDE. I assume when you say IDE mode you mean Legacy PATA mode. Most likely Native Mode. Possibly AHCI depending on BIOS settings and whether or not an AHCI controller is even present. A board can have PATA/SATA connectors and NOT have any AHCI capability at all. Most likely not. See above. No.

Amen. To hell with running my computer in a limited mode! And off-topic but just for good measure - to hell with all of the Linux people who act like its some kind of sin to enable the root account or run a system as root! I can't express how annoyed I get by this...