All Activity

My impression is that there might be HAL issues or CPU errata/microcode issues on at least the SandyBridge machines. I have tested the WinXPPAE.exe 3.5.0.0 patch tool on newer HAL files than the initial Service Pack 2 version, and they are also rejected as invalid by the patcher. Perhaps the SP2 versions do not need the patch; it is possible that whatever is patched for the Service Pack 3 HALs might not be an issue on the SP2 HALs. Have you tried using the SP2 HAL with the WinXPPAE.exe 3.5.0.0 patch tool patched SP2 kernel? Regardless, you might wish to try newer SP2 HAL. The update packages that I have are all intended as the English language (United States) versions, however, I would expect the HALs should still work in another language distribution if the HAL file is specified explicitly in boot.ini. I have uploaded the HAL updates for English Windows XP with Service Pack 2 to: https://www.mediafire.com/file/5ibjk0jsnltisxa/SP2_HAL_Updates.zip/file File Name: SP2_HAL_Updates.zip Size: 7,597,675 bytes CRC32: BA5633F7 MD5: 170844F1EDE2CE551C9E5F213A283059 SHA-1: E29ADE7FE24B8C7D10CDCF1EB30D197733B57DFA SHA-256: B911093A86B272BFDADCEF9F27335DD6E677E0DE60E4D00BBFEFD83C3AC3AB54 SHA-512: E7F08887D5E1DC432C269A40CD5E977F2806FF9D14DDFBBE86B6C58BFB519A3D738F9E98665F3D110619D314A8D6E6385BED5C5520CD97559A7058F62DB55A68

well "4 GB is the ram limit for a 32 bit operating system" is finally busted i wonder why even big company´s are still making that fault: https://www.asrock.com/mb/Intel/B560M-C/index.us.asp "**Due to the operating system limitation, the actual memory size may be less than 4GB for the reservation for system usage under Windows® 32-bit OS. For Windows® 64-bit OS with 64-bit CPU, there is no such limitation." to explain the selector/segment or maybe segment selector in the past like 8 bit or 16 bit (sometimes both - aka having 8 bit instructions and 16 bit data) the combination of segment + offset = "real address" also the instruction pharser that read the next opcode, automaticly use the next segment selector (for continuous flow - without chucks) - why this would not be the case for 32 bits ? (it is a cs:eip combination (cs for code segment)) you could write a code either with a selector+offset or just the offset - for "just the offset "the cpu automaticly then choosed the next one (where it then just executes the next instruction) if that isnt doing it there would be still the explained instruction codes that concretly use a selector:offset combination either way if the cpu isnt doing the next segment selector automaticly you still could write a jump at the end of the the 4GB address(or just changing the selector to the next one) https://wiki.osdev.org/Segmentation for a data allocation this would also be of use you could get a DS(data segment) + offset , and directly you would have a 4 GB chuck thats why i always (in like the past i wanted to have a virtualalloc2 function that also gives out the selector) - but me writing that info forums (including microsoft ones) where just ignored the others where already explained , like 4 mb pages (instead of 4k), PSE, PAE - PDE´s , PTE´s and why there is a chuckwise solution (and why this chuckwise solution is useable for app´s/executables/modules)

Yes, the batch script is rather defective in that it is unreasonably presumptive as to where resources or files are and can result in not finding the something it should find, finding the wrong thing (which can become a data corruption problem after write operations are performed on originals, such as boot.ini), presuming one wants to use kernel or HAL from sp3.cab, etc. However, the script does provide some level of instruction of a potential method to patch files and deploy those patched files.

