deksar wrote on 2022-12-30, 09:53:

Hi there. […]
Show full quote

Hi there.

If 32-bit Windows can address maximum 4096MB of physical memory, and if my system has 2x2 GB RAM slots (4 GB of System RAM in total), then what happens when I have a GPU that has 3GB of VRAM?

Only 1 GB of RAM (System RAM) remains for rest of the system?

Thanks.

No, you'll have the same ~3.3GB usable RAM for your system as you would with a 256MB GPU or 4GB GPU.

I don't claim to understand how 32bit Windows maps the usable memory, maybe someone else can chime in and unravel that mystery, but you don't need to worry about all of your RAM disappearing into some 32bit void.

deksar wrote on 2022-12-30, 09:53:

Hi there. […]
Show full quote

Hi there.

If 32-bit Windows can address maximum 4096MB of physical memory, and if my system has 2x2 GB RAM slots (4 GB of System RAM in total), then what happens when I have a GPU that has 3GB of VRAM?

Only 1 GB of RAM (System RAM) remains for rest of the system?

Thanks.

Before i had a nvidia GT710 2GB vram, and i had 3.6gb free, now i have a Radeon HD5760 1GB and 3GB free

Dont worry

Anyways, i have XP 32 bits and 8GB of ram, first i used PAE; but i have some old devices with ancient drivers dont work well with pae, what i did is a 5GB disk cache with primo ram disk, using hidden ram, 3GB swap file, and 2GB for temporary files

Works like a charm

Sombrero wrote on 2022-12-30, 10:16:

No, you'll have the same ~3.3GB usable RAM for your system as you would with a 256MB GPU or 4GB GPU.

Are we sure about that?

deksar wrote on 2022-12-30, 10:47:

Sombrero wrote on 2022-12-30, 10:16:

No, you'll have the same ~3.3GB usable RAM for your system as you would with a 256MB GPU or 4GB GPU.

Are we sure about that?

Yes we are.

32bit Windows doesn't subtract directly RAM minus VRAM, it just reserves a bit from the 4GB max RAM for stuff leaving about 3.3GB usable RAM even with a 4GB GPU. I'm not 100% certain does 4GB VRAM GPU's have all of the 4GB available for them but my guess would be yes. At any rate you are far, far more likely to run into a game that has trouble because you have too much VRAM than the opposite.

In 32-bit WinXP the maximum available memory is determined by the lowest starting address of any video card's linear frame buffer not by the amount of Video RAM.
Starting address of LFB:
0xC0000000 -> 3GB available
0xD0000000 -> 3.25GB available
0xE0000000 -> 3.5GB available
You can test this by checking the used memory resources of your VGA in device manager.
If you have 2 active modern VGA the available RAM would be less than with only 1 because the system has to reserve 2 LFB regions.
So even under a 32-bit OS you can use cards with 2/4 GB of Video RAM since addressing full video RAM is a concern of the driver. On the CPU side there's usually only a 256MB area in the PCI address space.

Apparently no card uses more than 256MB CPU address space even it has 2/4 GB of onboard VRAM.
But the point is the available max. RAM under 32-bit OS is not directly dependent even on the amount of used address space but the starting address of the card's LFB.
So even if your card has only 64MB VRAM and the used address space is only 64MB but its starting address is 0xC0000000 then you will only have 3GB available RAM under 32-bit WinXP.
While if you have an 1GB card that uses 256MB address space but its starting address is 0xD0000000 then you will have 3.25GB available RAM.

Regarding video memory handling and the 256MB area:
an analogy could be that under pure 16-bit real mode DOS that has an address limit of only 1MB you can use the full VGA frame buffer (8/16/32 MB etc.) through VESA driver/BIOS calls by using a 64KB area (A0000 - AFFFF) and bank switching.
A similar method is used in case of 32-bit Windows: while the CPU can only address directly maximum 256MB of video ram but through driver and API calls much more is available for applications for storing textures etc..

Also it is worth mentioning that you can use the unused RAM under XP for ramdrive. You can even put the pagefile on it.

@Edit:
Some examples:

Just remember the ReBAR-discussion on modern GPUs lately.
Even modern cards (normally) didn't map the whole memory into memory space. Only a small window.
With ReBAR, this window was configurable to be wider. But only 3xxx and higher GPUs (and AMD counterparts) support this by vbios/driver, so our old stuff is safe!

Falcosoft wrote on 2022-12-30, 11:52:

In 32-bit WinXP the maximum available memory is determined by the lowest starting address of any video card's linear frame buff […]
Show full quote

In 32-bit WinXP the maximum available memory is determined by the lowest starting address of any video card's linear frame buffer not by the amount of Video RAM.
Starting address of LFB:
0xC0000000 -> 3GB available
0xD0000000 -> 3.25GB available
0xE0000000 -> 3.5GB available
(snip)

