VistaLover

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)

... Actually, at the time of this writing, DIRECT links from Adobe STILL work, if you know beforehand the correct filename for the .ZIP file: https://fpdownload.macromedia.com/pub/flashplayer/installers/archive/fp_32.0.0.371_archive.zip Surely, that won't last for long...

... Well, that was quick of them : five whole months before actual deprecation... Perhaps that expedited removal was a knee-jerk reaction on their part, caused by recently increased batch-downloading traffic on the hosting CDN: https://forum.palemoon.org/viewtopic.php?p=193860#p193860 https://web.archive.org/web/20200630185339/https://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html ... however, expect these web archive snapshots to be hunted down by Adobe, as they do not allow redistribution of their closed-source material...

... Does also work in Serpent 52.9.0/Serpent 55.0.0 ; should also work in FirefoxESR 52.9.x, though haven't checked there, TBH...

You are welcome, but I'm not young myself... Each new day for me probably means many thousands of brain neurons dead, never to be replaced again (because, if you didn't know already, brain cells are the ONLY type of human cells that don't multiply/regenerate, only the number of connections between them can grow,,,). That is precisely the case ; SSL Labs / Server Test https://www.ssllabs.com/ssltest/analyze.html?d=winhelp2002.mvps.org caps this site as B, because it only uses TLS_ECDHE_RSA_WITH_AES cipher suites, now deemed weak: (... while, at the same time, still supporting TLS 1.0/1.1). Stay safe/healthy caro amico, the second wave of the Covid-19 pandemic has started in the Balkans/Southern Europe (with Greece, luckily, still at 30-40 daily cases of infection) ...

@roytam1 : Website issue/ bug report in latest New Moon 28 offering : Unfortunately, during the latest days, imgur.com have permanently thrust upon us their new, uglier, resource-heavier, mobile-device-targeting, interface, especially while being in their Upload section: After a successful image upload, you are presented with something like: When you click the Get share links button (to get access to "forum-type" link), a Share Options popup successfully emerges: The Copy Link green buttons do work, however, once finished, you can't dismiss the Share Options popup, because the X sign on the top right of it is unresponsive Actually, to get rid of that popup, you have to click on a page point outside of the popup but below its top, which, to say the least, is non-intuitive... <rant>Grrr... modern page layouts, designed for youngsters on smart phones with touch screens... Good ol' desktop computers are dying a horrible death these days... </rant>

... For fear that my heavily modified, old, NM28 profile would interfere, I started from scratch by downloading a fresh copy of latest NM28 32-bit (buildID 20200724223135) and a new, pristine, profile was created, on which I only imported a previous sessionstore.js file. Once launched, 1. I only installed (from GitHub) uBlock0_1.16.4.24.firefox-legacy.xpi 2. The MVPS filter list isn't enabled by default ; I selected it in the dashboard and applied changes; all went along as expected 3. I clicked the "clock" button at the end of the list entry, as expected the orange triangle sign took its place: 4. I pushed the Update Now button in the top of the tab, the list updated OK: 5. As you asked, I then deselected the MVPS list and applied changes 6. NM28 was restarted; once relaunched, I enabled anew aforementioned list 7. Clicking the Update Now button works as expected for said list here : Here are the loaded/updated contents of the list (inside uB0 itself): ... and, as said already, here is the secure connection result to the filter list itself, via browser: It is my understanding that uB0-legacy uses NM28's libraries to perform connections to HTTPS URIs, so me being on Vista SP2 vs you being on XP SP3 shouldn't really matter (?) ... Possibly something configured in your highly secured setup blocks the needed connection(s) for the list to update itself

... Both secure URIs load fine here under New Moon 28: https://winhelp2002.mvps.org/hosts.txt https://winhelp2002.mvps.org/ ... and the list can be properly (manually) updated in the third-party filters tab of the dashboard:

