LoneCrusader

That kind of stuff will encourage people running old browsers with vulnerabilities! That's absurd! Essentially Moonchild just made himself and PaleMoon into tools for Microsoft. Repeating the official Microsoft talking points... "unsupported" "insecure" "dangerous" "hack" and other rubbish. The decision of a user to choose this OS or that OS or to modify said OS in any way whatsoever should be none of his concern. Build the browser for XP, and if any reported bugs cannot be reproduced on a normal XP setup, then don't spend time on them. How hard is it? He claims that it was not intended to "target" anyone, but a poster over there made a good point about the fact that why has this suddenly become a problem when it wasn't before? Of course this was "dismissed" with vague claims about unspecific "strange problems under XP" rather than answered. LATER EDIT: And now they have resorted to deleting posts that criticize their decisions. A very well written post was just removed.

Interesting how this issue is playing out over at the PaleMoon forum. Moonchild and Tobin are defending their position citing what Microsoft thinks about this or that and claiming that they made the decision because they don't want to support "Frankenstein" versions of Windows, and basically telling people if they don't like it they can find another browser. What a load of .... I mean, so what? A simple notification that the POSReady configuration is not supported and that any bugs reported that cannot be reproduced in a standard Windows XP system will not be addressed should be enough to satisfy their supposed concerns. Then enter the "fanboys" who will defend them no matter what, and have nothing useful to say, only rubbish like "run Windows 7." And now apparently they are silencing dissent by actively locking threads about the issue and directing everyone to read what Microsoft has to say about it.

And for those who have no intention of removing the hack just to satisfy Pale Moon, here are two links for direct download of the offline installer of Pale Moon 25.8.1.(Atom/WinXP): <Link1> <Link2> You know, I had really started to like PaleMoon before they dropped XP compatibility in the main build line. What a load of rubbish that was to begin with; if there is nothing in the code that prevents it from working under XP, then the choice to not build the code in an XP-friendly environment is nothing but outright laziness (or arrogance/distaste for the right of others to use the OS of their choice) on the part of the developers IMNSHO. And now, apparently they are furthering their arrogance by deciding whether or not it is "dangerous" for users to modify their operating systems as they so choose. Why should Moonchild care (and what business is it of his anyway) what variety of XP users want to run PaleMoon on?

In my case, what it boils down to is that the developers of the game in question (League of Legends) could care less about their players who still run the game on Windows XP. Their forums are literally plastered with reports of the problem (a never ending white loading screen when trying to access part of the in-game online store), which are never even graced with a response from a Moderator or Developer. The problem is not always specifically limited to XP, but it seems to come and go and it seems that the "recommended fixes" found here and there from other users work for the later systems. It may also be a problem that I am running the game under XP x64 instead of regular XP x86, but who knows. The game works, I just can't use parts of the store. So when I need to do so I guess I will just have to log in on a Vista or later machine. Back on the IE9 Spoof front, I noticed that when I first implemented it and opened Internet Explorer 8, Google (my homepage) started to load properly for a split second and then reverted back to the "cannot display" rubbish. So apparently there is some other "secondary" way that these sites are detecting the browser version besides reading the User Agent.

Maybe! Check the Marvell driver package here. PCI-E video cards work as well so long as they have a driver (82.69/NVidia 7xxx family).

I've never yet seen an ASUS board that played nice with Windows 9x. As far as I know they use AMI BIOS as well, not AWARD, which is more 9x friendly. But some members here use ASUS, so I guess it depends on personal preference and the luck of the draw. I prefer Gigabyte first and then MSI. Not had much experience with ASRock or others. When you look at the specs for the motherboard you choose, be sure to check the exact brand and specs of the LAN controller. Certain RealTek and Marvell chips have 9x drivers, but not all. If it is Intel, then forget it, they dropped 9x support ages ago. It's possible to get a 9x compatible LAN controller, but there's no getting around the sound issue. You will either need a 9x compatible PCI sound card or a "USB Audio" device which I have no experience with.

Try this. Windows Imaging Component (64-bit) A little piece of the OS that was left out of x64 for whatever reason. I had to add it to my XP x64 "MediaPC/HTPC" that I built recently. I don't know if it directly addresses the problem you mentioned but I had to add it for something I needed... Ugh I must be getting old lol my memory is fuzzy!

