VistaLover

Same here; IMHO, I don't think that would be cause for any breakage... I checked AniView specifically: Update checks are made via the CodeDead.UpdateManager.dll file; in https://github.com/CodeDead/AniView/commit/2e9cb99 it appears it is accessing the following URI: https://codedead.com/Software/AniView/update.xml That one correctly loads in Serpent 52.9.0 through TLS v1.2: <Update> <MajorVersion>1</MajorVersion> <MinorVersion>5</MinorVersion> <BuildVersion>3</BuildVersion> <RevisionVersion>0</RevisionVersion> <UpdateUrl>https://codedead.com/Software/AniView/AV_setup.exe</UpdateUrl> <InfoUrl>https://codedead.com/?p=2217</InfoUrl> <UpdateInfo> Version 1.5.3 is now available! Please click the download button to download this version. </UpdateInfo> </Update> ... but DOESN'T LOAD in IE9 (TLS v1.2 enabled) https://www.ssllabs.com/ssltest/analyze.html?d=codedead.com&s=185.94.230.248&latest shows that the server is configured to ONLY connect through TLS v1.2 with only 4 cipher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 128 ... NONE of which are supported in IE9 "CodeDead.UpdateManager.dll" loads system network+crypto resources to access that URI (dependency walker reveals it loads, among many others, crypt32.dll, wininet.dll, secure32.dll, cryptui.dll, ieui.dll, ncrypt.dll, bcrypt.dll), so it appears it can't establish the secure connection that way and aborts... As per my analysis above. at least AniView.exe+CodeDead.UpdateManager.dll require just TLS v1.2; as for more testing, I'd be curious to know whether its "Update Check" feature works OK with .NET FW 4.8 on Win7+; if not, the developer should be made aware... Best regards

Well, I know you posted that app as a test for correctly installed .NET FW 4.8, but that same app can be launched with only .NET FW 4.6.1 installed; just download the portable version, patch file AniView.exe.config (L8-L10) to read <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1"/> </startup> and voila: However, what doesn't work with .NET FW 4.6.1 is the "Check for updates" feature (and thus, I suspect, also the "Automatically check for updates" one...) : Can you confirm update checks work as intended with .NET FW 4.8 force-installed?

... Yes, thank you .... Actually, the last working web archive capture of the original page is from last May 5th 2019: https://web.archive.org/web/20190505022505/https://www.quirksmode.org/html5/tests/video.html ================= EDIT (09/12/2019): As pointed out in a following post by @msfntor, it appears that "web.archive.org" have not captured the link to the last video (Ogg/Theora HTML5 test) in a reliable fashion ; however, that last test should be of little importance now, as almost no-one uploads these days video encoded with the Theora encoder (which is indeed a shame, as the encoder is open source and free); besides, Mozilla based browsers have had native support for Theora since long ago (it's bundled with the browser) ... Should you insist to verify Theora (in OGG container) support, the previous-to-last "web.archive.com" capture (Apr 26th 2019) of the original page has that test in working condition: https://web.archive.org/web/20190426003407/http://www.quirksmode.org:80/html5/tests/video.html ================= The test clips were removed (by the page owner) sometime after that date, at the request of his ISP, 'cause they were eating up huge chunks of bandwidth... Sadly, with a working capture available, this bandwidth consumption is now transferred over to web.archive.org (so I'd be "easy" on them... ) .

... This was addressed before in these threads - youtube (read Google) have themselves disabled the checking functionality on that page, in early autumn of this year ; to them, it's redundant now, since all the latest versions of the browsers they endorse returned all 6 blue checks... They DON'T CARE about older versions of browsers run on older, unsupported, Windows OSes... Workaround: 1. Use the last archived edition of the page (it actually works even now!) YouTube HTML5 Video Player http://web.archive.org/web/20190805082454/https://www.youtube.com/html5 2. Use an alternate checking service: Tek Eye HTML5 Video Test Page https://tekeye.uk/html/html5-video-test-page https://tekeye.uk/html/play-video-in-html5 http://demo.nimius.net/video_test/

... Unfortunately, this link currently only downloads a file sized a mere 32 bytes...

Tried it on Vista SP2 32-bit and yes, AERO works nicely ; so does the Task Manager; but every tab crashes when it tries to load ; I've seen this happen when I tried to run Google Chrome 51 (release) under Vista... My wholehearted wishes towards the success of this project (but it'd be a shame if it succeeds on XP but not on Vista... ) EDIT: Checking with dependency walker, it appears there are still missing function calls under Vista SP2; e.g. chrome_child.dll looks for function QueryUnbiasedInterruptTime in Vista's kernel32.dll system file; but that function requires Win7+'s version of kernel32.dll...

