Leaderboard

@Dietmar @reboot12 @Mov AX, 0xDEAD I discovered this today. https://github.com/FlyGoat/csmwrap Hopefully this means we can boot XP x86 on UEFI class 3 systems now.

I'm gonna post a reply only because someone else might be wondering about that in the future. The reason why you got menu in which you have to insert a username and a password instead of the normal login screen is actually because your Windows XP Professional thinks that it's part of a domain. In a real domain, when a computer joins, it allows the person logging in to use his Active Directory username and password which would work not just for that computer but also for every other computer and server scattered across the company that joined that domain. For instance, this is one of my XP machines and as you can see it's part of a domain which is federated with other domains and it allows the user to login it by selecting any of those and inserting a valid username and password: Once the user inserts the username and password and selects the domain he wants to login to, XP contacts the Domain Controller to make sure the credentials are valid, then it allows the user to get to the desktop. The reason why your XP was complaining about the network is that it was clearly failing to contact the domain controller you were trying to login to. Anyway, when a computer is in a domain, it doesn't mean that it only allows you to login using a domain account, in fact you can have local accounts as well, like a local separate user account or a local administrator account. As you can see from the screenshot I posted above, one of the entries you can select says "this computer" and that one is the one you gotta select to login to a local account.

About the xiaoxiaoflood script loading method in Mypal 68.14.8b With Mypal 68.14.8b, @feodor2 has unfortunately retired the best script loader forever. The Nuchi-Sporif script loading method as well as all other Nuchi based script loading methods no longer work in this Mypal 68 browser and logically in upcoming releases. This means that the first three script loading methods from my ranking list are no longer available in Mypal 68.14.8b and up. @feodor2 recommends the xiaoxiaoflood script loader from the seventh and last place of my ranking list for users of xiaoxiaoflood's stuff. I have therefore taken another look at this method in Mypal 68.14.8b. As already mentioned, I am currently using the Alice0775 script loading method in this browser, which I put together, fixed and modified myself. It has a good compatibility with existing scripts comparable to the Nuchi-Sporif script loading method. Of course, I first adapted my scripts to the JavaScript changes made in Mypal 68.14.8b. I now have all my important scripts, 24 in total at the moment, running successfully with this script loader. Due to a further, small modification I made to the Alice0775 script loader, all my scripts are again located in a chrome subfolder called Scripts. BTW, more than half of these scripts were created by myself and written to be as compatible and universal as possible. Now to xiaoxiaoflood. I downloaded the version of this script loader @feodor2 recommends on this GitHub site: https://github.com/Feodor2/Mypal68/releases/tag/68.14.8b. After setting up the xiaoxiaoflood script loader in a fresh installation of Mypal 68.14.8b with a brand new profile, I copied all my 24 scripts into the chrome folder. Unfortunately, only less than half of them were ready to use after starting the browser. The xiaoxiaoflood script loader can't do anything with my most important scripts , which in contrast work perfectly with every other script loading method . Besides the already mentioned Alice0775 script loading method, also with the Aris-t2/Ardiman-Endor8 or pure Endor8 script loading method. Furthermore, it reports in the Browser Console that certain variables such as gClipboard are not defined and does not understand some JavaScript commands such as style.backgroundSize and so on at all. In addition, problems with scripts that cannot be loaded are not logged in the Browser Console. No information! Nasty! All in all, the xiaoxiaoflood script loader failed my test once again and cannot be recommended by me for general use. All other script loading methods are much better. To be unbiased and fair , I also tested this method with xiaoxiaoflood's own scripts. These special but very few scripts basically seem to work fine. But when using external scripts with this method, the xiaoxiaoflood version of the rebuild_userchrome.uc.js script, for example, is not able to handle them correctly. It is able to disable non-xiaoxiaoflood scripts but can't enable them again. Spoken for me only, I do not consider most of the very few xiaoxiaoflood scripts on offer to be particularly useful. The xiaoxiaoflood version of the extensionOptionsMenu.uc.js script, for example, which is actually a great one, is far behind the version I use which provides much more functionality. One thing is clear. There are much better scripts available outside the xiaoxiaoflood world. In general, the following should apply to a good script loader: It should be able to successfully load as many scripts as possible, taken from different sources. Needless to say, these scripts have to be compatible with the JavaScript engine of the browser used. Conclusion: The xiaoxiaoflood script loading method has very poor script compatibility for scripts that have not been written specifically for this method, does not understand some standard variables, also does not recognise some JavaScript commands and does not log successful respectively unsuccessful loading of scripts in the Browser Console. The latter is particularly annoying when scripts cause problems and the cause needs to be investigated. An error message would be desirable and helpful. This script loading method can therefore not be recommended for Mypal 68 as a general script loading method. Especially not when much better script loading methods are available. However, for those who only want to use xiaoxiaoflood's stuff, it is ok. For all others, the xiaoxiaoflood script loading method is definitely not to be recommended. Greetings, AstroSkipper

Agree, it's very bright, for blind. older people?

Windows 11 Security claims it detected: Trojan:Win32/Bearfoos.A!ml "Details: This programme is dangerous and executes commands from an attacker." Someone explain pls, do I have to worry? How do they know it's driven by an attacker? It means it detected connections from the outer world? I'm scared... https://github.com/win32ss/supermium/issues/1399

And you wouldn't prefer to to have ESR 128.x? It's more up to date.

Correct. COPYCMD is only for specifying file overwrite parameters /Y and /?. It is also used by XCOPY and MOVE, not just COPY.

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.

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.

Seems very logical since it's a Dutch tradition, and New York was founded by the Dutch. New Amsterdam at that time.

Most likely, yes.

To the current date, no such driver exists.