@LSS10999 Thank you, now I do have a better understanding of the system area.
I assumed that older drivers could be culprit, too. Unfortunately, I have little experience with programming them.
One possible issue might be older compilers, I guess. Maybe they can't properly hangle values bigger than 32-Bits or something.

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

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.

I forgot to ask - Out of curiosity, which other posts ? I'll try to fix them, if needed.

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

You can do your own search ol been. There are a few over quite a number of years....

Any hints, please? Was it about DOS, GEOS, old/new Windows, HDDs, Pentium systems or games? 😕

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)

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.

I knew this prior to the year 2000. Not being in IT I'm confused why these experience Vogons members were unaware of it.

I hoped from Dos/windows 3.1 about then to the original version of Windows 98. Missed Windows 95 completedly at home. I had that Windows 98 system sharing our internet connection with a 486 with redhat 6.0 on it and another system with OS/2 v4 on it. Used a small proxy program on the win98 box to do that via coax.

Caluser2000 wrote on 2021-05-20, 21:16:

Not being in IT I'm confused why these experience Vogons members were unaware of it.

I hoped from Dos/windows 3.1 about then to the original version of Windows 98. Missed Windows 95 completedly at home. I had that Windows 98 system sharing our internet connection with a 486 with redhat 6.0 on it and another system with OS/2 v4 on it. Used a small proxy program on the win98 box to do that via coax.

Cool. So I'm apparently not the only confused guy here, at least. 😉👍

To be honest, I haven't heard of the "system arena" before. 🙁
None of my computer books from the 2010s and before mentioned it.

It seems that this either is a Windows specific term or a term that's often used in conjunction with Windows.
However, a search for "Windows System Arena" only provides two 2 results on Google.

Originally, I simply portrayed the range between the end of system RAM and 4GB as
as an equivalent to an XT PCs "adapter segment", which is between 640 and 1024 KB (end of 8-Bit ISA bus address space).

On ATs there's another region between 15-16MB (end of 16-Bit ISA bus address space), which has a special status.
Because, some BIOS Setups have a "15-16MB Memory Hole" option for compatibility.

From what I remember, this space was sometimes used by 16-Bit ISA graphics cards for their linear frame buffers (wrong?) .
Maybe by Windows Accelerator functions or for certain Vesa VBE modes (not sure).
Normally, plain VGA was still using the small RAM window past 640KB (A segment) though.

That's why I thought of it as another "adapter segment", too.

However, I do admit I made a few errors here. I'll try to better check things in the future.

Because, it seems that this was wrong or not entirely correct, at least.
It's apparently not the 3,5GB to 4GB range, but the whole 3GB to 4GB range that's used for PCI, AGP Aperture, BIOS code etc (System Arena/Windows?).
Also, some systems do use remapping, so things may varry?

https://en.wikipedia.org/wiki/Upper_memory_area

Sample result for "System Arena"+"Windows" +"GB" :

Basically, on older chipsets, e.g. i865, if you had 4GB memory, you only saw about 3GB +/- depending on settings like: AGP aperture size, number of PCI cards installed, etc. The reason for this is that the range 3GB-4GB is called the "system arena" in Windows 32 and is used for memory mapping peripherals and GPU.

If the above quote is correct, then on newer chipsets, the BIOS "swaps out" the system arena to some extent, so that more memory is available under Win32. Anyone care to comment on that claim?

Source: https://www.techpowerup.com/forums/threads/2g … rocessor.60023/

Ecit: Typos fixed.

Topic split. Caluser2000 harassments have been moved to the trash.
Stop calling people names or harass them like you did in this topic. Thanks

xcomcmdr wrote on 2021-05-19, 07:34:

PAE is a ""nice"" """solution""", but useless if applications don't use it. Very few of them do.

It's not useless. I'm typing this post on a 8 GB machine with 32-bit Windows 10, PAE patched.
And yes, it works.
Although a single 32-bit process is limited to 4 GB address space, the system itself can use up to 16 GB of RAM in PAE mode. So you can run multiple applications and make use of more than 3.5 GB at a time.

