VistaLover

The exact URI to that script is https://game314425.konggames.com/gamez/0031/4425/live/Build/UnityLoader.js I downloaded it locally on disk and probed it with an editor ; I couldn't find "Disabled by lack of compiler support", but did find the original warning/error: "Your browser does not support WebAssembly." Looking closer at your Web Console output, it appears the message is generated by the browser's asm.js module, when it tried to compile js code fed to it by the UnityLoader.js script ; BTW, many thanks @UCyborg for your most helpful contribution, as always : You might've mentioned it previously in these forums, but it didn't dawn on me that that was the case... I am running Vista SP2 32-bit and my 2007 era Intel Core 2 Duo is SSE2 capable; so using the "-xpmod" variety of Serpent-52.9.0-win32... By the looks of it, you should be running the "-xpmod-ia32" build, derived from the "ia32" branch of Roytam1's UXP fork: https://github.com/roytam1/UXP/commits/ia32 TBH, I don't follow closely the development of that branch, only that of the custom branch (produces NM28+St52)... @UCyborg wrote that WASM expects at least SSE2 instructions set , so there's your answer... @roytam1 : Perhaps it could be a good idea to disable WASM and LOCK the related prefs (inside about:config) in your ia32 builds, so as not to create false expectations by the users of those builds on their pretty old processors... Just throwing this out there for consideration... As posted, I first tried the site with a pristine St52 profile, and it did ask permission to use Flash; Flash is used to deliver ads in the embedded player, just before the game itself loads (when it does... ).

I thought Basilisk/Serpent supports that, huh?! Latest St52 has buildID=20200814013442; WASM has been indeed supported since long ago, even MozillaESR 52.6.0, the initial fork-point of UXP, came with native support... Whether that native support is ON/OFF by default is a different matter, though... MozillaESR 52.6.0 had all native WASM support pref'ed OFF by default; in latest St52, the behaviour is determined by following two commits: [Basilisk] Issue MoonchildProductions/UXP#1611 - Use platform default for WASM https://github.com/roytam1/UXP/commit/95c5a64 Issue #1611 - Enable WASM by default but only enable jit when 64bit https://github.com/roytam1/UXP/commit/ed0edf6 Indeed, when I launch latest 32-bit build in a NEW/CLEAN profile, this is what I get: i.e. WASM is ON, but baseline just-in-time (jit) is OFF; if that isn't the case in your set-up, then something altered the default settings, either a (security?) configuration imposed by an extension or you did it yourself (directly in about:config, using a user.js file, etc) in the past, possibly following online advice, and forgot about it... FWIW, visiting the linked URL in the above CLEAN profile, I get no warning of the kind you reported; the site does require Adobe Flash though, and it took a considerable amount of waiting for the game to fully load ; but it did eventually: OTOH, on my very old/DIRTY profile, with many extensions (some of which of the WebExtension format), many userscripts (in GM-for-PM), many userstyles (in Stylem + Stylus), uB0-legacy with many filter lists, the game never loads fully , because of async OOM errors: ... so YMMV even with WASM turned back ON...

I tried in Serpent 52 2020-7-31 and ... (redacted for brevity) But Config Descriptions does not show anything in "Source comment" column (the column is added). ... You assumed things and that's why it didn't work in the end as you had thought it would... My mention of that extension in my post (of more than a year ago) was only inside the context of Mozilla Firefox... The original Config Descriptions v1.0.1-signed.1-signed legacy extension DOES NOT support Serpent 52.9.0 (or official Basilisk, or Pale/New Moon for that matter...) Serpent 52.9.0 != FirefoxESR 52 Good News: 1. You can patch the extension yourself, so that it works in Serpent 52.9.0; in file bootstrap.js change L223-L224: - "resource:///defaults/" + prefsDir + "firefox.js", - "resource:///defaults/" + prefsDir + "firefox-branding.js", + "resource:///defaults/" + prefsDir + "basilisk.js", + "resource:///defaults/" + prefsDir + "basilisk-branding.js", While you're at it, you can also remove the META-INF directory, as Serpent does not observe extension signing... Proof: 2. The old Firefox extension has been ported to both Pale/New Moon + Basilisk/Serpent; just install from: https://addons.basilisk-browser.org/addon/config-comments/ ... A strong word of caution while you are toying with e10s in Serpent 52.9.0: what little supporting code is left there is very rudimentary/fragile/unreliable at best ; please back-up your Serpent profile, especially your sessionstore, prior to starting these experiments! Use a secondary/temporary profile for testing! I speak from BAD experience myself ; once you decide e10s isn't good enough for you or (my case) one of your most valued legacy extensions breaks under e10s and you, thus, have to return to single-process, it's highly probable your profile has been borked beyond repair (I had to begin from scratch, took me many hours to resume my original profile... I hadn't backed-up ; you really should ). MCP applications (and forks) have been developed as single-process, and that's it...

