Mathwiz

Yeah but PM isn't a "modern" browser, so it doesn't work like a 3D game engine and doesn't really need AVX.... I had a hard time taking that article seriously after I saw the diagram of a jet engine, with its components labeled "Quantum" this and "Quantum" that.... Talk about hype - and that was from 2017! Is that how we're supposed to "understand" modern Web browsers now? What's next - an "explanation" of Chromium illustrated by a diagram of a rocket? OK, the Web has officially jumped the shark. Web sites are dictating processor architecture now? How the heck is that supposed to work if you have an ARM processor, or one of Apple's new processors, or really, anything but Intel / AMD?

AVX instructions would be of some benefit on CPU-intensive applications like AI, but probably not much on a typical Web browser, and certainly not on an email client. PM might be an exception because its old FF 52 Javascript engine takes a lot more CPU than the corresponding engines in more modern browsers. Back in 2017, the JS engine could afford to be inefficient, but Web sites are much more bloated with JS in 2024. But if MCP is merely using AVX as a proxy for "faster CPU," then it seems silly to me. Instead of AVX, the PM installer could just run a simple loop to test CPU speed, and pop up a warning if the CPU is found to be "too slow." It'd be interesting to run some side-by-side tests of AVX and SSE2 Pale Moon builds on the same PC (with an AVX processor), so we could see how much improvement actually comes from AVX vs. the improvement just from a faster CPU. I suspect it's mostly the latter, but either way, it seems to me there would be a much greater ROI from backporting a more modern JS engine to UXP than from just building PM with AVX instructions to try to brute-force their way out of an old, slow JS engine. (Their stubborn insistence on a single process doesn't help either. Most modern CPUs have at least eight cores, but PM will basically use only one of them.)

Not really surprising. Every time it hits an AVX instruction a software interrupt occurs; interrupt handler has to save everything, do what the AVX instruction would've done (if you actually had an AVX processor), restore everything and return to Pale Moon. Then a few nanoseconds later, it all happens again - over and over. Only reasonable solution is to use the build of Pale Moon without AVX instructions that you discovered above. Not really clear why MCP did this (as opposed to why they say they did it); perhaps by limiting Pale Moon to AVX processors, they're effectively limiting it to newer processors, and thus (indirectly) to faster processors that can handle the Javledygook on modern Web sites without bogging down.

I'm just glad he's OK.

Is @roytam1 on vacation? He certainly deserves one, so I have no problem if he is. I never thought we really needed weekly browser updates - or even monthly, unless some significant new feature is added or security flaw is fixed. Personally, I'd be fine with quarterly updates! But usually, each week there's either an update or a post telling us otherwise. And he's held to that pattern for so long, it stands out when the pattern breaks. So I was just a bit concerned.

Supermium got mentioned by Micro$oft: I thought their typo ("Supremium") is actually a better name than Supermium! Seems to roll off the tongue a little more easily since "supreme" and "premium" are both common English words.

I think that's better; yes.

Amen. There is some truth in that. Case in point: MCP's refusal to support modern EMEs like WideVine because they're opposed to EMEs philosophically. Or for that matter refusal to support e10s because "I'm a browser, dammit, not an OS!" Do they really think those decisions have caused anyone else to rethink their own decisions?

I think a big part of the problem is that Javascript wasn't originally designed to do the kinds of tasks modern Web sites have it doing now. Originally it was just intended to do simple "bells and whistles" tasks that the site could live without - hence you could disable it and still use the site, albeit with less functionality. But since then, it's evolved into a complex programming language that folks even write .PDF viewers in! In a perfect world, perhaps we'd start over with C-script or something; some kind of language easy to JIT compile into efficient machine code. Come to think of it, didn't Micro$oft try to push VBScript as an alternative, many moons ago when IE was the dominant browser? The effort failed because no other browsers supported VBScript, but perhaps we'd be better off now if M$ had succeeded. Or not. Just a thought.

Yeah, that's unusably slow on St 55 (not strictly UXP but close), even with e10s enabled on 64-bit W7 with 8 GB RAM. But I'm not surprised an Android developer site uses Javascript that's only fast on "modern" browsers. After all, everyone who goes there (present company excepted) probably uses Chrome on at least an 8-core processor. Just bloat the site up with as many "cool" features as you can think of, and if someone finds it slow, just quote "system requirements" at them rather than making the slightest effort to optimize the code. It's the modern way of the Internet. My point was only that UXP meets @j7n's definition of "retro" - new functionality with an old UI. I even conceded that it was slow! Not many sites are as bad as that one, though.

I don't know if this is possible, but could you set up (say) an 8GB RAMdisk and then put the page file there? Obvious problem would be, how do you create the RAMdisk before the page file? Seems like you'd have to have XP boot without any page file, load the RAMdisk driver, then create a page file on the RAMdisk. Perhaps some sort of startup script could be used, IDK.... Edit: And if I'd just read two posts further down before posting this: https://msfn.org/board/topic/173201-gavottes-ramdisk-automation-package/

I think in this context, "older" means post-EOS, so Win 10 won't count for a few more years. Of course anyone is welcome here, whether they use an "older" NT-based OS or not. I was only pointing out that the very nature of this subforum will attract a disproportionate share of Win XP diehards, since XP was one of Micro$oft's most popular "older" OSes. I like that definition, even if not everyone uses the term that way. ReactOS is meant to be a Windows clone in the "style" of XP, although to be practical it must support at least some functionality of newer Windows versions. UXP browsers are another good example of that "retro" definition. They have the look and feel of older Firefox versions, but they do a halfway decent job of rendering many modern Web sites (as long as you're very patient).

You do realize you're posting in the "Browsers working on Older NT-Family OSes" subforum, don't you? I don't think it's particularly surprising that XP diehards are over-represented here. It's certainly not all of MSFN. If the thread linked above is TL;DR, Moonchild explained: It would be illogical for DDG to block Pale (and New) Moon intentionally, since DDG and MCP are business partners. DDG must've just, um, forgot when they set this up. So presumably, DDG will have this fixed soon; in the meantime, you can use Firefox compatibility mode (or an SSUAO), or turn off "Redirect when necessary" under DDG's "Privacy" settings, to work around the issue. They don't want Mozilla. Every browser alive has a user agent that starts with Mozilla/5.0! It's a historical artifact stemming from the Netscape browser's dominance oh so long ago. They want Firefox, like this: Mozilla/5.0 (Windows NT 10.0; rv:115.2) Gecko/20100101 Firefox/115.2 Strictly speaking, that is correct. However, the implication of your post is that ECMAScript is completely independent of Google; apparently you think they just pull new Javascript features out of their collective arses, and Chromium and Mozilla then dutifully implement said features. But you know that's nonsense. Anyone can see that Google has a massive influence (and Mozilla a lesser influence, and MCP no influence whatsoever) over ECMAScript. After all, Google owns the dominant Web browser! I think you just saw "Chromium-exclusive features" (which, to be sure, was a wrong thing to say) and went off half-cocked a bit. But our opinions about Google's degree of "fault" in all this don't really matter. After all, the Web is what it has become, and any browser has to be able to handle what it'll find there: So, if one wants good performance on modern Web pages when running XP, it's gonna be Supermium or Thorium. I resent the fact that there's no "unGoogled" Chromium-based browser for XP diehards, but them's the breaks. Actually version 53 (you forgot about St 55)! Be that as it may, it sounds like you missed the start of the discussion, which was NHTPG complaining about DDG turning AdNauseum off (which in turn was in response to questions about DDG no longer working properly in New/Pale Moon - see above). NHTPG also mentioned that he preferred AdNauseum's UI over uBO's, but didn't go into specifics. As it turned out, it wasn't some sneaky DDG Javascript; rather, AdNauseum just disables itself on several sites, including DDG. The reason for this (which NHTPG disapproves of, although others may disagree) was discovered and explained. So the discussion was relevant to anyone using either DDG or AdNauseum, whether on @roytam1's browsers or others; it wasn't Chromium-specific. Luckily, those words appear within the filter lists you're downloading. You're unlikely to get in trouble as long as they aren't part of a URL you're visiting. Well, it was probably a bit better when it was first introduced . But yes; it went downhill for a while, and some sites still need browser-slowing polyfills, but today (performance issues and occasional tab crashes aside), it's really not bad.

Glad you got it sorted out. That's correct. None of the Mozilla-based browsers use those, including the UXP line. Chromium-based browsers are, of course, different and do use them; that may be one reason Micro$oft was comfortable replacing Edge's browser engine with Chromium.

From the screen shots, connections to those sites are refused before you even get to the TLS negotiation stage, so TLS 1.3 support won't make any difference. (At present most sites still support TLS 1.2, so TLS 1.3 support doesn't yet add much to the places you can go. That will probably change in the future though.) I can get to all those sites with IceApe (although the GitHub site looks terrible). SeaMonkey 2.49.5 works too, so I think your problem could be a DNS issue, or maybe some kind of proxy is in the way. Whatever it is, some sites (such as SSL Labs) apparently work but others don't. If I "ping o.rthost.win" from a command line, I get responses from IP address 104.21.48.191. What happens on your XP system?