LoneCrusader

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.

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).

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..)

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...

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?

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).

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.

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.

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.

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:

Provided you 1) use rloew's PATCHATA to update ESDI_506.PDR on your Win98 installation (and your intended hardware does in fact support 48-bit LBA), or 2) keep your 98 partition limited to ~120GB at the beginning of the drive, then no, there is no problem using the 250GB drive. If the larger disk is connected via SATA, you will most likely also need rloew's SATA patch. re: 32GB limit; This is totally nonexistent. Windows XP (2K as well?) and later impose a false limitation and prevent you from creating a FAT32 partition larger than 32GB, but they manage larger FAT32 partitions created by other software/OS'es just fine. No such false limitation exists under 9x. I believe the origin of this falsehood can be traced back to an old KB article that claimed that the size of a FAT32 volume under Windows 95 was limited to 32GB.. but this was never true to begin with.

Aside from the other issues in this post... PATCHMEM has absolutely nothing to do with ESDI_506.PDR, or SATA drives, or 48-bit LBA, or ATA in general, or anything remotely related to or resembling a hard drive whatsoever for that matter. A standard SATA to IDE/IDE to SATA adapter will most definitely not provide compatibility with 48-bit LBA drives on a system that does not already support this in the BIOS. Where does this stuff come from? -- Now, as to the original subject. These types of adapters are now very common and cheap.. however the quality can vary widely. Do your homework on manufacturers and especially chipsets used. The Intel Application Accelerator does provide 48-bit LBA (beyond 137GB) compatibility for Windows 98/ME on certain supported chipsets, but it is locked down to these chipsets and cannot be used on "post-9x support" systems. IIRC, rloew said that there was a bug or some other limitation somewhere in the IAA, but I no longer remember offhand what exactly he said about it. It's probably stated somewhere here on the forum if one takes the time to search.

Welcome to MSFN, Tony! I wish it were under better circumstances, but we're glad to see you here. Thank you for the picture of your dad.. I know I probably speak for several others here as well when I say I wish I had known more about Rudy and been able to get to know him better personally. I exchanged many, many emails with him, and always enjoyed hearing about whatever he was experimenting with at the time. We once discussed meeting up if I were ever in New York, but unfortunately I never got the opportunity... One never knows the future, but if I had had any idea he would be gone so soon I would have MADE the opportunity. I haven't been able to work much lately on the page that I was making that is dedicated to Rudy's work, but I will add this picture to it, and I would be glad to add any other such things as might be interesting.. I thought about making a short biography type page, but it's hard to know where to begin, and it's depressing to realize just how few details you know about someone else's life and interests outside of whatever subjects you've discussed, even when you considered them a close friend...

I understand where you're coming from with that, however I certainly don't believe it's too much to ask for them to keep their "unsolicited opinions" to themselves. I don't care if they "disapprove" or "dislike" what we're doing, I know they don't approve and I didn't ask them to agree with it. I only ask that they stop "disparaging" us with it. This is how "diplomacy" works. If they expect us to do something that they demand, then they can show good faith by ceasing their constant attacks. And, I hate to say it, but they have no right whatsoever to insinuate that someone is "stealing" code; that's not how "Open Source" works. If that is their attitude, then they're nothing but a bunch of hypocrites, because they owe their entire existence to Mozilla and Firefox, from which they "stole" code to begin with. If they want the "right" to claim people are "stealing" code, then let them go and start from scratch and build a closed-source copy of what they have now. I would estimate they might be back up and running in five years or so, if they're lucky... That is Mr. Tobin's interpretation of the licensing. That doesn't necessarily make it the correct, or most accepted interpretation. You will recall that I disagreed with him on this previously, and he had no direct response to the points that I made. It would be pretty senseless to be able to obtain source code that could not be "built" - this, to me, is a perfect example of "attempting to limit the user's rights in the Source Code" which the MPL prohibits, as I listed before. Based on previous behavior, which I also provided links to, it seems to me that Mr. Tobin and company prefer to just go around making threats and creating a toxic atmosphere for those whom they don't like building their code, hoping that they can "scare off" or bluff them all into submission, because whoever they're targeting simply doesn't want to deal with their constant attacks. Oh no, I have absolutely no intention of beating that dead horse again. It is dead, and should remain dead. The issues of licensing are wholly independent from the "rebranding" discussion. I knew that, however these "ramifications" (read "threats") or whether they can be enforced or not come down to licensing. I covered that specific aspect in my other post. You did ask for other input...

