VistaLover

... But I did say I stopped updating manually at the end of October 2017; also, some previous 4.6.1 updates were not included in my "Snipping Tool" screengrab (I would need to scroll down and take a second one to include all installed in chronological order.) ...

@Blados, @artomberus The best approach on (manually) updating a (manual) install of .NET FW 4.6.1/4.6.2/4.7.0/4.7.1/4.7.2 on Vista SP2 is to have access to a Windows 7 machine, where the exact .NET FW version is manually installed; you should then let WU check for .NET FW related updates and selectively hide upgrades to a higher version, if it's not what you have on the Vista machine (e.g. I understand that on Win7, MS will offer to upgrade you to 4.7.2 (4.8 maybe?) if you've got a previous version installed). Install only the patches offered for the .NET FW version you're interested in, then head to Control Panel => Installed Updates (for .NET FW) and write down the KB numbers of these patches. Track them down in MUC and then proceed to manually install on the Vista machine! My sister has a Win7SP1 x64 laptop, where I "froze" .NET FW to v4.6.1 and, to make a long story short, that was how I was updating my own 4.6.1 install on Vista!

4.7.2 belongs to the 4.7 family of .NET FW versions, comprising 4.7.0, 4.7.1 and 4.7.2; of course, 4.7 family isn't supported on WS2008SP2 (NT 6.0) , so, presumably, Microsoft don't test produced patch files on 4.7.x installed on WS2008SP2... However, Win7 SP1 is supported; it just so happens that the update mechanism of 4.7.x on Win7SP1 is similar to the one of patching 4.6.x under WS2008SP2, so that is why what @WinClient5270 stated above is correct To illustrate: By visiting Microsoft Update Catalog, latest updates for 4.7.2 on Win7 SP1 include, e.g. 2019-05 Security and Quality Rollup for .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, and 4.7.2 for Windows 7 (KB 4495588) When you proceed to download, you are presented with file ndp46-kb4495588-x86_057aa7f4c87dcd7fbb4225e170a901a622b72ad7.exe Notice the ndp46-* prefix? This is exactly the same file you'd end up with if you wanted to fetch latest patch for 4.6 on WS2008SP2: 2019-05 Security and Quality Rollup for .NET Framework 4.6 for Windows Server 2008 SP2 (KB4495588) (Please also load and inspect https://www.catalog.update.microsoft.com/Search.aspx?q=KB4495588 ) On Win8+, the update mechanism of 4.7.x is different to both WS2008/Win7; there, the patches are being delivered in the form of "Windows" updates, i.e. .msu packages... 2019-05 Security and Quality Rollup for .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2 for Windows 8.1 (KB4495585) => windows8.1-kb4495585-x86_14b43821fa547611902f85baac67e8f013c40613.msu So, we should really thank Windows 7 in this case!

If it was file dotnet-hosting-2.2.5-win.exe that you downloaded (96.3 MiB), you shouldn't have used 7-zip to unpack, but more specialised applications like Bioruebe's Universal Extractor 2 Result of extraction: I personally feel there's no way this would work under Vista, I merely wanted to point out what else to try when 7-zip fails to yield desired results...

api-ms-win-core-console-l1-1-0.dll (the module that couldn't be found and caused System.IO.FileNotFoundException) is actually part of KB2999226, aka Windows 10 Universal C Runtime (Win10UCRT), which itself is a prerequisite for Microsoft Visual C++ 2015+ on Vista SP2. Please install latest redistributable for MSVC2019 found here: https://visualstudio.microsoft.com/downloads/ (scroll down all the way to "Other Tools and Frameworks", expand, "Microsoft Visual C++ Redistributable for Visual Studio 2019", download files for both 32-bit & 64-bit and install; Windows6.0-KB2999226-x86.msu is included and will be co-installed if not found in the system). The only way to be definitive about that is if you inspect executables (*.exe & *.dll) with Dependency Walker (please do so after you've installed MSVC2019)

@UCyborg: many thanks indeed for your very erudite comment , am always keen to learn new things...

On their site (you linked to) they state: Do you reckon 7's SP1 + PU are just for .NET FW 4.7.2 compatibility reasons?

Neither could I , but here is some more test material: ShadowSocks is an application very popular in China, because it can be used to connect to specialised servers outside of the GFW and thus circumvent regime implemented censorship ; the windows binary is built on .NET Framework 4.x.x; the last executable that could be launched under Vista SP2 with 4.6.1 (Final) installed is v3.3.4 all the way back from Oct 2016 ; any more recent version will throw an error: Unlike ShareX, Shadowsocks.exe does not come with a *.config file we can patch, you do have to have 4.6.2+ installed to make it launch! In their Wiki it's noted (in Chinese) that .NET FW 4.6.2 is the minimum version required, along with latest Visual C++ 2015 Redistributable; also in their wiki they suggest So I think shadowsocks should be a perfect "test-bed" application for correctly functioning .NET FW 4.6.2/4.7.2[4.8.0?] under Vista SP2... People here with Vista SP2 VMs, the challenge is open!

