For 2GB of ram, 32 bit seems like a good option. That's my usual cutoff point for thinking of 32 bit vs 64 bit machines... 2 GB and up is in the realm of 64 bit OS's.

Unless you need 64-bit support for an app/hardware you use (or to go past RAM limits - as you mentioned), you should use 32-bit OS on older PCs - even those with up to 3GB of RAM.

For Windows 10, 2 GB is rather tight for 64-bit. Running 32-bit may give you just a tad more breathing space.
For XP x64, 2 GB is fine though. I first ran XP x64 back when my system had only 1 GB of memory, and it was fine.

I dunno about Win10, but with Win7, a clean install of the 64-bit version consumes around ~800MB of memory at idle, while the 32-bit version is closer to ~550MB. YMMV. I'd stick with 32-bit if it isn't possible to add more memory to those machines.

If it's XP, then with 2GB the RAM isn't going to be much of an issue, so I could go either way.
If you want to be biased in favor of newer software then I'd prefer x64, especially if you know you'll run anything that has x64 versions available or there's a chance of wanting/needing to upgrade the RAM further.
If you want to be biased in favor of older software or devices, than I'd prefer x86. There are some older apps and hardware that will run on XP32 but not on XP64 (or any newer version of Windows). There's also x64's general incompatibility with all Win16 software, if you will run anything that old.

I have 2 machines running XP64. RAM isn't a problem, but I will need to reinstall one of them with XP32 due to legacy issues. I need it to run some things that don't like XP64, including an LPT-based EPROM programmer and some oscilloscope software, maybe some other things I'm forgetting. On my main PC though, XP64 does everything I need.

I remember trying XP 64-bit once. It made me want to stab myself to death with a blunt tea spoon.

My final XP (x86) machine was running with 4GiB of RAM. :)
I was able to get 3,25GiB of main memory on XP, because I kept the video memory little (between 64MiB to 128MiB).
The memory regions past 3,25GiB were reserved for the PCI address space (like the 640KiB to 1MiB region was for ISA bus on DOS PCs).
In my opinion, x64 makes sense if you have at least 4GiB of RAM or lots of video memory. Otherwise, you'll loose compatibility without a notable gain.

Edit: Back in the 2000s, I upgraded several aged PCs of friends and acquaintances with more memory.
From what I remember, the original Windows XP needed more than 256MiB (say 384 or 512MiB) of RAM to run fluently.
With Windows XP SP1, I noticed a performance gain if memory was beyond 768MiB.
With SP2, it was somewhen at the 1,5GiB boundary again.
Anyway, it was different hardware back then and my memory might play tricks on me.
In either case, I remember 384MiB and 768MiB beeing important numbers to me.
When I upgraded my ex-laptops, they improved things notably..

Matth79 wrote:

Kicking around a couple of systems between modern and retro, well, old XP systems that I persuaded to run Windows 10 just to see if it would work.

Now with 2GB, is it better to go x86 32 bit (supposedly uses les RAM) or 64 bit?
Where is the breakpoint? I know you NEED 64 bit to break the 3.25GB barrier and 32 bit is fading under the weight of modern games, but a quick look at some files did not show a huge size difference - in one case, the 64 bit was actually smaller!

1) just because the OS is 64-bit doesn't mean the apps are. The kernel does not take up a huge amount of memory.
2) you don't NEED a 64-bit OS to break your imaginary "barrier" of 3.5GB. Windows in it's default form has that limitation, although there are kernel extensions to 32-bit Windows to remove that limitation - but it breaks a lot of application compatibility.
3) 32-bit is not "fading" under the weight of modern games. If the game is 64-bit it won't even run under 32-bit windows, if it is 32-bit it won't make a grain of difference to game performance if the kernel is 32/64-bit.
4) 64-bit file sizes are almost always larger, if they are different it might be due to some other factor in the build/compilation of that program.

Jo22 wrote:

I was able to get 3,25GiB of main memory on XP, because I kept the video memory little (between 64MiB to 128MiB).
The memory regions past 3,25GiB were reserved for the PCI address space (like the 640KiB to 1MiB region was for ISA bus on DOS PCs).

I went up to 3,44GB 😀

agent_x007 wrote:

went up to 3,44GB 😀

Oh, that's cool. 😎 Looks like your chipset is a good one (doesn't litter up that space with uneccessary stuff).
I knew it was something close to 3.25GiB, but wasn't 100% sure about it. I had the limit at 3.25GiB, as far as I remember. 😀

Edit: PAE and 36-Bit addressijng (~since Pentium Pro) kernals do support an address space larger than 4GiB on 32-Bit Windows.
As far as I remember, the Datacenter Editions supported that. The 36-Bit addressing breaks some older device drivers (overflow/wrap-around issues),
so it was never used in mainstream editions of Windows. PAE, well.. It looks like an reincarnation of Expaned Memory (EMS) to me. 😉
Edit: What I mean is called AWE (Address Windowing Extensions), actually. It uses PAE on 32-Bit Windows.

squiggly wrote:

1) just because the OS is 64-bit doesn't mean the apps are. The kernel does not take up a huge amount of memory. 2) you don't NE […]
Show full quote

Matth79 wrote:

Kicking around a couple of systems between modern and retro, well, old XP systems that I persuaded to run Windows 10 just to see if it would work.

Now with 2GB, is it better to go x86 32 bit (supposedly uses les RAM) or 64 bit?
Where is the breakpoint? I know you NEED 64 bit to break the 3.25GB barrier and 32 bit is fading under the weight of modern games, but a quick look at some files did not show a huge size difference - in one case, the 64 bit was actually smaller!

