Paul wrote:

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

How is a 32-bit program going to manage a data block (with the document)
in memory that is over 4 GB in size? Yes, the program can, as you
implied, use a buffer to load part of the over 4 GB file into memory,
but, say, a search that scans the 4+ GB memory for the data block is
going to dump one buffer to move it into later bytes of the file. That
is for direct memory access to the file's contents. Sure, the pagefile
could get used (providing the user hasn't made it too small), but that
means slowed buffer due to paging. 64-bit apps can access far more
memory directly than the 4 GB that 32-bit apps, even after subtracting
the reserved memory space for the OS (and worse if the OP is stealing
some system RAM for the video buffer). Of course, if the OP doesn't
have more than 4 GB of system RAM, the advantages of 64-bit hardware is
lost.

With a 32-bit OS, the largest block of memory accessible as one [data]
block is 4 GB. However, the OP never even mentioned the bitwidth of his
Windows installation. He may not even be able to install the 64-bit
version of the program if he is still running a 32-bitwidth version of
Windows. Why would he still be running a 32-bit version of Windows even
if his hardware supports 64-bits? The 64-bit Windows has only the WOW64
(Windows 32 on Windows 64) emulator that allows running 32-bit programs
on the 64-bit OS. The 32-bit Windows has the WOW32 (Windows 16 on
Windows 32) emulator allowing it to run old 16-bit programs. If the OP
has critical or very important 16-bit apps, he is using 32-bit Windows.
Lots of users complained when they moved to 64-bit Windows to find out
their old 16-bit programs wouldn't run or couldn't even [re]install.

With a 4GB chunk of memory in a data block containing the document, it
would take about a million pages in a document with an average of 4K per
pages before buffering would be needed to chunk around inside the
document to see all parts of it. I've never created nor had to view or
edit a document anywhere near that size in pages, so FreeOffice
available only as a 32-bit app will very likely suit the OP just fine.
However, the hardware and OS protections afforded to 64-bit apps won't
apply to 32-bit apps.

The OS bitwidth info wasn't included in the OP's post or yet in a
followup post. If the OP is on 32-bit Windows, that there is a 64-bit
version of Softmaker payware and only a 32-bit version of FreeOffice is
irrelevant. With 32-bit Windows, the OP will be using either the 32-bit
freeware version (FreeOffice) or the 32-bit version of Softmaker Office
(payware). Peculiarly, while Softmaker makes a 64-bit version of
FreeOffice for other operating systems, they don't have one for Windows.
Why would they bother with a 64-bit app for the other OS'es if there
were no advantage over a 32-bit version? They know the huge marketshare
for their freeware are Windows users, so they lose nothing by providing
the 64-bit version for non-Windows platforms while using the difference
as a lure on Windows to buy their payware version.