Leaderboard

Finally got the time to create the much requested Update Repository for Vista. I've collected these updates a year ago, but only recently took the time to put them on my Mega account and organize them. It has roughly the same format as my post-EOL repositories, with x86 and amd64 versions. A few highlight points: Most updates come in ".cab" format, because at the time it was easier to manage bulk installations in this format (I was trying to update offline images) Includes hotfixes not distributed through Windows Update. These were collected through a mix of the now defunct MS Hotfix service and the website "hotfixshare". There's some interesting fixes in there. While most of the updates are language agnostic, some are specific to the language I use, Portuguese of Portugal (like the IE9 installer). If you'd like to provide a version for your language, please contact me. To install a ".cab" format update, just run the following command: start /w pkgmgr /ip /m:<path to updates> /s:<temp path for extraction> /l:<path for log files> /norestart To bulk install updates, I usually run the following set of commands: forfiles /p <path to update folder> /m *.cab /c "cmd /c mkdir @fname" forfiles /p <path to update folder> /m *.cab /c "cmd /c pkgmgr /ip /m:@file /s:@fname /norestart" The first command creates a folder for each individual update and the second one installs each update and extracts onto each created folder. Here's a practical example. Say, I have all of the updates from the repository located in my Downloads folder inside my user profile. In this case, I want to install every update in the "General" folder. I'd use the commands above like so: forfiles /p "C:\Users\greenhillmaniac\Downloads\General" /m *.cab /c "cmd /c mkdir @fname" forfiles /p "C:\Users\greenhillmaniac\Downloads\General" /m *.cab /c "cmd /c pkgmgr /ip /m:@file /s:@fname /norestart" I'd recommend you install no more than 200 updates at a time. This can also be used to create an updated Vista ISO for later use (tutorial coming soon™) Anyway, here's the link for the repository

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rths.ml/basilisk/basilisk52-g4.6.win32-git-20200808-57e81f0-uxp-b5762c6c2-xpmod.7z Win64 https://o.rths.ml/basilisk/basilisk52-g4.6.win64-git-20200808-57e81f0-uxp-b5762c6c2-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rths.ml/basilisk/basilisk52-g4.6.win32-git-20200808-57e81f0-uxp-b5762c6c2-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rths.ml/palemoon/palemoon-28.10.1a1.win32-git-20200808-5f05a0799-uxp-b5762c6c2-xpmod.7z Win64 https://o.rths.ml/palemoon/palemoon-28.10.1a1.win64-git-20200808-5f05a0799-uxp-b5762c6c2-xpmod.7z Official UXP changes since my last build: - Issue #1621 - Part 1: CSSEditUtils should use atom for CSS property if possible. (baa4b609d) - Issue #1621 - Part 2: Implement nsIAtom version of SetAttribute/RemoveAttribute/CloneAttirubte. (1c0c7cf58) - Issue #1621 - Part 3: Use nsIAtom to change attirbute if possible. (1115c63bf) - Issue #1621 - Part 4: Check whether node can be splited. (5f6ecd756) - Issue #1619 - Convert Intrinsic Ratio to Float (232f987cf) - Use an alt script to properly determine the OSX SDK version (c3ec6c613) - Add license header to media/webrtc/trunk/build/mac/find_sdk_uxp.py (02bd56c44) - Issue #1619 - Missing Dimension Computation (e664d4369) - Issue #1619 - Add Vertical Writing Testcase (ba0a2e796) - Issue #1619 - Nits Picked (a90b8d98e) - Merge pull request #1622 from RealityRipple/master (2e1c5dafc) - [js] Try to catch bad pointers for GC and bail if not valid. (8d38e3575) - Issue #1625 - Allow MailNews Oauth2 support to be configured in confvars.sh (7c6d822be) - Merge pull request #1623 from g4jc/libeditor_patch (267d32f4f) - Issue #1628 - Remove redundant PREF_EM_UPDATE_BACKGROUND_URL (d357eec56) - Pref and disable getRootNode() (b5762c6c2) Official Basilisk changes since my last build: - Update Back-end branch pointer (c15535d) - Issue MoonchildProductions/UXP#1628 - Remove extensions.update.background.url from preferences (57e81f0) Official Pale-Moon changes since my last build: - Update back-end branch pointer (2762ee9d5) - Issue MoonchildProductions/UXP#1628 - Remove extensions.update.background.url from preferences (5f05a0799) My changes since my last build: - Revert UXP issue 1628 related changes. (35f288dc4)

