Updated drivers for Windows XP SP3 and Windows 2003 SP2 (x32/x64) for modern hardware

[rubberwarrior]

On 7/15/2026 at 5:22 PM, reboot12 said:

@UsefulAGKHelper

I used a Dell 3040 to test the eMMC driver and it worked, but the computer has poor parameters to use it for anything specific , so I don't care about I2C support. I'm basically not interested in laptops and unusual mini-computers.

Besides, my goal was to add UEFI, NVMe, USB3 and ACPI support to WinXP 64-bit and I managed to achieve it, so overall the goal was achieved. I think I've had enough and don't want to continue patching - anyway, there's a lack of testers and too little interest

I've done a lot anyway:

• I added UEFI boot support
• I added basic UEFI NVRAM Boot Menu editing support
• I added restart from OS to UEFI firmware
• I patched kdcom.dll and bootvid.dll to easy debugging
• I patched hal.dll for restart working
• I successfully tested booting from the eMMC disk

I have my favorite modern desktop WinXP 64-bit computer with all working devices (full drivers) - 8 Gen CPU, 16 GB RAM, an NVMe drive from which it boots in 18 seconds + PCIe graphics card with working 3D and a large 2K monitor, sound, network.

The motherboard in this computer does not limit me like a laptop or some unusual mini-computer with soldered CPU, RAM or eMMC disk:

• I decide which keyboard and mouse I will use - PS/2 or USB
• I decide whether I will use a SATA or NVMe drive
• I decide which graphics, sound and network card I will use - PCI or PCIe
• I decide what processor and how much RAM I will use
• I have COM ports for debugging

Hi there. I'm new here but I can possibly help with testing drivers on my VM. Would it work on a VM or do I need to test the drivers on real hardware?

[rubberwarrior]

On 7/16/2026 at 4:49 PM, windows2 said:

If you still want to do this for XP 64-bit, I might be able to help you find testers. You can create a new post in the win2000_dev_community support section, and I will try to find people to test it with you. all I can say is that the future is now with the 64-bit system.

Really? For the most time windows xp x64 wasn't really popular

[windows2]

On 7/24/2026 at 5:32 AM, rubberwarrior said:

Really? For the most time windows xp x64 wasn't really popular

Not that it matters much right now, but many applications no longer support 32-bit. Windows XP with One-Core-API can still run a lot of modern software, but in the long run, only the x64 version will have the minimum capabilities needed for everyday use.

[user57]

3 hours ago, windows2 said:

Not that it matters much right now, but many applications no longer support 32-bit. Windows XP with One-Core-API can still run a lot of modern software, but in the long run, only the x64 version will have the minimum capabilities needed for everyday use.

we getting off-topic again

but can you explain why ?

that guy might wrote a other video where is said the oposite but the questions he answers to are asking it wrong (for example he is being asked for a short instruction list somewhere in the code - why it would be only made there ? people are seeing this problem quite often)

64 bit app´s result in bigger file sized because for example the offsets are bigger, there are things coming together (to avoid this they used the trick list, for example they didnt use always the full 64 bits or even 32 bit instructions)

often x64 app´s in elder compiliers use a 32 bit instruction set instead of a 64 bit instruction set (shown in regedit_64.jpg)

they are aware of this problem, bigger instructions means more demand, in the regedit (64 bit) case they use a 32 bit instruction set

so in theory it is not even a x64 bit application, but it is bigger in size even tho some tricks where used

 

then there is also useally the 4 GB question
that is also a longer story

in fact there are no 4 GB moves, or 4 megabytes moves, or 100 mbit/s
these things are made via a assembly command
and these are in common 32 bit or 64 bit (16 and 8 are only used if the data dont is smaller then 32 bit or 16 bit then 8 bit is used)
now comes the good part about that, the cpu for example the TLB can see the incoming commands
then there is actually no speed loss
for example there was the a older question in quad-pumped questions in the LGA 775 socket question
instead of pumping just 32 bit it quad pumps the 32 bit *4 aka 128 bit or more

the cpu´s gone longly away from just a clockrate + the 32 wires

32 bit is not limited for 4 GB of RAM either
(for the 32 bit move question it also would make no difference in speed or memsize)

in a programming language it normally looks like this like memmove(offset1,offset2, 5 megabyte)

https://www.geeksforgeeks.org/cpp/memmove-in-cc/

but that is always being translated into 32 bit moves maybe 64 moves (but these are not faster, the reason i tryed to explain buffering and such) 

,

here are the norms for passing 4 GB of ram in 32 bit
PSE (page size extension) and 
PAE (physical address extension) and
paging/segments
these exits since AMD athlon (1999) and for intel pentium 2 (1998?)
https://msfn.org/board/uploads/monthly_2024_10/page_size_method_PSE.jpg.21624fe4f9fa5ef04f8f49d5bf6f8d52.jpg

shortly said - these so called "virtual offsets (VA)" in 32 bit are not physical ones
physical ones are made via paging 

why 4 gb isnt used for a 32 bit application then  ? the reason goes rather back that in that time you barly needed more then 2 GB ram in only 1 application

then you could see that microsoft didnt use the extra segments to its full potential - rather they used maybe a few kilobytes of it 

the next reason is the compiler, the compiler normally just knows the 32 bit offset

it dont know how to generate a memflow over segments (the memmove command for example cant do that) 

so all the applications are compiled to have it with the 4 gb limit - but more would be possible 

there is no "continuous flow" question for the "32 bit move question" - 32 bit are a very small amount lets say we want to move 1024 (1 kb) that would make 32 times the 32 bit moves

and for that reason if the compiler (or better said the compiled code) at some point would reach the 4 GB ram - but since its a very small piece of 32 bits 

the cpu could not even reconize the difference it then would just say ds:00000000 (0002:00000000) instead of ds:ffffffff (0001:ffffffff)

but again a normal compiler do not know this method!

 

 

also something you can test the speed if 32 bit and 64 bit are slower or faster
is the heic encoder i wrote 
just turn off the hardware acceleration (then normal instructions are used)
i can compile a 64 bit version if you want but it makes no difference
the hardware acceleration use the hardware speed registers (MMX,SSE, AVX)
and these can move 512 bit 256 bit 128 bit (depending on what your cpu can do)
also they can interact - makes them a lot faster
so in sence of speed you also dont find yourself in a better position for x64

https://msfn.org/board/topic/185879-winxp-hevcheifheic-image-encoderdecoder

 

there is also a elder method called the ramdisc, but the ramdisc has to remap the virtual address space (it can use more then 4 gb of ram, but when it whats to see a other piece of that it has to make the pagein/remap) 

 

for a normal compiler you just set it from 32 bit to 64 bit

but 64 bit applications give an error to 32 bit operating systems - so i think 32 bit has the advantage in that question

you can run a 32 bit compiled app also on 64 bit - its like no problem - its not slower - often even a little faster and smaller

Edited 1 hour ago by user57