I'm not an expert on Open Source licensing either, but apparently someone here is going to have to become one... This whole business is ridiculous. I would prefer to see the great "dispute" settled as well, because it IS in everyone's best interests to NOT be fighting each other, BUT - NOT by simply giving in to the constant threats/intimidation coming down from "on high." I don't speak for anyone but myself, but if it were up to me I would not lift a finger to conform to any "demand" until some degree of mutual respect is established. The first step of which must include "them" putting a stop to the constant disparaging of the "XP (and Vista ) community" and "our" choices - as if anyone here needs "their" approval to use any given OS, or gives one iota what "they" think about our choice of that OS. That being said, I figured the "branding" problem would be simple enough.. just revert that particular change. While "they" will surely be very angry about it, in the end, (AS FAR AS I KNOW) they cannot force the change "retroactive" on already released code/versions/files. Even if they wanted to take the time and go through all of those old versions, and push out another update for each with the change, it would not erase what has already been made public, and is already covered under the "previous" existing license/redistribution conditions. These "private" repository issues are another aspect which we must figure out with regard to the licensing conditions. I see this "behavior" as simply an attempt to create more hassle for anyone who wishes to build the code for themselves.. which most certainly violates the "spirit" of Open Source, and may violate the actual licensing, depending on which licenses are applicable to different parts of the code. The MPL 2.0 (which to my knowledge governs the Firefox code that PM is developed from) contains some interesting specific statements that would seem to be relevant here: "All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License." "You may not attempt to alter or restrict the recipients’ rights in the Source Code Form." "...Covered Software must also be made available in Source Code Form, as described in Section 3.1, and You must inform recipients of the Executable Form how they can obtain a copy of such Source Code Form by reasonable means in a timely manner..." "You may distribute such Executable Form under the terms of this License, or sublicense it under different terms, provided that the license for the Executable Form does not attempt to limit or alter the recipients’ rights in the Source Code Form under this License." ... so, I see it as a question of whether or not these statements are to be "understood" at face value. If so, then I'm not so certain that "private" repositories and "hoops to jump through" to obtain sources are not in direct violation of this.

I've heard that this does indeed happen, but I don't have any experience with it. I'm a CRT monitor die-hard, lol. I have a few LCD monitors in my collection but I never use them. (Of course with a laptop you're stuck with it...)