For now, wumt and wsusscn2.cab is still able to search, download and install updates. Probably is a good idea to backup wsusscn2.cab. Microsoft might remember to delete older updates at anytime from now. (Top: vista sp2 vanilla, Bottom: xp sp3 + posready)

Yes, I would appreciate it too so it will be released when it is ready. Current status is that it does not work correctly yet. On the other side, I doubt that someone needs to upgrade to new builds immediately when it is released, especially when some needed software is not compatible with it.

@Dave-H and @Dylan Cruz I've fixed it! Found an easy way to fix Office 2010 and not break TLS updates. Get KB3081320 from WU Catalog, extract it and copy dssenh.dll to C:\Program Files\Microsoft Office\Office14. That's it.

i’ve stumbled on this issue myself (mind you it was before doomsday) but updating my Vista copy up until april 2017 and updating root certificates solved the problem. I hope microsoft would not prevent us from activating our os that we paid for??

... 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...

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...)

it would be the same on an x64 system. The only thing that really changes on x64 is that x86 components come under a "Wow6432Node" key.

BTW @roytam1 If you are wondering about shellservice and nsis installer code.. I am gonna be upgrading that modifying the copy from Pale Moon which was modified from Basilisk when Pale Moon was ported to UXP from Tycho. The technical reason is simply this.. The Suite Shellservice is not very appropriate for a standalone web client and over the years the SeaMonkey people have mangled it pretty badly and pieces of it are ancient. Basically getting a fresh copy that is geared to JUST a web client will improve matters greatly. The reason the nsis scripting is involved is because on Windows the shellservice needs to issue commands to an external application that can elevate and Mozilla shared routines in nsis scripting to produce the helper.exe which serves during install as well as commands issued by shellservice. Those two items need to be consistent. But yeah until I get it replaced you can just revert that. However, I suggest once it is replaced and verified you should switch it to that for best results.

... 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...

Let me clarify a few things. as I've spent several days creating this: - .msu files can't be used to install many updates at a time: those packages include an update scanner (wsusscan.cab) to check applicability, which is run before installing every update and gets slow and slow over time. Svchost also consumes more and more RAM until your system crashes. - .cab files are installed immediately, the check for applicability occurs during install, thus is faster and reliable. - some updates have pre-requisites that require a restart. Because of this, I've split the updates in 3 parts.

I've just finished an update list of Office 2010 (32/64-bit). The patches are automatically applied during installation. Anyone interested? If so, should I create a topic in the Office section?

Just checked the WindowsUpdate.log on Vista, XP and Win7, the block is in the remote WU servers. On supported OSes, this url is used to check for updates: https://fe2.update.microsoft.com/v6/ClientWebService/client.asmx On unsupported OSes, this url is used to check for updates: http://www.update.microsoft.com/v6/ClientWebService/client.asmx But it was deleted. If we could redirect it to the link above, maybe it would still work. Any ideas?

Was working a few hours ago. Now they killed it for sure: WARNING: SyncUpdates failure, error = 0x80244019, soap client error = 10, soap error code = 0, HTTP status code = 404 Database was deleted. RIP.

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:

Who's "we"? MSFN's policy is simple: we do not propagate FUD. Period.

You're the second one who has reported that. I still have it on mine, but that's my main machine with April 2017 updates. Indeed, my VM with July 2020 updates does have this problem. The solution is to make a folder named sidebar.exe.local in Program Files\Windows Sidebar and place your original ole32.dll in there (make sure you applied my reg key). Then it will work.

MS did say that they were shutting down SHA-1 endpoints for Windows Update. So 2000, XP and Vista are dead right there. The SHA-2 updates for Server 2008 came out after the build number changed to 6003, and Windows Update also broke on Vista with the change to 6003, so you're SOL.

My vista system now shows 0x80072efd error every time I search for updates. I suppose vista updates should still work because of windows server 2008... Can anyone confirm that updates are also down for vista?