It's the same situation as when running many 32-bit applications on a 64-bit system. The applications themselves are limited to 4 GB, but the system as a whole is not. So the total RAM in use can exceed 4 GB.

Keep in mind here that modern web browsers are usually multi-process applications. So even 32-bit web browsers can use more than 4 GB of RAM this way (when run on a 32-bit system with PAE patch, or unpatched 64-bit system).

Also I'd like to point out that since Vista, PAE mode is not optional as far as I know. It's still artificially limited to 4 GB by default (which is why patch is needed to use more memory), but it's not "enabling PAE", because it is always enabled.

Azarien wrote on 2021-05-22, 14:50:

Keep in mind here that modern web browsers are usually multi-process applications. So even 32-bit web browsers can use more than 4 GB of RAM this way (when run on a 32-bit system with PAE patch, or unpatched 64-bit system).

^Not the best example, though.
Memory limitations were the reason why Mozilla finally stopped compiling Firefox x86.

Not even PAE solved it.

It is the compiler which is having ressource problems. The profile-guided optimiser needs more than 3GB to be able to do its opt […]
Show full quote

It is the compiler which is having ressource problems.
The profile-guided optimiser needs more than 3GB to be able to do its optimisations.
And apparently, the Windows its running on can't do PAE to use more than 3GB neither.

PAE allows 32-Bit computers to use more than 4GB of ram, but it doesn't allow Windows to assign more than 3GB to any single process.

Source: Comments of link mentioned below.

Here's some news from ~2011 that explains it:

Firefox Too Big To Link On 32-bit Windows
https://m.slashdot.org/story/161896

Please, just let Windows x86 rest in peace and free the road for 64-Bit applications, so they can finally get a chance. 😉
(The presence/marketshare of Windows x86 is/was the culprit why devs hesitated to provide 64-Bit binaries.)

In a few years, BIOS/CSM and the ability to boot 32-Windows will be gone in favor of UEFI, anyway. Maybe, x64 too because of ARM..
Keep using 32-Bit OSes (as a daily driver) will only delay the inevitable.

Edit: Things fixed.
Edit: Little edit.

Only i that machime supports 32-bit OSs 🤣.

32-bit systems, OSs and applications are still useful today.

Like this system for example. All the software use on it is current and updated on a regular basis.

On a 14 year old system no less.

Hell, even my 286 does what it needs to do in regard to accessing the irc channels I want. And they aint going away any time sone...

Caluser2000 wrote on 2021-05-22, 16:56:

Only i that machime supports 32-bit OSs 🤣.

32-bit systems, OSs and applications are still useful today.

Like this system for example.

That's a different matter, of course.

Running a 286 laptop with Windows 3.1 is fine.
So is a Pentium II PC with Windows 98SE..

What I try to explain (oh god of English language, please help!),
that people with newer hardware have a choice not to use, say, Windows 10 x86.

Of course, it's possible and of course it's something required for limited hardware.

I had a nettop PC in 2014 that ran on a 32-Bit UEFI and wasn't fully compatible with Windows 7 x64 (originally).

But by doing so, you will only limit yourself.
And, indirectly, others too.:

As long as Windows x86 is being used, to some extent, Microsoft will continue to produce two releases of Windows.

Again, there's nothing wrong with using 32-Bit Windows per se.

It's just that it holds back Windows development.
As long as companies/developers can't expect Windows users to 100% have a 64-Bit Windows,
they will either develop both 32-Bit/64-Bit applications.
Or, more likely, 32-Bit applications only.

So why is this bad? Pointers and older Win32 development tools.

Using good, old 32-Bit compilers can lead to all sorts of overruns,
considering the huge amount of data that's processed in our age.

If 64-Bit Windows was clearly the norm (no matter if x64 or ARM), developers could explain the matter to their bosses
and could justify the need for modern compilers or the need for a code rewrite.

The same happened in the 90s with the transition from Win16 to Win32.
There was a maddive porting process going on.

Nowadays, would you take a company for serious that openly sells or runs dated Win16 applications?

