AstroSkipper

First thanks! And now just for clarification, I am not the creator of ProxHTTPSProxy. But I am the creator of the package ProxHTTPSProxy's PopMenu TLS 1.3 3V3. And as you can see inside the name of this package, it is based on a TLS 1.3 proxy since 2022. Unfortunately, the rest of your comment does not match our recent discussion about the tool WSUS Offline Update and how one can get Office 2007 updates today. To be honest, I don't understand at all what your comment here is actually referring to.

Did you replace the wsusscn2.cab file by an older one which is dated short after the EoS of Office 2007 in 2017 in the way I described in my previous posts? I checked this method, and it works. Even under Windows XP. No 2529 updates but 580 related to Office 2007 ofc glb. For me, the wsusscn2.cab file from 12.02.2019 also worked fine. In any case, the most current wsusscn2.cab files do not properly work at all. Too much files are downloaded which are not related to Office 2007. I have the impression that you haven't read my posts properly. The proof that my method works is the download log I provided in this post: https://msfn.org/board/topic/181623-updates-office-2007/?do=findComment&comment=1270043 Try, for example, this one from 29.01.2019: https://web.archive.org/web/20190129233558/http://download.windowsupdate.com/microsoftupdate/v6/wsusscan/wsusscn2.cab or this one from 05.10.2017: https://web.archive.org/web/20171005192358/http://download.windowsupdate.com/microsoftupdate/v6/wsusscan/wsusscn2.cab

These files are only temporarily generated for further processing to get a final csv list of updates which is then saved inside the corresponding folder of WSUS Offline Update and whose links have to be downloaded in the end. For example, the UpdateTable-ofc-glb.csv file I already mentioned. After processing, these files are immediately removed from the temp folder. The temp folder is, so to speak, the working directory of WSUS Offline Update when the links to be loaded are extracted from the wsusscn2.cab file.

Here is a part of my log in terms of ofc glb with a download of 580 files in the folder client\ofc\glb (only 3 files less downloaded than in 2019): q.e.d The updates whose download failed can be downloaded from external sources and as previously described added before creating the iso image. Cheers, AstroSkipper

At the moment, I am performing a download of all Office 2007 updates under Windows XP to check my theory. It seems to work as I planned. I inserted the pause command into the script and was able to replace the wsusscn2.cab file by a version from 12.02.2019 at the right time. Sorry, but I can't confirm your statement. I haven't got such errors. The files which were generated in the temp folder could be accessed and processed correctly. This doesn't seem a problem related to WSUS Offline Update 9.2.6 but rather to your system or whatever else. In any case, I got a valid UpdateTable-ofc-glb.csv file, and the download started successfully. When all has been finished, I'll post the download log.

@Cixert Another idea I have is to pause the script directly (very important!!!) after the download of the wsusscn2.cab file to replace it by an older version of this file. I would do that with the pause command inside the script. Doing so, this could reduce the download of unwanted files and maybe offer links that no longer exist in the most recent wsusscn2.cab file which has been automatically downloaded by the script. However, this is only a theory. I haven't tested it yet.

Didn't you create an archive for Office 2003 and/or 2007 back then? I never had Office 2003, but Office 2007. Years ago, I downloaded all updates for Office 2007 with WSUS Offline Update (logically with an older version), but of course only for the German version. Therefore, I think that won't help you. But in any case, depending on the OS you are targeting, you should set exclusions to reduce the download of unwanted files. For Office, it is the file ExcludeList-ofc.txt in the exclude folder.

The wmp11-windowsxp-x86-DE-DE.exe file is of course the German version and must be replaced by the desired language version. And yes, they can be downloaded from other sources and easily inserted before the iso image is created. If the user enables the programme option "Include C++ Runtime Libraries and .Net Frameworks", the download script should also be paused before the iso image is created just to remove tons of .Net Frameworks 4.5, 4.6, 4.7. and 4.8 files which are no longer work under Windows XP. I have found a way to make it even easier, faster and, above all, more convenient. You can set exclusions in WSUS Offline Update 9.2.6. To do this, you must insert the following strings in the ExcludeList-dotnet-x86.txt and ExcludeList-dotnet-x64.txt files in the exclude folder: ndp45- ndp46- ndp47- ndp48- Doing so, the download of files containing these strings will be skipped. And in order not to miss the right moment to press the pause button when adding the missing updates, you can add the following command in line 3 of the CreateISOImage.cmd file in the cmd folder: echo The script has paused. Now, you can manually add all updates whose download has failed. When done, press a key to continue! pause Cheers, AstroSkipper