It's possible to get Windows 9x running on fairly modern hardware. I've been experimenting some in this area for a while now; I've made it up to an Intel X58 Chipset motherboard but had to sideline further experimentation for a while. Your main issues to overcome will be the following: If you are serious about attempting this, then first I advise you to purchase rloew's RAM and SATA patches. It will eliminate a bunch of headache and give you a head start on other problems. Modern motherboards frequently use ACPI that does not get along well with 9x. This seems to be largely dependent on the type of BIOS. As previously mentioned, AWARD BIOS seems best based on my experience. Avoid newer Intel-branded motherboards (third party (Gigabyte/MSI/etc) boards based on Intel chipset are fine) because their BIOS is useless and they don't play well with 9x. I don't know anything about UEFI as yet. Be certain that your motherboard allows setting the SATA controllers to Legacy IDE PATA mode unless you purchase rloew's SATA patch. If you have it, then you will need to be able to set the controllers to Native IDE SATA mode. AHCI mode does NOT work with Windows 9x. Drivers for Windows 9x on newer hardware are virually non existent. This leads to the following points. Unless you want to run at 640x480x16 or use the experimental generic VBEMP9x driver that doesn't provide 3D acceleration, then you will need to choose a video card that is supported under 9x, as far as I know the last/most powerful ones that work properly are the ATI Radeon X850 XT PE 256MB and the NVidia GeForce 7950GT 256MB/512MB (patch from rloew needed for full use of 512MB or larger cards; also the 7950GX2 1GB card is an unknown at the moment, it works with the last NVidia driver but reports errors and doesn't use its full RAM). Since most likely no 9x drivers will exist for the onboard hardware, you will need slots available to install a 9x compatible Audio and Network card on top of any other cards you may use. No HD Audio drivers exist for 9x. Some Gigabit Network adapters are supported, but only a handful. Hopefully this gives you some info to start from.

I ran across a page a while back that barely mentioned the 9x build but it had a download link. The 9x package doesn't seem to actually contain the driver file though, "uniata.sys" that is present in the NT packages is not present in the 9x package and no other "expected" driver file types (VXD/PDR/etc) either. So the package is either incomplete or requires it to be manually compiled. I don't remember the link but the file name is "driver_9x_39g1.rar".

Small update... I managed to get IE8 spoofed to IE9 under XP x64 using a slightly modified version of the .REG file linked on this page. (The file may work as-is, but I added some lines to it first based on dencorso's earlier entries and this page. Also discovered this tool in the process, essentially a "User Agent Switcher" for IE.) Neither of these solved the problem however. I have a feeling it is directly related to the inability to use Google, Yahoo, etc in IE8. Anyone had success getting around this on any version of Windows or IE 6/7/8?

Interesting that the original link is gone. The package in the original was a .ZIP while the one you found is an .EXE. I haven't tried to unpack it but probably the same content anyway. I did an examination of that page along with several others. I think I managed to put it all in mostly good order. Since no one else has offered any suggestions on this point I guess I'll go with what I have. http://downloadmirror.intel.com/23061/eng/inf_9.4.0.1027_readme.txt Version: 9.4.0.1027 as mentioned in the top post appears to be more recent (September 02) than Version: 9.4.4.1006 (August 01) What Target should we be searching for? Edit:Then there's SuperMicro's ftp://ftp.supermicro.com/CDR-X10_1.03_for_Intel_X10_platform/Intel/INF/Chipset_v9.3.2.1020/Releasenote_9.3.2.1020.htm with History and changelog from 2012-2014And Intel's link for Intel desktop boards. There also exist versions: 10.0.13, 14, 20 WHQL, 22, 24, 27 and v10.1.2.10 WHQL. It appears that each version released by Intel is "extrapolated" based on some database they have and whatever commands are given. Some of the later versioned packages do indeed have files with earlier dates inside than files from the earlier package versions, however I'm not certain how much difference this makes. Sometimes the content is identical; sometimes there are small changes that have no effect on the necessary data (i.e. sections named "Intel_PCI_DRV" instead of "INTELPCI_DRV"); sometimes there are small changes in the device descriptions; and sometimes there are actually some new device VID&PID's added. One has to just compare the files to see what (if anything) has changed. Apparently some 10.x versions are not totally useless. I don't know where the change happens. The 10.x versions in this package do have device descriptions but I haven't figured out whether they have any newer devices or not yet since the format is completely different. Thanks for the updated ZIP. Did you happen to compare the newer files inside to their older counterparts to see if there were actually any additions? It would be nice to have a quick method of checking a batch of given files against my versions to see if any VID&PID combinations exist in a newer Intel package that are not already included. Of course this wouldn't handle situations where the descriptions change but given the later 10.x changes it probably won't matter as they are no longer even providing "descriptions."

Essentially this program (a game) opens a page inside it's own "client" using parts of IE. IE8 is supposed to still work with it (at least under XP x86, can't find any references to x64 specifically), but it does not, and I'm trying all possible angles. I tried your entries and checked it at the User Agent sites and it does not appear to have worked, I'm still getting IE8 reported.

Den, I'm trying to use this under XP x64 (for a program that uses parts of IE and isn't working with IE8) and it doesn't seem to have any effect. Any suggestions? Could you make a .REG file for both x86 and x64? Thanks!