PS: Again, this is no rant against 32-Bit Windows or Win32.
I myself do in fact, do love to collect and thinker with all sorts of Win16/32/s stuff.
It's merely about the drawbacks of using current 32-Bit Windows in 2021.

Edit: Windows x64/ARM do still support Win32 applications, so there's no loss.
In fact, even Windows RT does via win86emu.
Win32 still is the most important component of Windows (Win64 is based on it).
With OTVDM (third-party product), many Win16 applications can be used seamlessly on Win x64.

Your opinion is obviously not shared by everybody. You really need to get over that and except we all have different opinions on what we should run on OUR systems.

Caluser2000 wrote on 2021-05-22, 17:32:

Your opinion is obviously not shared by everybody. You really need to get over that and except we all have different opions onj what we should run on OUR systems.

Jeez, it's not about me. I'm not angry, either. I'm merely a long time observer of the situation with a teary eye sometimes.

And everyone is free to discard good advices, of course.

At the beginning of the early 21th century, many Windows developers were in euphoria about the 64-Bit computing.

However, things didn't turned out as hoped by them.
32-Bit Windows persisted and caused nothing but troublesome situation which 64-Bit computing could have solved with ease.

Here's a link about VB6 developers begging for a modern 64-Bit compiler,
so they could finally fix things up.

https://www.change.org/p/microsoft-bring-back … its-compilation

It's just ine example.

PS: 32-Bit systems are still in use in places other than homes.
Many people in offices and super markets are forced to work with sluggush, obsolete Windows systems.

It's not as funny as us running Windows 3.1 or PC/GEOS on a 286 at home.
These poor souls are forced to get their work done on such unstable, messy 32-Bit systems.
And if they can't, they are in deep trouble.

64-Bit systems, by comparison, can't run THAT bad, even if short on resources.
Their memory management and security levels (signed drivers etc) are higher grade than that of 32-Bit Windows.

32 bit is dead, long live 32 bit.

Caluser2000 wrote on 2021-05-22, 18:00:

Notice how I get my message across in a few sentences?

I noticed a lot of things, yes, sir.

And I come to the conclusion that you purposely don't want to understand what I mean to say. 😔

Anyway, each to his own.

Some people simply don't accept advices or can't be helped.
Or even worse, the more you explain, the less they even listen. But so is life.

Either way, I finished mentioning the pros/cons of 32-Bit/64-Bit. 🙂

It's now up to the readers to decide which one to use in which situation.

Have a nice day and
a nice weekend,
everyone.

xcomcmdr wrote on 2021-05-19, 07:34:

PAE is a ""nice"" """solution""", but useless if applications don't use it. Very few of them do.

