Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won

  • Donations

    1300.00 USD 
  • Country

    United States

LoneCrusader last won the day on September 13 2020

LoneCrusader had the most liked content!


About LoneCrusader

Contact Methods

  • Website URL

Profile Information

  • OS

Recent Profile Visitors

12,035 profile views

LoneCrusader's Achievements



  1. Well, I finally solved it about a year ago in one of those rare instances when I actually manage to find time to work on my long-suffering never-completed projects. You can stop the process that "deselects" these components by editing their respective .INF files and commenting out the "ValidateProc" line in each of their sections. Extract MOTOWN.INF and MMOPT.INF from precopy2.cab if they don't already exist in the main \WIN95 folder. Find the sections [media_acm], [Rec], [Vol], [media_clips], and [CDPlayer]**. Comment out (place a semicolon at the beginning of) the line in each section that begins with ValidateProc. (i.e. ;ValidateProc) Save changes. This should solve the problem. ** = I don't remember anything offhand about the [CDplayer] section; or whether or not this is required. I may not have looked into it further at the time, but just handled it similarly to the others once I figured out how to prevent them from being deselected.
  2. Very depressing news.. I had feared for the worst for some time now, given that he had not been active here, and had not responded to messages I sent previously. Den was one of the few people "online" who I considered a true friend, and I will sorely miss his presence here. While I had not spoken much with him over the past couple of years (where does the time go? ), he was always helpful and always ready to give clear insight on whatever issue we discussed. He was very wise, and not only on the subject of computers. While not the subject of this forum, he understood historical and political nuances that befuddle most. I believe my first interaction with him revolved around problems with a flash drive.. and IIRC by the time it was over the discussion included rloew and jaclaz as well. Now of these greats only jaclaz remains with us. I never expected to become one of the "old ones" - yet here I am. My pitiful knowledge can never live up to the bar set by Den and others, and I will never be the "diplomat" that he could be when dealing with differing viewpoints and difficult members. I know that this forum and the collection of knowledge that it represents mattered to him, so let us all work to continue and preserve it in memory of him. Rest in peace my friend. You will not be forgotten.
  3. I'd like to see something like this as well.. I hate the fact that every browser is trying to become Chrome, but unless some major player in the "industry" bucks against it, it will continue no matter what any individual user likes or dislikes. I'm no programmer, but I just can't imagine it is really that hard to produce a sane UI for a program. Worth mentioning, this Chrome derivative does seem to have some very small measure of UI customization support..
  4. Done. You all should review the posts here and in the original thread for continuity and edit if necessary.
  5. Also seeing this on Firefox 52.9.0esr; spoofing FF 68.7 on Win7 as the User Agent seems to fix it, for now.
  6. There are no working USB2 or USB-HID (Keyboard, Mouse, etc) drivers for Windows 95 available in the wild (rloew and I spent many, many hours searching and testing to no avail); so this could place a major roadblock in your path if you have no PS/2 or other legacy ports.* As pointed out earlier, even if a device provides Legacy KB/Mouse emulation during boot, once USB1 controller drivers are loaded in 95 this is lost. You can circumvent this to a degree by not loading USB1 drivers, but if you wish to use removable USB drives with your installation then this is not a viable alternative. I once managed to get through the device detection prompts on a system with no PS/2 ports by overloading the keystroke buffer with "Enter" presses before the KB emulation was lost.. but this still is not helpful if one cannot control the resulting installation once the desktop is reached. * - But such things do exist. rloew managed to backport some of these things from 98 to 95 for me. I hope to eventually pack these things up with an installer to set everything up, but I never seem to be able to find the time to work on it (or any of my other computer projects) anymore.
  7. NUSB (version 3.3 or 3.5 recommended) package will cover the USB2 drivers as well as add USB storage support. The rest should be here (including the original Intel provided USB2 controller driver if you prefer).
  8. No, I can't claim that title. Or at least it was never given to me, lol. I suppose I can be considered as such for the 9x forum, but unfortunately I can't take on such a role for the older-NT family as well. I'm doing well to manage to keep up a daily check in on things.. RL issues are really taking a toll on all of my "computing" endeavors these days. - (And while I agree it may not be ideal to have so many "pinned" threads, I don't see the need to start changing things just for the sake of changing them. It's been that way for a long time and hasn't been an issue... Why the sudden "wave of discontent?" .. not to say that it could not/should not be improved, but just saying..)
  9. Sorry for the late reply, and I can't really offer much help... IMO, it's probably a hardware-specific issue with your system. But... By chance, when you encountered this issue with XUSBSUPP were you attempting to shut down with a USB drive still attached to the system? If so, this may be the culprit.. I rather doubt it in a way as I believe it would have been manifested somewhere before during all these years. But I do know that most, if not all, of the "power management" code was stripped from the RLUSB drivers (originating from Microsoft UMSS sample source for 98) as a first step towards Windows 95 compatibility back when the project began. It would be interesting to see if having a USB drive connected or not makes any difference on your system. Also, if you wish to experiment you might try using other (older) versions of the USB driver stack files (USBD.SYS/USBHUB.SYS/UHCD.SYS/OPENHCI.SYS) from the other Microsoft HotFixes to see if any of them do not exhibit the issue. It's possible one of the "fixes" breaks something on specific hardware configurations...
  10. Obviously, if you want to remove the entire pack, you should delete all files modified by it and replace them with the versions from the corresponding previous update(s). This pack was long ago superseded by XUSBSUPP; I see you are aware of it... What shut-down bug? I am not aware of any such bug, you seem to be the only one who has this issue?
  11. Updating which USB drivers, specifically? The only drivers directly associated with USB storage are USBSTOR.SYS and USBMPHLP.PDR. Neither of these has ever received an "update" of any kind from Microsoft for Windows ME. Both of these files are directly used, UNMODIFIED,* in NUSB for Windows 98. * = USBMPHLP.PDR requires a "downversion" patch to allow it to load under 98. This has no effect whatsoever on the rest of the code. As far as I know, you are the only person to ever make such a claim about this "32GB USB limit." If there were such a limit, it would have been widely reported by now. If I had the time to dig through the forum, and through all of the correspondence I exchanged with rloew over the years, I'm sure I could find some more specific numbers. So the following is strictly my opinion, based on some experience and a lot of communication with the "expert" so to speak. So, YMMV. In short I would not worry about any FAT32 partition 450GB or smaller over USB, and even that number is only because IIRC he said somewhere that SCANDISK would choke at somewhere around 470GB. (USBSTOR.SYS/USBMPHLP.PDR do not suffer from a ~137GB limit as ESDI_506.PDR does) If you don't plan to use 9x SCANDISK or DEFRAG on the partition, then that number can be pushed up close to 1TB. At/around 1TB there is another bug in VFAT.VXD, which rloew also had a patch for, but I would probably not venture into this territory without the entire TBPLUS package, which unfortunately only exists for 98SE (and not for 95, 98FE, or ME).
  12. I've never had any experience with this chipset, so I can't speak from any experience with it. Maybe the SATA adapter did in fact cause something to be "reported differently" to the BIOS which allowed a drive connected through it to boot where a similar larger drive directly connected would not. It's impossible to know. But I would definitely not place any faith in such an adapter "providing" 48-bit LBA support where the original BIOS does not. Only thorough testing with multiple writes + retrievals of data beyond the barrier can prove whether or not the issue is resolved, and even then the results most likely only apply to that extremely SPECIFIC hardware configuration. Not really, if you understand how file patching works. Each patch fixes a specific issue in a specific section of code. These can easily be mutually exclusive. Remember that even Microsoft HotFixes are "cumulative" - fixes included in previous versions are still present when a new issue is fixed. It is worth noting for the record here that the "most complete" / "ultimate" patched version of ESDI_506.PDR exists in the TBPLUS package. This version includes everything from the two mentioned packages plus several other fixes. I know. There are several that even I do not have. I'm hoping that Jason does not give up on expanding the site he set up for his dad's work.
  13. Since you reminded me of this thread elsewhere, I realized I forgot to post this screenshot that I took back then for this purpose. There is no such limit.
  14. You may have booted with it, but did you actually verify that you were able to access and actually USE the entire disk beyond the ~137GB barrier, WITHOUT corruption or errors? There's a big difference in being able to boot with a newer, larger drive and actually being able to use it as intended/expected. AFAIK, there has never been an issue with "booting" from these larger drives on older systems, the problems only arise when you attempt to write data and/or access beyond the limit. It is my understanding that the adapters that are the subject of this thread only provide a translation of the data streams from SATA->PATA "protocol" and vice versa. This is only a bridge across the two ports to connect a drive of one type to a connector of another type. These intermediate bridges cannot override the actual PATA/SATA onboard controller and/or the BIOS, through which the OS must communicate with the drives in question. If the HDD controller and/or the BIOS does not know how to address a "larger" hard drive, then a bridge that simply changes the drive type connector cannot cure this deficiency. An add-in controller card that has its own HDD controller and ports however, is another thing entirely. Let's not further confuse rloew's tools. PATCHATA removes the 137GB barrier. PTCHSATA allows use of Native SATA controllers (i.e. not "Legacy" / "IDE" / "PATA"). Only the first is necessary on an IDE/PATA only system. The second will probably be needed in addition to the first on a SATA only or SATA/PATA mixed system. Both of these patches only apply to the built-in Windows 9x ESDI_506.PDR driver, and will not help you if you are using another manufacturer-provided driver, whether it's IAA or manufacturer-provided SATA controller drivers.
  15. Despite the fact that it is deemed unnecessary in the main instructions, and that other members here report success without this step, I have always had to include it to get this working on systems that I have set up:

  • Create New...