A more general way would be something like (one liner on command line): FOR /F %i in ('DIR /B *.msu') do (@call set name=%~ni&&@ECHO "%i" "%name:~0,-41%%~xi") and FOR /F %i in ('DIR /B *.cab') do (@call set name=%~ni&&@ECHO "%i" "%name:~0,-41%%~xi") Or in batch: @ECHO OFF SETLOCAL ENABLEDELAYEDEXPANSION FOR /F %%i in ('DIR /B') do ( SET name=%%~ni IF "%%~xi"==".msu" ECHO "%%i" "!name:~0,-41!%%~xi" IF "%%~xi"==".cab" ECHO "%%i" "!name:~0,-41!%%~xi" ) jacla

Yes. On 8th August, it downloaded and installed the definitions by itself. On 9th August, it refused. The only post 2017 update installed is kb4474419. Is it possible it downloaded the definitions, before I installed kb4474419, and only after installing kb4474419 it installed the definitions it had previously downloaded. Maybe, because I installed mse first. At some point, I will go and fetch from the link you posted and see if it will work that way.

@Dylan Cruz Mse is not working on my vista system today 9th August. It was fine yesterdy. Gives a message that it cannot install the definition update. Perhaps MS have nobbled it.

Turns out you CAN have your cake and eat it too, actually: Thanks to @daniel_k for figuring this out: Get KB3081320 from WU Catalog, extract it and copy dssenh.dll to C:\Program Files\Microsoft Office\Office14. If that doesn't work, copy it into system32 using Replacer and reboot

A while ago I did some google search about WUMT. The developer of the tool is said to be elusive and avoids publicity. The Russian forum mentioned above seems to be the original source of WUMT and the thread on My Digital Life followed. There are two verions of WUMT: 20.12.2016 - supports XP -> Win10 07.01.2020 - supports Win10 only Major Geeks replaced v20.12.2016 with v07.01.2020 early this year and does not have the older version available for download any more. Windows Update Offline Scan File wsusscn2.cab is updated from time to time and includes lists of all available updates for different versions of Windows. I could not figure out how often it is updated and which OSes are actually supported. I used it with XP, POSReady 2009 and Windows Embedded Standard 7. Here are all relevant links and checksums: v20.12.2016 wumt.zip MD5: 200B3B2198F32AFC6FBF2D5B6110C5CC v07.01.2020 wumt.zip MD5: 4B4BB34ADC4376E6F6DA6961DC59FAB3 WUMT - original source: http://gallery.ru-board.com/topic.cgi?forum=5&bm=1&topic=48142#2 WUMT - primary thread in English: https://forums.mydigitallife.net/threads/windows-update-minitool.64939/ Official web page of wsusscn2.cab: https://support.microsoft.com/en-us/help/926464/a-new-version-of-the-windows-update-offline-scan-file-wsusscn2-cab-is

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 :

I had a hard time ciphering through it all. I got 4.4.304 installed as indicated, but I'm just confused about why it says not a valid Win32 application, which doesn't seem to be the issue discussed there. These are the definitions we're talking about here, the 64 bit version of which work fine on the same 4.4.304 in Vista. So I'm wondering what's amiss - perhaps the definitions do no longer support XP, in which case what are the newest ones that do work, so I can use those? That looks like a Vista screenshot - I just installed 4.4.304 today and I have the latest definitions so mine is all up to date. I'm entirely aware that MSE will probably never offer adequate, realtime protection, but that's not really what I was looking for anyways. More just something lightweight that was better than nothing, since my brain is my primary antimalware! Of course, if there's a newer version than 4.4.304 that works on Vista still, I'd be open to hearing about it - but it seemed the consensus on that thread was there was not.

