All Activity

@Dietmar A CSMWrap version has been released, which allows you to use the BIOS video from the disk from EFI\Boot\vgabios.bin https://github.com/FlyGoat/CSMWrap/issues/37#issuecomment-3030297746 Compiled bins: https://github.com/FlyGoat/CSMWrap/actions/runs/16040013218 Thanks to this, WinXP boot OK on iGPU using ntldr as on a normal Legacy machine - I tested CoffeeLake, Haswell, SandyBridge: CSM Disabled, iGPU VBIOS extracted from motherboard bios. Now - I don't have to use SeaVGABIOS and Longhorn bootmgr 5472 loader.

Yes; the page could've been clearer on exactly how "modern" your browser's Javascript needed to be. At any rate, UXP does seem up to the task, albeit inefficiently. There are many reasons that might have caused me to get the "denied" page, but it wasn't worth the effort to track it down. I was just wondering what kind of nonsense we WWW users have to deal with now, and why. My curiosity is "mostly" satisfied now.

I just use comodo in paranoid mode. I have around 3500 network intrusions a day FROM windows system files calling home to random internet 443 ips... it's insane. And of course run in metered mode on my main networks to effectively block all updates. And naturally when I did update, it broke things (and tried to update defender, but was never activated thanks to Commodo already being sufficient for windows' logic). Now the start bar is over everything instead of under, so annoying. That and I lost all of my nvidia custom resolutions and can't save when I go to try to re-add it. Thanks Microsux! Upside is, I bought a new laptop that already had admin and a user setup, so I didn't need to open a microsoft account. Naturally, being paranoid, I created a new admin user and disabled the original admin user, all w/o MS account trash. I also removed all the telemetry crap (way more than win7) and uninstalled onedrive. Only downside there is you can't use the fingerprint reader like in the past to auth w/o windows HELLo.

Does this promise anything more than has been possible in Server 2003 without patching?

at least it won't contain stupid emoticon

Members are reminded of forum rule 1a. 1a. This is not a warez site! Links/Requests to warez and/or illegal material (e.g., cracks, serials, etc.) will not be tolerated. Discussion of circumventing WGA/activation/timebombs/license restrictions, use of keygens, or any other illegal activity, including, but not limited to, requests for help where pirated software is being used or being discussed, will also not be tolerated. Offenders may be banned on first violation. It is expressly forbidden to post links to, or to discuss, any form of warez.

Yes. I was getting rather tired when I wrote that and the post to you and did not proofread the post well enough. I had originally started writing around that quoted question, but then tried to patch the SP2 HALs myself to check. Something I wanted to ask, but forgot, is: Whether it is important for you to stay on an old Windows XP Service Pack 2 level kernel? If not, you might try a newer kernel version (and other possibly other updates).

WinXPPAE 3.5 can't patch any SP2 hal version: Patching halmacpi.dll (ACPI Multiprocessor PC HAL)... Invalid file!

In case anyone is interested, here attached are the two pairs of files used on the system by daniel_k's patch (hal2.dll and ntkrnl32.exe) and the '64G' patch (hal64g.dll and ntkl64.exe). I'm afraid I don't know how to analyse them to see just how similar they are. Looking with CFF Explorer, the dlls certainly do look very similar (they are exactly the same size), although of course not identical. If anyone with the necessary skills can compare them properly, I would be very interested to know the results! RAM Patches Files.zip

Totally right, interesting observation! "It was dropped in Beta 1 (Build 5112) of Vista for all errors except boot loader errors. It can also be found (but rarely) in early builds of Windows 98, even when it was known as codename "Memphis", because these early builds have poor/broken ACPI support." https://www.betaarchive.com/wiki/index.php?title=Windows_crash_screens

Seeking a video driver. Turns out this model requires a modified ACPI to install properly? Other integrations did not work regardless of SATA driver and often froze. I just need to find a working Windows XP driver for NVIDIA GT 230, yet it doesn't seem to work and the display settings states the driver was meant for an earlier version of Windows? Strange. Hopefully GeForce Release 185 for Notebooks 185.81 works...it didn't... EDIT: 285.58 installed. It seems NVIDIA removed it from later packages. However...I'm stuck at a lower resolution opposed to 1080...

It's a convoluted mess... See issue #12482. You may need to provide a PO Token. That said, I didn't yet have this warning (I download 1080p avc1/mp4a videos most of the time). Related?

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.