VistaLover

... It is my understanding that even the SHA-2 only code-signed installers (standard/debug) will install and function OK on a fully updated XP SP3/Vista SP2 system, it's just a minor irritation though that the OS+user can't verify the validity of the code signature...

... And for my XP friends here, since the officially provided installer (.exe) won't launch under Windows XP SP3, I hereby provide the official (but hidden behind a mandatory Oracle account ) link to the extractable jre-8u251-windows-i586.tar.gz archive/package that XP users can use to manually update their JRE8 installation: (32-bit:) https://javadl.oracle.com/webapps/download/AutoDL?BundleId=242059_3d5a2bb8f8d4428bbe94aed7ec7ae784

Adobe Flash Player plugin has been updated recently to v32.0.0.363 (replaces previous version 32.0.0.344); here comes the bad news: if one composes and uses the "standard" link template for the SHA-1 only code-signed official distribution packages (installers), http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.363/install_flash_player_ax.exe http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.363/install_flash_player.exe http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.363/install_flash_player_ppapi.exe then the downloaded binaries are, sadly, ONLY SHA-2 code-signed ; people following me in the Vista subforums would already know that I've installed a relevant Windows Server 2008 M$ update that enables reading/validating SHA-2 code signatures (but which, at the same time, "upgrades" Vista SP2 to build 6003, denying it completely from M$ update servers ), so that is the reason I can produce the following screenshot (for NPAPI v32.0.0.363): For history books, the below (now non-working) links for v32.0.0.344 were indeed able to fetch SHA-1 only signed installers: http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.344/install_flash_player_ax.exe http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.344/install_flash_player.exe http://fpdownload.adobe.com/get/flashplayer/pdc/32.0.0.344/install_flash_player_ppapi.exe (for NPAPI v32.0.0.344): @Bersaglio , can you confirm and are you able to offer alternate links to SHA-1 Adobe Flash Player packages?

@FantasyAcquiesce Thanks for your info... BUT... The latest version available on the linked site is 3.0.205.0 and yes, min Windows version compatible is Windows Vista (32-bit and 64-bit) - no surprise then that the client wouldn't run under XP... The downloaded standalone installer has a digital SHA1 signature of May 20th 2018 ; even worse, when the installer is extracted/installed, the browser has a buildID of 20150421120931 (i.e. April 21st 2015); in this case, New Moon is just a generic UNBRANDED fork name, not to be confused with @roytam1's unbranded builds... The BlackHawk browser build is based on Pale Moon 25 (platform is Gecko 25.3.0), so extremely outdated security/features-wise ; IMHO, that browser deserves an entry inside digital history books, not installed in one's Vista machine today... (OT: I honestly hope you're well - stay safe )

... This isn't quite accurate... An SSL labs server test, https://www.ssllabs.com/ssltest/analyze.html?d=ffmpeg.zeranoe.com reveals that the hostname resolves to two IPv6 and two IPv4 addresses (4 in total); selecting, for example, the first IPv4 one (104.24.105.227) : https://www.ssllabs.com/ssltest/analyze.html?d=ffmpeg.zeranoe.com&s=104.24.105.227 ... one can see that the site supports even TLS 1.0 (which is why it is capped with a B mark): However, you are right in saying that the site can't be accessed on XP with browsers that rely on the OS crypto libraries (like IE8/Chrome 49), and this is reflected on the test site as well: ------------------------------------------------------------------ Handshake Simulation Chrome 49 / XP SP3 Server sent fatal alert: handshake_failure IE 8 / XP No FS No SNI Server sent fatal alert: handshake_failure ------------------------------------------------------------------ ... however this fact is purely because: === This site works only in browsers with SNI support === SNI requires Vista at minimum; FWIW, I can load the Zeranoe forums site with IE9 on my Vista SP2 laptop... OT: I hope you're all well and staying safe, away from Covid-19 infection...

... To make this even more clear, CAA is NOT a collection of extensions, but simply a database, a list if you will, of legacy Firefox extensions scraped off AMO before Mozilla removed them from sight... The actual XPI files are hosted externally, in a hosting space (CDN) kindly provided for free by the Waterfox community (so please, do not abuse their bandwidth ); as you can imagine, the actual total size of the hosted XPIs amounts to many GBs... The CAA .xpi file itself, when installed, expands to an SQLite database of ca. 62 MB (to be found in ".\<profilefolder>\ca-archive").

