VistaLover

... Now you hush, "young" gentleman! Those people are already extremely p***ed that you, single-handedly, created the Vista Extended Kernel project, so much so that they fear their "support channels" will get overwhelmed by Vista users running their official builds: https://forum.palemoon.org/viewtopic.php?p=198116#p198116 As the saying goes, "No good deed goes unpunished" ...

In yet another move, MCP have just modified specifically the unofficial branding for their Pale Moon web browser application: https://github.com/MoonchildProductions/Pale-Moon/commit/54aeb54 with updated graphics and nomenclature ... The overhauled graphics resembles that of the Mozilla Firefox recent Nightly channel, in blue-purple colours: ... but the new name given to unbranded unofficial builds (like what has been till now @roytam1's New Moon 28) is just... Browser ! No doubt a attempt on their part to coerce things to move to the direction they want... So, come this weekend (with the hope @roytam1's hardware issues are somehow rectified), be prepared to say hello to Browser 28.10.2a1 ...

@Vistapocalypse : A teaser/taster for now:

Moonchild's reaction, as of several hours ago: https://forum.palemoon.org/viewtopic.php?p=199503#p199503 In that same thread, now locked, he even hinted/threatened to move Pale Moon source code to a private repository, a la Binary Outcast... Let's just hope things don't get to that... Addendum: Related: https://forum.palemoon.org/viewtopic.php?f=40&p=199513 (... and Mypal build 28.13.0 - discussed above - has been now withdrawn, due to issues, replaced by build 28.13.1; this one has the same limitations though, with regards to upstream resources...)