I assume this amount is for them to actively recover the data for you, not just for some recovery software? Is the price contingent upon them successfully recovering everything? Of course it also depends on just how "irreplaceable" the data is; or how hard it would be to "recreate" the lost items... If you have PayPal, some of us might be able to contribute a few dollars toward helping you... (for reference, if the conversion I'm getting is right this amounts to approximately $400 to $900 USD; seems a very wide price margin!)

One year ago today... Rudy, you are sorely missed!

I believe I read it on a website somewhere, not on a forum... I thought it was MDGx's site, but I think I was unable to find any such reference there whenever I last checked (but I no longer remember when that was, or how thorough my search was...); possibly it came from a site linked from his?? Interesting about VBEMP... I suppose experiments with .SYS video drivers might be in order if anyone has the time and hardware to experiment... a good first experiment might be to attempt to use a Win2K-compatible .SYS driver for a video card that we already know works under 9x with the proper 9x driver... such as a Radeon 9xxx series or an nVidia 5xxx/6xxx series card.

It's been a long time since I did any research into this, but previously I settled on the HP ZD8000 (or Compaq NX9600) for my own attempt at a high-end 9x laptop. It features a high-end P4 CPU, uses a desktop chipset so is capable of >2GB of RAM* (*3GB visible to OS with a BIOS mod; search for my name and "ZD8000" over at BIOS Mods), and has an ATI Mobility Radeon X600 graphics chip and AC'97 audio that can be made to work with available 9x drivers. These laptops have their quirks however, and it took me many failed attempts to achieve anything close to success. When I last worked on it, I had 98SE up and running without any major issues left to solve, but I just haven't had time to spend on it... Too many projects; too many real-life responsibilities; too little time.

Short answer; No. Despite the fact that some WDM (.SYS) drivers are supported under 9x, as far as I know, video drivers MUST be .VXD type drivers under 9x. I read that somewhere years ago, but I no longer remember the source. However; to be perfectly honest I don't know if it has ever been tried. We worked on HDAudio and USB3 drivers without any success, but never video. This is a very deep rabbit hole... I don't recommend such an experiment for most average users. For the record however, so that anyone else who ends up reading this will know: first (UNDER 9x, NOT NT!) run Walter Oney's WDMCHECK utility or rloew's DISPPE32 on the 2K/XP driver you wish to load and see which WDM functions are missing. Then you must load WDMEX and repeat the same process again to see if all functions are satisfied. If they are, then there may be hope, and one must proceed to INF modification. If not, then you're probably out of luck unless someone else who knows how to expand WDMEX comes along. ... And if you're already lost, or can't figure out how to use those two tools, then you're in over your head.

I've not had any direct experience with mobile nVidia cards... I bought a laptop some time ago that has one but I've not been able to find the time to do any experimenting with it; I had plans to try and use it with Windows 9x, but it has HD Audio, and rloew and I never managed to get HDAudio working under 9x. So, the only experience I have with mobile video cards and 9x comes from my HP ZD8000 (ATI Mobility Radeon X600) experiments. I do know that some 7xxx series desktop cards were supported by the last "official" 9x release, (81.98 I believe), but not (IIRC) the higher-end 78xx/79xx cards. These cards do work when using the last released "beta" driver, which is 82.69, and which I believe you have tried. (Note, not all of the cards included in the unofficial 82.69 INF, including but not limited to any 8xxx/9xxx series cards, do NOT work with this driver.) The only other thing I can add to this discussion that may be relevant is that the "actual memory size" and "reported memory size" of any VRAM must match under 9x, or problems will occur. rloew and I did extensive testing in relation to this in order to find out why some people reported success with 512MB cards, and why some did not. Hence the NVSIZE patch... For example; newer cards with large amounts of RAM may report 256MB of RAM to Reserved Memory/MMIO to minimize the >3GB memory "reduction" to x86 systems and use a "memory banking" method to access all VRAM (reserved resources are doubled, so a 512MB card that reports 512MB of RAM will automatically cause 1GB of RAM to disappear from an x86 system with 4GB of RAM, so you're already down to 3GB reported to the OS). However, the 9x driver does not know how to handle this memory banking, and expects the reported VRAM to match the actual VRAM. Cards that report 256MB when actually using more will cause crashes... TL;DR; I had a 512MB 7200GS card that reported 512MB. It didn't crash under 9x with the 82.69 driver. I had a 512MB 7950GT card that reported 256MB and used banking. It caused crashes. Patching the card BIOS to report 512MB corrected the problem. I hope I've explained this well enough; it's been some time since I worked with these issues, and sometimes I struggle to remember the exact terminology rloew used in context... So, to make use of this... you need to figure out how much VRAM is reported under XP, and how much system RAM is reported on the Control Panel/System tab. Then we must figure out if the correct total VRAM size is being reported by the card BIOS. Since actual system memory is being used, and not dedicated VRAM, I don't know if this can be fixed or not...

Glad you got things running, (partially at least).. DLLHOOK is an API redirector; it's used to fool programs into thinking an API is present where the program expects it, when in reality it may exist in a different place or not exist at all under 9x. This can help you bypass missing exports/etc when programs are run. For Example; some programs expect a function in KERNEL32.DLL "IsDebuggerPresent"; this function does not exist under Windows 95. Using DLLHOOK, you can redirect this call to a different call (in a different DLL if necessary), thus circumventing the error, and allowing the program to run (provided the function you redirect to provides a "compatible" return value!).

There's always room for improvement. I don't like some of the decisions the PM team have made, but they're far ahead of the other "main" choices. Was just throwing out an opinion, since everyone else was doing so...lol

Forget the system.ini tweaking game and install RLoew's RAM Limitation Patch. I would use the /M option with your setup. No more tweaking or jumping through hoops necessary.