Mathwiz

How does he do it? Has he found - or created - a Rust compiler that targets XP? Could he let us (or at least @roytam1) in on the secret?

UXP browsers like NM 28 are updated monthly now. Be patient. Besides, did you really feel the need to update your browser every week? Unless there's a critical security fix, even monthly seems like overkill to me. The Web doesn't change that fast! +1. It's just another instance of Mozilla chasing Google. Chrome is way up into the 90's, so Mozilla thinks FF has to be too. Are users really so dumb that they'd think Chrome 95 is "better" than FF 91 just because it has a higher version number? Well, I'm sure a few are, and they're both chasing the lowest common denominator.... I've mentioned this before, but it reminds me of when the DECT cordless phone standard came to the US. They named the US version DECT 6.0, even there was no version 1.0, 2.0, 3.0, 4.0, or 5.0 - because the previous generation of cordless phones worked on a 5.8 MHz frequency, and they thought folks would think "5.8" phones were "better" unless the new DECT phones carried a higher number Personally, I'd just use the year as a version number; you know, like Windows 95, 98, 2000 ... what was wrong with that? You could use the month as a subversion if desired.... Not sure what's going on here, but it's interesting to see updates to NM 27's Javascript engine.

Thanks for that info; unfortunately, it makes the stats less useful IMO. Quantum is as different from UXP as Chrome is. I guess all anyone cares about is who's "winning" the browser "wars." No surprise it's Google, with their own major OS (Android), a deal with the makers of another major OS (Micro$oft Windows), and their joint control of much of the Web. Yes, Firefox offers an alternative, but there's not much advantage in running it these days. There's still Apple Safari, I suppose, but (typical of Apple) it's closed-source, isn't it? I think the last version of Safari to run on XP is as ancient and unusable as IE 8.

@xpuser33, I think you may misunderstand @roytam1's role. He isn't writing browsers from scratch; he's merely bringing them to the XP/Vista community from other platforms. You may also misunderstand the role of the browsers you tried. They are not modern browsers and will fail on many modern Web sites, mostly due to changes in Javascript libraries used by many Web developers. They're based on older Firefox versions and are intended to provide a fast, "lightweight" browser for the sites that still work on those older versions. Roytam1 has some ability to fix minor bugs on his own, but it sounds like you're asking for a major redesign. If you need support for modern Web sites, I'd encourage you to try one of his UXP browsers instead: New Moon 28 or Serpent 52. (For your convenience I linked to the latest versions for non-SSE2 CPUs.) Unfortunately some Web sites won't render properly even on these newer browsers, and of course they'll run more slowly, but I think you'll have much better luck on many sites with these newer browsers. If the sites you need won't work on these newer browsers either, you'll have to try one of the many flavors of 360EE instead. Almost all sites will work correctly on 360EE v13, but it is something of a memory hog.

In retrospect, I wonder if Mozilla regrets jumping on the Google bandwagon? You're not gonna out-Chrome Chrome, and they probably didn't endear themselves to their user base by dumping their entire add-on ecosystem in one fell swoop. Multiprocess mode is nice, but users deserve a choice and weren't given one. Of course, a little perspective on those numbers would be nice. Although I'm sure most of those lost users switched to one of the Chromium variants, I wonder how many moved to other FF variants, like Mozilla's own SeaMonkey, MCP's browsers, Waterfox (Classic and modern) and the like.

I don't think that was what he meant. Sounded to me like he thinks the Rust language (used for FF 56+) has some inherent vulnerabilities, regardless of OS. I do run MBAE on my XP VM; hopefully that's good enough....

More modern browser options for XP are certainly a good thing. And it's also good to hear that it's faster than 360EE. And it does my heart good to see @feodor2 stick it to the jerks at MCP by just forking Firefox itself But don't let this become an excuse to cease development of @roytam1's current browsers! Remember, from FF 57 forward, Firefox no longer supports the vast majority of add-ons we've all been using. Every add-on will need to be replaced with a "Web Extensions" version - if it exists. Otherwise you're SOL. An XP fork of "classic" Waterfox (before they got sold) would solve the add-ons problem, but I don't know if that's in his plans. Also, while not a big deal for most users these days, be aware that FF 91 no longer supports Adobe's Flash plug-in. If you run Flash content you'll need to keep an older browser around.

