Post by Tim SlatteryPost by PaulYou can run a 32-bit executable on a 64-bit OS.
The address space available to 32-bit executables
forms a kind of implicit "quota" and prevents
zooming off to infinity.
Umm??
32-bit programs in Windows (either 32-bit Windows or 64-bit Windows)
get a 4GB virtual memory space to run in. Why 4GB? Because that's how
many bytes you can address with 32 bits. It has nothing to do with
quotas or runaways.
64-bit executables currently get a 128TB virtual memory space. 64 bits
will address far, far, more than 128TB. But current hardware
constraints must be taken into consideration.
Still, the huge VM space for 64-bit programs makes it much easier for
them to handle huge data sets - video, or large pictures or whatever
you need.
Not quite correct, Obiwan.
The 4GB address space, is split into userland and kernel space.
By default the split is 2GB:2GB, and when certain things are
taken into account, a 32 bit process "cannot use more than
roughly 1.8GB of RAM". That's a rough rule of thumb.
That's the actual address space limit.
When you run Photoshop x86 (a large application), then it
might report usage up to 1.8GB.
The kernel address space is needed so you can call into the
kernel for your various low level things.
If you alter the split (I've done this on WinXP, long enough
to finish a build of Firefox), you can do the split
as 3GB:1GB. But if you do that, there are some side effects
that hint maybe leaving things alone full-time was best.
You should not run a daily driver with WinXP 3GB:1GB .
https://learn.microsoft.com/en-us/windows/win32/memory/4-gigabyte-tuning
"The /3GB switch makes a full 3 GB of virtual address space
available to applications and reduces the amount available
to the system to 1 GB.' [The "system" being kernel space]
The total address space is 4GB, but it's split.
Programs can be Large Address Aware. This allows a program
to actually use 3GB when you set the split to 3GB:1GB.
This might have had something to do with editbin.exe
(dumpbin.exe to verify).
editbin /LARGEADDRESSAWARE:NO program.exe # Turn it off
editbin /LARGEADDRESSAWARE program.exe # Turn it on
I'm having some trouble with my test programs that show
the effects. I don't know if this is a side effect of being on
W11 or what. So I redid my editbins, and dumpbins, and
had a go at it. First the canonical article, now a bit uglified
by web monkeys. I ran eight test cases for actual test, and
copied in the six that were important (met the conditions
mentioned in the table). The left column tests were done
in a 32-bit VM, the right column tests were done native in Terminal.
https://learn.microsoft.com/en-us/windows/win32/memory/memory-limits-for-windows-releases
Limit on x86 Limit on x64
32 bit process 2GB 2GB
3GB with LAA 4GB with LAA
64 bit process --- 2GB
License-limit etc with LAA
******************************** Actual test **************************************
C:\Downloads>malloc-no D:\MALLOC\NOT>malloc
01916 megabytes t=001.190557 01898 megabytes t=000.308925
bcdedit /set IncreaseUserVA 3072
C:\Downloads>malloc-yes D:\MALLOC>malloc
02879 megabytes t=001.889975 03821 megabytes t=000.613203
D:\MALLOC\NOT>malloc64
01901 megabytes t=000.317975
D:\MALLOC>malloc64
30632 megabytes t=005.741883
The last one stopped at 30GB, only because other RAM in the computer
is occupied right now, but not doing computing. The RAM license on this
machine does not interfere. I had to buy Windows 7 Pro on the other machine,
to get enough memory license to use all the RAM.
If there wasn't a RAM license, the upper limit on 64-bit is controlled
by CPU arch. One of the CPUs was 2^43, a slightly later one (perhaps
the thing I'm typing on) is 2^48. There is a hardware trick for the
other bits. On AMD, even a desktop CPU, has the same address bit width
as the server CPUs. Intel likely does things a bit differently, but
this is not visible in normal use anyway. It's just an academic note.
For example, an AMD machine could stuff 6TB in it today, a server,
but I doubt that's clunking 2^48 over the head. I'm not even going
to calc. But when machines have limits that matter to Intel or AMD
business plan, you may find the address decoder spoils your fun.
Even if 6TB would fit in my desktop consumer machine, it would be
neatly snipped off and unusable, above 128GB.
So actually, while you can show me a 64-bit register value for an
address on your screen, if you dump enough of them, you might notice
something peculiar about the top bits. The top bits are used for
some other purpose I would have to look up. Irrelevant to use,
but important to "someone". The hardware, the high speed comm links
between cores (coherent cache and so on), the address field on the
links might show six bytes of address bits, not eight. Since carrying
the extra two bytes, slows down the link a bit, it's in your best
interest to "only carry what the arch predicts is needed".
*******
Getting back to my original comment, 01898 megabytes is
what I was referring to as an implicit quota. I would
have to check specific executables to see if editbin has
been used on them.
In the past, using LAA was a waste of time, since
no user would be setting the /3GB switch or using
bcdedit like that for a later OS. But using dumpbin
you can check.
H:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.30.30705\bin\Hostx64\x64>
dumpbin /headers D:\MALLOC\malloc.exe
Microsoft (R) COFF/PE Dumper Version 14.30.30706.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file D:\MALLOC\malloc.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (x86)
F number of sections
53D49DBF time date stamp Sun Jul 27 02:35:43 2014
10800 file pointer to symbol table
45B number of symbols
E0 size of optional header
127 characteristics
Relocations stripped
Executable
Line numbers stripped
Application can handle large (>2GB) addresses <=== LAA is Yes
32 bit word machine
Paul