back
13 comments
Hmm, also on x86 in order to be able to access more than 4 GiB of physical memory there was a new paging mode, Physical Address Extension, that makes the pages 4MiB in size, that might have affected that as well but I doubt it. However this mode is required when entering long mode.
PAE came ~20 years later, so it's not related to the OP
A small addition though: although the operating system can address more than 4GiB of memory (up to 64 GiB) in PAE-enabled 32-bit x86 CPUs, the user-space applications are still limited to 4GiB of virtual address space and can't address more than that.

But I don't see how it's related to the default base address chosen by linkers being 0x00400000. It's just a field in the PE header and can be easily changed.

Address 0x00400000 can't be just changed in PE header. You need also to "rebase" your app with SDK tool.

Tool is now deprecated because ALSR and reason that all apps/libraries should be relocable runtime.

> You need also to "rebase" your app

Sure you need to (unless it's some kind of a base independent code like a well-written shellcode). I was just saying that 0x00400000 isn't hard-coded in the x86 architecture or in Windows and it can be set to anything (aligned to 0x10000 boundary).

With PAE pages can be either 4KB or 2MB. You're thinking of PSE-36.
The fact that Microsoft puts so much care into creating elaborate structures to preserve legacy is why I trust them with securing my identity.
I am sure I will get downvoted to all hell, but were you serious? And do other people trust MSFT for similar reasons?

(This, by the way, as a full time IT guy for 6+ years bc of bad Windows software makes me continuously feel the opposite; I did not even open a Hotmail/Live account until I was forced to try and report a bug with MSFT Connect, which requires it.)

I remember, once upon a time, you could just phone up Microsoft (UK) for support. This was early 1995 when I was battling with video driver stability problems on an Olivetti M series PC running a beta of Windows 95. The nice helpful person on the other end of the phone asked me to get updated drivers and lo and behold everything magically started to work.

On a serious note MSFT Connect is basically a ghost town. There are so many well documented and easily reproducible issues logged on Connect that languish there for months and months with no-one paying attention. I logged a fairly crippling issue with IIS7, complete with steps to repro, and it was ignored.

The only way to get any kind of support is to pay for a PSS incident. If the root cause does lie firmly in MS's backyard they do at least refund your money. I even got a knowledge base article written up about one of my PSS logged issues :)

(ex-Gold Partner IT guy here)

I hope this is sarcastic.
Terminate and stay resident.
This is for legacy reasons dating back to the time of the 8086 processor. Basically, the 8086 could only access 1MB of memory. In this one megabyte, the BIOS would store a lot of data structures (necessary for accessing disks and setting the video mode). When the first 32-bit processors came out, the original 32-bit operating systems still needed to make use of the BIOS in order to do things like change screen resolutions and enable graphics. To do this, they needed to leave the lowest 1MB of space intact and memory mapped to the corresponding physical addresses. Executables had to be based above this 1 megabyte in order to not overwrite the BIOS. 0x400000 is hexadecimal for 1 megabyte and so executables are often times loaded here.
1 megabyte is 0x100000

Also, as the article mentions, other OSes like WinNT are capable of mapping executables within the first 1mb. Virtual memory and paging can hide the BIOS area away. I think your statement about "original 32bit operating systems" is inaccurate. The limitations given in win95 appears to be mostly due to win3.x legacy backwards compability.

In fact, the main article explains everything accurately. Your summary is more confusing than helping.