... This specific pref, which I DID NOT mention in my attempt to help you (once more...), is to enable you to install UNSIGNED extensions in your Firefox[Nightly]ESR v45.9.18 copy; FALSE is its default setting; so, when starting with a new/clean profile, there was nothing for you to set beforehand! In any case, that pref you brought up has nothing to do with language packs, which are unsigned! And, pray tell, what is the message Nightly (45.9.18esr) spawns? Installing a compatible language pack has nothing to do with having an SSE only processor; if you're able to launch and run the browser, then you should be able to install a langpack on it! The language pack, through the proper installation process, would end up in the "extensions" subfolder inside your nightly-45.9.18 profile folder (which, needless to say, should be writable by your user account); to locate your profile folder: about:support => Profilordner => Ordner anzeigen You've also asked how to tell which version of Firefox[Nightly]-45.9.18 is currently running in your system: simple answer is the latest you have installed in your system, if you only have that one (the latest) and only that one present in your system; don't keep various versions around, install the new one OVERWRITING the previous one! Sadly, the Uber Firefox popup doesn't notify about build ID (but this should be fixable in code, should @roytam1 indulge...) and only displays 45.9.18; but you can again use "about:support" to have an indication of the build ID; the latest available compile, file "firefox-45.9.18-20191123-a1b817dab-win32-sse.7z", has a build ID=20191122161113 (this number is actually a timestamp in ISO format => Nov 22nd 2019, 16:11:13), so its "complete" version would be 45.9.18 (32-bit) (2019-11-22): As for a German language pack for @roytam1's Firefox 45.9.18 (SSE-only compatible) fork, the screenshots already posted are a testament to my original guide to you... I can assure you that the de.xpi file I linked to previously is FULLY compatible and installable in a new/clean profile of the browser, where the only extension installed is uBlock0-legacy 1.16.4.11: I couldn't begin to imagine why it won't install in your case... What is consistent with your many other reported issues in these forums is that your OS/system is fundamentally borked... Adding to whatever issues at the OS level (hardware, permissions, etc.), you probably also have corrupted browser profiles (possibly due to launching/mixing the same profile with different browser versions, due to incompatible extensions, God knows what...), so, though I genuinely wish to assist you, it's becoming quite hard to do... If you can download the de.xpi file in another browser/system, try opening about:addons in your Nightly-45.9.18 browser and drag-and-drop it there; it should install (most certainly in a clean profile)... Zuss

You need to install the Adobe Primetime CDM. As posted in the past, since my old Intel Core 2 Duo processor (Merom) does support the SSE2 instructions set, I've not had the curiosity to try Firefox (Nightly) 45.9.x on this laptop, happily using the UXP forks, rarely Serpent 55.0.0. But, from memory, I think your quoted suggestion regarding RoyTam1's Firefox 45.9.18 under Windows XP is flawed... 1. EME support in the Mozilla Firefox browser in the form of the Adobe Primetime CDM first materialised in Firefox 38.0; the CDM targeted Windows only OSes and was only visible from Vista SP2 onwards ; in a later Firefox version (unsure exactly which ), it was made available to Windows XP, too; but the makers, Adobe, didn't want to support APCDM for DRM purposes under XP, especially since the initial implementation of it, v15, had issues on that OS; the Mozilla team couldn't make their minds up whether to keep the CDM on XP or not: they kept un-hiding and then hiding it again for a certain period (), especially when the next iteration of it (v17 - v16 was only 64-bit) was offered by Adobe (with lesser issues on XP): Unhide Adobe GMP on Windows XP https://bugzilla.mozilla.org/show_bug.cgi?id=1234099 Make Adobe GMP available to Windows XP users in Firefox 45 and later https://bugzilla.mozilla.org/show_bug.cgi?id=1234100 GMP crash or garbled HE-AAC audio when playing MP4 decoded using Adobe's GMP https://bugzilla.mozilla.org/show_bug.cgi?id=1236756 Hide Adobe GMP on Windows XP in Firefox 46 and 47. https://bugzilla.mozilla.org/show_bug.cgi?id=1265928 On supported OSes, the CDM was automatically downloaded and installed in Fx <=46.0; in v47.0-51.0, in new profiles, it was only downloaded and installed on demand, when visiting a media site that asked for it (although previous installations of the CDM in existing "dirty" profiles, put there under Fx < 47.0, remained unaffected). Support was officially disabled by Mozilla in Firefox v52.0 for all WinOSes, because, by then, the Audio-Video media industry had completely moved over to (Google acquired) Widevine CDM for enforcing DRM on copyrighted content (the WVCDM first appeared in Firefox v47.0 and is visible on Vista SP2+) ; in Fx 52.0/ESR 52.x.x, the APCDM would no longer be downloaded on demand in a new profile, previous installations of it get disabled; but the underlying support code was still left intact; that code was finally completely removed in Fx v53.0 (compatible with Win7+). At least on Vista (SP2), FxESR 45.9.1 downloads and installs APCDM v15 automatically: 2. From a previous exchange with Roy in these forums, it was made known to me that to get proper h264/aac decoding support on that fork under XP, needed for HTML5 embedded MP4 video, you'll have to download and place inside the browser's main installation folder (not its profile) the LAV filters DLLs that were made available previously to get the same feature for the New Moon 27.x.x/Tycho fork: @roytam1 : Post #1 in the original thread is now locked, so probably you can't edit that yourself now (nor can I properly quote the above excerpt ); perhaps a mod can, or you could add that FxESR 45.9.x specific bit on post #1 of this second (continuation) thread ? Thanks! Sadly, even with the above decoders installed, it's not definite Twitter clips will play OK; they use MPEG-DASH and/or HLS streams, which require MSE support in the browser; I'm not sure how mature is Fx45's MSE implementation for those vids to work...