So are mine, as it happens. I never got around to uploading a picture of myself in them, though. I used to have a profile pic, but it wasn't a picture of me - just a parody of the old Enron logo after that company defrauded itself into bankruptcy. At any rate, it went away some years ago, and rather than putting up a self-portrait, I just left the big "M" in its place.

Yes, it is. Often it's a kind of shorthand: I often say, "this program is stupid" when what I really mean is "this program was designed stupidly." Similarly, I think describing an OS as "evil" is usually shorthand for ascribing evil motives to its designers. In the case above, though, I think "ugly" may have been a better adjective, since the complaint was about appearance, not (say) telemetry. We'll never all agree on which OS is the most pleasing to the eye, let alone "best." To each his own; that's one reason MSFN exists!

That is correct. The problem appears to be that if it's too recent, it seems to trigger that blasted "[0x80072F8F] Your computer's date and time appear to be out of sync with an update certificate." The original CA.crt ran from 2015-2025 and seems to work just fine. Yours runs from 2020-2030 and also seems to work fine. Dave's runs from 2021-2031 and does not seem to work. I also had one that ran from 2021-2031 that didn't work. I had to replace it with the original 2015-2025 one to fix it. I assume a new one was created when @Dave-H installed @Thomas S.'s version, which presumably runs from 2022-2032. It doesn't work either.

So, maybe 2020-2030 works too? If so that would be better than 2015-2025; it would give us another five years, assuming the remnants of WU/MU last that long....

