VistaLover

Yes, I have verified that on a Win7SP1 64-bit laptop, where the same Serpent 52.9.0 32-bit build will have no problem playing back Twitter gifs with Win7's native WMF h264 decoder , whereas on Vista it would barf, as already posted... FWIW, Vista's WMF implementation (which requires SP2 to be present) is notably inferior to the one present in Win7; Win7 OEM was released with native h264 decoding support present, while on Vista it was implemented via post-SP2 Microsoft updates (and, I suspect, as best as Vista's then internals would allow... ).

... But I think you neglected to include in your custom changes: - Hidden preference to toggle addon version in addon manager which did land in the 20191123 builds of both Serpent 52 & New Moon 28 (PR authored by @Mathwiz )

Fellow Vista Home Premium SP2 32-bit user here ; on Vista, there seems to be a conflict/incompatibility between the native WMF h264 decoder (not present in XP) and certain gif formats, like the Twitter ones ; the ffmpeg-based h264 decoder present inside @roytam1 's custom-patched ffvpx library is still capable of rendering those gifs though, but has a lower value (in the preferred order) and is thus not used by default on Vista (while it is on XP, which lacks WMF); so, your issue is Vista specific... To view such Twitter gifs on Vista, temporarily set (in about:config) media.wmf.enabled to false and reload the twitter page; the gif should play now (because ffvpx takes over...) NB: I'd advise against making this a permanent pref change, as the WMF framework is better suited for media playback integration with UXP browsers under Vista (e.g., if your gfx card supports hardware (i.e. GPU) h264 decoding, it can make use of that, while ffvpx always uses software (i.e. CPU) decoding) ! Best regards

This was posted in the past (in the now closed original thread), but the official Mozilla langpack for FxESR 45.9.0 should do: https://ftp.mozilla.org/pub/firefox/releases/45.9.0esr/win32/xpi/de.xpi Install, restart browser, in about:config set general.useragent.locale;de, restart once more...

... And a nice find I stumbled upon just now (!) :

(Continuing, hopefully not for long , OT discussion about media playback capabilities of Otter Browser under XP/Vista) Many thanks for that link, which also uncovered the rest of the official Otter Browser Forum for me ; thing is, I only keep Otter here as an oddity item, not investing serious time in educating myself about its peculiarities and overall development ... I did read, though, the whole linked thread and have to say the real money is on the very last post there, by member maxxproff : It's in fact that huge (77.4 MB) DLL alone that gives the "-xp" (QT 5.6.2 based) Otter builds h264 (and VP8) decoding support; so this is a big improvement compared to the stock XP/Vista builds But that support alone will only allow for the reproduction of standalone MP4 files (local files or ones streamed via progressive download, such as 360p & 720p avc1+aac youtube encodes); however, as also pointed out in that post, with this solution there's still no support for MSE, despite setting about:config => QtWebKitBackend => EnableMediaSource : Yes So, MP4 files streamed over MPEG-DASH , like youtube's higher resolution (e.g. 1080p+) encodes (separate video/audio streams), won't be played back (actually, they don't appear as options at all...). This is made clear using the (now archived) YouTube HTML5 test page: Inside the blue-lined rectangle, functions enabled by the standalone libgstlibav.dll file... That fix has been really appreciated though, many thanks indeed! Cheers!

It's there for me, under "Connected Domains": Adding and enabling the filter list you linked to, blocks it (green colour turns to red) ! Screenshot of the uB0 logger with the tracking script blocked: I've opened that actual script inside a private tab and it's indeed nasty...

Otter v1.0.81[weekly300-xp] uses OpenSSL 1.0.2o, so that fact alone empowers it with support for a plethora of cipher suites (and TLS versions); not only a great number of cipher suites are already enabled by default, you can also add additional ones (out of the many OpenSSL supports): However, the xp (and Vista) compatible package (compiled with QT 5.6.2) uses gstreamer as the media backend; because of patented decoders (h264, aac) licence issues, the distributed binaries lack support for h264 decoding and this is a deal-breaker for me in today's media-rich web; the Win7+ packages are compiled with a higher QT version (5.13.1, requires Win7+) which comes with support for the native WMF framework (present in Vista+), enabling access to OS provided patented decoders; to cut a long story short, Otter v1.0.81 on XP/Vista will load fine cote.co.uk, but won't play the background video... The reason Opera 36/XP doesn't, also, play the background video is quite similar; the browser (unlike Chrome 49) doesn't come bundled with a h264 decoder, the OS has to provide that through WMF; but, as you know already, XP lacks WMF . FTR, Opera 36/VistaSP2 does load the site and does play the background video... Best regards

... When Vista SP2 reached the end of Extended Support on April 2017, the EoS'd OS at the time was left with only TLS 1.0 native support; the same was true for XP SP3 when it reached its ES end in 2014. Both these OSes can be upgraded to have native TLS 1.1+1.2 support using M$ official updates originally prepared for sibling OSes that had/have "End of Extended Support" dates way past the ones for the OSes in question... XP users can get TLS 1.2 support by installing updates for (NT5.1) Embedded POSReady 2009 (which reached EoS earlier this year) and Vista users can do the same by installing update(s) for (NT6.0) Windows Server 2008, to reach EoS next January (2020); for Vista, you might read this ; I'm afraid XP & Vista (and soon Win7) are no longer regarded as new systems; yes, they are newer compared to Win98 but otherwise "deprecated" by today's standards... Regards

@Dave-H : A check of "cote.co.uk" on SSL Labs Server test page https://www.ssllabs.com/ssltest/analyze.html?d=www.cote.co.uk confirms what has already been reported; just scroll down to the Handshake Simulation section: ... and see that IE11 only works on Win10 ! As to why, I think I have some clues: I couldn't help noticing how that server was configured: Only TLS 1.2 version is enabled, and only 3 cipher suites for that protocol version: Now, IE11 uses the cipher suites available in the OS's "Microsoft Schannel Provider" library; however, different Windows versions support different sets of cipher suites: https://docs.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel If one checks the available suites on Win7: https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-7 one cannot find any of the three cipher suites needed for connection to the server in question... OTOH, checking the available cipher suites on Win10 v1903: https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v1903 one can find the first preferred (by the server) cipher suite, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, as available, hence the TLS 1.2 handshake succeeds and the site loads in IE11/Win10! However, I don't have answers as to why Chrome 49/WinXP[SP3] also succeeds, unless, of course, ProxyHTTPSProxy is used with it... BTW, Chrome 49 does open the site successfully here, Vista SP2 32-bit, but I do have installed WinServer 2008 updates that enable TLS 1.2 support: Perhaps Chrome 49 has native support for that cipher suite and only uses the Windows Store for certificates, NOT using Schannel like IE does (I'm sorry, my Chrome related knowledge is limited, have only been a Firefox fan from the start!) ... Cheers

... However MS states that the offending function ("GetLogicalProcessorInformation") IS supported under Windows XP SP3: https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getlogicalprocessorinformation#requirements EDIT: @jaclaz : I was notified of your newer post just when I was about to submit this ; submitting regardless, hope you don't mind... EDIT2: It seems the app is compiled using QT Framework 5.6.2; 5.6 is the last version to be XP+Vista compatible, so it appears they knowingly made the effort to keep compatibility with those "legacy" OSes (the same is true for SMPlayer, a GUI for mplayer/mpv - but I think the dev there had different reasons for sticking to QT5.6 ...) ...

@apreese16 https://www.howtogeek.com/126430/htg-explains-what-is-the-windows-page-file-and-should-you-disable-it/

... and, as stated, a "minimal" installation of it: ...which suggests some OS components have been omitted...

Are you talking about MiniTool Partition Wizard 11 Free (file pw11-free.exe) ? This doesn't seem to be the case with pw11-free.exe :

... 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...