VOGONS

Common searches


"...not a valid win32 application"

Topic actions

Reply 20 of 62, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Okay, I admit, I'm a bit confused now. The 1720 is not even a PC, but a notebook with a Core 2 Duo ? 😕
That's a different story then. Notebooks and nettops usually have poor driver support (sometimes 32-Bit only). 🙁

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 21 of 62, by Hoping

User metadata
Rank Oldbie
Rank
Oldbie

I also use more than one computer with 4gb of physical ram and windows 7 32 because in my opinion they are the most versatile. They can run current software and almost all software designed for XP.

Reply 22 of 62, by jgf

User metadata
Rank Newbie
Rank
Newbie
Jo22 wrote on 2021-05-06, 19:15:
Um, yes? Running a 32-Bit vintage system like Windows 98SE is one thing, but running a 32-Bit edition of a modern system such as […]
Show full quote
DosFreak wrote on 2021-05-06, 18:23:

Are we really asking someone why they are running a 32bit version of Windows on this forum? Really?

Um, yes? Running a 32-Bit vintage system like Windows 98SE is one thing,
but running a 32-Bit edition of a modern system such as Windows 7/8 is another.

That's akin to running Windows 3.0 in Real-Mode on a 486. Sure, the user can do that. It's nothing illegal, after all.
But why, just why? 😕

If that 32 bit system does what you need, why not? A 64 bit OS requires a 64 bit mobo, plenty of perfectly good mobos are still in use that are not 64 bit compatible ...should they all be scrapped? A dual overhead cam, multiport, 500hp, V-12 engine is great, but not every car needs one.

Reply 23 of 62, by Jo22

User metadata
Rank l33t++
Rank
l33t++
jgf wrote on 2021-05-06, 20:38:

If that 32 bit system does what you need, why not?

Um, because 64-Bit Windows is the standard for 10 years now? Like SSDs are?

I mean, I consider myself more of a retro person and also consider my own equipment to be totally out of date, but..

Even I slowly realized over the years that the time of 32-Bit is over by now.
Nothing against a VM, a dual-boot scenario, a second machine for a special purpose (EPROM programmer with 32-Bit driver) though.

But still running a 32-Bit OS *solely* as a daily driver is likely asking for trouble:
I did this myself for years, when Windows XP still was my host OS.

32-Bit OSes are simply too limited by now. They're limited to ~3GB RAM, HDDs with MBR partition style and 32-Bit executables.
Even running VMs or emulators is difficult, due to the RAM limitations.

They are like FAT32 formatted USB pen drives:
By now, they can hold several hundreds of gigabytes, but FAT32 has a 4GB file restriction.
You can't even store an ISO file of an old DVD-ROM on that.
That's why people also use exFAT now, which XP SP3 and Mac OS X 10.6 Snow Leopard support out-of-box.

Again, nothing against classic versions of Windows that are 32-Bit.
Using them is fine I think, they can't be made responsible for their bittness, after all.

And they are sometimes required for their compatibility.
But a modern 32-Bit Windows is different, I think - there's a choice (to not to use it).

Programs that are written with Windows 7 and up in mind do *usually* run as well on the commonly used 64-Bit versions, if not better.

Edit: Or let's put me it this way:
Running 32-Bit Windows today as the main OS is like running 16-Bit Windows 3.1x from 1992 in 2002.
That was perfectly possible, but no one did use DOS6+Win 3.1 as a primary OS anymore.
As a secondary OS in a dual-boot scenario, say with Windows 98SE as the main OS, sure, why not. 😀

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 24 of 62, by Error 0x7CF

User metadata
Rank Member
Rank
Member

If that 32 bit system does what you need, why not? A 64 bit OS requires a 64 bit mobo, plenty of perfectly good mobos are still in use that are not 64 bit compatible ...should they all be scrapped? A dual overhead cam, multiport, 500hp, V-12 engine is great, but not every car needs one.

A 64 bit OS requires a 64 bit CPU, of which every Intel CPU as new as a Core 2 Duo is. A 32 bit only CPU like a Pentium 4 (and some of those were 64 bit!) would provide a miserable experience in Windows 10. The AMD Athlons prior to the Athlon 64 lack SSE2 and as such won't run a huge number of programs anyway. Very few systems Pre-C2D and Pre-Athlon-64 are still going to be in use at all, most people are even moving on from very late C2Ds and early first-gen iSeries at this point. Fewer and fewer programs are even offering 32 bit builds at this point.

I would say that no 64-bit incapable board is "perfectly good" for Windows 10. Most of them I'd say even would be only passable for Windows 7, in no way good. A 4GB limit is getting quite restrictive since people are starting to use things like Electron (yuck! but popular enough) to write a "desktop program" in javascript, which in reality is just running on a separate Chrome instance.