... I don't want to derail this thread, but I recently became aware of the following extended article: Mozilla - Devil Incarnate It's certainly an eye opener for those that have little to do with Mozilla internals, most certainly a recommended read... Having been a Firefox Nightly tester (from versions 27.0a1 all the way to 46.0a1, then briefly from versions 51.0a1 to 53.0a1=EoS for Vista SP2 ), having been a subscriber on both Bugzilla and the Nightly Testers mailing list, I can assure you the attitude exhibited by most Mozilla devs towards anyone in the user base not condoning their "devine" decisions is pretty accurately detailed in the linked article... E.g., I, with several other Vista users, tried - in vain - to persuade them not to put Vista in the same boat as XP and, hopefully, extend Vista support further, past Fx 52 (up-to-version 54.0 could've been easy), but was met with a brick wall - their pretenses were that Vista was too much of a burden to support resource-wise and they insisted I switch to Linux; and that was at a time (circa end of 2016) when Firefox users on Linux were 1/20th of the Vista users... I recall I persevered and tested the whole 53.0a1 development cycle on my Vista machine many days after they made everything in their power to block 53.0a1 on Vista; when the installers blocked the OS, I switched to the "zip" packages and continued telling them that their - then - current code remains Vista compatible and that they were wrong to drop Vista support so soon - they were really mad and unsure as to how I was able to pull this through, until another user pointed to them (!) that the standalone executables (firefox.exe) would launch on NT6.0; then they quickly patched that by raising subsystem version to 6.1 in the EXE's PE header; but I used PE_patch (or similar tools) to undo their artificial block and set it back to 6.0; they went livid when I posted with a Nightly 54.0a1 version running on Vista SP2: ... But eventually they started using their new shiny toy, Rust programming language, which, when compiled, only targets Win7+, thus my 54.0a1 testing experiments ended abruptly... In fairness, very few code authors like it when their coding decisions are being challenged by the user base; I've witnessed this in many instances and this is certainly true with Moonchild Productions team, too; simply browse their official forum and GitHub tracker, where any "questioning" voice (outside their narrow circle of devs) is quickly muffled (more politely by Moonchild himself, brutally by you know whom...) But in the end, if I had to choose between a Google product and a Mozilla one, the lesser of two evils is the obvious choice...

The latest pre-release language packs targeting the Pale Moon unstable channel (at v28.8.0a1 atm) have been uploaded just minutes ago: https://github.com/JustOff/pale-moon-localization/releases/tag/28.8.0_RC1 They should be natively compatible with New Moon 28.8.0a1 (i.e. without having to modify install.rdf file) !

I would advise against this setting for those combinations of Windows OSes (Vista SP2 and up) and GPUs where hardware video (h264) decoding is actually possible and the default; disabling HVD delegates h264 decoding to the CPU, which may have (depending on the CPU) a significant performance toll (especially on high res videos) ... Additionally, I'm not quite sure whether the above "media." pref has any actual bearing on XP (where HVD via WMF is not possible) ...

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 :