So that's how it works, great stuff!

This reminds me of AGP Aperture Size in CMOS Setup..

https://www.evga.com/support/faq/FAQdetails.aspx?faqid=59067

The problem of limited memory in Windows XP in 32bit mode is conceptually similar to the 640Kb limit in MS-DOS / IBM-PC architecture. You can't communicate with devices using port mapped IO efficiently and need memory mapped IO. This reserved memory area has historically been at the end of addressable space. In IBM-PC architecture there was need to read BIOSes (system, video) and send data to devices on ISA bus. One method to do that is memory mapped IO. Instead of accessing system memory the data goes to/from devices. This may result in parts of the system memory being unavailable if you have too much memory. Back then memory mapped IO was configured usually using jumpers on the board. With PCI this moved to OS (if PNP OS option is on) or BIOS (if PNP OS option is off).

You may be able to increase usable memory size by changing AGP/PCI device IO memory configuration to occupy higher memory.

Thankfully with 64bit address space we are unlikely to ever run into this problem ever again.

From the P6 days onward, 32 bit x86 CPU's could address more than 4GB physical memory--
https://en.wikipedia.org/wiki/Physical_Address_Extension
PAE was first introduced by Intel in the Pentium Pro, and later by AMD in the Athlon processor.[2] It defines a page table hierarchy of three levels (instead of two), with table entries of 64 bits each instead of 32, allowing these CPUs to directly access a physical address space larger than 4 gigabytes (232 bytes).

32 bit XP can't use more than 2GB in a single process, but if you get PAE enabled and 4GB Tuning enabled, you should be able to use the 4GB RAM, just not all in the same process.
https://itstillworks.com/how-to-enable-pae-on … s-xp-10155.html

From the Microsoft docs, the 32bit OS's have a 384GB virtual address space
https://learn.microsoft.com/en-us/windows/win … mits_windows_xp
Kernel-mode virtual address space 1 GB to a maximum of 2 GB when 4GB tuning is enabled
User-mode virtual address space 2 GB for each 32-bit process
Paged pool 384 GB or system commit limit, whichever is smaller.

So you might you might be able to use cards with a lot of video memory if the driver pages the address space in and out.

After all, people have written 32bit drivers for 4GB video cards.

Looking at the limits of 32bit operating system don't forget about chipset's limits. Intel chipsets were 32bit till i945 . So PAE won't help for those systems

And also the fact that Microsoft hard-limits the 32-bit Client versions of Windows to 4GB physical RAM, since XP SP2 (Server versions have higher limits).

I vaguely remembered that the Pentium Pro was capable of 36-Bit addressing.

http://www.rcollins.org/ddj/Jul96/

http://www.rcollins.org/articles/2mpages/2MPages.html

So in theory, Windows NT could have had been prepared for it as early as 1995/1996..

However, the problem isn't so much Windows itself, perhaps. It's the device drivers.
Those made by third-party companies were being developed for the consumer releases of Windows.

Windows 2000 in the datacenter editions did support 4GB+ since a long time ago (32 CPUs / 64 GB max) .
With the built-in drivers or certified/tested server drivers, they may work just fine.

That being said, there also was PSE-36..
It was rather shortlived, though. NT 4 supported it.

https://en.wikipedia.org/wiki/PSE-36

Edit: Or in other words, what makes Windows XP SP2/SP3 so interesting is that it can
run "modern" software with a wide variety of hardware,
that it can use both "recent" hardware and outdated device drivers for outdated hardware.

(In my use case, that means support for old MIDI softh synths, gameport/MPU-401 and virtual null-modem drivers.)

Once we remove the requirement to support 32-Bit drivers, there's no real need for x86 XP anymore.

Windows XP x64 can run 32-Bit Windows XP applications just as good, if not better.
They can get a whole 4 GB per process, that's more than XP x86+PAE could ever offer.

Nowadays, legacy support for 16-Bit Windows could be provided by OTVDM/WineVDM.

So XP 64 is technically superior in all these things.
But it's not classic XP in several ways. It uses localization files, the base system underneath is English. Like Vista+. 😒👎

The "real" Windows XP was completely localized from inside out.
Like for example, the directory structure. Instead of "Programme" (German), "Programmes" (French), the program folder now uses "Program Files" (English) in XP x64.

This causes compatibility issues, because there's a space character being used.
So the programs must use "C:\Program Files\Foo", because C:\Program Files\Foo is no valid path.
By comparison, C:\Programme was.

This can lead to trouble with older applications that weren't written with English Windows in mind.
Permissions could be a problem for applications not installed in the official program directory, for example.

Edit: Small typos fixed.