Yep. And thanks! Reviving, modifying and fixing programmes that no longer work properly is one of my favorite things to do. Just for clarification. The Wget option --no-check-certificate has nothing to do with the download option "Verify downloads updates" in the main programme window. In my first download logs generated by WSUS Offline Update 9.2.6, I noticed some errors related to certificate checks when connecting to servers. The Wget option --no-check-certificate is meant to not check these server certificates. The programme option "Verify downloads updates" on the other hand, switches on or off the signature verification of downloaded files by the Sysinternals programme Sigcheck. This is the full list of files that can no longer be downloaded by WSUS Offline Update 9.2.6 for Windows XP: The wmp11-windowsxp-x86-DE-DE.exe file is of course the German version and must be replaced by the desired language version. And yes, they can be downloaded from other sources and easily inserted before the iso image is created. If the user enables the programme option "Include C++ Runtime Libraries and .Net Frameworks", the download script should also be paused before the iso image is created just to remove tons of .Net Frameworks 4.5, 4.6, 4.7. and 4.8 files which are no longer work under Windows XP.

I deleted the default download links pointing to .NET Frameworks installer files higher than 4.0 inside WSUS Offline Update 9.2.6 and then enabled their download. No errors anymore. After the download of all updates for .NET Frameworks, I additionally removed all downloaded updates for higher versions than 4.0 just before the iso image was created. This measure significantly reduces the overal size. Personally, I do not really use anymore Microsoft Office but I assume that the dowload of Office updates will also work in the same way as it does for Windows XP updates. I mention this as Office 2007 was actually the topic here.

After deleting all certificates in the folder Certs and updating the certificate cacert.pem, all certificates will be generated by ProxHTTPSProxy once again. That means my certificate chi.uk2.net.crt was updated 2 days ago. It has a validity from 28.07.2024 to 28.07.2034.

To be sure that WSUS Offline Update 9.2.6 really works I ran it a second time and activated some more options as, for example, the download of Windows Service Packs. Works. Only if you enable .NET Frameworks, the downloads can't be done as some links don't match anymore. The log file shows the code 404 in the end. So, some scripts would have to be updated regarding download links for .NET Frameworks and maybe for more. But generally, WSUS Offline Update 9.2.6 works great with a few modifications, even in 2024.

WSUS Offline Update 9.2.6 does not do anything good from scratch under Windows XP in these days. So, I modified the DownloadUpdates.cmd file in line 206 located in the sub folder cmd where I added an additional option to the downloader wget.exe: set DLDR_PATH=..\bin\wget.exe --no-check-certificate Furthermore, I replaced the wget.exe file by the last XP-compatible version 1.19.4. Then, I configured WSUS Offline Update 9.2.6 to use ProxHTTPSProxy to avoid any possible connection problems, especially certificate related. But one can also try to download all updates without it, of course. And I inserted the last XP-compatible version Sigcheck 2.30 to avoid any verification problems although I didn't enable the option "Verify downloaded updates". And what shall I say? WSUS Offline Update 9.2.6 still works under Windows XP even today. Of course, only if such modifications were done I listed above. Here is my log generated after a successful download of German Windows XP updates under the OS Windows XP : TBH, I did all that here to show that even today these updates can be downloaded under Windows XP. Personally, I do not need to download those updates anymore as I already did it in 2014, 2019 and 2022. And I archived all installed updates I got from Windows Update from the very first including all POSReady updates. Cheers, AstroSkipper

First of all, the most recent version is MyPal 68.14.3b. So, why do you want to install an older one? Regarding the updating of Mypal 68, there is no updater. You simply copy all new files over the old ones, or you create a new programme folder. Via the profile manager, you can call up your old profile, or you can create a fresh one. In any case, all has to be done manually. Personally, I usually edit my profile.ini file manually to my needs. If you create a fresh profile, you can copy, for example, your bookmarks file from your old profile to the new one. The same applies to other important files so that your data is not lost.

Indeed, it would be interesting to see what kind of Windows XP projects you made so far. Did you already release some of your projects, for example, on GitHub? Are your projects open source?

