VanguardLH wrote:

That doesn't mean the 32-bit version is slower. It does mean
you can't open documents bigger than 4 GB;

32-bit does not mean that.

Without dwelling on detail, 32-bit Photoshop could
malloc around 1.8GB of memory. If Photoshop had multiple
undo buffers, then the uncompressed size of images in
memory could be "relatively small" by modern standards.
The 1.8GB value was related to the 2GGB:2GB address
space split, with 2GB for kernel addresses and 2GB for
user-space addresses. And the malloc of memory for the
program is in user space, and in that example, can't be
more than 2GB. And for Photoshop, this number happened
to be 1.8GB. We don't really know what filesizes might
correspond to the availability of that much RAM.
Maybe a 2MB GIF decompresses to fill a 1.8GB space
in memory for example.

There are filesystem primitives, that support 64-bit
operands from a 32 bit call. I can seek to an offset
of 7.8TB and read one megabyte if I want. I can use
open64() and seek64() in a 32-bit application.
The operands are 64-bit operands in the call.

The FAT32 filesystem has a limit to the size of a
single individual file, but this is not what we worry
about with 32-bit applications. The 32-bit application
may not even know or care, that the filesystem is
FAT32 or NTFS (limits or no limits). It's only
if we try to exceed those limits, a write error
occurs. Like take Firefox downloading onto a FAT32
volume - it does not warn us in advance "hey, if this
download is over 4GB, you are screwed". It just
hits 4GB, returns a "too bad, so sad" error and
quits. And it's up to the user to smack their
forehead and declare "doh, dammit, FAT32 limit".

For document processing, 1.8GB of RAM is pretty decent.
The terrible scroll performance will drive you crazy,
before it runs out of RAM.

Paul