>>250095
MyPal, OpenOffice, and 7-zip all have 32-bit binaries, but you're probably going to suffer from the 4GB RAM limitation unless you activate the /pae (Physical Address Expansion) switch on your boot.ini (which will let 32-bit Xp support more than 4GB of RAM, assuming your CPU supports PAE) and make sure your 32-bit software is LAA (Large Address Aware) flagged - you can use https://ntcore.com/4gb-patch/ to make manually flag binaries (exe files) Large Address Aware so it can use 4GB RAM instead of being capped at 2 (make sure MyPal and OpenOffice have the LAA flag active). There is a slight risk that software isn't written to handle more than 2GB of memory (pointer arithmetic with lazy signed integers because of shit coders causes havoc because numbers over 2GB get interpreted as negative numbers instead) in which case it'll crash at some point and you'll want to undo the patch, but that's rare these days. Most software, even by shit coders, can be flagged LAA safely if it isn't already. It makes a huge difference.
Basically, it still works, but obviously you're going to be able to run less shit. Can't run 64-bit software on 32-bit Xp, after all. But there's plenty of open source shit that's got 32-bit binaries.
But, on the upshot of things, you can now run old-school 16-bit Windows software (which uses 20-bit addressing space, because otherwise it'd only access 1MB of RAM) and commands on 32-bit Xp that are gone or unusable with 64-bit Xp (because while 64-bit Xp is 32-bit compatible, it isn't 16-bit compatible, unlike 32-bit Xp). Then again people use DOSBox these days for their 16 to 20 bit needs. The real fancy part is just being able to use 16-bit era Windows software in case you want to fuck with WINFILE.EXE and PROGMAN.EXE (These program, largely holdovers from Windows 3.11 era, are still available in 32-bit Xp) and other shit. You can also use glorious DOS commands like EDLIN and DEBUG (which is very useful and easy if you're interested in teaching yourself assembly programming for DOS - just look up Ralf Brown's Interrupt List). I still have batch scripts that would pipe input into those programs to achieve some voodoo you don't expect MS-DOS batch scripts' limited as fuck syntax to pull. I think the craziest batch script I'd seen that uses that crap was Laura Fairhead making a DOS 5.0 era chess game as a batch script.
Laura's website: https://web.archive.org/web/20110707070232/http://lf.8k.com/
The chess BAT: https://web.archive.org/web/20110721192043/http://lf.8k.com/BAT/CHESS.HTM
If you want to fuck with MS-DOS ASM (which unlike later Windows OSs is actually fairly intuitive for ASM programming), here is the RBIL: http://www.ctyme.com/rbrown.htm
You will still need to find your own guide to 16 bit ASM commands, but it's pretty easy to do 16-bit ASM. Go nuts. Learning how to write basic software in MS-DOS ASM does a world of good for making your ability to understand pointers, buffer overflows, and type-casting in programming feel easy and intuitive once you understand what is happening under the hood. Learning 16-bit ASM spoiled me.
Nowadays MS has basically replaced the Command Prompt (which it still supports for legacy reasons) with the PowerShell because they knew Command Prompt had degenerated into shit and in the MS bureaucracy it was easier to get a cool new feature approved than maintain an old one.
Anyway, 32-bit Xp loses out on 64-bit software, but for retro purposes it can be even more fun if you want to fuck with 16-bit Windows software.
One thing that may fuck with you though is lack of driver support for Windows Xp. Some hardware is just unsupported.