VistaLover

... CPU-Z wasn't causing any issues for @sukistackhouse , though...

While there's no doubt the ESET v12.2.30.0 range of products had been officially released on Oct 2nd 2019, as per @Vistapocalypse's link above, the second link of his only gives access to 64-bit builds (under the "Early Access" category, submitted on Sep 27th 2019 ). OTOH, the official ESET support site, when searched for older versions of ESET products, https://support.eset.com/en/download-and-install-eset-offline-or-install-older-versions-of-eset-products lists as latest v12 version the 12.2.23.0 one, where indeed an official download link for the 32-bit flavour is present: E.g. the direct link for the Antivirus product is The plot thickens by the fact the downloaded installers don't display a v12 file version, but a v10 one (!), e.g. file eav_nt32.exe from above link is of version 10.9.73.0 (a fine mess, if you ask me...); so, if anyone has official (/unofficial?) links to the 32-bit setups of ESET v12.2.30.0 products, do share!

... Makes sense; the installer is of the Inno Setup v5.5.7 type; I downloaded and unpacked the installer for MTPW 11.5 Free via Universal Extractor 2, but I kept logs for the process; here's an excerpt: ... so I'm not sure what's awry in @sukistackhouse 's case... Might be the fact the installer is only SHA-2 code-signed (but then why would it work in @Dave-H 's XP system?) ...

Well, if you want a Chromium 69 based browser that is able to run on XP (and Vista!), we already have it by now: it's 360 Extreme Explorer by QiHoo (11 version recently updated to build 2251, i.e. v11.0.2251.0, official site here).

Sadly, this is indeed true ; Inno Setup v6.0.x+ supports Vista (NT6.0 ?) and upwards... For such cases, I can recommend two CLI tools that allow the extraction of "Inno Setup" installers without running them... The latest versions of innoextract (v1.8) and innounp (v0.49) can both extract up to v6.0.2 of IS; however, there are cases where these would not work (custom modifications of the official IS code and encrypted setups, configured to only install via a proper installation route); unfortunately, I have no way of knowing here (Vista SP2 32-bit) whether either CLI launch under XP... So, you could use the last XP compatible setup of the app (to install in XP), (hopefully) use the unpacker to extract the binaries from the updated version of the (incompatible) installer and then do an in situ replacement (with the proviso the updated binaries are still XP compatible)... Kind of what is done currently by XPers wanting to update Java RE 8 past 8u152... Personally, I'm using, when need be, innounp.exe with the following .cmd file:

@roytam1, @Mathwiz : How is that guaranteed to only touch Serpent 52's AOM (WebExtAM) but NOT NM28's AOM (TychoAM) ? On GitHub, in the PR's description, it says But NM does not need that pref, OR the functionality of that PR ... Also, Was that actually carefully examined (... I mean, the impact it has on the rest of the UXP-based apps) ? If I am to voice my personal humble opinion, this whole issue was rushed... Also, I'm a firm believer in the adage: "Don't fix it if it ain't broken!" and, as of this writing, NOTHING IS BROKEN (yet) ... To re-emphasise what I wrote in my previous posts: 1. Serpent 52.9.0/UXP and Serpent 55.0/Moebius both have a WebExAM type of AOM (St52 one derived from FxESR52, St55 one derived from Fx53.0a1 - probably not identical, but with very few differences between them...) 2. CTR v1.7.8 serves both above browsers perfectly, and AVN is offered as an option (OFF by default); also, CTR is incompatible with NM, so this leaves NM totally out of this discussion. 3. CTR v1.7.8 won't break in St52 in the future, unless @roytam1 explicitly touches Serpent's AOM code (not likely) 4. The upstream team have implemented the TychoAM on both Pale Moon and Basilisk; I'd speculate that they are unlikely to change TychoAM any further, but you can never really be sure with them... In the event they do change it, it's probable (from my viewpoint) that those changes won't be applicable to St52's WebExAM and would have to be reverted by Roy (but somehow applied selectively to NM28?)... The CTR v1.7.8.2019 branch was created by Aris with only classic Waterfox (Firefox 56 derived, but heavily forked...) and official Basilisk in mind, but after official Basilisk had changed to the TychoAM; if upstream implement changes to TychoAM, then CTR v1.7.8.2019 will have to accommodate, of course, but with code not relevant to Serpent's AOM... There's absolutely no compelling reason to install CTR v1.7.8.2019 on Serpent 52 currently (... just because you can is not a valid argument in my book )... 5. If, despite all the above, one insists on installing CTR v1.7.8.2019 in St52, then, as posted, to get the AVN feature back (present in CTR 1.7.8) just co-install either of Version Number in Add-ons Manager 1.10 (by magicp) caa:addon/addonvernumber/versions?page=1#version-1.10 Add-ons Manager - Version Number 1.4 (by Aris) caa:addon/amversionnumber/versions?page=1#version-1.4 NB: Latest v1.5 not compatible with Serpent (it installs, but BREAKS the AOM!) Of course, you can install either one without any version of CTR, if you JUST want the feature of AVN in St52's AOM... Thus, no need at present to touch the UXP platform code... In all fairness, MCP might in the future do something more radical in Basilisk's GUI, outside its TychoAM; if that big change lands in Serpent 52, then CTR 1.7.8 might get (partially) broken, and an update to a future version of 1.7.8.20xx might be needed; even then, CTR 1.7.8.20xx + one of the above extensions should suffice (but let's cross that bridge when we get to it...). In closing, I thought I'd detail my personal, lukewarm, view on that PR, since it was I that instigated this chain of events (after pointing out to @Mathwiz the existence of CTR versions past 1.7.7.2 and providing a link to the Wf PR that implemented AVN natively in its - Fx56 based - AOM) ; and to clear out any trace of a possible misunderstanding, this has nothing to do with the author of the PR; I highly appreciate all his efforts (coding and otherwise) and contributions offered to this great community here, not to mention the outstanding quality of his posts; plus, I sort of think of him as a good friend (especially since we've conversed in the past over PMs); so, @Mathwiz, nothing personal here Best regards!

... Unfortunately, it doesn't look like v12.2.23.0 installers are still available on the official site (truth be told, I did not search exhaustively... ); some third party sites may host them, though...

+1

Sadly, wrong filenames and links, that fetch last Saturday's builds...

I think I've found the exact reason for your recent Adobe Flash grief: privacy.resistFingerprinting in Firefox versions 50.0+ hides the contents of the navigator.plugins query, as per Bugzilla bug #1281963 ; that piece of JS code is used by sites to query various NPAPI plugins installed in the browser; when the official Adobe Flash Plugin test page uses that code but receives no results, it assumes the plugin is not installed/its installation is corrupted, hence the test fails to display plugin's version... It's all clear to me, now...

IMHO, the best thing for both @looking4awayout and the community consuming his efforts (UOC Patches & Enforcers) would be for him to change to git (or other Version Control System) and ultimately host his nice project on GitHub | GitLab and similar; then, automation would be the simplest of things... Just my 2 (euro)cents, of course...

Thanks for that! I've now bookmarked that third party Adobe Flash Test page, it's nice, desired even, to have an alternate test page, besides the Adobe official one...

... But all Mozilla devs live under the illusion that constantly aping Google Chrome (by removing native browser features and GUI customisations, delegating removed features to WEs instead) IS the way to deter Fx users from changing camp over to the competition, ie. Chrome! They've also assigned a "name" to this illusion, it's "Chrome parity" (!) But, as you say, the net result is quite the opposite...

Does the previous version of NPAPI Flash (32.0.0.270) work there? Of course, just a sample of two people (works for one, doesn't for the other) has no statistical value...

Cannot reproduce here: New clean profile of latest St55 (32-bit) on Vista SP2 x86 - NPAPI Adobe Flash properly installed systemwide:

If you want to hide from view various addon-related warnings inside Firefox's AOM, but don't wish to install CTR just for that function, then you can achieve the same using the following CSS code (inside a userstyle manager, like [legacy] Stylish 2.1.1 or Stylem, or inside your chrome\userChrome.css file in your browser profile) : @-moz-document url-prefix(chrome://mozapps/content/extensions/extensions.xul), url-prefix(about:addons) { .warning { visibility: collapse !important; } }

It's funny you mentioned SSUAO in Firefox, because today I became aware of another Mozilla change involving SSUAO support in Firefox... During the pre-Australis era, Mozilla had implemented native SSUAO support in Firefox (but I'm now too lazy to search and quote relevant Bugzilla bugs, it's 01:50 AM on Friday already here...), but then disabled it at some point (in Fx 25.0 ?) in desktop Firefox (but kept it in the mobile version) to, supposedly, gain a 7% speed increase in page loading times... The feature supporting module (UserAgentOverrides.jsm) was still kept in the source tree, but was not initialised in desktop Fx versions - hence the need of an extension (or additional code) to re-initialise it properly in Fx ESR 52.9.x In a previous MSFN post, I had searched Bugzilla and found that the SSUAO native feature was again restored in Fx 55.0, so from Fx 55.0+ one would not need extensions (legacy/WE) or JS code to apply SSUAOs in the browser... However, it appears that this native useful feature was again binned, starting with Firefox Browser (previously known as "Quantum") v71.0 (currently in the beta channel); this time, the original SSUAO supporting module (UserAgentOverrides.jsm) was completely excised, reason being "it was just old code", and those users wanting the removed functionality back should, once again, resort in using a dedicated (WE) addon... I was alerted by the following Mozillazine thread: http://forums.mozillazine.org/viewtopic.php?f=23&t=3055169 Bugzilla bug #1513574 : Remove UserAgentOverrides.jsm Once again, I beg to differ...

... Pardon me dear dencorso, but this was first made public on Jul 25th, 2017, more than two years ago already; so, most people browsing the web today should be sort of aware of the "crónica de una muerte anunciada" of Flash... On that same vein, there was recent discussion in the official Moonchild forums regarding Flash deprecation: https://forum.palemoon.org/viewtopic.php?f=3&t=23191 and Moonchild himself stated: But, come the end of 2020, NPAPI Adobe Flash won't be further patched for security; if MCP leave NPAPI Flash support in, as stated, then it's up to individual users to decide upon themselves if the inevitable security risks are really worth sticking to Flash in PM/Basilisk...

Sure you can: Do you, by any chance, have the sidebar displayed? (Because for me, when the sidebar is ON and the tab content width shrinks, the "</>" button disappears from the MSFN post editor's header... )

Of course, I can't deploy Waterfox in my Vista SP2 x86 laptop, but a targeted GitHub search reveals plenty : https://github.com/MrAlex94/Waterfox/pull/566 Thanks, but it's useless when it goes live (i.e. in your original post, I can only switch between "Hide contents" & "Reveal hidden contents" state, while the actual "content" is void); you need to document (pun intended!) this function by stating plainly the code to be used inside MSFN's post editor... EDIT: So it should look like this [spoiler] contents [/spoiler] which, when submitted, turns into Thanks

... But don't actually pay attention to what other people made the effort to post ... I did mention the reason in the part you chose to ignore: When MCP chose to remove WEs support from UXP and official Basilisk, it was a perfect chance for them to switch Basilisk's AOM (WebExAM) to the one present in Pale Moon (TychoAM) - PM's AOM dates from a pre-Australis era, has no support whatsoever for WEs and, as stated by Aris, displays addon version number by default. But it was decided (by popular demand here) to keep WEs support in Serpent 52.9.0, that meant staying with the original AOM shipped with UXP, pretty much the same as the one in FxESR 52, which supports WEs but doesn't display addon version number by default (an additional legacy extension is needed for that, e.g. CTR). In CTRv1.7.8.2019.xx.xx, Aris removed the .css code that enables the WebExAM to display addon version number (by selecting that option in CTR), since it's now a native feature of the TychoAM present in official Basilisk. Please read for more info: https://github.com/MoonchildProductions/UXP/commit/2cbbc5d https://github.com/Aris-t2/ClassicThemeRestorer/issues/402 https://github.com/Aris-t2/ClassicThemeRestorer/issues/408 Regards Addendum: Mozilla had intentionally removed the default display of AVN (addon version number) in the Australis[later WebExAM] AOM back in Firefox v40, when Bugzilla bug1161183 landed: https://bugzilla.mozilla.org/show_bug.cgi?id=1161183 This was again an unnecessary move, a type of "chop head to get rid of headache" approach, since the bug originally wasn't about AVN per se... https://bugzilla.mozilla.org/show_bug.cgi?id=1161183#c10 Remember, that was back in 2015 and already Mozilla devs had an opinion on what is of use in the browser GUI to most users, the rest were deemed to be few... I guess @roytam1 would have to revert that bug in both Serpent 52+55 (which use WebExAM) for CTRv1.7.8.2019 to be used as wished by @Mathwiz; but I don't think it's needed (now me sounding like a Mozilla dev...): if one is adamant on installing CTRv1.7.8.2019 in Serpent (which, I emphasise, is maintained with only official Basilisk in mind!), may co-install the following legacy extension: Version Number in Add-ons Manager 1.10 (by magicp), recoverable via CAA (caa:addon/addonvernumber) (Hope this time post is NOT ignored... )

... You are developing a habit lately of not closely reading my posts (just kidding, of course! ) : So, for both Serpent 52/55, CTR_v1.7.8 IT IS; CTR_v1.7.8.2019.10.27 applies to official Basilisk (on Win7+) and Classic Waterfox... Should be possible to read posted fixes/changes in https://github.com/Aris-t2/ClassicThemeRestorer/releases after Classic Theme Restorer 1.7.7.2 and including Classic Theme Restorer 1.7.8

Out of curiosity, I downloaded that MS update from the link in the KB article; that fetched file "excel2010-kb4484164-fullfile-x86-glb.exe", sized 36.1 MB (!). I can confirm this is only SHA-2 code-signed: You'll have to test file code-signing signatures in a fully updated Win7 system (or higher) or, in my case, in Vista SP2 with one of the WS2008SP2 updates which give the OS SHA-2 code-signing verification support... Trying the Windows Update Catalog link (mentioned in that same KB article), http://www.catalog.update.microsoft.com/Search.aspx?q=KB4484164 I ended up with a different file, excel-x-none_a5b150722cca4d6d9b062063747b02df0eaaaf51.cab (sized 19.8 MB); extracting it yields an excel-x-none.msp file (Windows Installer Patch, sized 40.3 MB), which is also only SHA-2 code-signed; notice that on the MUC, only a generic version is offered, regardless of the OS on which Office 2010 is installed ; perhaps the .exe and .msp files check OS version when launched, but it didn't occur to M$ that XP+Vista don't support SHA-2 code-signatures; there was a specific update on Vista (KB2763674) that allowed for .exe file execution even in the case the .exe was only SHA-2 signed, I guess a similar one might exist in XP (as part of the POSReady ones?) ... The deal breaker here is that Windows Update on both XP and Vista was never patched to deliver updates signed with only sha-2 code signatures - for WS2008SP2, such an update does exist, but when that's installed on Vista, it changes the build number of Vista to 6.0.6003 - but that cuts off Vista completely from WU servers , because they were only configured to serve Vista 6.0.6002 builds; it emerges that WU servers are intelligent enough to tell apart Vista 6.0.6003 (blocked) from WS2008 6.0.6003 (supported); so, starting with Nov 2019 (and for the remaining updates till Oct 2020), users of Office 2010 SP2 on XP/Vista should manually install applicable updates from either MS Download Center/MUC... ( ... and you thought M$ would screw Office 2010 only on XP, by sending incompatible mso.dll files... )

... I was under the impression Disney+ launched initially only in the US, Canada and The Netherlands... https://www.cnet.com/news/disney-plus-streaming-service-launch-dares-prices-shows-movies-marvel-star-wars-pixar/ Aren't you currently in Poland?

If they're using DRM (with no Silverlight NPAPI fallback), then 1. Any version of Pale Moon (official 27.9.4 runs on Vista, official 28.x.x doesn't) or New Moon don't have any support for EME, DRM and the WidevineCDM needed to decrypt the DRM'ed streams. 2. If you're actually using the Serpent 52.9.0 fork, able to run on Vista, then I have seriously bad news to tell you: while St52 does support EME/DRM, the version of WidevineCDM it is compatible with is 1.4.9.1088; that version was revoked by Widevine licence servers (owned by Google) on Aug 13th, 2019. There is a task underway by a Moonchild Productions developer to port support to latest official Basilisk for currently supported WidevineCDM v4.10.1440.19; this task is currently stalling due to real life issues affecting that developer; even if/when that attempt reaches fruition, it is a moot point for the Serpent fork on Vista; new WidevineCDM dlls contain functions (actually, only one: TryAcquireSRWLockExclusive, Win7+) not compatible with Vista's kernel32.dll system file; as WidevineCDM is proprietary closed source code and Google don't support the CDM on Vista, there's practically 0 chance DRM services requiring WV will ever work again on Vista If Disney+ use DRM with WV, then, if you can, try Firefox Quantum 60.9.0/68.2.0 (with WV v4.10.1440.19) on a supported OS (Win7+); or the latest Chrome there; as I can't try D+ myself, I speculate your predicament is DRM related; if they don't employ DRM - highly unlikely - then some other member here (in the US, CA or NL) might throw some light... PS: If you don't grasp some terminology in this post, Google is your friend (actually, in the above WV context, your foe... ). Regards