Motherboard has almost nothing to do with 64bitness, on some Pentium 4 systems it can limit how much RAM the CPU can see, but I've run a 64 bit CPU and OS on a 2GB-limited chipset. An extremely small number of Intel Atom motherboards cause problems with 64 bit windows, but you don't have one of those.

32 bit-only motherboards should not be scrapped but nobody is using them. I have 5 Dell Dimensions and would not dream of scrapping them, but trying to use one as a daily driver would be absurd.

64 bit should even provide a performance improvement, as the standard means programs have twice as many general purpose registers to play with.

32 bit can make sense as a separate machine but why Windows 7 at that point? It'll only produce more compatibility issues (as you've observed) while you're trying to use 32 bit windows to run programs with compatibility issues. On the handful of 64-bit capable systems I own with 32 bit OSes it's XP and no higher.

Old precedes antique.

Reply 25 of 62, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

Indeed, I would think that if one is limited to 32-bit operating systems and plans to principally run old software, then it might be better to stick with XP. On the other hand, I suppose a fully-patched XP might have a lot more security vulnerabilities than Windows 7 – but then again, maybe the vulnerabilities of Windows 7 are more actively targeted than those of XP? And I guess there might be software that runs under 32-bit Windows 7 but not under XP, like newer versions of Office maybe.

Reply 26 of 62, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
Error 0x7CF wrote on 2021-05-06, 21:26:

64 bit should even provide a performance improvement, as the standard means programs have twice as many general purpose registers to play with.

Not always. Adding registers won't do anything if a program doesn't actually need them, and the increase in memory usage (pointer size doubles when going from 32 -> 64) and slower thread switching can cause a net decrease in overall performance.

Reply 27 of 62, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
jgf wrote on 2021-05-06, 20:38:
Jo22 wrote on 2021-05-06, 19:15:
Um, yes? Running a 32-Bit vintage system like Windows 98SE is one thing, but running a 32-Bit edition of a modern system such as […]
Show full quote
DosFreak wrote on 2021-05-06, 18:23:

Are we really asking someone why they are running a 32bit version of Windows on this forum? Really?

Um, yes? Running a 32-Bit vintage system like Windows 98SE is one thing,
but running a 32-Bit edition of a modern system such as Windows 7/8 is another.

That's akin to running Windows 3.0 in Real-Mode on a 486. Sure, the user can do that. It's nothing illegal, after all.
But why, just why? 😕

If that 32 bit system does what you need, why not? A 64 bit OS requires a 64 bit mobo, plenty of perfectly good mobos are still in use that are not 64 bit compatible ...should they all be scrapped? A dual overhead cam, multiport, 500hp, V-12 engine is great, but not every car needs one.

Sadly Windows Vista/7 and higher aren't really a good idea for existing 32-bit only systems. The system requirements are simply too high. 2000/XP remains a good idea for these and there are some unofficial efforts keeping them alive. Not to mention thanks to the changes introduced with WDDM, legacy software (namely DOS stuffs) are pretty much out of question since Vista/7.

As for 4GB RAM limit on Windows 32-bit, I strongly recommend reading this article.

There's nothing wrong using a 32-bit edition of Windows as it takes less RAM compared to a 64-bit edition. You're still limited to about 2GB for an indivudual process, though, and this applies to 32-bit processes running under 64-bit Windows as well.