@PPeti66x : You are being served the mobile version of GitHub... And the reason is that recent versions of New Moon 27 have a default SSUAO for GitHub of the following kind: general.useragent.override.github.com;Mozilla/5.0 (Mobile; Nokia_8110_4G; rv:48.0) Gecko/48.0 Firefox/48.0 KAIOS/2.5 i.e. mobile Firefox 48.0; I can't pinpoint the exact commit this was introduced, nor the reasoning behind its implementation; the https://github.com/roytam1/palemoon27/commits/master repo is very hard to browse/troubleshoot, as each commit is the sum of many squashed commits, involving the patching of too many individual code files... All I can assume is that was just a decision made upstream, i.e. by rmottola/ArcticFox. You can change that SSUAO to report a desktop browser, e.g. general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.0; rv:52.9) Gecko/20100101 Goanna/3.4 Firefox/52.9 PaleMoon/27.9.7 and that setting will get you back the desktop version of GitHub : Be advised though that both the mobile and desktop versions of GitHub are severely crippled/broken on NM27, because the platform/browser engine does not have adequate support for the Javascript version/features that GitHub requires as a bare minimum... FTR, I composed this post in latest NM27 and it has serious issues/bugs with the MSFN post editor, too... Actually, hadn't used NM27 for more than a year, alternating between NM28 and Serpent 52 ... ... C'mon, surely you can do better than that...

FTR: https://forum.palemoon.org/viewtopic.php?p=185808#p185808 @Alex654 and others feeling the urge to do that: PLEASE, NEVER TAKE ISSUES SPECIFIC TO NEW MOON/SERPENT to the official Moonchild forums! What you'll only achieve is to cause additional aggravation to the devs (especially to a certain Mr. Tobin) who, as most people here know already, harbour animosity towards the forks for "old" OSes... The thing is, I have fought hard in these threads in the past so that the New Moon 28 fork doesn't deviate significantly from the official Pale Moon code with respect to language strings, in order to keep parity with the official PM language packs which, I stress, are only being produced to target (and be fully compatible with) official Pale Moon! The fact that we were able to install and use the official LPs (to be more precise, the ones compatible with NM28 were the ones offered by @JustOff to target the official unstable Pale Moon builds) was just a side bonus, these packs do contain the official branding and I'm sure the MCP devs weren't/aren't happy we were using them to begin with... Due to certain coding decisions taken by our maintainer ( @roytam1 ), the custom UXP fork branch he's compiling NM28 off has distanced itself from upstream (which already uses a different build system, i.e. official unstable PM29 is now being compiled from a dedicated PM repo, with official UXP as a module), so that the LPs currently produced by @JustOff are simply not compatible with New Moon; from past discussions, it is my belief that we are not to see any updated LPs for New Moon coming from @roytam1 himself, so I guess it's a task to be undertaken by the user community...

... But OP confirmed this in ... which, to me, sounds like OP used an installation medium with integrated SP2...

Additional links: 1. From a browser with a UA advertising XP/Vista (NT<= 6.0) : https://browser.yandex.com/download?full=1 2, Using any UA: http://download.cdn.yandex.net/browser/_xp_builds/int/en/Yandex.exe http://download.cdn.yandex.net/browser/update/17_4_1_1026_2644_w_s_m/yandex.exe FTR, the downloaded file has a digital signature (it's dual signed, i.e. both SHA1+SHA256) dating from September 24th 2017 (not Mar. 2017, as stated...) The above behaviour is by design; only per user installations (not global) are allowed by the installer: https://yandex.com/support/browser/about/install.html That means the global installation directory (%PROGRAMFILES%) is not used, only the current Windows account's HOME directory (%APPDATA%) is... Their documentation describes what, to me at least, appears to be a fairly standard way: Anyone following my posts, especially in this thread, will surely know I'm an avid fan of Portable software installations, especially in the PAF format; this "love-affair" with portables began a long time ago, when I had a very small C: drive and I thus had to try/install various apps in my second, external USB, drive (then D:); also, having both the program's core files and settings in the same directory becomes very handy when you want to "re-install" or carry the fully customised program to a different host... While currently I have ample disk space in my "OS" drive, the habit of portable installs has endured all these years... However, in the case of Yandex Browser 17.6, the portable "package" is the ONLY way, because the proper YB 17.6.0.1633 installer is very hard to come across, plus it's been (artificially) blocked from launching under Vista (and, as I recall, I did mention this fact somewhere previously in this very thread... ); so, the available 17.4 installer being only capable of "per user" installations was not the reason I had chosen "portable" in this case... Best regards