1) just because the OS is 64-bit doesn't mean the apps are. The kernel does not take up a huge amount of memory.
2) you don't NEED a 64-bit OS to break your imaginary "barrier" of 3.5GB. Windows in it's default form has that limitation, although there are kernel extensions to 32-bit Windows to remove that limitation - but it breaks a lot of application compatibility.
3) 32-bit is not "fading" under the weight of modern games. If the game is 64-bit it won't even run under 32-bit windows, if it is 32-bit it won't make a grain of difference to game performance if the kernel is 32/64-bit.
4) 64-bit file sizes are almost always larger, if they are different it might be due to some other factor in the build/compilation of that program.

I presume you mean PAE. That lifts the overall limit for RAM, although each process is still stuck at 32 bit pointers.

gdjacobs wrote:

squiggly wrote:

1) just because the OS is 64-bit doesn't mean the apps are. The kernel does not take up a huge amount of memory. 2) you don't NE […]
Show full quote

Matth79 wrote:

Kicking around a couple of systems between modern and retro, well, old XP systems that I persuaded to run Windows 10 just to see if it would work.

Now with 2GB, is it better to go x86 32 bit (supposedly uses les RAM) or 64 bit?
Where is the breakpoint? I know you NEED 64 bit to break the 3.25GB barrier and 32 bit is fading under the weight of modern games, but a quick look at some files did not show a huge size difference - in one case, the 64 bit was actually smaller!

1) just because the OS is 64-bit doesn't mean the apps are. The kernel does not take up a huge amount of memory.
2) you don't NEED a 64-bit OS to break your imaginary "barrier" of 3.5GB. Windows in it's default form has that limitation, although there are kernel extensions to 32-bit Windows to remove that limitation - but it breaks a lot of application compatibility.
3) 32-bit is not "fading" under the weight of modern games. If the game is 64-bit it won't even run under 32-bit windows, if it is 32-bit it won't make a grain of difference to game performance if the kernel is 32/64-bit.
4) 64-bit file sizes are almost always larger, if they are different it might be due to some other factor in the build/compilation of that program.

I presume you mean PAE. That lifts the overall limit for RAM, although each process is still stuck at 32 bit pointers.

And?

squiggly wrote:

And?

Not explaining the fundamental limitations of PAE was disingenuous.

Personally I wouldn't install a 64-bit OS on a computer with 4GB or less RAM, unless you have a program that specifically requires it. You're posting on a PC gaming forum and a lot of old PC game uses 16-bit installers that are really annoying to deal with on 64-bit OS, plus there are a lot of games that are 16-bit that won't work on a 64-bit OS and will require emulators/virtualization to run.

32-bit applications running under a 64-bit OS are basically running in the same way as PAE: because of the extra addressing space, each process can get the full 4 GB of virtual address space, whereas under a 32-bit OS, they only got 2 GB (or 3 GB with a special boot option), because the OS had to reserve the rest for kernel, drivers and other shared memory-mapped stuff.

Plenty of food for thought, I'd always stuck by the perceived wisdom, in fact, being dubious if the extra bit of 4GB recovered made up for the greater bulk of 64 bit. Just wondered if it was one of those things that just got to be the way it was always done

I think the biggest problem was (and still is) lack of software.
Back when I ran x64, the only game that had an x64 version was Far Cry. And yes, it made a difference. Performance was better, especially load times were shorter (even with just 1 or 2 GB of memory).

x64 versions aren't naturally better though. The main reason I started using an x64 version of Windows was to test my own code for portability. What I quickly found was that some code ran slower in x64 more than x86 mode, if I just recompiled it. So I ended up looking for x64 bottlenecks and optimizing my code.
There was an experimental x64 version of Steam some Source Engine games back in the day, most notably Half-Life 2. These games were notorious for running considerably worse than the x86 versions. Probably for similar reasons as my own code: had some bottlenecks they never addressed.
At some point, they just pulled the x64 versions, and I don't think they ever came back.

I can't disagree. By the end of the 2000s I thought about recompiling my own little VB6 stuff using VB.NET's transpiler.
Back then, I expected x64 to catch on widely and normal Win32 programs to disappear.
Alas, it didn't happen. Now I don't bother anymore.
(On a side note: Win10 on ARM promised Win32/x86 support but not native Win64/x64 or Win64/ARM).
I wouldn't be surprised if classic Win32/x86 compatibility will outlive .NET framework and native Win64 apps in the end.

Yes, the whole thing is somewhat ironic. Microsoft originally intended Windows NT to be a platform-agnostic OS. The file format they introduced is even known as PE: Portable Executable.
The Win32 API was designed to be able to compile applications from a single codebase to a variety of CPU architectures. This also made the move from 32-bit to 64-bit reasonably painless. I didn't have to spend all that much time to just get my code running in x64 mode because of that. I also ported my code to ARM later, and in theory most of it should also be able to compile on Itanium, Alpha and perhaps even MIPS and PowerPC.

However, it just seems that most developers didn't bother. Why spend time at all on recompiling and testing, when you can just continue to use x86?
I feel that Windows Phone/10 Mobile is mostly a victim of this complacency of Windows developers. It is very easy to port most Win32 code to a phone or tablet. Yes, you'd have to redesign the UI to fit the different form factor and touch controls, but you'd have to do that on any mobile platform anyway. Everything else is very portable, you even get the full DirectX environment, so especially games are easy to port.
It just never happened.