Yes, with the daniel_k's solution, he is not providing a pre-patched binary of a single kernel variant version and a single HAL variant version like that "other" patch you referenced; rather, he provides a patcher that can be used on any compatible variant or HAL and any version of such. The daniel_k's solution is generally better and provides more compatibility options. I would disagree. Older PCs could have relatively large amounts of RAM. It is also important to note that it is not RAM that needs to be considered, but addressable memory (which is inclusive of RAM and other things like allocations for video card memory). A old PC system utilizing only 4 GB of RAM would still likely benefit from the PAE fix patch. Even then, there were computers with much larger amounts or RAM and addressable memory; these were often rather expensive at the time. It is also best to think of the patch as a PAE (Physical Address Extension) fix patch rather than a RAM patch; the intentions and products are different. It also seems like there is a presumption that multi-core processors must use a Muti-processor HAL; however, that presumption would not be correct. Multi-core processor can still use Uniprocessor HAL. It is a configuration I often use (one may also often take the opportunity to scale a single core well beyond where it would tend to scale in a multi-core conflagration while having the other cores turned off). Many CPU architectures since about 13 years ago have had this capability and design consideration. The daniel_k patcher provides a patch tool, while "other" patch you linked to is someone's product of patching and in a limited case.

i dont know but the name "ntkrln64g" sounds like it is a wrapper, maybe a kernel extender ? if not there like many versions of ntoskrnl´s you have to find the right version in that case the searched patches show 7 changes 138-13a is probaly the checksum, that checksum is a "elder driver signature" - if that one isnt currect the system driver (in this case the important ntoskrnl) is not loaded as you may reconized that patch did not touch that ntkrpamp.exe, you should check what ntoskrl was loaded (there are only 3, ntkrnlpa, ntoskrnl and ntkrpamp to check if it use up more then 4 gb ram you should repeat the test from page 7, there is also a page-file that actually can pass that limit you might turn that one off while doing that test

I am glad u like my proposal, but I haven't yet got an informed answer. if ur test proves right, we still do not know whether we can, and/or how we will, effectively automate it into winntsetup.exe. U got a point, though: if it cannot be pre-installed, we will keep using it on a post-install basis.

Thank you! I will give it a shot.

Bring back the Azure Screen of Indifference! Wasn't there a red screen of death in a Vista beta?

I don't know, but if you compare patched kernel files 5.1.2600.6368 in a hex editor and are changed exactly the same bytes in the same offsets, it means that they work the same. You must first patch using a patcher v3.5 kernel file 5.1.2600.6368 ntkrnlpa.exe 5.1.2600.6368 > https://catalog.update.microsoft.com/Search.aspx?q=2813170 WinXPPAE.bat script default patch all RAM: WinXPPAE.exe /M:ALL /NOBACKUP so, put ntkrnlpa.exe (GDR version) and WinXPPAE.exe in same folder then patch as above: winxppae /M:ALL Windows XP PAE Patcher 3.0 by daniel_k | HAL patches by <Mov AX, 0xDEAD> PAE will be enabled using all available RAM. Patching ntkrnlpa.exe (Uniprocessor PAE Kernel)... OK! File ntkrpamp.exe (Multiprocessor PAE Kernel) was not found. File hal.dll (Standard PC/Standard PC w/ C-Step i486 HAL) was not found. File halaacpi.dll (ACPI Uniprocessor PC HAL) was not found. File halacpi.dll (ACPI PC HAL) was not found. File halapic.dll (MPS Uniprocessor PC HAL) was not found. File halmacpi.dll (ACPI Multiprocessor PC HAL) was not found. File halmps.dll (MPS Multiprocessor PC HAL) was not found. No, this is not simple to compare - too big differences :-( Probably ntkl64g.exe is compiled from source code. org vs v35 differ only in 11 bytes: Search for differences 1. org_ntkrnlpa.exe: 2 070 016 bytes 2. 35_ntkrnlpa.exe: 2 070 016 bytes Offsets: hexadec. 138: C2 04 139: FF 03 13A: 1F 20 16B632: 07 00 16B637: 01 02 1703C2: 74 EB 1BE554: 10 00 1BE555: 00 02 1BE56A: 1B 00 1BE572: FC F8 1BE576: 01 02 11 difference(s) found.

So it would be a waste of time installing daniel_k's patch on a uniprocessor machine anyway? I wonder why he bothered to include the option! So, do you think the two patches I've tried are actually doing exactly the same thing, so there's no advantage of one over the other? One isn't making the extra RAM any more accessible to programs or the system than the other, for instance?

This is not impressive - simply this is patched ntkrpamp.exe for multi CPU/multi core use: Modern computers have multi-core processors and the use of RAM patch on old PC does not make sense because old computers with a single-core processor do not support a large amount of RAM and a patch is not needed. Therefore, the 64G patch does not contain other kernal and hal files.

OK, I decided to have a try with daniel_k's patch to see if it produced any different results to the one I was already using, which was linked to here. It took me a while to get it installed. As I have a multi-boot machine, my file paths are not standard, which caused the batch file to fail. For instance, the batch file contains many instances of the path "%SystemDrive%\Windows\". As my Windows XP installation is in D:\WIN-NT this did not of course work! The author should really have used "%WinDir%" I would have thought, unless I'm missing something. Do be aware of this if you try to use this patch on a system which doesn't use the standard paths. Anyway, once I'd edited the batch file so all the paths were correct for my system, it still didn't work. It said it couldn't open SP3.cab, so couldn't extract the files it needed to patch. Why I do not know, It warns that it needs to be run as Administrator, but apart from the fact that I am of course an Administrator user on the machine, there is no option to run the batch file as an administrator as far as I can see when the installation is on FAT32 drives. Maybe that wasn't the issue, but I could execute the commands fine manually in Command Prompt, the batch file just didn't seem able to do that itself. Very strange. Anyway, I did the whole thing that way, manually executing the lines in the batch file one by one, and it all seems to have worked. Everything looks exactly the same as with the previous patch, the browser is still falling over on Facebook. It's certainly a much more complicated install routine than the patch I was using first. How the other patch does it by just using two extra files added in System32 and a simple modification to boot.ini is a mystery to me. In the daniel_k patch, you have to specify what sort of machine it is (ACPI Multiprocessor in my case) to get the right HAL files. How the other patch does it without having that specified is impressive! I'll let you know how I get on now with this patch. Cheers, Dave.

But it existed before! It'd be confusing.

It seems to work. I can add [language=en] to my existing format query. It seems to also download videos that are not in English (at all) instead of failing. Lately many videos don't download. It gives one of these error messages: an experiement is forced to use SABR, or all TV formats use DRM. It then proceeds to download a very big VP9 file without sound. I need to watch the downloader dosbox to see if the error happens, cancel and try again, perhaps in 720 pixel height to get a good video.

I'm assuming "modern" Javascript is ES6+ Those versions of Javascript are fairly recent and supports modern features.

I am available if you need more information

You mean "Microsoft 365 apps"? They are refering to the Office 365 suite with that. I don't think they have done a statement on the Microsoft Store on Windows 10 yet. I guess the Microsoft Store itself will be supported with feature updates till 2026 and the servers will probably be available till 2028

Sure if I could reproduce that

IMO trying to install it from the CD on an unsupported platform is basically a waste of time, even if you end with a success the process will take an exaggerate amount of time. Just install using VBOX , fully update it, replace the files you may need to replace, like acpi.sys or whatever, copy the partition, make it bootable, and use fix_hdc to avoid the 7B error. Basically that's all, you can even boot the VHD directly (just like a modern native VHD, which is a thing since W7) using grub 4 dos and firadisk or SVbus drivers, but that belongs to a different tutorial. Reversing the perspective you can also use a whole physical disk connected to VBOx (or vmware or hyper-v), so you can skip the partition copy step, but that makes sense only if you have a secondary disk dedicated to the task, not if you want to use a partition from your only HDD. For sure you need to use a SP4 install media. SP0/SP1 were possible as bad as Vista SP0, ISOs updated to unofficial SP5 may be a good idea as well, but personally I prefer to do as much as I can myself, which makes easier to identify problems.

@UCyborg I've tried to make a fix, but I've not been able to reproduce the correct behavior with bTimeAdjustmentDisabled set to FALSE via MinGW. After one hour, the time is still changed. It's hard to check if applying the property succeeded as well, because GetSystemTimeAdjustment fails with error 203 - ERROR_ENVVAR_NOT_FOUND - "The system could not find the environment option that was entered". If anyone is interested in looking into it, I've shared the source code here: https://git.lumen.sh/Fierelier/winutcfix .EXE (sha256: f594d6112c8c64928b74bcff5c0c608d27a2c7003bf7d4548c2b503ecf1d8507): http://fier.me/software/winutcfix.exe Maybe this just doesn't work with MinGW but I'm trying not to spend too much time on one project right now, and I don't feel like installing Visual Studio.

It's ok for me, 126R7,XP x86

Can you try: --extractor-args youtube:lang=en ? [Edit] Ignore that. That is for the title, not for the audio. Maybe first get the formats using `yt-dlp -F URL`. Then choose for example this to get this mr. Beast video dubbed in Russian: yt-dlp -f 136+140-1 https://www.youtube.com/watch?v=yhB3BgJyGl8 Or: yt-dlp -f "bv*+ba[language=ru]" https://www.youtube.com/watch?v=yhB3BgJyGl8

@Ascii2 I make big tests: using Macrium Reflect clone OS to other HDD - still problem replace RAM modules - still problem use only 2GB RAM 1+1 - still problem using Macrium Reflect make disk image, then restore on other PC - Haswell 8GB RAM (4+4 Dual Channel), OS boot, find new devices, I install drivers. I test and it looks like there is no problem and WinXPPAE 3.5 works well :-) I use exactly same patched files and settings: ntkrnl2.exe SP2 5.1.2600.2180 + hal2.dll SP3 5.1.2600.5512, noexecute=optin I have to use the system for some time to make sure 100% that there is no problem. It seems that the problem is only on SandyBridge machines.

