Question

So the addressable memory space in a 32-bit program is 4 gigabytes. Respectively, in a 64-bit application, there are ~18 exabytes of addressable space.

The kernel32.dll API has a variety of methods regarding the program’s heap and/or memory.

So my current understanding is that for example if you call HeapAlloc and pass it the amount of memory you need to allocate, it will return a pointer to the address of that allocated memory space… (Please correct me if I’m wrong here though.)

Now the advantage of using the win32-api functions for this is obviously that Windows knows best where it put other components like loaded DLLs. That’s why I’m asking…

Is there a fixed position in memory for DLL files. I think I read somewhere that for 32-bit it commonly is the upper half of the memory space (0x80000000 and up), but even if that’s true, what would the position be for 64-bit applications?

Also, is it not possible to simply use pointers to some memory freely without having Windows allocate it first? What would the side-effects be?

I’m semi-new to this subject, so any help or hints are appreciated! =)

Answer 1

Also, is it not possible to simply use pointers to some memory freely without having Windows allocate it first? What would the side-effects be?

The side effects are simple: your application would crash.

Windows (and every other sane OS) uses virtual memory: the OS maps physical memory into the virtual address space that your process sees. And it performs this mapping on demand: when you ask it to allocate a block of memory, it maps a corresponding range of virtual memory addresses to a valid chunk of memory.

Writing to an arbitrary address means you’ll hit a memory page that has not been mapped by the OS to any backing memory. Then you’ll get an access violation (or segmentation fault on *nix)

Is there a fixed position in memory for DLL files

Nope. How could there be? If you had one DLL file, it could be done. What if your application loads two DLLs? What if it loads 40? 400? And each DLL has a different size, so if they were loaded into fixed locations, they might end up overlapping.

On top of this, recent versions of Windows perform address space randomization: to mitigate certain security exploits, Windows tries to ensure that it loads DLLs and executables to different locations if you launch the application multiple times.

In short: your process runs under Windows. It is a Windows citizen and has to obey Windows laws. If it needs to access a resource (including, but not limited to, memory), it has to ask Windows to please make that resource available.