The last WidevineCDM version that was Vista SP2 compatible was 4_10_1196_0 ; that version was deprecated by Widevine licence servers last August 2019; newer versions, like the currently sanctioned 4_10_1440_18, 4_10_1582_1, 4_10_1582_2 & 4_10_1610_0, have been compiled and optimised by Google (the owners of WV) to target Win7+ Up until Aug 13th 2019, I was able to use the Spotify Web Player in 360 Extreme Explorer v12, until v4_10_1196_0 could no longer acquire decryption licences... The newer Widevine DLLs have a missing function in my Vista SP2 32-bit: If the Extended Kernel satisfies that missing function, then web services requiring the WV CDM should be usable in a Chrome-type browser, which comes with bundled patented decoders; Firefox, for the reasons I outlined earlier, won't be a choice... FWIW, all this ExtdKernel talk here is wayyyy beyond my level of expertise and, since I'm on 32-bit Home Premium install, will remain for me just a reading topic of high interest... (hopefully, in the not so distant future, a pre-compiled "installer"/"package" will be made available for simple Vista lovers, although I understand the redistribution limitations that'll come with such an endeavour...) Best wishes!

Vista SP2's WMF patented decoders (h264/aac), which are installed via the Platform Update Supplement (PUS, KB2117917), have filenames (H.264 decoder is in mfh264dec.dll, the AAC decoder is in mfheaacdec.dll) different to the respective patented decoders already present in Win7 OEM; starting from Firefox 53.0a1, the Mozilla devs have completely removed any support for Vista's WMF decoders, so while e.g. Firefox Quantum 68 may launch under Vista SP2 64-bit with this Extended Kernel (which simply satisfies kernel functions missing in vanilla Vista SP2), it is not instructed in code to search for mfh264dec.dll / mfheaacdec.dll; it does try to locate decoders present in Win7+ (since it properly targets those OSes), but, of course, fails... The only way to tackle this serious shortcoming is if you recompile from source, having first reverted those changesets responsible for disabling Vista's WMF decoders... Related Bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1324183 (and my relevant comment https://bugzilla.mozilla.org/show_bug.cgi?id=1324183#c15 which, needless to say, caused a stir with those damn developers...)

When I navigate to https://www.azul.com/downloads/zulu-community/?version=java-8-lts&os=windows&architecture=x86-32-bit&package=jre (filters selected were Java Version: Java 8 (LTS) Operating System: Windows Architecture: x86 32-bit Java Package: JRE), I am informed that the minimum system requirements are Windows (Server) 2008R2; are you implying one can install and successfully use that package (zulu8.46.0.19-ca-jre8.0.252-win_i686.msi) in XP/Vista 32-bit?

This is to be expected and already reported elsewhere: Nothing can be done about that, unless recent ECMAScript 6 javascript features are backported to NM27...

I can confirm: => Works as expected, though, in "classic" style...

... That's good to know... I have not ever been myself a user of ABL or other members of the AB family of content blockers, last thing I remember reading was how much more resource-greedy they were compared to uB0 (and RAM/CPU consumption should always be a consideration on those old hardware setups where NM27-sse is being deployed...). Resources-usage aside, the crux of the matter here is the following question: Does current ABL address successfully the very issues/reasons that forced uB0 to drop PM27 support? As detailed in the previously linked GitHub PR comment, uB0-legacy now needs ES6 support in the browser itself to tackle the removal of certain classes of unwanted content ; does ABL handle such content in a different way? If not, then existing users of uB0-legacy 1.16.4.21 in NM27 should probably stay put at that version (sadly no longer updating ) and face some random/occasional breakage in their ad-removal... It'd be like Chrome 49 users on XP/Vista, who are now confined in using uB0 v1.16.18 for good... Unless something new crops up?

... which, sadly, removes support for Pale Moon 27 based forks, like @roytam1's New Moon 27.x.x (whose sse builds are very popular with our members running pre-SSE2 CPUs): https://github.com/gorhill/uBlock-for-firefox-legacy/pull/239#issuecomment-651090892 https://github.com/gorhill/uBlock-for-firefox-legacy/blob/3524cbc34b30d9555eb7e9089aa4a5ea91465741/platform/firefox/install.rdf#L47-L54 https://github.com/gorhill/uBlock-for-firefox-legacy/commit/990daae