Well, PAE is really meant to allow operating systems to use a 64 rather than 32 bit page table entries, which is then used by the MMU to address actual physical RAM or swap - the page table is given an extra 4 bits so your hardware can work with 64GB RAM max. Your normal user process are still limited to 4GB max (in Windows it's 2 GB user space + 2GB system space, or 3GB user space + 1GB system space, depending on whether 4GT (4GB Tuning) is turned on or not). That's not really a limitation since the app can spawn multiple processes, each with its own 4GB process space. That being said, just because your MMU can deal with 64 bit page table entries and can now address more than 4GB of physical RAM doesn't mean that the northbridge/memory controller can deal with that much RAM. The flipside to PAE is that it's not just a temporary hack to allow x86 servers to use more RAM while Intel preps the Itanium - the no execute bit is bit 63 on the 64 bit page table entries, so if you expect Data Execute Protection (DEP) to be enabled on your Windows OS, you'll need PAE .
Now whether xD/NX is present on your CPU for hardware enforced DEP? That's a different question. You'll need at least an AMD K8, a Prescott-2M or a Dothan Pentium-M or beyond...which is around 2003-4 vintage.

Also, the entire RAM limitation of Windows XP SP2 or Vista even with PAE and >4GB RAM count was due to the need to support devices that can only do 32 bit DMA bus mastering - if your DMA device can only read/write to physical memory locations below 4GB, it cannot talk to processes that expect memory mapped I/O space allocated above 32 bits through PAE. Win2K/2K3 supports that to a certain extent by doing double buffering, allocating memory locations below 4GB to the device driver and then copying the operation to another location where the requesting process space resides. The issue here is that it's slower, and in 2K/2K3, some consumer hardware (like video capture cards) that don't play well with the double buffer scheme will be unsupported. XPSP2+, Vista, 7 and Win10 32 bit simply limit the machine to 4GB minus whatever the OS reserves just for the sake of supporting all those consumer devices.

Why yes, you can totally run 32 Bit OS on a 64 bit processor...hell, you can buy Win10 tablets with Intel Cherry Trail SoCs new from Amazon (usually an Atom x5, 2GB of RAM, 32GB eMMC). Those have UEFI32 and will never, ever run 64 Bit Windows. As for whether it's a good idea? Eh, that's a matter of personal preferences - I got Ubuntu x64 running on one of those tablets and it was a royal pain with not too many benefits. That Dell 1710? Yeah, it can totally go 64 Bit Windows - the i965 chipset can take up to 8GB of RAM and it should be fairly usable with modern Win10, but 32 Bit Windows 7 is perfectly fine if your intention is playing the classics. Just do the world a favor and firewall it from the rest of the world - who knows how many Win32/64 security vulns went unpatched ever since Microsoft dropped consumer Win7 support.

As for the original question...why is it not a valid win32 application? Use dependency walker or dumpbin on patch.exe and see if it references a different DLL that was expected (who knows if that patcher hooks a DLL that might've dropped the functions that it needed - DLL hell was/is a thing), or if the patcher had code that expected a specific value on the DOS/Windows version string, and it didn't like what it saw (oh no, version 6.01.7600?! That's obviously not Win32). That's also a known reason why errors like that can kick off.

I've read in a few computer related forems that some folk have reverted back to 32-bit Windows on their 64-bit systems. Why you ask-because it was more stable on their particular set up. 🤣

Caluser2000 wrote on 2021-05-22, 22:07:

I've read in a few computr related forems that some folk have reverted back to 32-bit Windows on their 64-bit systems. Why you ask-because it was more stable on their particular set up. 🤣

Ah yes, the same kind of people who calls up HP asking why their 20 year old WinPrinter/PPA Inkjets can't work in Windows 10. Or why their Hauppage WinTV PVR350 keeps crashing their machine (oh for fucks sake why are you using a PCI analog TV tuner card in 2021?!). Or that somehow only using bottom half of your x64 registers makes it more stable. It's your machine and you can do whatever you want - it doesn't mean it's always a good idea.
Oh well, at least it's not someone trying to shoehorn a Pentium 4 with a Radeon 9800 to run Windows 98.

There is one argument for using 32-bit Windows even if a 64-bit version would work on a given machine: better compatibility with older games, ie. fewer problems to solve.

Azarien wrote on 2021-05-23, 20:26:

There is one argument for using 32-bit Windows even if a 64-bit version would work on a given machine: better compatibility with older games, ie. fewer problems to solve.

Do you have specific examples in mind where 32-bit Windows 7/8/10 has better compatibility than 64-bit Windows 7/8/10? Other than 16-bit installer issues?

There was a thread about this at Retro pre Windows XP(non 16-bit) games which run on Windows 32-bit but not on 64-bit or vice versa which kind of went nowhere.

Jorpho wrote on 2021-05-23, 22:49:

Azarien wrote on 2021-05-23, 20:26:

There is one argument for using 32-bit Windows even if a 64-bit version would work on a given machine: better compatibility with older games, ie. fewer problems to solve.

Do you have specific examples in mind where 32-bit Windows 7/8/10 has better compatibility than 64-bit Windows 7/8/10? Other than 16-bit installer issues?

There was a thread about this at Retro pre Windows XP(non 16-bit) games which run on Windows 32-bit but not on 64-bit or vice versa which kind of went nowhere.

Networking ye olde systems ol been.