Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why doesn’t Windows use 64-bit virtual address space below 0x00000000`7ffe0000?

devblogs.microsoft.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Why doesn’t Windows use 64-bit virtual address space below 0x00000000`7ffe0000?

#51

Post by WalterBright »

worewood wrote: post #25
CalChris wrote: post #21

Earlier quoted context omitted.

This was only 'enforced' by the linker on x86. You could handcraft a Mach-O executable to get around it. But it is now enforced enforced by OSX on ARM. I don't see any good reason for this. My own half assed explanation is they're enforcing 32b cleanliness. It's not a very good explanation. But it's my explanation for something I don't like.

When migrating 32bit apps to 64bit platforms, it's common to follow the recipe: 1. Try to recompile on 64bit without any changes 2. Realize the program does not work because the types have different sizes now 3. Cast everything on sight to types that have same size as in 32bit. 4. Now the program "works" (as in, it compiled and maybe ran but you didn't test thoroughly) This address space restrictions ensures that if…

> 2. Realize the program does not work because the types have different sizes now

Such an enormous amount of time in C/C++ programming is devoted to accounting for the size of an int, long, wchar_t, and long long being unreliable when porting.

This is why D has int fixed at 32 bits, long fixed at 64 bits. It's amazing how the problems just melt away.

Now, just remember to use size_t for everything used as an index, and you're good to go. (ptrdiff_t is almost never needed.)

Re: Why doesn’t Windows use 64-bit virtual address space below 0x00000000`7ffe0000?

#52

Post by WalterBright »

gruez wrote: post #43
worewood wrote: post #25

Earlier quoted context omitted.

When migrating 32bit apps to 64bit platforms, it's common to follow the recipe: 1. Try to recompile on 64bit without any changes 2. Realize the program does not work because the types have different sizes now 3. Cast everything on sight to types that have same size as in 32bit. 4. Now the program "works" (as in, it compiled and maybe ran but you didn't test thoroughly) This address space restrictions ensures that if…

>3. Cast everything on sight to types that have same size as in 32bit. Which is why on windows they defaulted to 32 bits for ints

Except for 16 bit Windows!

Re: Why doesn’t Windows use 64-bit virtual address space below 0x00000000`7ffe0000?

#53

Post by yardstick »

WalterBright wrote: post #51
worewood wrote: post #25

Earlier quoted context omitted.

When migrating 32bit apps to 64bit platforms, it's common to follow the recipe: 1. Try to recompile on 64bit without any changes 2. Realize the program does not work because the types have different sizes now 3. Cast everything on sight to types that have same size as in 32bit. 4. Now the program "works" (as in, it compiled and maybe ran but you didn't test thoroughly) This address space restrictions ensures that if…

> 2. Realize the program does not work because the types have different sizes now Such an enormous amount of time in C/C++ programming is devoted to accounting for the size of an int, long, wchar_t, and long long being unreliable when porting. This is why D has int fixed at 32 bits, long fixed at 64 bits. It's amazing how the problems just melt away. Now, just remember to use size_t for everything used as an index, a…

Isn’t it similar in C with using uint16_t, uint32_t, etc?

IMO it helps to write programs from the ground up that you know will need to be cross compiled.

Re: Why doesn’t Windows use 64-bit virtual address space below 0x00000000`7ffe0000?

#55

Post by messe »

titzer wrote: post #23

> No. The virtual address space starts at the 64KB boundary. You can confirm this by calling GetSystemInfo and checking the lpMinimum­Application­Address. It will be 0x00000000`00010000. Aw, man. I recently found out there is also a similar restriction on Linux. Bummer, because I have a good use for putting code into the lower 64KB of memory (not 4KB, still want to use that for catching NPEs). My use case is a fast i…

> Since every bytecode handler needs an entry in the dispatch table, and I have 7--yes 7!--dispatch tables, I'd like to make their entries 2 bytes. So instead of taking 1KB each, they would take only 512B each. But alas.

Hmm. If the upper half of the handler addresses are the same, then why not store just the lower 2-bytes of each handler address in the dispatch table. If you're on x86, there's no add needed if the upper bytes of the register you're loading into already contain the upper half of the address, for example:

   mov eax, HANDLER_BASE
   mov ax, [edi + ebx]

Re: Why doesn’t Windows use 64-bit virtual address space below 0x00000000`7ffe0000?

#57

Post by WalterBright »

yardstick wrote: post #53
WalterBright wrote: post #51

Earlier quoted context omitted.

> 2. Realize the program does not work because the types have different sizes now Such an enormous amount of time in C/C++ programming is devoted to accounting for the size of an int, long, wchar_t, and long long being unreliable when porting. This is why D has int fixed at 32 bits, long fixed at 64 bits. It's amazing how the problems just melt away. Now, just remember to use size_t for everything used as an index, a…

Isn’t it similar in C with using uint16_t, uint32_t, etc? IMO it helps to write programs from the ground up that you know will need to be cross compiled.

Yes, you could use int32_t. But who wants to type that? People default to convenience, and that's int.

Besides, the C Standard Library doesn't even use stdint.h. Now you've got unknown implicit integer conversions going on. It's just not a solution.

Re: Why doesn’t Windows use 64-bit virtual address space below 0x00000000`7ffe0000?

#58

Post by tyleo »

krylon wrote: post #12
darknavi wrote: post #7

I enjoy the short and sweet blog posts from Raymond Chen on "Why does Windows X?".

He is great at summing up these things in a way I can understand (most of the time, not being very experienced with Windows internals) without having the feeling he is dumbing it down, just that he is explaining it very clearly.

While this article doesn’t have it, I especially like his subtitles which are essentially a 1-line TL;DR of the content. As a recent example:

Title: Instead of a C++ template parlor trick, why not just add support based on whether the header file has already been included?

Subtitle: Header file inclusion order dependencies

Re: Why doesn’t Windows use 64-bit virtual address space below 0x00000000`7ffe0000?

#59

Post by nikau »

bunabhucan wrote: post #20

Has anyone here ever used Windows NT on a DEC Alpha? A company in Ireland I worked for gave a mobile phone GIS demo to the Irish national phone company and Digital lent us a beefy server with two AXP CPUs (it was gonna be the future!) running windows NT. We literally pulled it on cobbled dublin streets on a a handcart to bring it to their offices.

Only once for around a week, we purchased a alphaserver and it didn't come with the correct OSF/1 installation media, so one of the guys installed NT4 just to see what its like - we were all impressed as it ran multiple copies of Doom without issue.

Re: Why doesn’t Windows use 64-bit virtual address space below 0x00000000`7ffe0000?

#60

Post by TazeTSchnitzel »

CalChris wrote: post #21
TazeTSchnitzel wrote: post #15

Tangent: on 64-bit Apple platforms, nothing is mapped in the lowest 4GiB of address space. This ensures any pointer truncated to 32 bits and dereferenced will segfault.

This was only 'enforced' by the linker on x86. You could handcraft a Mach-O executable to get around it. But it is now enforced enforced by OSX on ARM. I don't see any good reason for this. My own half assed explanation is they're enforcing 32b cleanliness. It's not a very good explanation. But it's my explanation for something I don't like.

Maybe they're now relying on it for safety in core system libraries that get linked into your process? If you can be sure that the offset in *(ptr + offset) is always a 32-bit unsigned type, you get null pointer checking for free, right?
Post reply on HN