Jo22 wrote on 2023-01-01, 11:12:

However, the problem isn't so much Windows itself, perhaps. It's the device drivers.

Yes, that's the excuse they claimed for leaving Windows-32 limited to 4 GB even though it has to support PAE anyway (to support NX/DEP); note that in exchange you get, on average, superior backwards compatibility even with drivers (personal experience: ATI X1300 using on LTSC 2019) and no driver signing racket!

You can in fact get a "PAE Patch" that basically runs the Windows 2003 kernel with full PAE support, but I can confirm you're back to [Win9x + 3rd party drivers] quality so why not just install 2003 directly?

I see. I assumed that PAE was mainly activated here in order to be able to use DEP or NX-Bit.

In essence, DEP tries fix the biggest flaw of that overrated flat-mode, the possibility of executing code in data.

In the old 16-Bit/80286 Protected Mode, there was memory-protection based on segmentation.
In theory, this feature is still available, but modern OSes nolonger use segmentation, sadly.

When developers moved to 32-Bit programming, the 80386 MMU (in 32-Bit Protected Mode) was usually instructed to inflate the segment size to 4GB, thus essentially making the segmentation-unit inoperable.

DEP tries to fix this my making certain code/data block in flat-memory non-executable.

If segmentation was still in use, the 4 GB barrier wouldn't exist in first place, also.

Physical memory might be still limited to 4GB, but virtual memory size (segmented) would be 1GB for 80286, 64TB for 80386+.

Edit: Another excuse by MS was that NTVDM depends on V86 and that V86 can't be used in x64 long mode.

Which in turn is merely true in part. NTVDM existed as pure emulator, too, for example.
Then, x64 long mode still permits execution of 16-Bit Protected Mode code, which most Windows 3.x applications use kind of.

Thing is, there's no real difference between Real-Mode and 16-Bit Protected Mode code if the default segment size of 64KB is used and no memory arithmetic is done.

That's why many Win16 programs run fine in different kernal modes of Windows 3.0 (Real-Mode and 16/32-Bit Protected Mode; 32-Bit PM with V86 additionally enabled).
The 16-Bit code in those applications merely does perform API calls to Windows (and DOS/int21h), it's not manipulating memory addresses (that's something Windows 1/2 applications sometimes did).

So it would be possible to run Windows 3 programs directly in x64 long mode, too, if a custom WoW was made for a non-V86 version of NTVDM:

Concurrent DOS had the ability to multi-task well-behaved DOS applications on a 80286, for example.

So if MS-DOS 5 (the core system) was modified to run in 16-Bit Protected-Mode VM,
it could host a modified Windows 3 with a modified 16-Bit Protected-Mode kernal that's x64 long mode friendly.

But even if a full-fledged emulator was used in 64-Bit Windows, performance would still be fine, because it would still be way past a 286/386/486 performance level.

Edit: I'm too chatty again. I'm sorry.

One more detail here.
From a process point of view - by default you can allocate up to 2gb of ram from your 32-bit application unless LARGEADDRESSAWARE flag is used to grow that to full 4gb.
On 64-bit OS the app instance can allocate up to 4gb ram.
On 32-bit OS this will take advantage of the additional ~1gb ram (/pae) which can be crucial in some cases.
You dont even need to build from source. There is a command line tool in VS that can set the hint in compiled executables.

deksar wrote on 2022-12-30, 09:53:

Hi there.

If 32-bit Windows can address maximum 4096MB of physical memory, and if my system has 2x2 GB RAM slots (4 GB of System RAM in total), then what happens when I have a GPU that has 3GB of VRAM?

Only 1 GB of RAM (System RAM) remains for rest of the system?

I guess I should have asked this yesterday, what CPU and Chipset are you using?

douglar wrote on 2023-01-01, 17:17:

I guess I should have asked this yesterday, what CPU and Chipset are you using?

Sure; Biostar H61MHV3 Lga 1155 Intel motherboard, i7-3770K (or i7-3770) CPU. So it's H61 chipset.

deksar wrote on 2023-01-04, 11:04:

Sure; Biostar H61MHV3 Lga 1155 Intel motherboard, i7-3770K (or i7-3770) CPU. So it's H61 chipset.

Nice Rig. Supports up to 16GB RAM. Should work with PAE no problem. Any CPU that supports NX bit should support PAE without issue.
I'd feel less confident if we were working with something < 2004. Just getting 4GB in the system might be a challenge.

It's easy to talk theory. I'm curious to see how this plays out in practice.

What video card are you using?
What does the BIOS report when you put 4GB in the system? (Pretty sure that MoBo still has BIOS and not UEFI )
Have you tried the XP install yet?
Have you to tried to enable PAE ?

I'll dig up an older system and try this on an Athlon XP or P4 if you get this working.