This is most excellent news @SIW2 , thanks for the confirmation! If only we could untangle @Dylan Cruz 's predicament...

... so without SHA-2 code-signing support (AFAIAA, this can't be implemented to OSes prior to Vista SP2 and in the latter, packages targeting originally WS2008SP2 are needed ), that method will become a moot one... I foresee that the next release will only be SHA-2 signed... ... And, as expected, that has just happened! The latest WSUSscn2.cab file (links are still the same as in my previous post) is ONLY SHA-2 signed and probably just useless under XP SP3: M$ is putting an end to everything pre-Win7, it seems...

... And just to be on the safe side, your previous screenshot from Aug 8th reported definition version 1.321.917.0; can you confirm you are now on a "higher" version after executing downloaded file mpam-fe.exe ? That would dispel any doubt that the manual update procedure for MSE is a viable way to keep using it under Vista SP2! I am genuinely sorry you can't get this to work, Dylan, but I'm also out of ideas what you should try next... Perhaps a visit to Windows Event Viewer could shed some light on this mystery... Just one final, probably just silly, question: Where did you get your copy of MSEInstall.exe v4.4.304.0 ? If it was within the context of some WinXP related thread, it's possible they linked the 32-bit variant, which would also install under Vista x64; verify you have MSE 64-bit installed (the 64-bit mpam-fe.exe is not able to update MSE 32-bit, and vice versa...). Ultimately, only you know how you've configured your Vista SP2 system (I read several times that GPOs were used - not available here in my Home Premium Edition ), so it's possible something went amiss there... Best regards

... Says a WinXP x64 user (going by your avatar), a minority inside the community of XP users (most of which have been on x86 all along) ... FWIW, when Vista OEM was first released (as a successor to WinXP x86) and pre-installed in new hardware (this was my case here ), it was practically always 32-bit (the lack of 64-bit Vista drivers was, of course, an issue at the time...)! Do you actually have figures to support that "long shot" argument, or are you simply going by MSFN posters in these threads? In any case, I am a 32-bit user myself and just being patient for @win32 to work his miracles ; all Vista users have waited and wished for this for the last, say, four years, I think one can wait just a tad longer until something stable and functional is released in due time...

What do you actually mean by that? Please download latest 64-bit mpam-fe.exe from the link below: https://go.microsoft.com/fwlink/?LinkID=121721&arch=x64 and save it in a location you have write access - please note down its actual file version; at the time of this writing, the latest file I can pull down is of v1.321.1115.0 (~ 107MB) Open then your MSE (x64) app and switch to the "Update" tab; note down the "Virus definition version" displayed (consult the screengrab uploaded by @SIW2 ). Then launch the previously downloaded mpam-fe.exe file (if you are under a limited User account, it may be necessary to run the file "as administrator"); it performs a SILENT install/update, do not expect a GUI to pop up... Give it 3 to 4 mins and revisit the "Update" tab of MSE; if the "Virus definition version" displayed now has been raised, compared to its previous value, then ALL IS FINE! You have successfully updated your MSE - repeat the process as needed...

... You must've gotten the wrong file, then... "mpas-fe.exe", whether 32 or 64-bit, is the standalone offline installer for updated anti-spyware (as) definitions; this file should only be used to manually update Windows Defender, Vista's native anti-spyware solution! "mpam-fe.exe", whether 32 or 64-bit, is the standalone offline installer for updated anti-spyware (as) + anti-malware (am) definitions; this file should only be used to manually update MSE (NB that when MSE is first installed, WD is being de-activated, so as not to conflict with MSE, which is both an anti-spyware and anti-malware solution!) You should probably only download from the (revamped) Microsoft Security Intelligence portal: https://www.microsoft.com/en-us/wdsi/defenderupdates Definitions for MSE there get updated 3-5 times during the course of 24h, but probably once a day is a sane frequency to manually update... You can read the Release Notes below: https://www.microsoft.com/en-us/wdsi/definitions/antimalware-definition-release-notes ... for latest as well as the previous 19 releases...

Hi @SIW2 When I first quickly read your post as an e-mai notification, I must have got it wrong , believing that the "is not working" bit meant that the whole app itself somehow stopped working ; this doesn't seem to be the case, most fortunately! The "it cannot install the definition update." bit I believed it to mean that the MANUALLY downloaded "offline" standalone defs updater, file mpam-fe.exe, ceased being able to be run/installed; that doesn't seem to be the case, either... By "It was fine yesterday" do you actually mean that before August 9th, 2020, MSE on your Vista SP2 install was able to (automatically/manually) fetch and install updated MSE definitions via Microsoft/Windows Update (that's what the big "Update" button does, it searches MU)? If affirmative, that would be the first such mention... On my own system, MS/WU quit fetching anything in mid-July of last year, and that included Windows Defender (WD) defs updates... Installing SHA-2 code-signing support to the system, alas, did not change things... You obviously have SHA-2 code-signing support installed, if you were able to get current (prior to Aug 9th) defs updates installed; but that support augments Vista's build number to 6.0.6003, and WU (when it worked) gave it the cold shoulder; that's why I'm quite sceptical of your report.. In any way, Error 0x80244019 when checking manually for defs updates in MSE is because dear M$ has shut down the WU infrastructure for Windows Vista ; this has been reported and detailed elsewhere in the MSFN forums... (EDIT: @Vistapocalypse posted while I was in the middle of composing this message...) The only solution is to download manually (e.g. once daily) the standalone updated definitions installer, mpam-fe.exe, from MS's security portal: https://www.microsoft.com/en-us/wdsi/defenderupdates and run that file to get you up to date... (Scroll down to the MSE section and select the bitness of installed MSE; download and run file mpam-fe.exe) Please report back, MSE on Vista SP2 shouldn't be dead yet! @Dylan Cruz , what is the situation there?

First thing I want to say is that I agree with @Vistapocalypse that your query ("How to get MSE running on XP SP3 in August 2020") does NOT belong in this thread... But having seen your failed attempts at this endeavour being spread at various places in the MSFN forums, let me "put you out of your misery" ( ) by offering you an abridged version of the story of MSE on XP (more detail can be found towards the last pages of the relevant thread linked to by @Vistapocalypse ) : 1. M$ continued to offer definition updates for MSE/WD on XP SP3 automatically through Windows Update for approximately two years after the OS was EoS'ed ! This fact alone upsets me tremendously to this day because we, Vista users, were not offered a single day of additional support by MS with regards to MSE! (the very last version of the app compatible with Vista contains a trigger/time-bomb that completely locks it after the OS EoS date! ) ; we're seeing the same thing again with EoS'ed Win7 SP1, which continues to receive MSE defs via WU! 2. When WU stopped offering MSE defs on XP, updated defs had to be manually downloaded from MS's Security Portal https://www.microsoft.com/en-us/wdsi/defenderupdates and applied by the user. Community enthusiasts and an esteemed member here in MSFN created automation for that procedure, so XP users were kept happy for a while longer... 3. Before I proceed with the story telling, let us focus on the offline defs file itself, mpam-fe.exe ; this is comprised of 6 constituents (you can extract the .exe with 7-zip) mpasbase.vdm mpasdlta.vdm mpavbase.vdm mpavdlta.vdm mpengine.dll MpSigStub.exe ALL these files are digitally code-signed by MS against MS root certificates and are verified by the OS that they haven't been tampered with before they are allowed to be applied/update MSE; any attempt to modify these files renders them invalid; but more of that later... .vdm files contain the actual antispyware/antivirus definitions, either in full (mpasbase.vdm, mpavbase.vdm) or delta (differential) formats (mpasdlta.vdm, mpavdlta.vdm); mpengine.dll is the most important constituent, i.e. the AV engine inside MSE which does get updated from time-to-time (and partly mitigates the fact that MSE itself hasn't been updated for quite a long while now... ) . 4. With a specific mpengine.dll update, M$ dropped a nuclear weapon on WinXP users of MSE, because the updated DLL contained new functions not found under XP, only under Vista+ (thankfully for us Vista users.. .) You can probe yourself the mpengine.dll file under XP with Dependency Walker... Hence, newer/updated versions of mpam-fe.exe would not succeed in installing, after that failure MSE would revert to the last working defs+engine. 5. MSE on XP was then stuck with a stale version of engine+definitions and, as time went on, started nagging about that fact... As with all signature-based antimalware solutions, the software itself becomes ineffective at protecting you from the ever evolving online threats... 6. A desperate solution was given some consideration, that is using the last compatible mpengine.dll file coupled with updated .vdm files (extracted from an updated version of mpam-fe.exe), but this was actually "a hole in the water" kind of thing, because updated .vdm files also demand an updated engine to work, i.e. both are interlinked! 7. So here we are now: MSE on XP dead and buried! 8. In the following months, M$ introduced further changes to the defs installer, mpam-fe.exe: 8a : The "Subsystem version" value in the PE header was raised to 6.0 (Vista+); this is the main reason you get the "is not a valid Win32 application" error on trying to launch it; lowering that SubSysVer to 5.1 (XP) will accomplish NOTHING, because of two reasons: one is the incompatibility of the mpengine.dll with XP's kernel, discussed in 4 above; the other reason is: 8b: Starting on the weekend of 19/20 Oct 2019, the standalone mpam-fe.exe file as well as all of its constituent files are ONLY being code-signed with a SHA-2 digest algorithm; no matter what you do, you can't get SHA-2 support under XP (and on Vista SP2 you must install select WS2008SP2 updates, as I'm sure you know by now...). Do you now see why this quest of yours is totally futile? Please, lay it to rest... As for some other points you made, M$ don't keep/offer an archive of deprecated mpam-fe.exe versions; in all honesty, what good would that be to anyone, security-wise? In a total hypothetic scenario, you would need first an XP Extended Kernel solution that will restore XP compatibility to mpengine.dll , plus backporting SHA-2 code-signing support to XP; I've seen stranger things happen, but you shouldn't hold your breath on both of these... For the benefit of the whole community, I have re-uploaded that at below link: http://s000.tinyupload.com/index.php?file_id=60954865039051356545 (included is a custom batch file; place the modified PE inside FixPEC folder and run .cmd; as with everything downloaded from the internet, please first scan with a reputed AV software; I can assure you the file that was uploaded by yours truly was safe...)

Please re-read my actual post! It pertains to insecure/weak cipher suites when ONLY TLS 1.0+1.1+1.2 are enabled! I'm sure you've been notified already of the fact I ONLY use the 32-bit variant of the OS, so no clue really... Try using the one I provided and go your way from there; I have faith in you! (FTR, a link to a M$ support article IS provided...)

For the more observant among you, you might've noticed that @Dylan Cruz 's last screengrab contains one additional IE9 cipher suite [TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13)] that is absent on my IE9 SSL Labs Client Test! In fact, on a TLS 1.0+1.1+1.2 enabled Vista SP2 machine, IE9 supports the below twelve variations of cipher suites: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Forward Secrecy 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Forward Secrecy 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Forward Secrecy 256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32) Forward Secrecy(2) 128 TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x38) Forward Secrecy(2) 256 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) WEAK 112 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112 TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE 128 TLS_RSA_WITH_RC4_128_MD5 (0x4) INSECURE 128 (2) Cannot be used for Forward Secrecy because they require DSA keys, which are effectively limited to 1024 bits. At some point, I had removed support for half of them, deemed to be extremely WEAK/insecure: Removed: *TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128 (TLS1.1) *TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256 (TLS1.1) *TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112 (TLS1.2) *TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) WEAK 112 *TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE 128 *TLS_RSA_WITH_RC4_128_MD5 (0x4) INSECURE 128 which currently leaves me with TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Forward Secrecy 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Forward Secrecy 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Forward Secrecy 256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32) Forward Secrecy(2) 128 TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x38) Forward Secrecy(2) 256 NB: The last two do not support FS, so I might remove them, too... PS: On my 32-bit system I used Disable_RSA_Ciphers_RC4-128-128_3DES-168.reg : Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\PKCS] "Enabled"=dword:00000000 A computer restart is needed before these changes take effect! Reference: https://support.microsoft.com/en-us/help/245030/how-to-restrict-the-use-of-certain-cryptographic-algorithms-and-protocols