Huge thanks, indeed

@roytam1 : I want to raise your awareness to upstream UXP issue #1446 : Only allow extension class add-ons to use the dual-GUID system Now, Moonchild has tagged this as "App: Pale Moon", which means, for the time being at least, they'll only be enforcing this on Pale Moon... In NM28 I'm currently using a native Full Theme (Dark Moon 2.4.1), but it's possible other members here are using Complete Themes made for Firefox originally (so these will stop loading if/when #1446 is merged into NM28)... However, on Serpent 52 I'm using, since very long ago, an "originally-for-Fx" Complete Theme, FT DeepDark (v14.3+slight local modifications); the following two upstream commits Only allow extension add-on types for Firefox compat mode Only match extension add-on types for target applications were pushed into the upstream master UXP branch (i.e. platform-wide), which, IIUC, is "mirrored" in your own master UXP branch and then selectively merged into your custom UXP branch (the one used to produce the UXP forks); IOW, I harbour some slight trepidation that, if due diligence is not paid here, suddenly my FTDD complete theme will cease working in a soon to be released Serpent 52.9.0 build... Thanks for your consideration on this matter, huge gratitude in fact for keeping your projects "going" despite adverse real life conditions ... Take the best of care!

I've noticed this yesterday (Feb 15th 2020), using several different browsers, being logged-in/logged out and with my content blocker (on which MSFN ads are allowed ) OFF - I've cleared browser cache, restarted browser, all to no avail ; actual flags are missing for me...