Ironically that may be the solution: CRTs just don't "do" sub-pixel font rendering. I guess in theory they could, but you'd have to set up a custom screen resolution that exactly matched the details of the CRT's shadow mask, and only a Trinitron-style CRT could possibly work with ClearType. OTOH, a CRT may make things worse on an OS that "assumes" sub-pixel font rendering is always possible. FWIW, I don't think Win 7 is "evil," but if you can't stand to look at it, it's pretty useless to you. (I do have a few very old but working CRT monitors lying around; if anyone wants one PM me. Pay for shipping and they're yours.) As for myself, sub-pixel font rendering has always looked great as long as the colors involved were black and white; but when other colors get used, it starts to look pretty awful. Looks fine. Unfortunately we're all trying to render that image on our own monitors, so it may not look to us the same way it looks to you! I had no idea the vagaries of font rendering were causing so many of us so much grief. Too bad M$ isn't listening. Now, what were we talking about again? Oh, yes.... I never thought I'd say this, but thank M$ for IE!

I see D.Draker uploaded it for you. (Thanks!) It won't make any difference, though, unless you need it to validate another certificate that was signed by that one. I understand. I don't think there's any problem with ProxHTTPSProxy. I think there's a bug with Windows Update when it tries to validate a site certificate signed by your ProxHTTPSProxy certificate that runs from 2021 (last year) to 2031. It's throwing that date/time error code when it shouldn't be; your ProxHTTPSProxy certificate is fine but WU still chokes on it. As to actually finding that bug and fixing it, where's @mixit when you need him? For some reason, WU seems to like the original ProxHTTPSProxy certificate (the one that runs from 2015-2025) better. But, it won't work unless you put it in your trusted root store (with a command like the one D.Draker gave you for the M$ certificate) and also recreate your site certificates. I think ProxHTTPSProxy will re-create your site certificates automatically if it sees that CA.crt has changed, but just in case, you can rename your ...\Certs folder and create a new, empty one. That will force ProxHTTPSProxy to generate all new site certificates and sign them with the new CA.crt. The reason for renaming the folder vs. just clearing it is just for performance; if things go wrong, you could just delete everything in ...\Certs, but if instead you go back to your current configuration, ProxHTTPSProxy won't need to re-create all your site certificates yet again. If you have to put your current CA.crt back, it can just go back to using the old ones. A final note: CA.crt contains both a certificate and its private key. The private key is needed to sign the site certificates that ProxHTTPSProxy creates. From a pure security standpoint, it's unwise to share a file with a private key like CA.crt, because (in theory) any two folks using the same CA.crt could decrypt each other's communications, if they had access to each other's computers. But for what we're doing, it's probably fine. I doubt that any of us is inclined to spy on anyone else! That said, does anyone using ProxHTTPSProxy have a CA.crt expiring between 2025 and 2031? It'd be interesting to see if it works or not. I suspect there's a particular point in between (1/1/2028?) where things go wrong.

Clean Flash Installer version 34.0.0.211 is now available at https://gitlab.com/cleanflash/installer/-/releases/. Confirmed working on Windows XP. Don't forget you need JustOff's GitHub-wc-polyfill add-on installed to access GitLab from a UXP browser; also Serpent 52 must be in single-process mode. 360EE should work without issue.

I have Windows 7 too, which actually isn't too bad (someone once joked that Windows 7 was just Vista SP2; M$ just bumped the version so they could charge you for it again). And I do have a copy of ChrEdge on it, although I rarely use it anymore - I just use the same 360EE v13 as on XP.

Well, at least Micro$oft uses Javascript to remove the "browser not supported" banner, rather than just looking at the User Agent and "assuming" the browser isn't supported! Most sites just don't work at all if the Javascript errors out, and/or give "browser not supported" if the UA is unexpected, even if the page's Javascript does work! The https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-createwindowexa page renders correctly in 360EE v13, but shows "browser not supported" in Serpent 52 even with 360EE's user agent. That said, there's nothing on that page that requires any particularly advanced Javascript. Micro$oft just wants you to use their Edge - and of course a Windows version that supports it (not to mention a PC that will run that Windows version). How dare you try to browse a Micro$oft site with XP!

No. It is confusing though. MCP forked the UXP engine (used in NM 28, Serpent 52, IceDove/IceApe, and MailNews/BNavigator) from the last XP-compatible version of Firefox, 52 ESR. (I think version 52.6 specifically, but I wouldn't swear to it.) And they've made some improvements since, including, apparently, globalThis and modules support for Javascript. NM 27, along with ArcticFox and K-Meleon, were forked from a much earlier Firefox version and hasn't received as much attention in terms of improving the Javascript engine.

Looks like an add-on for the globalThis polyfill should be targeted to NM 27, since globalThis is apparently implemented in UXP (NM 28, etc.) already. Speaking of polyfills, I poked around in JustOff's github-wc-polyfill add-on a bit. It seems to implement custom elements, which has been a JavaScript standard for some time, but still not implemented in UXP. But his add-on limits the polyfill to GitHub/GitLab. Anyone know why? Since it's a standard, I'd think you'd want to add it to all Web pages, wouldn't you?

Thanks, @InterLinked! Now I finally understand what a "polyfill" is! Same reason there are multiple versions of 360EE: the older versions are lighter and thus run better on older hardware. Which reminds me: your ChromeFill extension would be great for 360EE v11, which is based on Chromium 69. Lots of folks don't want to run the RAM-hogging v13. So you might want to post in the 360EE threads too. BTW, the globalThis polyfill won't be as useful on NM 27 as on 28 because, of @roytam1's builds, only UXP browsers like NM 28 support Javascript modules. But it's probably still worth doing if possible.

I don't have that IC and everything seems OK; therefore, that one probably isn't needed. I don't think having it causes a problem, though, aside from wasting an insignificant amount of storage space. (FWIW, I do have an IC called "Microsoft Update Secure Server CA 2.1 which expires 21 June 2027. Do you have that one?) Note: you do need some expired certificates, for verifying things like signed files and the like. I recently made the mistake of deleting all expired certificates from my trusted root certificate store and WU failed spectacularly. Lesson learned! I reran @heinoganda's certificate updater and it fixed my mistake by reinstalling several expired root certificates, including one called "Microsoft Root Certificate Authority" with the same expiration date (9 May 2021) as your IC.

That's the same error code you were getting before you updated your config.ini. I think ProxHTTPSProxy isn't working with the original CA.crt. Try this: Rename the working (new) CA.crt and the ...\Certs folder so you can revert if things go sideways Create a new (empty) ...\Certs folder Run the cert. installer program from @i430VX's version of ProxHTTPSProxy (you don't need to install his version; just run that program). That will put @heinoganda's original CA.crt out there and make it a trusted root cert. Try again - if it still fails, you can reverse the above steps. You'll have to reinstall your new CA.crt as a trusted root again.

It's just a pref, so once you set it, it sticks even when you update New Moon. I can see the argument for turning it off by default (don't let NM ping the MCP server and poke the bear, so to speak), but some folks prefer NM to have the same default prefs as PM - fewer surprises that way - and it can always be turned off easily if desired.