... Impatience is not actually a virtue, at least not by me... You've also asked me practically the same thing last Sunday: In fact, I had already scheduled a detailed reply tackling the WD-on-Vista situation, but due to other things I'm into currently (coupled with an emergency visit to the dentist's ), that reply has been delayed... More to come when I find the time...

Off-topic: Well, people like you and me need to "spend" there, period: https://archive.org/donate/ (I have donated twice in the past... ) On-topic: As a friendly reminder, Adobe Flash player v32.0.0.171 has publicly disclosed security vulnerabilities, which have been patched in later versions; as long as the vendor continues to issue updated versions (currently 32.0.0.443) and until the announced final deprecation date (31/12/2020), the wise thing to do is use a current version when facing the internet... v32.0.0.171 should only be used to play back locally stored content (.SWF files) after the last "timebombed" version ceases to function... Just my 2 (euro)cents, of course...

... Well, fortunately things aren't yet as dire as you pictured them , all thanks to web.archive.org The URL https://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html has been captured 187 times in total, the last time "valuable" content was still in was on July 18th 2020 (https://web.archive.org/web/20200718192527/*) The last version of Adobe Flash Player without the 2021 timebomb was/is 32.0.0.371; WAO have actually captured the following URI https://fpdownload.macromedia.com/pub/flashplayer/installers/archive/fp_32.0.0.371_archive.zip 5 times, last one was on June 30th, 2020 (https://web.archive.org/web/20200630185943/*) ; the zip archive itself is at 388 MiB, so it'll take a while to come down from WAO... It contains all possible flavours of installers/packages, no need to search further... Don't make that mistake again...

... Do I get extra points for prophesying ? Try the above Direct Link now and you'll get the door slammed at your face : Access Denied You don't have permission to access "http://fpdownload.macromedia.com/pub/flashplayer/installers/archive/fp_32.0.0.371_archive.zip" on this server. Reference #18.c46656b8.1600036305.1ef6b01c

FT DeepDark has been my preferred Firefox Complete Theme ever since it was made available ; of course, Fx Quantum killed it , so development reached an end, with its final version supporting Fx 56.0 (and I could only run up to Firefox v53.0 on this Vista machine ) ... It is a crying shame that Firefox Complete Themes haven't been salvaged, in CAA or elsewhere... If you are persistent, you may find some versions archived in the web archive and similar services... Specifically where FT DeepDark is concerned, its author (Stefano Rosselli, a Swiss) has attached a very limiting licence to it so, despite me having the XPI file saved on disk (from the era it was still on AMO), I'm not at liberty to redistribute myself... However, all hope is not lost for you:

... I took the test using Firefox ESR 52.9.1 (32-bit), and the pop-up with the error reported was also displayed at the end of the test execution: Given that the initial fork point of official UXP was Mozilla ESR 52.6.0 (the platform used in Mozilla Firefox 52.6.0 browser), an educated guess of mine would be that this is something Serpent 52 inherited all the way back from Mozilla ; at the same time, one may also claim that the "site" doesn't - by choice - support fully older desktop Firefox versions/engines ... At any rate, this is all probably a moot point , seeing that - as I can also confirm - by dismissing the pop-up, one can successfully get the final test score... I went as far as searching for the term "parent.RankDataLists", but nothing useful for debugging purposes showed up EDIT: ... Scratch that ; it's been reported that even Firefox 80 produces the same error pop-up ...

... Has been reported in the past, but in relation to Serpent 55 : ... BTW, not a fan of these benchmark sites myself, but whatever tickles your fancy...

TBH, I don't think Moonchild himself had anything to do with it; that was all pure/unadulterated M.A.T. , acting out of spite indiscriminately against forks run on NT < 6.1; proper branding was irrelevant at that point in time; and, of course it was intentional; M.A.T. claiming snarkily, quite proud of himself, on the afternoon of the 25th that https://forum.palemoon.org/viewtopic.php?p=197919#p197919 ... and some of his sidekicks in that same thread trying to prove the doubters are delusional... I'm happy for @letmeindude for standing up to the lot of them, and for doing major debugging of the issue (both in the PM forums and GitHub). As for a "reasonable explanation", don't expect one... I'll just refer you to what MC posted on the matter (link in my post just above yours...)

... Are you sure this is FULLY de-obfuscated? function displayContent() { if (X("0x3", "^Mn5") in navigator) { uaPrefix = navigator[X("0x10", "wOY$")] + "/5.0 (" + navigator[X("0x5", "&j9b")] + ";"; if (!navigator["userAgent"][X("0xf", "wkB!")](uaPrefix)) return; if (navigator[X("0x4", "G9*&")] && (navigator["oscpu"][X("0x8", "^Mn5")](X("0x9", "Puzb")) || navigator["oscpu"][X("0xe", "73(^")](X("0x11", "e6DU")) || navigator[X("0x0", "DLe0")][X("0x2", "fCh&")](X("0x6", "pseB")) || navigator["oscpu"][X("0xb", "k4n@")](X("0xc", "GBIt")))) return null } var ig = document["getElementById"](X("0x1", "6osW"))[X("0x7", "rMvY")][X("0x13", "czCY")](!![]); document[X("0x12", "&iPz")]["appendChild"](ig); document[X("0xa", "Y8yJ")]["id"] = X("0xd", "wOY$") } ... Though he doesn't acknowledge he had anything to do with their removal, Moonchild's account of things: https://forum.palemoon.org/viewtopic.php?p=198040#p198040 TL;DR 1. He pretty much (as expected) justifies M.A.T. because he was undeservedly banned from MSFN without notice, as being "a long-standing member with a good track record" () 2. Once again, fork users are being called "so selfish"... The whole affair boils down to two things, basically: 3. MONEY ; the addons infra is being maintained fiscally out of M.A.T.'s own pocket; supposedly, "freeloaders" such as the fork-users put a significant extra burden towards bandwidth consumption/server costs... Edit: Fork users, when using the default Search Engine, DDG, also contribute towards the official project by Moonchild, do they not? 4. Branding (and all related stuff discussed extensively elsewhere in these forums). NB: The term "out of spite" is never mentioned ... I must thank @siria for being the first person in these forums mentioning in the past this HIDDEN Firefox pref When SSUAOs for the add-on repos stopped working for me, but I could still access them in my sister's Win7 laptop inside the same WLAN, I became sure I smelled of fish ... I arrived to the conclusion he must be checking OS version by Javascript, so I remembered that pref and applied it independently on my own; I did not disclose this early on, fearing the involved person's unpredictability... general.oscpu.override changes the Javascript-detected OS version globally; you can read more about it here . However, I wanted something more elegant, that would only work on these two "affected" sites; since I have Greasemonkey for Pale Moon installed, I concocted the following userscript: // ==UserScript== // @name Fake 'navigator.oscpu' on PM & Bk add-on repos (25-08-2020) // @namespace VistaLover // @description Changes 'navigator.oscpu' on PM & Bk add-on repos // @include https://addons.palemoon.org/* // @include https://addons.basilisk-browser.org/* // @run-at document-start // @grant none // @version 1 // ==/UserScript== Object.defineProperty(navigator, 'oscpu', { value: 'Windows NT 6.3' }); Sharing it now for purely academic reasons, just in case... BTW, navigator.oscpu is a feature of only Firefox and friends, Chromium-based browsers don't (easily) divulge the OS version when queried by JS... So, one major crisis averted, I'm sure there'll be more coming...

... I, too, was using DNS Quad 9 Public servers (9.9.9.9,149.112.112.112) until I recently found out that Dropbox links weren't resolving , e.g. : https://www.dropbox.com/ https://dl.dropboxusercontent.com/s/7d47x36vuibc39h/palemoon.js ... so I went back to DNS Cloudflare Public (1.1.1.1,1.0.0.1) ... (OT: Using the very handy nirsoft utility QuickSetDNS v1.30 )

The block was originally implemented (no doubt by M.A.T. ) in the afternoon (my timezone, i.e. UTC+0300) of August 14th, 2020; it denies access to forum.palemoon.org by UAs containing the PaleMoon/28.10.1a1 slice ; that one was relevant to recent New Moon 28 builds prior to the latest one (which, at last, has 28.10.2a1 as appversion) : What is noteworthy is the nature of the error generated, which would have the uninitiated believe it was related to a genuine TLS connection/certificate issue ... On that day, @roytam1 "dared" to post in The Official Interlink Mail & News Discussion Thread : https://forum.palemoon.org/viewtopic.php?p=197174#p197174 which presumably tripped M.A.T. over: But the official forums do not only contain M.A.T.'s "board", who granted this individual God-like rights to ban online community content at a whim? <OT rant> I'm not a young person anymore, sadly, but I swear to all of you I hadn't come across, both in my whole real life and in my "digital" one (since ca. 2005...), such a mean-spirited, vindictive and petty individual, and this is also taking into account the latest unethical shenanigans... The great Albert Einstein might have said : ... but I must add a third one: human evilness Note to admins: As you all probably know by now, I have shown exemplary conduct in these forums; but this time I had to vent ; I apologise profusely and can only swear this won't happen again... </OT rant>

... He's using the WSUS (Windows Server Update Services) that comes with Windows Server 2008 R2 SP1 to access and download Win2k updates, not an actual Win2k installation... @max-h : Where can one find/install/configure a suitable version of WSUS on Vista SP2 itself (if at all possible...) ? Having an existing installation of WSUS on WS2008R2 as a means to fetch Vista updates isn't practical, to say the least...

2008 R2 is the Server side of Win7 (and plain 2008 is the Server side of Vista); both 2008+2008 R2 are still supported by WU/MU, thus WSUS, if the corresponding updates that bestow SHA-2 support are manually pre-installed... This isn't any news, is it? OTOH, you haven't responded with clarity to @Vistapocalypse's query: Have you recently tried WSUS on plain Vista (+SP2?) ??? M$ don't offer an official update that implements SHA-2 support to the OS, one may use the KB for 2008, but does WSUS really work on Vista SP2?

Hello I'm not a Discord user myself, so the report "this trick stopped working" doesn't provide, at least to me, any detail I could use to troubleshoot further... My original post you quoted was from 20 months ago so, yes, many things might've changed since then... First thing that stands out is the domain name change, discordapp.com -> discord.com Then, FirefoxESR 60 has been long EoS'ed by Mozilla, likewise Win7 has been EoS'ed by Microsoft... It is highly unlikely Discord have already removed support for Win7 (... but I'm sure they'll do so when paid by Microsoft, who push their spyware Win10 onto everything on-line...), but it's quite probable they've stopped supporting ESR 60; ESR 68 (now at version 68.11) is on the way out, so to speak, while the new ESR is 78; so, in August 2020, I'd use general.useragent.override.discord.com;Mozilla/5.0 (Windows NT 6.3; rv:78.0) Gecko/20100101 Firefox/78.0 How exactly is your Discord experience broken in @roytam1’s (latest) Basilisk forks (BTW, they're called Serpent; mentioning the official app name tends to upset people upstream... ) ? Please be specific... This is, of course, the place to post about Serpent (and friends); while letting us know that a different Basilisk fork works for you has importance on its own for the wider XP/Vista communities, it doesn't help to identify that specific "some reason" you wrote about, due to which Discord stopped working in Serpent; if we are to assume the breakage is due to Serpent code and not due to a change implemented recently by Discord, then you can at least perform some bisection to identify the LAST GOOD and the FIRST BAD Serpent builds where Discord is concerned; then it'd be fairly easy (usually...) to pinpoint the culprit change that caused the offending bug... Is the above used in Centaury? I see two issues with it, though... 1. %OS_SLICE% will reveal the actual OS you're running the browser on, and if that one is XP (Windows NT 5.1;), then you're more probable to get blocked by Discord... 2. Having different values for Mozilla Platform (Gecko) revision (rv:73.0) and Firefox version (69.0) is not standards compliant, so I'm really puzzled the whole UA string works for you (?) Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent FWIW, I have just created a temporary/guest account with Discord and having applied the SSUAO I posted above, I first see some GUI glitches in latest Serpent 52.9.0 32-bit: ... i.e. three vertical (empty) scrollbar placeholders display, while, IMO, they shouldn't (they don't show up in 360EE v12, Chromium 78 based...), but I can't tell anything more is broken, since I've never used Discord before...

The exact URI to that script is https://game314425.konggames.com/gamez/0031/4425/live/Build/UnityLoader.js I downloaded it locally on disk and probed it with an editor ; I couldn't find "Disabled by lack of compiler support", but did find the original warning/error: "Your browser does not support WebAssembly." Looking closer at your Web Console output, it appears the message is generated by the browser's asm.js module, when it tried to compile js code fed to it by the UnityLoader.js script ; BTW, many thanks @UCyborg for your most helpful contribution, as always : You might've mentioned it previously in these forums, but it didn't dawn on me that that was the case... I am running Vista SP2 32-bit and my 2007 era Intel Core 2 Duo is SSE2 capable; so using the "-xpmod" variety of Serpent-52.9.0-win32... By the looks of it, you should be running the "-xpmod-ia32" build, derived from the "ia32" branch of Roytam1's UXP fork: https://github.com/roytam1/UXP/commits/ia32 TBH, I don't follow closely the development of that branch, only that of the custom branch (produces NM28+St52)... @UCyborg wrote that WASM expects at least SSE2 instructions set , so there's your answer... @roytam1 : Perhaps it could be a good idea to disable WASM and LOCK the related prefs (inside about:config) in your ia32 builds, so as not to create false expectations by the users of those builds on their pretty old processors... Just throwing this out there for consideration... As posted, I first tried the site with a pristine St52 profile, and it did ask permission to use Flash; Flash is used to deliver ads in the embedded player, just before the game itself loads (when it does... ).

I thought Basilisk/Serpent supports that, huh?! Latest St52 has buildID=20200814013442; WASM has been indeed supported since long ago, even MozillaESR 52.6.0, the initial fork-point of UXP, came with native support... Whether that native support is ON/OFF by default is a different matter, though... MozillaESR 52.6.0 had all native WASM support pref'ed OFF by default; in latest St52, the behaviour is determined by following two commits: [Basilisk] Issue MoonchildProductions/UXP#1611 - Use platform default for WASM https://github.com/roytam1/UXP/commit/95c5a64 Issue #1611 - Enable WASM by default but only enable jit when 64bit https://github.com/roytam1/UXP/commit/ed0edf6 Indeed, when I launch latest 32-bit build in a NEW/CLEAN profile, this is what I get: i.e. WASM is ON, but baseline just-in-time (jit) is OFF; if that isn't the case in your set-up, then something altered the default settings, either a (security?) configuration imposed by an extension or you did it yourself (directly in about:config, using a user.js file, etc) in the past, possibly following online advice, and forgot about it... FWIW, visiting the linked URL in the above CLEAN profile, I get no warning of the kind you reported; the site does require Adobe Flash though, and it took a considerable amount of waiting for the game to fully load ; but it did eventually: OTOH, on my very old/DIRTY profile, with many extensions (some of which of the WebExtension format), many userscripts (in GM-for-PM), many userstyles (in Stylem + Stylus), uB0-legacy with many filter lists, the game never loads fully , because of async OOM errors: ... so YMMV even with WASM turned back ON...

I tried in Serpent 52 2020-7-31 and ... (redacted for brevity) But Config Descriptions does not show anything in "Source comment" column (the column is added). ... You assumed things and that's why it didn't work in the end as you had thought it would... My mention of that extension in my post (of more than a year ago) was only inside the context of Mozilla Firefox... The original Config Descriptions v1.0.1-signed.1-signed legacy extension DOES NOT support Serpent 52.9.0 (or official Basilisk, or Pale/New Moon for that matter...) Serpent 52.9.0 != FirefoxESR 52 Good News: 1. You can patch the extension yourself, so that it works in Serpent 52.9.0; in file bootstrap.js change L223-L224: - "resource:///defaults/" + prefsDir + "firefox.js", - "resource:///defaults/" + prefsDir + "firefox-branding.js", + "resource:///defaults/" + prefsDir + "basilisk.js", + "resource:///defaults/" + prefsDir + "basilisk-branding.js", While you're at it, you can also remove the META-INF directory, as Serpent does not observe extension signing... Proof: 2. The old Firefox extension has been ported to both Pale/New Moon + Basilisk/Serpent; just install from: https://addons.basilisk-browser.org/addon/config-comments/ ... A strong word of caution while you are toying with e10s in Serpent 52.9.0: what little supporting code is left there is very rudimentary/fragile/unreliable at best ; please back-up your Serpent profile, especially your sessionstore, prior to starting these experiments! Use a secondary/temporary profile for testing! I speak from BAD experience myself ; once you decide e10s isn't good enough for you or (my case) one of your most valued legacy extensions breaks under e10s and you, thus, have to return to single-process, it's highly probable your profile has been borked beyond repair (I had to begin from scratch, took me many hours to resume my original profile... I hadn't backed-up ; you really should ). MCP applications (and forks) have been developed as single-process, and that's it...