With a total sum of 3GB of RAM, I'd definitely opt for a 32-bit flavour of Vista, especially in the case of an under-resourced netbook; and, as advised already, I wouldn't go past Home Premium on that machine (the only thing I'm missing in HP is the Group Policy Editor ... ). Just my 2 cents...

... Old news now, of course, but here's the list of WS2008SP2 ESU Feb 2020 updates, as posted by the vendor themselves: https://docs.microsoft.com/en-us/windows/release-information/windows-message-center#388

You need to add the Iceape-UXP specific application id inside the extension's install.rdf file: <!-- Iceape-UXP --> <em:targetApplication> <Description> <em:id>{9184b6fe-4a5c-484d-8b4b-efbfccbfb514}</em:id> <em:minVersion>27.0</em:minVersion> <em:maxVersion>52.*</em:maxVersion> </Description> </em:targetApplication> Hyperbola provide an Iceape-UXP compatible fork of uB0-legacy, which they call uBlock Origin-Libre; unfortunately, it's only officially installed via their Package Manager; you can have a look at their (limited) set of extensions below: https://wiki.hyperbola.info/doku.php?id=en:project:iceweasel-uxp_addons As a workaround to the missing Package Manager, you can navigate to https://www.hyperbola.info/packages/community/any/iceweasel-uxp-ublock-origin-legacy/ and download the package via the "Download From Mirror" link; that will get you file iceweasel-uxp-ublock-origin-legacy-1.16.4.16-1-any.pkg.tar.xz Extract repeatedly with 7-zip and inside the ".\usr\lib\iceweasel-uxp\browser\extensions\" directory you'll find the needed .XPI file; install that manually on the iceape-uxp suite via drag-n-drop...

... Actually, my dear Italian friend , the last XP compatible version should be 6.047 ; you can fetch that from vendor's own "archived versions" repository: https://toolslib.net/downloads/viewdownload/1-adwcleaner/files/ => https://toolslib.net/downloads/finish/1-adwcleaner/851/ BTW, have you tried any higher versions on XP with .NET FW 4.0 installed? ... Of course, any Vista discussion is OT for this thread, but I had made several AdwCleaner tests on my own, reported below: FWIW, v7.4.2 launches fine here: ... But, binaries of the 8.x.x branch just silently fail to launch when double-clicked ; inspection with Dependency Walker does not reveal any vital missing function calls (only one in a delay-load dependent module), plus the executable's PE header has a Sub System version of 6.0, so I assume its devs have implemented a hard block on Vista in another way ; perhaps it requires a version of .NET FW > 4.6.1 ? In any case, though officially unsupported, v7.4.2 appears to be the last running on Vista...

Yes, the Tycho (platform) codebase was forked off Mozilla ESR 38 but (official) PM27, IIRC, comes with a native SSUAO for youtube; I don't have it handy ATM, but I believe it is advertising itself as Fx 42 to YT; low enough to make YT nag about it... I am delighted to report that YB 17.6.0.1633 (built on Chromium 58.0.3029.1633) gets served, as of this writing, the most recent YT iteration, i.e. Material Design with Polymer version 2 layout: (if you place the cursor on a video thumbnail, you get a video preview) Thus, I expect YB to work on YT for the foreseeable future; BTW, I composed this post using that very browser, so expect details of our exchange to reach President Putin's ears... (joking, of course... ) Best regards

My guess would be Update your browser for the best viewing experience. Actual link is (no surprises there) : https://www.youtube.com/supported_browsers Except for Firefox Browser (which is simply a Chrome wannabe ), all three other alternatives are Chromium based...

That's because FxESR 52 gets by default the (supported) Polymer v1 (Pm1) layout; only versions of Firefox older than 44 (Fx <=43) are being served the Classic layout, the one to be retired in March; if you use a UAO on FxESR 52 to spoof it as Fx 43, you'll get the older layout with the deprecation infobar: BTW, Firefox (Quantum) versions newer than 62 (63 =< Fx) are being served the newer Polymer v2 (Pm2) layout, which, on the outside, looks a lot like Pm1, but on the inside it's quite a different beast... FxESR 52 and the UXP browsers don't currently support it; of course FxESR 52 isn't maintained anymore, but MCP devs are already making talk about "upgrading" UXP to support Pm2 in the coming months; Google have not yet indicated for how long they'll keep supporting Pm1 Pm1 is considerably more resource hungry compared to the out-going Classic style, and this fact alone will create problems for older browsers capable of handling Pm1 but which are installed on old hardware (which seems to be the case with many XP/Vista users here... ) Of course, the forced migration to Pm1 will disable many user YT customisations, in the forms of XUL extensions, userstyles, userscripts etc., which were initially targeting the Classic layout; sadly, it'll be game over for those older browsers (on, perhaps, even older OSes/hardware) that can't cope with Pm1 at all... Some relevant links: https://support.google.com/youtube/thread/27596769 https://www.reddit.com/r/youtube/comments/eyjy4i/misc_fd_youtube_is_removing_the_old_design_soon/ https://forum.palemoon.org/viewtopic.php?f=3&t=23566 Chrome 49 has adequate support for Pm1, so if OP wants to continue using it for YT past March 2020, OP must: Install the User Agent Switcher extension from GWS: https://chrome.google.com/webstore/detail/user-agent-switcher/kchfmpdcejfkipopnolndinkeoipnoia Set a "Permanent Spoof" for youtube.com domain (aka SSUAO) and pretend to be Firefox 60 (e.g. Mozilla/5.0 (Windows NT 6.3; rv:60.0) Gecko/20100101 Firefox/60.0); then, every time a YT URL is loaded, OP will get the supported Pm1 layout without any nags about an unsupported browser: However, that workaround will, sadly, come to an end when evil Google decide to remove Pm1, too (which can be anytime, I hazard a guess and predict some time towards the end of this year) .

Posting duplicate posts asking the same query won't get you any popularity points here, plus it's against forum rules... https://msfn.org/board/guidelines/ @dencorso , would you agree?

... Yes, Yandex 17.6 (Chromium 58.0.3029.1633) appears to still handle successfully most sites I throw at it; if you additionally enable in flags (browser://flags/) Experimental JavaScript (it was experimental at the time Chromium 58 was released, most of it has become standard nowadays): browser://flags/#enable-javascript-harmony you'll increase considerably its compatibility with today's web ; even latest GitHub appears to function as intended with that setting turned on! Well, I can certainly understand your privacy concerns, but I have opted to use the Russian repacked X-portable (WinPenPack format) version of 360EEv12 here: The Russian modder has removed most of the telemetry features phoning Beijing (and this has been confirmed by fellow MSFN members in the relevant thread) : As one would expect, it's quite superior to YB in page rendering and RAM consumption/management, plus has full TLS 1.3 (final) support (which YB 17.6 lacks; only supports a previous to final draft); but its main drawback is that although you can manually install extensions from GWS, the browser can't check GWS for extension updates automatically (that's because Google services in general are banned in China); one has to check for extension updates manually on the corresponding extension's GWS page, export settings (for the ones that come with such a feature), remove the old version, manually install the updated version and manually re-import its settings from the back up file... BTW, I have stayed at version 12.0.1012.0 (current is 12.0.1053.0) because that's the last one in which the native dark mode (chrome://flags/#enable-force-dark) works without issues... I now see you have edited out that part in your last post (it's still there, though, in the e-mail notification of the original post ), because at first I got the impression my TeamViewer dedicated post had simply gone totally unnoticed... All the best

I'm not a TV user, so I had missed this unfortunate development... I went earlier on the official site to fetch and archive an installer of the last Vista compatible TV version, where I found the following notice: https://community.teamviewer.com/t5/Knowledge-Base/Which-operating-systems-are-supported/ta-p/24141 Unfortunately, the latest version is v15 (15.2.2756 to be exact) and I have confirmed it doesn't launch under Vista (due to missing function calls in Vista's system files... ); so, the last Vista compatible version, v14.2.x, can't be used anymore with a free licence... But even if you pay for a commercial licence, there are limitations: Sunsetting active servicing of operating systems That previous link suggests going to https://www.teamviewer.com/en/download/previous-versions/ for a v14 download; v14.7.13736 is displayed there (???); I am using NM28 and my UA does advertise my Vista OS (NT 6.0); the link to the installer is https://download.teamviewer.com/download/version_14x/TeamViewer_Setup.exe Upon clicking that, it redirects to https://dl.teamviewer.com/download/version_14x/14.2.56673/TeamViewer_Setup.exe which suggests a v14.2.56673 is the last Vista compatible TV version; however, it is impossible for me to complete the download, the browser generates an error, the wording is "The page doesn't redirect correctly" (translated from Greek); what gives? The portable download link https://download.teamviewer.com/download/version_14x/TeamViewerPortable.zip simply fetches v14.7.13736, which I confirmed doesn't launch under Vista... ; at last, I was successful in fetching the portable version of TV v14.2.56673 via the following, manually composed, link: https://dl.teamviewer.com/download/version_14x/14.2.56673/TeamViewerPortable.zip ... and I confirmed v14.2.56673 (portable) does successfully launch here (be it only after a considerable while since the main executable is double-clicked): ... But, the installer of v14.2.56673 is still a no-go for me... ... And do you want to know how I ended up getting that one? By requesting version 14.2.8352 (!) ; yes, the link (manually composed): https://dl.teamviewer.com/download/version_14x/14.2.8352/TeamViewer_Setup.exe will fetch: How MAD has this world become?

@roytam1 : Admittedly, I'm not closely following development on your palemoon27 branch (NM27 builds are only occasionally used here for testing ), but could you be so kind as to let me know why the latest NM27 build has a native SSUAO for github.com that advertises it as a mobile phone? general.useragent.override.github.com;Mozilla/5.0 (Mobile; Nokia_8110_4G; rv:48.0) Gecko/48.0 Firefox/48.0 KAIOS/2.5

Can confirm, new build based on toolkit: restore ResetProfile.jsm to previous state, fix about:support (so, in reality, new archive is more properly described by the filename palemoon-27.9.7.win32-git-20200202-aafa3ce17-xpmod.7z) Many thanks for the swift fix, highly appreciated!