Strangely, that redirects to http://fe2.update.microsoft.com/microsoftupdate. That trailing period looks wrong and the link just gives a server error page. (That may have been the original problem, but I couldn't see the error because IE's https: handling hid it from me.) But if you remove that trailing period (i.e., http://fe2.update.microsoft.com/microsoftupdate), it works! (BTW, MU takes way longer to scan than WU, but that makes sense because I have Office 2010 and I think one of its cumulative updates triggers the old "scans forever" bug. Oh, well; at least I can get to the scan now!) I'd still love to know why the MU link on the WU page worked a few days ago but doesn't now, but since removing the trailing period works, I'll just bookmark the link that way and not worry about it. Yes I copied your config.ini entries from your screen shot earlier. They work fine but didn't solve the MU problem, since the redirect on M$'s server is apparently wrong (has that extra period as shown above).

When you start ProxHTTPSProxy, if there's no CA.crt found when you start it, it will create one, valid from that date until 10 years hence. It then uses CA.crt to sign all the certificates it creates for the https: sites you visit, so you must install CA.crt as a trusted root certificate for ProxHTTPSProxy to work at all. I'm guessing your ProxHTTPSProxy install didn't come with a CA.crt, so it created the one you installed. @i430VX's install comes with the one that's valid from 10/1/2015 until 9/30/2025 (presumably it was created on the former date). The .exe I ran appears both to place that CA.crt in your ProxHTTPSProxy directory and to install it as a trusted root, so I believe ProxHTTPSProxy will create new site certificates and continue working. At worst, you may need to clear the ...\Certs subfolder to get rid of the old, no-longer-valid site certificates so that it will create new ones. To be safe, you could back up both your current CA.crt and your entire ...\Certs folder, so you could put them back in place if anything goes wrong with the new CA.crt. I don't really understand why it would matter either. But, at least in my case, it did fix the date/time issue with Windows Update. The message seems to indicate that your system date is earlier than the start date of a certificate, which is impossible unless either your system date is incorrect, or there's a bug in WU's certificate validation routine. Clearly it must be the latter. Perhaps there's a bug in dealing with dates after some point between 2025 and 2031. Not sure what we'll do if we still need Windows Update after 2025.... I was going to post on this myself, but you beat me to it! The .cmd file deletes wuaueng.dll from ...\DLLCache, then renames the one in ...\System32, then it copies the patched file into System32. But then SFC sees the new file, tries to compare it to the one in ...\DLLCache, and, not finding it there, it copies the original version from \i386! Then when you try to run Windows Update, it sees you have the old version and downloads the original, unpatched version that you started with. Round and round we go.... I didn't disable SFC; instead, I copied the patched file first to ...\DLLCache, then to ...\System32. That way SFC found the file in ...\DLLCache, discovered it matched, and left it in place. That brings up a curious problem I ran into. When I started on this journey, I could click the link and pull up the Microsoft Update page without issue. (Of course neither WU nor MU worked at the time, but I could at least bring up the page.) But now, I only get "Internet Explorer cannot display the web page." The error comes up immediately. The IE address bar shows https://update.microsoft.com/microsoftupdate and I can see a 302 (Moved Temporarily) response in the ProxHTTPSProxy window, so the link is redirecting (somewhere) but immediately failing.

Well, how about that; it works! Yes, his response was a bit terse for my taste too, but I figured it out. So let me fill in the details a bit: Download & extract the version of ProxHTTPSProxy at @i430VX's site: http://i430vx.net/files/XP/ProxHTTPSProxyMII_REV3d_PY344.7z The .7z has four folders. Open the folder labeled ProxHTTPSProxyMII_CertIns_Windows. It contains two .exe files: ProxHTTPS Cert Install.exe and ProxHTTPS Cert Uninstall.exe. Run the Install one. It won't seem to do anything, but it will silently install the needed certificate wherever it needs to go. It'd be nice to know exactly what it's doing; nonetheless, try Windows Update again, and you should get past the dreaded clock date/time error. It's a bit of a moot point, since there aren't going to be any new updates; yet it's quite gratifying. I never thought I'd see that Web page again!