Jump to content

LoneCrusader

Moderator
  • Posts

    1,459
  • Joined

  • Last visited

  • Days Won

    7
  • Donations

    2700.00 USD 
  • Country

    United States

Posts posted by LoneCrusader

  1. No matter the topic title from way back whenever, no GeForce 8xxx or higher card has proper working drivers for Windows 9x. Just because someone added them "hopefully" to the INF file and created a thread about it does not magically produce positive results.

    Discussion of flashing one card to another is generally off-topic for this thread, but I don't think anyone would have a problem with it as long as it involved cards that were actually 9x compatible, In this case, both cards in question are incompatible, and therefore very much off-topic despite the initial discussion of them being well intentioned and likely arising from not knowing they were incompatible in the first place.

    Enough of this.

  2. On 3/28/2024 at 11:11 AM, pappyN4 said:

    @LoneCrusaderI dont know what you need it for... But looks like all the patch does is skip the checks in pSetupVerifyFile found in setupapi.dll.  Fortunately XP64 has the same logic as XP for that part so same patch should also work.

    Thanks for the info. :thumbup For completeness could you also list the correct location for patching x64 version 5.2.3790.3959?

    I note that the same byte sequence occurs several times throughout the file.. how does one know which instance specifically requires patching?

    The SETUPAPI patch allows one to modify certain files on the installation source prior to SETUP.. some can be edited without problems (i.e. TXTSETUP.SIF, DOSNET.INF that are used by nLite) but others such as LAYOUT.INF cannot be modified without causing errors during SETUP. FDV's patch for this works on XP x86 but I had no way to port it to XP x64.

  3. On 6/24/2022 at 7:39 AM, George King said:

    Here you can find what you are looking for :)

    https://www.wincert.net/forum/topic/17689-xpw2k3-x64-on-modern-hardware/?do=findComment&comment=138860
    https://www.wincert.net/forum/topic/17689-xpw2k3-x64-on-modern-hardware/

    Patch is there for SYSSETUP.DLL but not for SETUPAPI.DLL.

    I've not been able to locate a patch for the x64 version of this file, and the byte sequence for the x86 version doesn't match even though they're the same build number.

    Anyone have information on this? Thanks!

  4. On 1/19/2024 at 4:59 AM, MilkChan said:

    There's change documentation in UpdatePacks, I've updated that as well.

    Thanks, I looked over the updated .htm file. Looks like a lot of new additions. I assume a bunch of these came from the NT5.x Updates URL drop by abbodi1406.

    But I also am interested in the process (how and why) of what has changed; for example if one of the new updates completely supersedes/replaces a previous update that was in a previous version of the Update Pack. An old example from 5eraph's thread at RyanVM:

    Quote

    High priority update KB4018466 replaced high priority updates KB2508429 and KB4012598.

    Keeping track of all these things can be a pain.. I know all too well from doing my own slipstreamed builds of earlier Windows versions. But it's nice to be able to follow all the steps that lead to the finished product.

    On 4/9/2023 at 7:55 PM, MilkChan said:

    ...

    And I broke the stupid limitations of UpdatePacks x64.

    ...

    Also, what do you mean by this? What was the limitation and what was the solution?

    Thanks! :thumbup

     

  5. On 6/25/2023 at 12:46 AM, ABCDEFG said:

    Hello.

    So, these .inf files, are they available for the x79 chipset?

    It's been a long time since I've worked on these. (Wow, almost 8 years.. where does the time go?) I believe x79 was the highest chipset covered by the version of the Intel INF files I used as a base. I see some x79 references in the files, so this chipset should be covered. I never got around to working on x99 or higher. Virtually impossible to find the time for any of my projects these days. :(

  6. On 12/16/2022 at 5:48 AM, johnyept said:

    ...where LoneCrusader left off, but he never solved his last problem, just worked around it.

    6th problem (unsolved): some components aren't installed when the soundcard isn't detected, specifically "Audio Compression", "Sample Sounds", "Volume Control" and "Sound Recorder". It's the same problem LoneCrusader was having, and the problem is described in this article, but adding "/p c-" to disable safe class detection will make install crash on Virtualbox, and possibly some real computers too.

    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.

  7. 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? :no:), 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.

  8. On 3/13/2022 at 6:48 PM, Jody Thornton said:

    ...might be a clever idea, especially for those that choose forked browsers for UI customization above all else...

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

  9. 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. :no:

  10. 15 hours ago, Tripredacus said:

    However, this is managed by the "forum leader" and is not usually handled by globals or supers. I believe the XP forum leader is @LoneCrusader

    No, I can't claim that title. Or at least it was never given to me, lol. :angel

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

  11. On 12/15/2020 at 9:56 AM, assenort said:

    Immediately after its installation, the computer began constantly refusing to shut down, instead displaying and getting stuck at "Please wait while your computer shuts down" message (red letters on blue screen, hope you recall what I am referring to, if not see pic below). This annoyed me to no extent, and I had to uninstall the XUSBSUPP pack even though it had excellent functionality. After the uninstall, the shutdown problem disappeared*.

    After that I installed the half-baked pack created by PassingBy, which did not cause problems with shutting down the machine, and seem to be working fine. Only recently I discovered that the pack has serious deficiency with both functionality and un-installation, hence my first post in this topic.

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

  12. On 12/13/2020 at 7:35 AM, assenort said:

    the USB pack install its own patched nodriver.inf file in

    C:\WINDOWS\INF

    C:\WINDOWS\OPTIONS\CAB

    so my question is - should I leave this file as is, or try to replace it with a previous version?

     

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

    On 12/13/2020 at 2:02 PM, assenort said:

    Thank you, sir, but this does not address the problem I currently experience and for which I seek resolution.

    On a side note, I am well aware of the USB mass storage pack created by RLoew and LoneCrusader. This pack has excellent functionality, however it triggers the shut-down bug on my machine.

    Regards.

    What shut-down bug? I am not aware of any such bug, you seem to be the only one who has this issue?

  13. 22 hours ago, Goodmaneuver said:

    If you use WinME straight out of the box there is a 32GB limit on USB without updating the USB drivers. The internal native drivers had this limit that is why I said the SYS files need to be updated in earlier post but I wanted to change wording a bit on the particular post you have shown as it is not that good. I tried the early pure ME build and I know that 32GB was the limit but it is not an important 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.

    15 hours ago, siria said:

    => What happens when writing "too much" to a huge USB-disk?? Which was partitioned with some tool on a NOT updated XP-SP3 or early Vista or Win7? Perhaps data on this complete partition lost? Or possibly even complete HDD with all partitions lost??

    => Would I even notice data are lost after writing "too much"? Any error message? Before or only after too late? Or just silently messed, and some data still work, but all 'overflow' will be lost?

    => Mainly: is there any chance to check *beforehand* if USB-HDD partitions are "too big"??
    .

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

  14. 21 hours ago, Goodmaneuver said:

    ...SIS 5597/98...

    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.

    21 hours ago, Goodmaneuver said:

    If both PATCHATA and PTCHSATA patch the same file then if you install both patches then it would only work for the last driver patch that is installed, you would think.

    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.

    21 hours ago, Goodmaneuver said:

    Not all RLoew products are available like File64. I have the demo and it stops several games starting but no full package available.

    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.

  15. 16 hours ago, Goodmaneuver said:

    You did not believe me before but it is true the SATA hardware uses 48bit addressing and I have tested it on a SIS 5597/98 motherboard. A 500GB SATA drive booted with this early motherboard with the IDE to SATA plug in board but read my link I showed.

    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.

    16 hours ago, Goodmaneuver said:

    RLoew ... PTCHSATA.EXE ...will not eliminate the 137GB Hard Drive limit ...

    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.

  16. 11 hours ago, Cixert said:

    Well, it's been almost 2 months, I get to install Adobe Primetime on Firefox 52 ESR but in the plugins list the message "Adobe Primetime will be installed shortly" appears continuously.
    Any ideas to activate it and remove the message?

    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:

    On 8/5/2017 at 12:44 AM, LoneCrusader said:

    I just went through this same problem on a machine I built for someone else. I kept getting the "will be installed shortly" message until I manually set 51.0 in the %VERSION% section of the update URL and manually forced it to check for updates. Then it magically decided that it would work...:wacko:

     

     

  17. On 11/9/2020 at 9:10 AM, Tripredacus said:

    The first question is what the maximum disk size is that I can clone and extend to that will work with Windows 98 FE? Shiva currently lives on a 20 GB IDE disk, and the disk in the new system is 250 GB, which I presume is too large.

    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.

  18. 3 hours ago, Goodmaneuver said:

    These IDE to SATA adapters take care of the 48bit addressing because they are using ATA-6 or 7. There are a number of caveats see here and a few of my posts above and below https://msfn.org/board/topic/180571-hd-ac97-audio-beyond-the-137gb128gib-barrier/?do=findComment&comment=1175057 The 48bit extender unofficial driver for 98 may still need to be needed though to read the larger drives properly - checked in Paragon Partition Manager -  just have to see when connecting a non boot drive that has been formatted if you have all that is required to use the larger drives. I was running with the original ESDI_506.PDR until just recently as well so I do not know but I have installed the above mentioned driver for WinME and it made a difference.  If you update to use Rudolph Loew's PATCHMEM.ZIP then ESDI_506.PDR is updated/patched only if you use the /M option.
     

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

    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? :wacko:

    --

    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.

  19. 3 hours ago, jasongeo2 said:

    Thank you for the kind words about my father. Rudy has two sons. Jason loew is his blood son and we have the same mothers and I am Tony Sotomayor. Rudy was my step dad. I miss him so much.And Im glad to see how he impressed his fellow programmers on this thread and how much they respect his work. I knew as a child Rudy was very intelligent and a gifted programmer. If anyone would like to download a picture of Rudy when he was in his last year in College at University of Oklahoma 1970(Sooner 1970). I have a pic of him that was taken of him at the Engineers Club Engineers week party pic. Maybe someone can put it on this thread or something? He was young fresh leaving college and healthy. Picture is how I like to remember him. You can email me direct for that pic or anything else you want to know about my dad at jasongeo2@aol.com

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

  20. 9 hours ago, VistaLover said:

    I'm sorry to admit that the above expectation borders with Utopia... :( The general consensus on "their" camp seems to be that "we" are in essence practically stealing code "we" were never meant to lay "our" hands on, that "we" are just acting selfishly, full of entitlement... :huh:

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

    9 hours ago, VistaLover said:

    I think that part was explained previously by M.A.T; hosting the source code of one project covered by MPL-2 in a private repo does not make it Closed Source; whenever the code author releases an executable form (binary) of the code, he has the obligation to provide, by reasonable means, access to the source code that was used to compile the executable form; "reasonable" means could very well be a link to a source tarball or, upon user request, dispatch of the used source via a physical storage medium (the cost of which should be covered by the user requesting it...); what's more important is the fact that the publicly revealed source code does not carry the "buildability" obligation, that is any additional "hack" used by the author to compile the source into an executable form can remain private...

    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.

    9 hours ago, VistaLover said:

    I see this discussion (here in this thread) quickly exploding, again, to Rebranding Roytam1's browser offerings ; so I agree with @TechnoRelic that any additional content to that end be posted in the existing specific thread, not here...

    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.

    9 hours ago, VistaLover said:

    My initial comment here was to highlight the fact the unofficial Pale Moon branding (upon which NM28 is built) has been changed upstream but not adopted by "us", and the eventual ramifications (if any) that decision (by "our" maintainer) may entail... I hope it's clear now... :)

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

×
×
  • Create New...