armagaddon-2.0 bug (and fix) has to do with SIGNED extensions; uBlock-firefox-legacy-1.16.4.10 (from GitHub) is an UNSIGNED extension; to install it on FxESR 52.9.0[1], one must first flip (in about:config) xpinstall.signatures.required to false, restart the browser and then attempt to install; to remove warnings generated by installed unsigned extensions, read previous post in this page...

... As it finally turned out, it is yet again another case of intentional/artificial block of Vista by M$ ; the blocking code lies somewhere inside the compiled .EXE setup, but it's obviously absent in the unpacked .MSI installer.I do wonder if it's still possible to install 4.6.2 Final by running the Setup.exe file (86.1KB) that exists inside the (unpacked) directory; an inspection with Resource Hacker reveals it does indeed support Vista in its manifest: <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> <application> <!-- Windows 10 --> <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" /> <!-- Windows 8.1 --> <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" /> <!-- Windows 8 --> <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" /> <!-- Windows 7 --> <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" /> <!-- Windows Vista --> <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" /> </application> </compatibility> I guess if that doesn't work, on a 32-bit platform one should run netfx_Full_x86.msi (in the unpacked directory); as mentioned by Osman, in the root of the unpacked setup one can see prerequisite windows updates for Win8 (KB3151804), Win8.1 (KB3151864) and Win10 (KB3151900), but, surprisingly, not for Win7 (and, of course, none for WinVista, which the package doesn't officially support) - in any case, it should be stressed that the (somewhat unorthodox) 4.6.2 install shouldn't be attempted on a Vista system which isn't fully updated (SP1+SP2+all subsequent updates at least until EoS on April 2017), just for good measure... All in all, a very positive outcome from a joint effort, started by @Osman Kovan and joyfully concluded by @WinClient5270! Cheers PS: I couldn't help noticing how a 59.1 MiB file (NDP462-KB3151800-x86-x64-AllOS-ENU.exe) blows up to more than 1.62 GiB (!) when expanded!

... Is there any specific reason you had not upgraded to the more secure 52.9.0esr version? 52.9.0esr is the last 52ESR build to have been officially released (and, of course, the last version of Firefox that would support XP/Vista), there shouldn't be any compatibility issues (extensions-wise or other) between what you now have (52.6.0esr) and the last of its breed, 52.9.0esr... Have you disabled application updates in Firefox? I was under the impression 52.6.0esr would auto-update to 52.9.0esr Best regards

You have (what I call) an "obsession" we've already witnessed in other threads to falsely report to all sites you're running Firefox 66, instead of adopting the default user agent of FirefoxESR 52.9.0[1] and only spoof that on sites broken in FxESR 52 (and I recollect @Mathwiz and possibly others advising you towards that direction ). Once again you fell prey to your "obsession"; the suitable "fix" you should install from AMO is found on https://addons.mozilla.org/el/firefox/addon/disabled-add-on-fix-52-56/ But if you pretend to be running Fx 66, AMO will think you are running Quantum (yes, Firefox 66.0 is of the Quantum "variety") and forbid you access to what it thinks is an incompatible extension! Please, for one last time, STOP this practice of adopting a global UA string of Fx 66.0 (sent to all sites) and return to the default value that comes with your actual browser; currently only few sites will nag you about Fx52 being outdated, use SSUAO just for these...

KB956250 was installed in my system through WU on June 23rd 2010; of course, Final 4.6.2 still refuses to install, as with the rest of Vista SP2 users From your findings, it looks that KB956250 is a prerequisite to 4.6.2 Preview under NT 6.0 (Vista+WS2008), but it isn't included anymore in the 4.6.2 Final setup, since that one has moved on to target NT 6.1+ İyi akşamlar