If anyone is interested, I'm looking for some assistance with making an updated (possibly final, more on this below) version of the INF package. With data from the newer Intel INF package xrayer found, adding another MACHINE6.INF will be required in order to contain all of the device data and keep the INFs below the 64KB limit. In the last version I split the collected data from the various Intel INFs up however seemed best in order to use the smallest number of INF files and still get all of the necessary actions performed during SETUP. Since I'm going to have to add another INF this time anyway, I would like to step back and attempt to organize all of the previous data in a "chronological order" according to when each chipset was released. Here's what I need: When the Intel INF packages are extracted, one ends up with a whole folder full of small INF files which are named either according to their Chipset family number, ICH level, or more confusingly the "code name" associated with the chipset or CPU intended for the chipset. I need someone to organize these file names into a chronological order from the oldest devices to the newest. Then I can use this to rearrange the data inside the INFs accordingly. (A detailed list of Intel chipset/CPU code names in chronological order might work here as well, depends on the detail.) I have attached a list of the file names to be organized. Obviously the first file would be "ich5core.inf" then the other "ich5*" files, then the "8xx" files, then the ICH5 server chipsets (E7xxx), then "ich6core.inf" and so on accordingly. It gets much more confusing as the devices get newer and the files are no longer named according to chipset or ICH level. Now, above I mentioned that this may be the final version of these INFs. This is due to the fact that the current Intel INF package 10.0.27 intended for Windows 7/8/8.1/10 etc is almost completely useless. I downloaded it and was forced to find a Windows 7 machine to extract it on (it wouldn't even extract under Vista!), and once extracted I discovered that it simply names anything and everything to "Intel Device" with no further description. Wow, just how far will the "dumbing down to the lowest common denominator" go? So, if anyone knows of other versions of the Intel INF's between the last one xrayer found 9.4.4.1006 and the 10.0.27 version I tried, please post links here to them. LIST.TXT

Might help to also ask them to give you the source code for the last 9x driver as Drugwash pointed out, especially since it's for an unsupported and outdated operating system. What would they have to lose by allowing others to work on it if they don't want to? Probably won't change their minds but at least you give them something to think about.