The Protocol Support section of the SSL Client Test available in browserleaks.com also fails for me here in IE9 32-bit: ... while, at the same time, the Handshake section is displayed correctly: Perhaps they're using some CSS/JS code in the first failing section that the deprecated IE9 rendering engine can't cope with... (?) For IE9 specifically, you may want to use the SSL Labs Client Test, https://www.ssllabs.com/ssltest/viewMyClient.html :

WUMT v07.01.2020 supposedly only launches under Win10: (It doesn't on Vista SP2 32-bit here ... ) ... Which is exactly? FTR, I got my copy of Windows Update MiniTool v20.12.2016 from our Russian friends! https://forums.mydigitallife.net/

... That link also mentions the following: ... so without SHA-2 code-signing support (AFAIAA, this can't be implemented to OSes prior to Vista SP2 and in the latter, packages targeting originally WS2008SP2 are needed ), that method will become a moot one... For the time being, the latest cab downloadable via either http://go.microsoft.com/fwlink/?linkid=74689 http://download.windowsupdate.com/microsoftupdate/v6/wsusscan/wsusscn2.cab is dual-signed on July 14th 2020: so you might want to back it up... I foresee that the next release will only be SHA-2 signed...

@Eclectic : It's been already uploaded, but simply mis-linked http://o.rths.ml/gpc/files1.rt/iceape.win32-20200808-id-eed056673-ia-41157bf-uxp-b5762c6c2-xpmod.7z

... It looks as though my plea above has fallen on deaf ears : https://github.com/roytam1/UXP/commit/3bfc57422015a7f356b9b6a55f23561861b3553a https://github.com/roytam1/UXP/commit/15c137e0b0b9d1935d273a55e22f263f38cb606f @roytam1 , may I kindly ask why?

@roytam1 : Can you please NOT implement upstream issue #1628 https://github.com/MoonchildProductions/UXP/issues/1628 in your custom UXP branch? I don't know about New Moon 28, but in Serpent 52.9.0 we do still support WebExtensions installable from/updatable by AMO, and the use of a modified value for the extensions.update.background.url pref is a viable way to keep checking for WE updates (from AMO), while the standard extensions.update.url pref can be left pointing at the Basilisk extension repository (or, possibly, vice versa; point the main URL to AMO and the background one to addons.basilisk-browser.org...). FWIW, in my copy of Serpent 52.9.0 I have: extensions.update.background.url;https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=52.9&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% Thanks in advance, take good care!

Sadly, not the case anymore... OTOH, it does search Microsoft Update Catalog successfully and filters out 361 updates (mostly in .cab format); but the filter is probably windows6.0 (not Vista), so that number (361) includes a mixture of both Vista+WS2008 applicable files; if you sort the results by date, you'll find post VistaEOL files targeting (by default) WS2008SP2: It's not ideal hence, but still it could prove useful... On an OT note, the app's window is NOT resizable, which I consider a major faux-pas...

MS/W Update is also broken on Windows Vista SP2 (with or without SHA-2 code-signing support): I think this time it's for good... EDIT: @daniel_k just beat me to it...

It is now ca. 20:40 UTC, Aug 6th 2020, and Windows Update is again broken here, in Windows Vista SP2 32-bit ... When I opened the WU window I got: Notice that WU did last perform a successful check on Aug 6th 2020, 00:57 EEST (that was Aug 5th 21:57 UTC); as expected, the check had ended with a Windows is up to date message () ; when I click "Check for Updates", I end up with: i.e. no dice, but with a different Error Code this time (80244019) Something similar happens when I manually check Windows Defender for updated definitions: Normally, the manual check would return a "No updated definitions were found for Windows Defender" result (or something to that effect...), but now it quickly errors out like this: I think we can say, with a fair degree of certainty, that WU on Vista IS DEAD... Of course, there are various online articles pertaining to Windows Error 80244019 (or 0x80244019), e.g. https://blog.pcrisk.com/windows/12473-how-to-fix-widows-update-error-code-80244019 which states: but in this case I think it is both a "Windows Server problem" (M$ shut the door to it, took it down, etc. ) as well as due to "computer system and configuration" (we have the Vista OS, which M$ vehemently wants to swipe off the face of the Earth...). FWIW, I have WS2008 M$ updates installed that enable SHA-2 code-signing support: so I had, at least, expected that I would still be able to connect to the newer SHA-2 WU endpoints, though, of course, nothing would come down from there, as Vista 6.0.6003 is detected (not being proper Vista SP2 & not being proper WS2008 SP2) and fenced off... PS: KB4474419 is v4 ; please also notice that the last thing ever WU fetched on this machine (then at version 6.0.6002) was a WD def update, on July 6th 2019; after that date, nada ! EDIT:

... For the time being at least, ONLY Microsoft Download Center content will be affected: Microsoft Download Center != Microsoft Update Catalog The Windows XP communities had been preparing for a good while now for the (inevitable) event M$ busts the WU service on fresh XP (SP2/3) installations; I might be wrong, but I haven't witnessed (at least here in MSFN) a similar impetus for salvaging all Vista updates off of WU/MUC come to fruition...

... Considering that the title of that thread on the Windows XP subforum is "On decommissioning of update servers for 2000, XP, (and Vista?) as of July 2019" i.e. our beloved OS is inside parentheses and with a question mark, and given the, admittedly, low respect XP-diehards hold for Vista (), I would suggest a separate dedicated (pinned?) thread/post be posted in the main Vista subforum, wouldn't you agree @greenhillmaniac ? FWIW, a casual search on the Vista subforum has revealed an entry that hasn't (till now...) attracted much attention, Should be helpful for the duration Vista .msus are kept online in the catalog by evil M$... There's also another thread with a very promising title https://msfn.org/board/topic/179120-windows-vista-post-sp2-updates/ but, sadly , NOT the content one would expect going by that title... =========================================== Semi-OT: Vista SP2 reached its EoS without ever getting support for either TLS 1.2 nor SHA-2 code signing ; so I am inclined to believe that all Vista SP2 created MS updates were sha1 code-signed; in https://support.microsoft.com/en-us/help/4569557/windows-update-sha-1-based-endpoints-discontinued so what breaks WU for Vista SP2 is the secure connection negotiation to those WUS SHA-2 endpoints (CDNs); connections which, and this isn't said explicitly, have been probably updated to use TLS 1.2 ... I don't think MS will touch and re-sign with SHA-2 sigs existing WS2008SP2 sha1 update packages (and certainly not the Vista ones...); but we, Vista users, are extremely unlucky : While we can implement postEoS TLS 1.2 support, installing KB4474419 (even v1 with a digital sig of 16/04/2019) + KB4493730 will, as pointed out elsewhere by @Vistapocalypse , change the kernel version to 6.0.6003.205xx; while that is fine with WS2008SP2 and WU, the latter had been probably configured in a way to only serve Vista with a 6.0.6002.xxxxx kernel version... And no-one has found (yet?) a way to (cheat and) make Vista appear in the eyes of WU as WS2008... Another question that comes up is if the Vista MS updates were hosted on special "outdated (SHA-1) Windows Update service endpoints used only for older platforms" that are "now being discontinued", does that mean that the update packages themselves will cease being on line on WU servers? If so, any (theoretical) discussion about re-enabling connections to WU from Vista will be a moot one... ... As The Doors sang many decades ago:

... If you have upgraded past 32.0.0.371 (as I expect most have already), simply uninstalling the newer version and running a backed-up version of the 32.0.0.371 installer won't cut it Adobe, since long ago, have taken extra measures to hinder you from easily downgrading AFP; you have to first uninstall a current version with their special Uninstaller tool: that tool also gets updated with each new AFP release and can uninstall the current version of Flash as well as all preceding ones; but it can't uninstall a fresher AFP version than its own! https://helpx.adobe.com/flash-player/kb/uninstall-flash-player-windows.html (BTW, they have removed the check that was present after Flash Player information ; you get: Issue Flash Player installation was not successful. FWIW, version checks still exist on https://helpx.adobe.com/flash-player.html https://get.adobe.com/flashplayer/about/ ) https://helpx.adobe.com/flash-player/kb/uninstall-flash-player-windows.html#main_Download_the_Adobe_Flash_Player_uninstaller Permalink to the executable: https://fpdownload.macromedia.com/get/flashplayer/current/support/uninstall_flash_player.exe (currently at version 32.0.0.403)