I've attached RAR5 compressed files with lists of download links for all official updates for Vista 32-bit and 64-bit Post SP2 up to April 2017. Includes all language packs for Vista, IE9 and local Help update. Also included are Ultimate Extras, Optionals and .NET Framework 3.5 SP1 / 4.52 with updates. Superseded updates are not included except for a few ones just to satisfy Windows Update. Hotfixes are not included, unless available through Windows Update. Someone please mirror them on Web Archive. ASAP. EDIT: Updated files with .NET Framework 3.5 SP1 Language Packs. WindowsVistaSP2_x86.rarWindowsVistaSP2_x86_Installer.rar WindowsVistaSP2_x64.rarWindowsVistaSP2_x64_Installer.rar Installing System Updates: If you want to install a language pack, you must do it first, by downloading and running the language pack executable. 1) Download all files from Main_URLs.txt to the same folder. 2) Using WinRAR, sort files by type and unpack all .MSU files to the same folder, overwriting existing files. Then you may delete the .MSU files to save space. 3) Unpack the WindowsVistaSP2_x86_Installer.rar or WindowsVistaSP2_x64_Installer.rar (just batch files) to the same folder where you extracted the files. 4) Open a Command Prompt with Administrator privileges and switch to the folder where the update files are. 5) Run Main_Part1.bat, Main_Part2.bat and Main_Part3.bat. At the end of execution of every batch file, Windows will restart automatically. 6) Optionally you may install local copy of Help update (LangPacks_Help_URLs.txt) and the IE9 language pack (LangPacks_IE9_URLs.txt). PS: It'll take a while to install all 210+ updates. Installing .NET Framework 3.5 SP1 / 4.52 with updates: 1) Download all files from NDP35_45_URLs.txt to the same folder. 2) Unpack the WindowsVistaSP2_x86_Installer.rar or WindowsVistaSP2_x64_Installer.rar (just batch files) to the same folder where you extracted the files. 3) Open a Command Prompt with Administrator privileges and switch to the folder where the update files are. 4) Run NDP35_45_Install.bat, if needed Windows will restart automatically. 5) Optionally you may install a language pack (LangPacks_NDP35SP1_URLs.txt and LangPacks_NDP452_URLs.txt). Installing updates for optional features (only if you have installed IIS, IIS ASP, IIS FTP or Telnet from Program and Features Control Panel extension) Download all files from Features_URLs.txt and run the following .MSU packages if you have installed: IIS: KB4012373 IIS ASP: KB2124261 IIS FTP: KB975254 Telnet: KB960859 and KB3020393

That did the trick! I hadn't seen the comments regarding 64-bit vs. 32-bit, thank you it worked! I had examined the reg files closely myself and run various versions of it, but they were all targeting 32-bit in retrospect. I use Group Policy to disable insecure SSL anyways so the additional changes seem not to be necessary, just this did the trick: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.1] "OSVersion"=- [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.2] "OSVersion"=-

Your IE9 version number depends on which cumulative security update for IE9 is installed. The last cumulative security update with a dual signature was KB4507434. (VistaLover wasn’t using that one in July 2017 because it wasn’t released until July 2019.) For those who have installed SHA-2 support, the highest possible version of IE9 remains a cutting-edge question. Your latest and longest post seems to be about the reg files that were created by greenhillmaniac, who has never posted in this thread. It is possible to scrutinize the changes in a reg file without running it. I have looked at the reg files (in fact once offered some input regarding the x64 version), and recall some arguably superfluous changes that I interpreted as being for the sake of security (e.g. having SSL enabled has been unwise for years). If anyone running Vista x64 would like to manually edit their registry pursuant to TLS 1.1 and 1.2, see this post.

If you have already installed a number of Server 2008 updates, then you probably have KB4056564, which superseded KB4019276 as first noted in a June 22, 2018 post above. Otherwise, you might have downloaded a patch with incorrect bitness or for Itanium-based systems.

Yes. But you can edit your post here above and add a link to that topic, for easy reference, too.

Hi, I've just built kind of my dream 2008 PC and I've installed XP and Vista on it. I've gotten the XP side of things working fine, but I can't for the life of me get Windows Update to work on Vista. I've tried a few YouTube tutorials, but none seem to work, but feel free to post some of the easy answers in case I missed something. Here's the specs if it helps anyone Intel Core 2 Duo E6700 4GB DDR2 800 Nvidia GeForce 9800 GT Creative Sound Blaster X-Fi Intel 82566DC Gigabit Network Adapter EDIT: I tried updating my Ethernet driver off of the Microsoft Update website, and that didn't work, though the driver I downloaded was from 2011, but it seems that Intel isn't carrying any Vista drivers for any of their Ethernet products anymore. If anyone has an archive of an updated driver, that would be great. EDIT 2: archive.org is a great website. Using some link copying I found a link for the Vista driver for this Ethernet controller, and while updating the driver still didn't fix the issue, I'll still post the link for archival purposes. https://web.archive.org/web/20181130184021/downloadmirror.intel.com/18718/eng/PROWinx64.exe