I originally decided not to include MSHDC.INF with the latest package because of the various issues with 9x and SATA, AHCI, or RAID controllers. (I build two sets of the INF's for my own use, one for 95 and one for 98SE. There are additional issues that rloew and I discovered that apply to Windows 95 and not 98 that caused me to consider not bothering to update MSHDC.INF further.) I suppose however since 98 is unaffected I could release an updated version that behaves like the last version in which it will only load a driver when the controllers are set in Legacy PATA mode. I'll consider adding this when I update the package with the newer INF data you found. Apparently I'm not following this discussion... The 8168 device is commented out in the Tenda package but is not commented out in the latest package available from RealTek which is newer by version and by timestamp. According to the INF in the RealTek package up to RTL8111D is supported, but rloew said previously that "D" and "E" devices don't work with it...

Did you ever get an answer? Maybe we should all email them with the same request... lol

I was referring to the other device when I said it was ASUS-specific. rloew's SATA patch patches the existing IDE driver to support SATA and provides an INF file that properly recognizes the Native Mode controllers and allows them to be used exactly as if they were regular PATA controllers. I've been using it during all of my "newer Intel" testing. Basically you install it (or preload it into your SETUP source if starting from scratch) and never worry about SATA issues again. My updated MSHDC.INF you were referring to will only recognize the controllers when set to Legacy PATA mode. If they are set to Native SATA mode it will report "No Support" for them and they will remain in DOS Compatibility Mode.

Apparently Intel does not differentiate between the 82801 and 82802 Firmware Hub device since it is identified by *INT0800 rather than VID&PID. My INFs are not designed to handle devices enumerated under ACPI, in fact I have seen some problems with this on my X58 system where devices will be treated as "unknowns" despite having a corresponding entry in the original 98SE MACHINE.INF. In any case this seems to be an ASUS specific device and therefore would never be handled by a specific Intel package. The issue with the I/O port is normal. Remember these INFs only provide specific ID's for each device, not any special resource configurations. Looks like otherwise your system is working as expected. Interesting, although I'm not bothered by having to switch off. I used AT-powered computers long after ATX beacame the norm so I'm "used" to it I guess. Also I'm in the habit of switching off the main PSU switch after Shutdown, so either way it gets done.

Every NForce chipset system I have experimented with has some bug or another under Windows 9x. I'm surprised any of you had good results with them. I'll quote myself from another thread where I discussed the issues: Hopefully your experiences are the norm and mine were just bad luck...

I haven't used ICH6 boards much, as the two I did experiment with exhibited undesirable behavior. So I'm not intimately familiar with ICH6; I have more experience with ICH7 and ICH8. I'm not sure about the Firmware Hub discrepancy, it may be that Intel did not differentiate the PID between the two versions which would cause the same string to be used for both. Use REGEDIT to export a .REG file of the HKEY_LOCAL_MACHINE\ENUM Key from the registry and attach it. With this I will be able to see the VID&PID of the Unknown Device and the Southbridge. Resource conflicts are the "normal to-be-expected" behavior for post-9x supported motherboards. I've seen the "Motherboard resources" conflict on almost every such system I have tried. I even tried removing the "Motherboard resources" install routine from MACHINE.INF once, which only resulted in an unknown device which still showed a conflict. I have no idea what the problem "resources" are, but they are virtually impossible to get rid of unless one installs 98SE using "SETUP /P I" to disable ACPI. This usually clears such problems, but may cause you to have to manually switch off your machine after Shutdown similar to an older AT-powered machine (you will get the "it is now safe to turn off your computer" screen).

Never tried. It's almost impossible to use Windows 9x online these days unless you're OK with completely disabling JavaScript and other annoyances. Your best bet may be to ask Andrew T or wait for him to notice this thread; I would say he has probably pushed 95 further online than anyone else here.

I see no advantage to changing from the ME USB1 stack to the 2K USB1 stack. The fact that the files are "versioned higher" is the only logical argument for doing so, and even this is irrelevant because the 2K files were designed for 2K and the NT codebase while the ME files were designed for ME and the 9x codebase. Just because a newer versioned file was issued as a fix or update for 2K does not guarantee that the newer file is "better" for Windows 9x. In fact, the opposite is likely. But all of that aside, I decided that I would give your method a try, just to see what happens. I removed all of the USB devices from the Device Manager and ran the USBSTACK.EXE file from inside your latest uSP 3.51 which updated all of the USB files accordingly. Not only did the exact same behavior with the BSODs remain, I also noticed that the USB Storage device did not trigger the HOTPLUG/Safe Removal tray icon as it should. I'm glad all if these newer files work as expected on your system, and I hope they also work for others, but apparently yours is the exception and not the rule.

I may be wrong, but I assume that the USB Legacy Storage Support function must be intended to "trick" operating systems into running from a USB Storage device as if they were running from a standard internally connected drive. I remember rloew mentioned somewhere before that Windows 9x would run from a USB Flash Drive up until the point where it detects the controller where the drive is connected, at which point it will crash. I don't know what the "rules" are for this situation on newer systems, but "masking" a USB Storage device from being automatically detected as such might help in this specific case. Apparently XP is not affected (or helped if so intended) by this setting.

I set up a test using USBPORT.SYS 6941 along with the other two USB2 driver files which were already at their latest 2K version. I removed all of the USB2 controllers and hubs from the Device Manager in Safe Mode. (BTW, removing a USB2 controller under Normal Mode will trigger a BSOD even with the oldest USBPORT.SYS so this issue mentioned before is present no matter what) I then rebooted the machine and allowed the USB2 devices to be reinstalled from scratch, using the updated USBPORT.SYS. I rebooted again after this for good measure and then connected a USB Flash Drive. To my surprise it worked without a BSOD and was detected and installed properly. I was able to access it and then safely remove it using the tray icon. However, as soon as I connected a second USB Flash Drive I got a BSOD immediately, as before. I had to manually reset the machine and I was able to reproduce the issue exactly again. So it appears that if the controllers are originally installed using 6941 then once can successfully connect, use, and remove ONE USB storage device without triggering the problem. But when one connects a second flash drive, the old behavior resurfaces. I can only assume that there is some slight difference (maybe in the registry?) made by using the later file during installation. It does change the behavior from that of simply directly replacing the one file, but in the end the result is the same because the BSODs still resurface. This test was done using the ME USB1 stack. I don't know what effect using the 2K USB1 stack may or may not have. All part of the plan.. haha. I've been stepping up incrementally with newer Intel systems, mainly looking for the point where using 9x becomes "more of a problem than it is worth," but as a second benefit I will eventually have a "high performance" system for XP as well. Next system on target after the X58 is the X79.. but I'll need to save some more money for that, lol.