This is most excellent news @SIW2 , thanks for the confirmation! If only we could untangle @Dylan Cruz 's predicament...

... so without SHA-2 code-signing support (AFAIAA, this can't be implemented to OSes prior to Vista SP2 and in the latter, packages targeting originally WS2008SP2 are needed ), that method will become a moot one... I foresee that the next release will only be SHA-2 signed... ... And, as expected, that has just happened! The latest WSUSscn2.cab file (links are still the same as in my previous post) is ONLY SHA-2 signed and probably just useless under XP SP3: M$ is putting an end to everything pre-Win7, it seems...

... And just to be on the safe side, your previous screenshot from Aug 8th reported definition version 1.321.917.0; can you confirm you are now on a "higher" version after executing downloaded file mpam-fe.exe ? That would dispel any doubt that the manual update procedure for MSE is a viable way to keep using it under Vista SP2! I am genuinely sorry you can't get this to work, Dylan, but I'm also out of ideas what you should try next... Perhaps a visit to Windows Event Viewer could shed some light on this mystery... Just one final, probably just silly, question: Where did you get your copy of MSEInstall.exe v4.4.304.0 ? If it was within the context of some WinXP related thread, it's possible they linked the 32-bit variant, which would also install under Vista x64; verify you have MSE 64-bit installed (the 64-bit mpam-fe.exe is not able to update MSE 32-bit, and vice versa...). Ultimately, only you know how you've configured your Vista SP2 system (I read several times that GPOs were used - not available here in my Home Premium Edition ), so it's possible something went amiss there... Best regards

... Says a WinXP x64 user (going by your avatar), a minority inside the community of XP users (most of which have been on x86 all along) ... FWIW, when Vista OEM was first released (as a successor to WinXP x86) and pre-installed in new hardware (this was my case here ), it was practically always 32-bit (the lack of 64-bit Vista drivers was, of course, an issue at the time...)! Do you actually have figures to support that "long shot" argument, or are you simply going by MSFN posters in these threads? In any case, I am a 32-bit user myself and just being patient for @win32 to work his miracles ; all Vista users have waited and wished for this for the last, say, four years, I think one can wait just a tad longer until something stable and functional is released in due time...