1.16.20 (probably installed from GitHub) is UNSIGNED; as such, it can only be installed while in Developer Mode and yes, stable Chrome branch will alert you about this at every browser (re-)launch You should have been stuck at the signed version 1.16.18 on Chrome 49; BTW, 1.16.18=1.16.20 for Chromium based browsers; please read following post: Export first your 1.16.20 settings to a file, then uninstall 1.16.20, manually install 1.16.18 (by dropping onto chrome://extensions) and then manually re-import your previous settings; have done this many times, it just WORKS!

I agree that the management of already installed Search Engines can be performed quite fine by New Moon's native functions/tools; using the extension I mentioned comes very handy in the cases one wants to add a rather obscure search engine not to be found on the official PM Search Plugins page that you linked to, or when a page does not provide an easy way to add its search among the browser's Search Engines set... E.g. with "Add to Search Bar" I can easily add our own forum's search utility, or BBC iPlayer's, etc : The extension itself appears to be using minimal resources: (via about:addons-memory, extension to be found on GitHub)

... Yes, that is indeed the case - it appears that all three 4.6.x flavours (4.6.0 [final], 4.6.1 [final], 4.6.2 [final]) are being patched by the same .exe files! I can only speculate, but, as feared, the 4.6.2 Preview has an internal version number different to the stable/final release of 4.6.2, which renders it not eligible for further 4.6.x patches (that is if the patch files check for some sort of version ID of the installed 4.6.x package); in fact, inspecting the setup files, one sees: 4.6.2 Preview setup: NDP462-KB3120735-x86-x64-AllOS-ENU.exe => File version 4.6.1532.0 4.6.2 (Final) setup: NDP462-KB3151800-x86-x64-AllOS-ENU.exe => File version 4.6.1590.0 Of course, the real puzzle here is what was actually changed by MS so that 4.6.1532.0 installs under Vista SP2, but 4.6.1590.0 doesn't ; is it just an artificial block for NT < 6.1 ? So, the prudent thing here is to stay on Final 4.6.1, for which compatible Security and Performance Updates are being rolled-out by MS and which can be manually downloaded (& installed) from their Update Catalog . Let me, once more, thank you immensely for your precious time spent conducting those tests for me (and, of course, other Vista users); I have a 12 year old low-end Vista laptop (and the OS has already started kicking the bucket last February ), no VM software installed (and my total RAM is only 3 GB), so no practical way I could test myself - I would also hate to lose 4.6.1 and all its manually applied updates for the sake of testing the 4.6.2 Preview - I hope you understand... )

... Yes, that is indeed true if you have 4.6.0 installed and you expect to receive updates via Windows Update With 4.6.1 (manually) installed, I have always found that the updates for 4.6 made for WS2008SP2 would still apply to 4.6.1, too: (around November 2017 I stopped manually patching my OS, but that's a different story... ) Yes, you shouldn't be trying to install a Win7 specific .NET FW 4.6.x update, but its WS2008SP2 counterpart; the actual "payload" should be the same; from Microsoft Update Catalog: 1. 2019-05 Security and Quality Rollup for .NET Framework 4.6 for Windows Server 2008 SP2 (KB4495588) => ndp46-kb4495588-x86_057aa7f4c87dcd7fbb4225e170a901a622b72ad7.exe vs. 2019-05 Security and Quality Rollup for .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2 for Windows 7 (KB4495588) => ndp46-kb4495588-x86_057aa7f4c87dcd7fbb4225e170a901a622b72ad7.exe 2. 2019-05 Security Only Update for .NET Framework 4.6 for Windows Server 2008 SP2 (KB4495587) => ndp46-kb4495587-x86_c4172ad5803a4e71ca948c751be9d339fed66ca3.exe vs. 2019-05 Security Only Update for .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2 for Windows 7 (KB4495587) => ndp46-kb4495587-x86_c4172ad5803a4e71ca948c751be9d339fed66ca3.exe Are you able to spot that the corresponding KB numbers are identical and that, when clicking the download button (a pop-up window appears with content to fetch), you are presented with identical .exe binaries for either W7/WS2008SP2 ? My gut feeling is (based on experience) that e.g. file "ndp46-kb4495587-x86_c4172ad5803a4e71ca948c751be9d339fed66ca3.exe" will apply successfully to a 4.6.1 32-bit install under Vista SP2 x86; when your spare time permits, can you please test this hypothesis in your Vista SP2 VM (I understand it's 64-bit, so perhaps you need 4.6.1 64-bit and the 64-bit equivalent of ndp46-kb4495587-*.exe) ??? If you indeed tried to apply "ndp46-kb4495588-x64_cd387e77d1f73443776c35dd9cfa8f5581b93277.exe" on a 4.6.2 Preview 64-bit installation and failed (as pictured), then my suspicions are confounded; the "Preview" can't be patched (but "Final" 4.6.1 should be)

The first Firefox Quantum version in the release (stable) channel was v57.0; 60.0esr was the first Quantum version in the ESR branch (update channel); latest ESR build is now 60.6.3esr, to be soon followed by 60.7.0esr (currently in the "candidates" stage) ...

According to this, latest version is v1.5 Rev 3c; sadly, I haven't been following very closely the progress of that project lately, but was under the impression it could only go as far as TLS 1.2; @heinoganda, would you be so kind as to verify that actual support for TLS 1.3 Final has been indeed achieved? Best wishes and congratulations for your efforts

... Actually, this statement is not entirely accurate; the site does indeed support TLS protocol versions down to even v1.0: https://www.ssllabs.com/ssltest/analyze.html?d=comedonchisciotte.org&s=104.24.109.160 However, adding TLS 1.2 protocol support to an OS (XP in this case) is one thing, but adding support for needed Cypher Suites to match that protocol is, sadly, another thing! If you inspect closely the supported cypher suites for even TLS 1.0 (natively supported in XP's IE8), you'll see that only Elliptic Curve (ECDHE) Suites are accepted by that site, but, unfortunately, ECC is NOT supported under Windows XP, thus the secure connection can't be established! Under Vista SP2, I have also enabled TLS 1.2 protocol in IE9 (via a set of MS updates - Server 2008 intended - and hacks similar to those available under XP) and there IE9 has no issues connecting with TLS 1.2: FWIW, it even connects with plain TLS 1.0 (when I manually disable 1.1 & 1.2): So, in this specific case, it's all about the OS, not the protocol only...

Remotely relevant, but in all three of New Moon 28, Serpent 52.9.0 and Serpent 55.0.0 I have installed the XUL extension Add to Search Bar: https://firefox.maltekraus.de/extensions/add-to-search-bar Last version 2.9 can be found inside CAA (caa:addon/add-to-search-bar)

... Official link to the Web installer: https://download.zonealarm.com/bin/free/1042_za/zafwSetupWeb_154_062_17802.exe (digitally signed on Sep 28th, 2018) However, I haven't tried an install myself to check whether the stub installer does indeed retrieve (from the web) all the needed v15.4.062.17802 files for a complete and working installation...

Thanks from me, also, for this nice find ; however: Like many of us Vista users, I have the stable release of .NET FW 4.6.1 (manually) installed (file NDP461-KB3102436-x86-x64-AllOS-ENU.exe); sadly, that one is not officially supported (last one to be is 4.6) and, as such, won't receive security+performance updates directly from MU. One has to hunt down those updates manually in Microsoft Catalog (or use @greenhillmaniac's MEGA repo) and then proceed to install manually... AIUI, 4.6.2, even in its Preview variety, is an in-place upgrade from 4.6.1, meaning that not only the base install of 4.6.1 would be overwritten, but all of its already installed updates would also be gone, once one installs 4.6.2 Preview; has someone of you verified that this is indeed the case? Furthermore, would the updates already released for the stable version of 4.6.2 (file NDP462-KB3151800-x86-x64-AllOS-ENU.exe) play nice (i.e. apply correctly) with the 4.6.2 Preview version installable under Vista SP2 ? Thanks in advance for any insight...

One can hide such remaining warnings (generated by UNSIGNED installed extensions) via CSS code . If you already have a userstyles manager installed (e.g. the XUL version of Stylish [2.0.7-2.1.1] or Stylem 2.2.4), create a new userstyle named "AOM -> Add-ons list: Supress "unverified" add-on warnings" with code: @-moz-document url-prefix(chrome://mozapps/content/extensions/extensions.xul), url-prefix(about:addons) { .warning { visibility: collapse !important; } } This should have an immediate effect; if you don't want to install a userstyle manager, then you can go the userChrome.css route: 1. Locate your profile directory (about:support => Application Basics => Profile Folder => open Folder) and create a text file with path "./chrome/userContent.css" ("./" means the root of your profile folder); the "chrome" subdir may or may not be already present; if not, create it yourself! 2. Open file userContent.css, paste the CSS code posted above and save the file, taking care not to have a ".txt" file extension after saving it. The effect of the CSS code should become apparent after a browser RESTART! In the event you have Classic Theme Restorer installed in FxESR 52, that extension already comes with a setting to hide AOM warnings...

... And despite all recent incidents involving Mr. Matt A. Tobin and Moonchild Productions in general, there still exist people who post in the official Pale Moon forums questions related to Feodor2's MyPal and @roytam1's New Moon forks: https://forum.palemoon.org/viewtopic.php?f=4&t=22110 These "people" are only doing a disservice to the XP and Vista communities benefiting from the continued existence of these forks and they must be stopped from continuing such an infantile and foolish behaviour; the only unwanted effect they'll cause is more aggravation for the MCP devs, more hostility towards the maintainers of the forks and their users! Who in his/her right mind would go to the official Pale Moon community (devs+users) forum and query about third-party "unsupported" forks running on OSes that the mere mention of their names would cause those people to throw a hissy fit? Please, anyone here with a PM forum account (I know several exist) contact that @DJboutit individual and try to talk some sense into him/her . We can't risk any additional animosity from the upstream devs !