I think latest for XP are 368.91: https://drivers.softpedia.com/get/GRAPHICS-BOARD/NVIDIA/NVIDIA-GeForce-iCafe-Graphics-Driver-36891-for-XP.shtml But it seems like it is a hit and miss game, see: https://msfn.org/board/topic/177373-winxp-drivers-for-gtx-10xx-video-cards/ https://msfn.org/board/topic/177373-winxp-drivers-for-gtx-10xx-video-cards/?do=findComment&comment=1177300 jaclaz

YouTube seems to work more or less fine in New Moon 28 and Firefox 52.9 ESR on Windows 2000 with Extended Kernel. Presumably, would work in XP, too.

Should be OS-agnostic, or to be eexact, for OS supporting Windows Update v6 and up

Windows Update v6 not dead https://drive.google.com/file/d/1MzNoy_hUv3gIcm35JkoQTlKbUSTNrh2S/view?usp=sharing Maybe it was a little maintenance, thinking that Microsoft did the same as Windows Update v3.1 and v4 in this month but in 2011. Sorry i'm fixed permissions

There's like no reason to use anything above 4.19 though.

Thanks so much for your communication, and letting us know that this great project is still alive! Looking forward to "when it's ready"!

Oh, well i'll make one in but with version 79 then

Should you want a small, simple, no bells and whistles, working worksheet running on *any* windows AND Excel/.xls/.xlsx compatible, check this SPREAD32: http://www.byedesign.co.uk/ (portable, can run even from within a .zip) jaclaz

July 2019 was obviously a false alarm, but Doomsday will come like a thief in the night: https://support.microsoft.com/en-us/help/4569557/windows-update-sha-1-based-endpoints-discontinued

@bigmuscle Yes, please consider this for the future development of Aero Glass. If you want to keep it paid, at least provide a bit more communication.

Normally you right click on the link and choose "Save as", anyway you can copy and paste the following and save it with Notepad as "vista-tls-1.1-1.2-update.reg" Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.1] "OSVersion"=- [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.2] "OSVersion"=- it is a simple .reg file that - once merged to the Registry - deletes the two OsVersion values. But the issue here may be (see my previous post) that the above is OK for 32 bit systems but for x64 you need other modifications, i,e. this .reg: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.1] "OSVersion"=- [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.2] "OSVersion"=- But since they are just a few changes, only involving deleting a value you can do the above manually with Regedit. jaclaz

Wow, this is awesome! Thank you very much for this. It's certainly appreciated especially during this hard time for you. Don't feel obligated to rush things, take all the time you need. We're all just so glad that his "presence" didn't just go cold and nobody knows what happened to him so thank you for continuing to login and update us on things. I'm hoping that you've been able to find some sort of comfort in this difficult time considering tomorrow will be a month since your dad's passing. It's still hard on some of us, myself included, but we're getting through it. I'm just sorry I never got to talk to him and know him on more of a personal level.

Just to make you aware: The Vogons Community was able to provide some of the software sold on rloew's website in the past. It has been archived on archive.org so it doesn't get lost: https://archive.org/search.php?query=creator%3A%22Rudolph+R.+Loew%22 If you have bought some software still missing there, you can help extending that library. Just make sure to fill the creator field with "Rudolph R. Loew" so it gets added to that list. I wanted to create a collection, but that's only possible with a minimum of 50 items. So we'll have to make due by going with the creator name.

If I may, besides the actual value of the patches/programs he made (some or which are simply invaluable) , it was the value of what he taught us (directly or indirectly) that made him a reference point. Personally - besides and beyond his work - I always admired his rigour and staightforwardness, qualities that while they should be "default" for engineers, are not at all common. We will miss him. jaclaz

Very sad to hear this. I didn't use his software, but I always respected his knowledge and experience. Rest in peace, Rudolph.

Rest in peace, Legend Rloew. You were a Windows 9x god. For historical purposes, here is a recent archive of his web site, dated 12th August 2019. http://web.archive.org/web/20190812081523/http://rloew.x10host.com/

Apparently for all versions of Windows. Patched DOS can go to 32KiB Sectors for a maximum of 128TiB per Partition. Patched 9x can support Drives larger than 16TiB but with a maximum Partition size of 16TiB.