On the other hand, I once had a few Win9x apps that refused to work on NT/2K/XP. After some searching I came upon this article on PE Explorer which seemed relevant to my cases (it's about the boundary check differences between 9x and NT), though I haven't really tested yet. Since your program in question is a DOS one, I'm not sure how relevant it would be.

Reply 28 of 62, by Jo22

User metadata
Rank l33t++
Rank
l33t++
LSS10999 wrote on 2021-05-07, 02:12:

On the other hand, I once had a few Win9x apps that refused to work on NT/2K/XP. After some searching I came upon this article on PE Explorer which seemed relevant to my cases (it's about the boundary check differences between 9x and NT), though I haven't really tested yet.

That's cool, thanks for the information! 😎

Ironically, though, some old 16-Bit Windows applications do run much better on Windows NT/2k/XP.
Like some of the pre-Windows 3.0 applications, which Windows 9x refuses to execute (except if patched with Mark30 etc.)

That's because these have a dedicated VM that runs a stripped-down copy of Windows 3.11:
Windows-On-Windows or WoW (not World of Warcraft! 😀), which itself runs on NT's Virtual DOS Machine (NTVDM).

Unfortunately, that's not available in x64 editions anymore, because MS was too lazy to fix
WoW for x86-64's Long-Mode or update the Soft PC emulator that was used in NT for RISC PCs (long story; even longer story).

By the way, there was a certain group of programs from the early Win32 days that required Win32s (database software; SQL for Windows?).
These Win32 programs used heavy thunking and required are shared memory model, which only Windows 3.1 (Win32s) had.

Win95 always used preemptive multi-tasking and process separation for Win32 programs.
It behaved close to Windows 3.1 only when executing Win16 programs.

These however, if run on Win95, had the ability to use Win95 features like bezier curves and new file dialogs.
Which means that some programs with a Win16 header could be totally incompatble with Windows 3.1 and Windows NT/2K/XP.

So yeah, Windows 3.1 and Windows 9x really were a big mishmash. 😀

Edit: Many typos fixed.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 29 of 62, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
Jo22 wrote on 2021-05-10, 15:50:
That's cool, thanks for the information! :cool: […]
Show full quote

That's cool, thanks for the information! 😎

Ironically, though, some old 16-Bit Windows applications do run much better on Windows NT/2k/XP.
Like some of the pre-Windows 3.0 applications, which Windows 9x refuses to execute (except if patched with Mark30 etc.)

That's because these have a dedicated VM that runs a stripped-down copy of Windows 3.11:
Windows-On-Windows or WoW (not World of Warcraft! 😀), which itself runs on NT's Virtual DOS Machine (NTVDM).

Unfortunately, that's not available in x64 editions anymore, because MS was too lazy to fix
WoW for x86-64's Long-Mode or update the Soft PC emulator that was used in NT for RISC PCs (long story; even longer story).

By the way, there was a certain group of programs from the early Win32 days that required Win32s (database software; SQL for Windows?).
These Win32 programs used heavy thunking and required are shared memory model, which only Windows 3.1 (Win32s) had.

Win95 always used preemptive multi-tasking and process separation for Win32 programs.
It behaved close to Windows 3.1 only when executing Win16 programs.

These however, if run on Win95, had the ability to use Win95 features like bezier curves and new file dialogs.
Which means that some programs with a Win16 header could be totally incompatble with Windows 3.1 and Windows NT/2K/XP.

So yeah, Windows 3.1 and Windows 9x really were a big mishmash. 😀

Edit: Many typos fixed.

OTVDM (based on WineVDM) is constantly improving and can be considered a usable solution for 64-bit Windows to run 16-bit stuffs. If something doesn't work on stable, you might consider trying the unstable CI builds that may contain some fixes to certain issues. But again, Windows NT/2K/XP remains a good idea for 16-bit compatibility like you said.

Still, Win9x and onwards aren't going to provide a comparable experience for Win3x (16-bit) apps due to changes that associated with the introduction of taskbar and such.

On Win 3.x, a window could be minimized into an icon (and vice versa), but on Windows 9x and onwards, a window minimized this way would end up as a small titlebar instead of an icon, if it couldn't go to the taskbar for whatever reasons. Program Manager is a good example for this. Although it still exists on Win9x, the feel is completely different thanks to that change. I once read that some games originally designed for Win3x also leveraged this feature and suffered from the same issue when played on Win9x and onwards, where ingame icons (that would open respective windows) become titlebars.

Reply 30 of 62, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
LSS10999 wrote on 2021-05-11, 02:01:

I once read that some games originally designed for Win3x also leveraged this feature and suffered from the same issue when played on Win9x and onwards, where ingame icons (that would open respective windows) become titlebars.

I can definitely see why that might happen, but I would be curious about which specific games have a particular problem. (Metal Marines, maybe?)

Reply 31 of 62, by furan

User metadata
Rank Member
Rank
Member
LSS10999 wrote on 2021-05-07, 02:12:
Ironically, though, some old 16-Bit Windows applications do run much better on Windows NT/2k/XP. Like some of the pre-Windows 3. […]
Show full quote

Ironically, though, some old 16-Bit Windows applications do run much better on Windows NT/2k/XP.
Like some of the pre-Windows 3.0 applications, which Windows 9x refuses to execute (except if patched with Mark30 etc.)

That's because these have a dedicated VM that runs a stripped-down copy of Windows 3.11:
Windows-On-Windows or WoW (not World of Warcraft! 😀), which itself runs on NT's Virtual DOS Machine (NTVDM).

This doesn't work quite like that. 😀 The way that WOW works, if you call, say, CreateWindow() from a win16 app, it's eventually going to call CreateWindowEx() from WIN32. If you call DestroyWindow(), it will eventually thunk through to calling DestroyWindow from WIN32. I worked on USER and GDI for 16 years on Windows, and it works well because we worked very, very hard to keep it compatible. The wndproc of a 16 bit game on 32 bit Windows is being called just like the wndproc of any other window - by USER32 (sometimes on behalf of WIN32K), but it goes through thunking layers. Yes, the application is running within the memory space of an NTVDM instance, but it is using native win32 - the 16 bit DLLs only exist to be thunking layers.

I can't speak for the business decision around WOW on 64 bit machines, but OTVDM is very nice.

Reply 33 of 62, by xcomcmdr

User metadata
Rank Oldbie
Rank
Oldbie
JO22 wrote:

OSes like Windows Vista/7 are as equally demanding as they are powerful.

The OS itself needs roughly 2GB of the 3,5GB that's maximally available (the remaining 512MB are reserved for PCI/PCIe i/o).

Windows Vista/7 can run well with only 2GB... ?
I'm using Win7 x86 on a Thinkpad T43 right now.

Reply 34 of 62, by Jo22

User metadata
Rank l33t++
Rank
l33t++
xcomcmdr wrote on 2021-05-18, 09:04:
JO22 wrote:

OSes like Windows Vista/7 are as equally demanding as they are powerful.

The OS itself needs roughly 2GB of the 3,5GB that's maximally available (the remaining 512MB are reserved for PCI/PCIe i/o).

Windows Vista/7 can run well with only 2GB... ?
I'm using Win7 x86 on a Thinkpad T43 right now.

Hi! I was thinking in retrospective. Vista was released in the XP days, when many PCs had 512MB of RAM still.
By comparison, Vista (and shortly after Win7) was very demanding. However, it also had many improvements underneath.

For example, IP v6 support, special support for SSHDs (?) with a dedicated flash part (as a cache for system files), GDI came back to User Land..
So with the right hardware, it was a very pleasant experience. It also provided a better 64-Bit experience. XP had two 64-Bit releases, too, but these were Server editions in disquise (NT 6.2).

On the other hand, it was very sluggish on normal hardware of the day. GDI, Oerlay and DirectDraw were nolonger accelerated (thanks, desktop composition engine).
Thus, the 2D graphics processors in XP era office PCs were nolonger used, making the machines as slow as running Linux via VESA VBE. 😉
(With Win 7 and its newer WDDM driver architecture, GDI became accelarted again.)

To make things worse, the DRM part of Vista constantly checked the graphics driver for integrity to prevent screen captures of DRM material.
Audio capture via StereoMix also nolonger worked on most hardware for some reason. MPU-401, Gameport, ISA (non-PnP) and DirectMusic/DirectSound3D got removed.

If memory serves, on my family's PCs, XP ran fine/snappy with 768MB first time. Next speed boost was at about 2GB..

Caluser2000 wrote on 2021-05-18, 08:23:
Jo22 wrote on 2021-05-06, 17:30:

-.
The OS itself needs roughly 2GB of the 3,5GB that's maximally available (the remaining 512MB are reserved for PCI/PCIe i/o).

Bull poop.

It was just because opf crappy programming of 32-bit NT Windows on MSs part.

Well. If memory serves, the address space after the RAM and Video RAM is used for the I/O channels of the PCI bus.
While it's technically possible to address more than the 4GB since the Pentium Pro (i686, 36-Bit range), the feature was't really used for a long time.

Except for the Server Editions of Windows 2000 and later.
I think this is because of a compatibilty problem of the device drivers that are used on normal 32-Bit Windows.

Without tricks (PAE etc), 4GB is all that can be addressed from the software side of a pure 32-Bit OS.

Of course, the hardware itself likely can move the I/O range of PCI or PCIe to another location.
As can AGP graphics cards through GART and so on.

Again, if memory serves.. I'm speaking under correction here.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 35 of 62, by Jo22

User metadata
Rank l33t++
Rank
l33t++
Caluser2000 wrote on 2021-05-18, 18:20:
jo22 in on post you stated the missing 1/2 gig was because of 32-bit Pentium architecture. Now you post more crap that is totall […]
Show full quote

jo22 in on post you stated the missing 1/2 gig was because of 32-bit Pentium architecture. Now you post more crap that is totally incorrect.

I suggest you don't rely on your memory and go do some reseach on it before post ths stuff. I've you've made quite a few errors in other posts because you have relied on your memory.

If your statements/ramblings were correct other 32-bit OSs would be missing this 1/2gig as well. They do not.
In with a suitable addition to the kernel they can access far more ram.

Thanks for the feedback. To err is human and I'm always open to new ideas.
Could you please be so kind and post a link that explains the matter properly ?

Edit: I took your advice and did some research. However, I wasn't really succesful.
Best I got was a memory layout of the Haswell architecture (left part), which is not a proper representation of a generic PC.

"PCI/PCIe memory range below 4GB—This memory range is only seen from the CPU perspective.
This range is determined by whether the IGD is activated or not. If the IGD is active, this memory range starts at the value of the BGSM register;
otherwise this memory range starts at the value of TOLUD register. The upper limit of this memory range is 4GB-20MB (FEC0_0000h).
Access to this range is forwarded to either the external PCIe graphics via the PCIe 3.0 connection or to the southbridge via the DMI.

PCI/PCIe memory range above 4GB—This memory range is only seen from the CPU perspective.
The value of top of upper usable DRAM (TOUUD) register in the hostbridge determines the start of this memory range.
The value of TOUUD is equal to the value of REMAPLIMIT register plus one. The PMLIMITU register (in the hostbridge) value determines the end of this memory range.
Access to this range is forwarded to either the external PCIe graphics via the PCIe 3.0 connection or to the southbridge via the DMI.

Graphics aperture range—This memory range is seen as part of PCI/PCIe memory range below 4GB in Figure 14.
However, in practice, this memory range may as well reside in the PCI/PCIe memory range above 4GB, depending on the platform firmware and the system configuration.
This memory range is always mapped to the PCI/PCIe memory range. It’s used as contiguous address space or as additional graphics memory space if the graphics memory
in the IGD or external PCIe graphics card is running out. The graphics aperture range in the platform firmware configuration must be enabled for this range to exist.
Otherwise, it doesn’t exist. Memory management for the system memory allocated to serve the graphics aperture uses a graphics translation table just like the legacy AGP aperture.
The difference lies in the possibility that the aperture lies above the 4GB limit and the handling of the graphics aperture memory management.
It’s the responsibility of the OS—specifically the graphics device driver—to carry out memory management for the graphics aperture. [..]

Source: https://resources.infosecinstitute.com/topic/ … -based-systems/

IF.. THEN.. EXCEPT, IF.. Well. This is.. confusing. 😢 I'm not an expert of current technology by any means.
Last time I was into such stuff was when I built an AMD APU E-350 PC.. And that was about ten years ago!

010814_1515_SystemAddre14.png
Filename
010814_1515_SystemAddre14.png
File size
151.19 KiB
Views
951 views
File license
Fair use/fair dealing exception

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 36 of 62, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
Jo22 wrote on 2021-05-19, 05:37:
Thanks for the feedback. To err is human and I'm always open to new ideas. Could you please be so kind and post a link that expl […]
Show full quote
Caluser2000 wrote on 2021-05-18, 18:20:
jo22 in on post you stated the missing 1/2 gig was because of 32-bit Pentium architecture. Now you post more crap that is totall […]
Show full quote

jo22 in on post you stated the missing 1/2 gig was because of 32-bit Pentium architecture. Now you post more crap that is totally incorrect.

I suggest you don't rely on your memory and go do some reseach on it before post ths stuff. I've you've made quite a few errors in other posts because you have relied on your memory.

If your statements/ramblings were correct other 32-bit OSs would be missing this 1/2gig as well. They do not.
In with a suitable addition to the kernel they can access far more ram.

Thanks for the feedback. To err is human and I'm always open to new ideas.
Could you please be so kind and post a link that explains the matter properly ?

Edit: I took your advice and did some research. However, I wasn't really succesful.
Best I got was a memory layout of the Haswell architecture (left part), which is not a proper representation of a generic PC.

"PCI/PCIe memory range below 4GB—This memory range is only seen from the CPU perspective.
This range is determined by whether the IGD is activated or not. If the IGD is active, this memory range starts at the value of the BGSM register;
otherwise this memory range starts at the value of TOLUD register. The upper limit of this memory range is 4GB-20MB (FEC0_0000h).
Access to this range is forwarded to either the external PCIe graphics via the PCIe 3.0 connection or to the southbridge via the DMI.

PCI/PCIe memory range above 4GB—This memory range is only seen from the CPU perspective.
The value of top of upper usable DRAM (TOUUD) register in the hostbridge determines the start of this memory range.
The value of TOUUD is equal to the value of REMAPLIMIT register plus one. The PMLIMITU register (in the hostbridge) value determines the end of this memory range.
Access to this range is forwarded to either the external PCIe graphics via the PCIe 3.0 connection or to the southbridge via the DMI.

Graphics aperture range—This memory range is seen as part of PCI/PCIe memory range below 4GB in Figure 14.
However, in practice, this memory range may as well reside in the PCI/PCIe memory range above 4GB, depending on the platform firmware and the system configuration.
This memory range is always mapped to the PCI/PCIe memory range. It’s used as contiguous address space or as additional graphics memory space if the graphics memory
in the IGD or external PCIe graphics card is running out. The graphics aperture range in the platform firmware configuration must be enabled for this range to exist.
Otherwise, it doesn’t exist. Memory management for the system memory allocated to serve the graphics aperture uses a graphics translation table just like the legacy AGP aperture.
The difference lies in the possibility that the aperture lies above the 4GB limit and the handling of the graphics aperture memory management.
It’s the responsibility of the OS—specifically the graphics device driver—to carry out memory management for the graphics aperture. [..]

Source: https://resources.infosecinstitute.com/topic/ … -based-systems/

IF.. THEN.. EXCEPT, IF.. Well. This is.. confusing. 😢 I'm not an expert of current technology by any means.
Last time I was into such stuff was when I built an AMD APU E-350 PC.. And that was about ten years ago!

010814_1515_SystemAddre14.png

This is about the "system arena" which resides between the 3GB and 4GB ranges. If you have read the article I mentioned before you should know what exactly is that "4GB limit".

TL;DR: M$ artificially limited the addressable RAM range to less than 4GB since Windows XP SP2 (below PAE). Taking the "system arena" into the account, you'll only get 3-3.5GB usable. Additionally, completely disabling DEP would disable PAE as well (only applies to XP SP2 and SP3), as it becomes totally redundant thanks to this artificial limit.

On the other hand, M$ broke something (HAL, USB stuffs, etc.) to prevent the system from working correctly with more than 4GB RAM available and this in turn justified the reasons behind this new limitation.

Efforts are being made to expand the potential of Windows XP and make it usable on modern hardware (see this very long and active thread on Win-Raid). Among them are patches to remove the 4GB RAM limit (plus fixes/workarounds to known related issues), with daniel_k's patch being the most recent one. Up to 64GB of RAM can be reliably used after patching, though some drivers (notably Asus/C-Media ones) simply BSOD with the RAM limit removed, so your mileage may vary. (NOTE: The same BSODs can occur on Server 2003 as well, which can already access more than 4GB of RAM)

Caluser2000 wrote on 2021-05-18, 18:20:

If your statements/ramblings were correct other 32-bit OSs would be missing this 1/2gig as well. They do not.
In with a suitable addition to the kernel they can access far more ram.

Indeed, this 4GB (precisely 3-3.5GB) limit is specific to Windows. Other 32-bit OSes (such as Linux) can access as much RAM allowed by PAE if supported and enabled.

Reply 37 of 62, by Jo22

User metadata
Rank l33t++
Rank
l33t++
LSS10999 wrote on 2021-05-19, 06:45:
This is about the "system arena" which resides between the 3GB and 4GB ranges. If you have read the article I mentioned before y […]
Show full quote
Jo22 wrote on 2021-05-19, 05:37:
Thanks for the feedback. To err is human and I'm always open to new ideas. Could you please be so kind and post a link that expl […]
Show full quote
Caluser2000 wrote on 2021-05-18, 18:20:
jo22 in on post you stated the missing 1/2 gig was because of 32-bit Pentium architecture. Now you post more crap that is totall […]
Show full quote

jo22 in on post you stated the missing 1/2 gig was because of 32-bit Pentium architecture. Now you post more crap that is totally incorrect.

I suggest you don't rely on your memory and go do some reseach on it before post ths stuff. I've you've made quite a few errors in other posts because you have relied on your memory.

If your statements/ramblings were correct other 32-bit OSs would be missing this 1/2gig as well. They do not.
In with a suitable addition to the kernel they can access far more ram.

Thanks for the feedback. To err is human and I'm always open to new ideas.
Could you please be so kind and post a link that explains the matter properly ?

Edit: I took your advice and did some research. However, I wasn't really succesful.
Best I got was a memory layout of the Haswell architecture (left part), which is not a proper representation of a generic PC.

"PCI/PCIe memory range below 4GB—This memory range is only seen from the CPU perspective.
This range is determined by whether the IGD is activated or not. If the IGD is active, this memory range starts at the value of the BGSM register;
otherwise this memory range starts at the value of TOLUD register. The upper limit of this memory range is 4GB-20MB (FEC0_0000h).
Access to this range is forwarded to either the external PCIe graphics via the PCIe 3.0 connection or to the southbridge via the DMI.

PCI/PCIe memory range above 4GB—This memory range is only seen from the CPU perspective.
The value of top of upper usable DRAM (TOUUD) register in the hostbridge determines the start of this memory range.
The value of TOUUD is equal to the value of REMAPLIMIT register plus one. The PMLIMITU register (in the hostbridge) value determines the end of this memory range.
Access to this range is forwarded to either the external PCIe graphics via the PCIe 3.0 connection or to the southbridge via the DMI.

Graphics aperture range—This memory range is seen as part of PCI/PCIe memory range below 4GB in Figure 14.
However, in practice, this memory range may as well reside in the PCI/PCIe memory range above 4GB, depending on the platform firmware and the system configuration.
This memory range is always mapped to the PCI/PCIe memory range. It’s used as contiguous address space or as additional graphics memory space if the graphics memory
in the IGD or external PCIe graphics card is running out. The graphics aperture range in the platform firmware configuration must be enabled for this range to exist.
Otherwise, it doesn’t exist. Memory management for the system memory allocated to serve the graphics aperture uses a graphics translation table just like the legacy AGP aperture.
The difference lies in the possibility that the aperture lies above the 4GB limit and the handling of the graphics aperture memory management.
It’s the responsibility of the OS—specifically the graphics device driver—to carry out memory management for the graphics aperture. [..]

Source: https://resources.infosecinstitute.com/topic/ … -based-systems/

IF.. THEN.. EXCEPT, IF.. Well. This is.. confusing. 😢 I'm not an expert of current technology by any means.
Last time I was into such stuff was when I built an AMD APU E-350 PC.. And that was about ten years ago!

010814_1515_SystemAddre14.png

This is about the "system arena" which resides between the 3GB and 4GB ranges. If you have read the article I mentioned before you should know what exactly is that "4GB limit".

TL;DR: M$ artificially limited the addressable RAM range to less than 4GB since Windows XP SP2 (below PAE). Taking the "system arena" into the account, you'll only get 3-3.5GB usable. Additionally, completely disabling DEP would disable PAE as well (only applies to XP SP2 and SP3), as it becomes totally redundant thanks to this artificial limit.

On the other hand, M$ broke something (HAL, USB stuffs, etc.) to prevent the system from working correctly with more than 4GB RAM available and this in turn justified the reasons behind this new limitation.

Efforts are being made to expand the potential of Windows XP and make it usable on modern hardware (see this very long and active thread on Win-Raid). Among them are patches to remove the 4GB RAM limit (plus fixes/workarounds to known related issues), with daniel_k's patch being the most recent one. Up to 64GB of RAM can be reliably used after patching, though some drivers (notably Asus/C-Media ones) simply BSOD with the RAM limit removed, so your mileage may vary. (NOTE: The same BSODs can occur on Server 2003 as well, which can already access more than 4GB of RAM)

Thank you for your explanation, I just started reading the links you mentioned.

However, I still can't see what was wrong with my early statements.

Even if 32-Bit Windows could access only 3,5GB instead of the full 4GB due to an artificially limited,
does this really matter so much?
The PCI range and video memory/video page frame do still reduce the amount of the RAM below 4GB that otherwise would be theoreticaly available to an OS.

I'm afraid that's there's a problem in communication here.
I didn't mean to say that things are impossible to archive somehow.

The 32-Bit server editions of Windows NT were able to access more than 4GB of memory, for a long time, too. That's what I mentioned before.
Aren't these mechanisms available in the desktop versions of 32-Bit Vista+, too?

I've also said that "pure" 32-Bit OSes do inherent a 4GB limit.
By 32-Bit, I meant software that uses 32-Bit pointers at best. Such as from the 386/486/585 era.

The device drivers that are meant to be compatible with 386-586 PCs,
cannot address more than 4GB, rather less.
(Except if using segmentation; pointer/offset)
If they' tried to, couldn't a address wrap-round or overflow happen at worst?

Since Windows 2000 can run on a 486 PC, still, I assume, the makers of 32-Bit device driver and/or MS were rather conservative in this respect.

Windows XP, can run on Pentium MMX-based machines onwards, which are technically more recent than the Pentium Pro.
However, the Pentium MMX wasn't directly based if the Pentium Pro.
Rather, the later Pentium II was based (?) on Pentium Pro technology.
So I'm not sure if the P MMX can use 36-Bits, aswell.

However, XP can still use Windows 2000 era device drivers meant to work on 486/585 PCs.
Which can mean a risk if they are used with a a recent kernal that uses PAE or any similar technology.

I didn't mean to say that 32-Bit OSes are entirely unable to do use more than 4GB.
Linux did this since the early 2000s.
It can boot off MBR partitions that are located on HDDs bigger that 2TB, even.
Windows, by comparison, demands GPT and UEFI for this.

Edit: Ok, I finished reading.
Some parts reminded me of the pointers used by Windows 3.1 Standard Mode kernal
and the bank-switching mechanisms in MP/M on Z80 platform and EMS on MS-DOS..

"Even kernel-mode drivers don’t need to know anything specific to PAE,
much less be written specially to support it. All that’s required is a general awareness that physical memory addresses may be wider
than 32 bits
and that accommodation of this comes naturally from following the documentation. "
^This segment just killed me. 🙄 As if that was not a big deal, at all.

Edit: I've also noticed that DEP was rarely mentioned.
DEP was used to prevent the execution of malicious code.
I mentioned it in an earlier thread, which likely is faulty, too:
Re: Hardware for Win3.11

Could it be, that PAE simply found its way into the XP installation media because it was required for DEP rather than for accessing additional memory?

Last edited by Jo22 on 2021-05-19, 08:14. Edited 4 times in total.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 39 of 62, by LSS10999

User metadata
Rank Oldbie
Rank
Oldbie
Jo22 wrote on 2021-05-19, 07:30:
Thank you for your explanation, I just started reading the links you mentioned. […]
Show full quote

Thank you for your explanation, I just started reading the links you mentioned.

However, I still can't see what was wrong with my early statements.

Even if 32-Bit Windows could access only 3,5GB instead of the full 4GB due to an artificially limited,
does this really matter so much?
The PCI range and video memory/video page frame do reduce the amount of the RAM below 4GB that otherwise would be theoreticaly available to an OS.

I'm afraid that's there's a problem in communication here.
I didn't mean to say that things are impossible to archive somehow.

The 32-Bit server editions of Windows NT were able to access more than 4GB of memory, for a long time, too. That's what I mentioned before.
Aren't these mechanisms available in the desktop versions of 32-Bit Vista+, too?

I've also said that "pure" 32-Bit OSes do inherent a 4GB limit.
By 32-Bit, I meant software that uses 32-Bit pointers at best. Such as from the 386/486/585 era.

The device drivers that are meant to be compatible with 386-586 PCs,
cannot address more than 4GB, rather less.
(Except if using segmentation; pointer/offset)
If they' tried to, couldn't a address wrap-round or overflow happen at worst?

Since Windows 2000 can run on a 486 PC, still, I assume, the makers of 32-Bit device driver and/or MS were rather conservative in this respect.

Windows XP, can run on Pentium MMX-based machines onwards, which are technically more recent than the Pentium Pro.
So I'm not sure if the P MMX can use 36-Bits, aswell.

However, XP can still use Windows 2000 era device drivers meant to work on 486/585 PCs.
Which can mean a risk if they are used with a a recent kernal that uses PAE or any similar technology.

I didn't mean to say that 32-Bit OSes are entirely unable to do use more than 4GB.
Linux did this since the early 2000s.
It can boot off MBR partitions that are located on HDDs bigger that 2TB, even.
Windows, by comparison, demands GPT and UEFI for this.

I don't know how to properly explain this well, either.

The system arena is a special area in the address space placed between 3GB and 4GB with varying size, which is considered a "memory hole" and cannot be used to access actual memory. If you have 4GB or more RAM, the memory that otherwise would end up in that area would have to be remapped to above 4GB (requires PAE) in order to be accessible. In some BIOSes, there's an option called "Memory Hole Remapping" which does this to allow access to all installed RAM. Without it, you'll lose access to the amount of memory equal to the system arena size. For example, if your system arena takes up about 0.75GB, with 4GB RAM installed, you can only access 3.25GB without remapping. The same will apply if you have more than 4GB (e.g. 8GB, which would result in 7.25GB).

On desktop versions of Windows, M$ simply limits accessible memory range to up to 4GB (below PAE), and discards anything above that. Since the memory in the system arena range is being mapped to above 4GB, it also gets discarded, so only the 3-3.5GB which is actually below 4GB can be used. All those memory limitations on M$ Windows are purely artificial and license-based, not architectural.

As for device compatibility, it depends on how the drivers were written. It shouldn't cause any problem on a PAE environment with more than 4GB of RAM if written correctly, but I'm not an expert on drivers and I've already seen problematic drivers that BSOD under such circumstances.

As for being able to boot MBR partitions located on HDDs bigger than 2TB, I think you're talking about 4Kn HDDs whose sector size is 4KB instead of 512 bytes (512e). Such disks can address up to 16TB within MBR specs.

Jo22 wrote on 2021-05-19, 07:30:

Could it be, that PAE simply found its way into the XP installation media because it was required for DEP rather than for accessing additional memory?

EDIT: Yes, for 32-bit Windows since XP SP2, PAE exists only because DEP requires it, now that M$ artificially limited the available RAM to below 4GB.