You should use New Moon 28 or Serpent 52 in combination with uBlock Origin Legacy and suitable filter lists enabled. A more recent user agent can't hurt, either. Mypal 29 and Firefox 52 are much too old.

Yep, a bit strange. But as I have already described, my 360Chrome 13.5 Build 1030 Redux initially also reported no secure connection to the website https://chi.uk2.net/ using ProxHTTPSProxy, i.e. no green padlock. Only after I had deleted all certificates in the Certs folder and updated the cacert.pem certificate inside the ProxHTTPSProxy installation, 360Chrome immediately reported a secure connection after a restart and showed the green padlock. However, recognising valid certificates has always been a problem in almost all 360Chrome versions for Windows XP. TBH, I very rarely use 360Chrome only to check sites for browser compatibility. I generally surf with Mypal 68 (is now running great ) and New Moon 28, and I try to open the more modern, very bloated sites with Thorium. If all else fails, I use my Android tablet.

Hi @TheLeftOldComputer! Many antimalware programmes are no longer compatible with Windows XP but ClamWin has always been. Unfortunately, it does not have a real-time protection. Only an additional tool called Clam Sentinel which has no longer been developed for years and never was a good one. It could only use ClamWin to scan downloaded files. So what about a programme based on the open source ClamAV with its virus definition databases which offers real-time protection? Or a fork of ClamWin with real-time protection and still compatible with CPU's only having the instruction set SSE? Kind regards, AstroSkipper

That's good. But in your original screenshot there wasn't a green padlock.

Ok. No problem.

@sparty411 Are you sure about your specifications regarding your internet speed? The unit mb/s does not actually exist. You wrote 300 mb/s. Did you really mean 300 MB/s or perhaps 300 Mbit/s? If you really had a speed of 300 MB/s, then that would be a line with 2400 Mbit/s, which I have never heard of existing for a normal citizen. At least here in Germany. I assume you rather meant 300 Mbit/s (Mbps in English, and very rarely can also found the unit Mb/s).

Or have I overlooked something?

@Dave-H Just for fun, I tried to open the website https://chi.uk2.net/ in 360Chrome 13.5 Build 1030 Redux. I got no green padlock and the hint the connection is not secure when connected in both ways, directly or via ProxHTTPSProxy. I then closed the proxy, deleted all certificates stored in ProxHTTPSProxy's Certs folder and performed an update of the cacert.pem file. I then started the proxy and called up the website https://chi.uk2.net/ again. Now, the connection is reported as secure with a green padlock. Here is a screenshot: I don't know why your credentials are no longer filled in automatically when connected directly but I assume it is certificate related due to the age of 360Chrome. In any case, you should not forget to maintain your ProxHTTPSProxy installation in terms of its certificates, i.e, purging the Certs folder and executing the cacert Updater from time to time.

Just an idea. Have you already patched and removed the limit on TCP connection attempts in the tcpip.sys file in your Windows XP installation? And don't forget to adjust your MTU and RWIN values as Windows XP does not do it automatically! This can be easily done, for example, with the tool SpeedGuide.net TCP Optimizer, currently in the version 4.1.1. The correct MTU value mainly depends on your internet provider and can even be determined with the SG TCP Optimizer tool in the corresponding tab. A suitable RWIN value can also be manually calculated and set in the registry, of course. All values should be then tested to find the optimal ones. In any case, be aware that such fast connection speeds as you are using today didn't exist when Windows XP was developed and still maintained. TBH, I don't know whether Windows XP with its very old network drivers is at all able to handle such high speed you mentioned above. The old Internet tariff I booked years ago has a speed of 25 Mbit/s only, which I can achieve in full on my Windows XP computer, but only with optimal settings mentioned above. However, my old processor wouldn't be able to cope with any more, either. And regarding the QoS Packet Scheduler, I deactivated it from the very first on my standalone Windows XP desktop computer long, long time ago.

Just an idea. Have you already patched and removed the limit on TCP connection attempts in the tcpip.sys file in your Windows XP installation? This can be done, for example, with the tool xp-AntiSpy, or manually following the instructions here: https://www.speedguide.net/articles/windows-xp-sp2-tcpipsys-connection-limit-patch-1497/p-2/ There, you can find a further tool for patching called Event ID 4226 Patcher: http://www.lvllord.de/?lang=en&url=tools Long time ago, I did it with xp-AntiSpy which also creates a backup of the original file.