I am not doubting that you have been able to the a PAE kernel to load. The /PAE switch appears to modify the bootloader configuration behavior towards selection to PAE, but does not override explicitly specification the kernel and HAL. Yes, there are various criteria that is evaluated to determine what the bootloader would load, but the criteria should not usually override explicit and compatible specification. With regards to your sources for the DEP default handling behavior, it is my impression that the evaluation mechanism is against hardware provided DEP (which is often an option on BIOS that is reasonably configurable). Where hardware DEP is detectable by the bootloader (perhaps because BIOS has the feature disabled), I do not believe the bootloader selection behavior would necessarily tend towards selection of a PAE kernel. I have never tested that, however. With regards to Windows XP with Service Pack 2 HAL updates, I have compiled a list of fixes that I think should be useful to you: For Windows XP Professioal with Service Pack 2 Install in ascending order: HAL updates (all in ascending order): KB889673 - A hardware DEP-enabled computer may stop responding when you resume from standby or from hibernation in Windows XP Service Pack 2 KB896256 - Computers that are running Windows XP Service Pack 2 and that are equipped with multiple processors that support processor power management features may experience decreased performance KB938826 - A Windows XP-based multiprocessor computer does not restart automatically after a memory dump operation KB951126 - A multiprocessor computer that is running Windows XP stops responding on a black screen after you resume the computer from hibernation KB954434 - A multiprocessor computer that is running a Windows XP, Windows Server 2003, or Windows Vista stops responding on a black screen after you resume the computer from hibernation KB958244 - The system may stop responding when you restart a Windows XP-based multicore computer Only need, to fully update: KB889673 - A hardware DEP-enabled computer may stop responding when you resume from standby or from hibernation in Windows XP Service Pack 2 KB938826 - A Windows XP-based multiprocessor computer does not restart automatically after a memory dump operation KB954434 - A multiprocessor computer that is running a Windows XP, Windows Server 2003, or Windows Vista stops responding on a black screen after you resume the computer from hibernation KB958244 - The system may stop responding when you restart a Windows XP-based multicore computer Other Fixes of interest despite not being HAL: KB952117 - When you try to put a Windows XP-based computer into hibernation or into standby, the computer stops responding

Some of the XP x64 App Addons aren't on the MediaFire