5

So I was playing with Olly debugger, sniffing around what I can yet find out about windows and I pressed that M button and it popped up that memory map window. So I googled up some articles on the subject and I found out I can actually write to addresses above 64K which I tried and well.. why would it not work. About those lower 2GB of space:

  • Why are there those gaps? For example there is 0x10000-0x1FFFF R/Wable space then there is 128K nothing and then some just readable space. I mean this is already paged right, so it should not really matter whether there was something in the past like in the physical space (not mentioning 0x20000-0x40000 should be totaly ok to r/w to anyway), why would someone decide not to use some address space so randomly? Very likely I am just confused because in that memory map from olly debugger a lot of lines are left void where the column says 'Contains'. Is there perhaps some reference I could just put against this memory map from olly and find out what space has what purpose and is thus is or is not paged like this?

  • Suppose that I really wouldn't screw anything up about memory management, is it OK to write programs for windows using that lower memory instead of using heap or could I encounter some problems?

Thank you for reading this question.

EDIT

Ah here we go with what's at 0x10000 and that's also probably why that page is let writable.

Community
  • 1
  • 1
Pyjong
  • 3,095
  • 4
  • 32
  • 50
  • Well.. that's what I'm trying to do with this :) – Pyjong Jan 26 '12 at 16:16
  • regarding your last question... I doubt you could write to protected memory. It's location depends on the OS. So read more about making an OS, then read ab how windows maps its memory (I assume win since you mentioned Olly) – Adrian Jan 26 '12 at 16:29
  • Loading the address 0x10000 into pointer and then writing values up to 0x20000 did not throw any error. – Pyjong Jan 26 '12 at 16:35
  • Anyway that "how windows maps its memory" is what I'm unable to find and why I ask here. I mean there are articles on Windows's virtual address space, but for what I have found it's always just about this split on user and system part and how every process has cunningly the same memory layout. – Pyjong Jan 26 '12 at 16:46
  • @adelphus it's Windows 7 – Pyjong Jan 26 '12 at 16:47

2 Answers2

4

You don't seem to have a focused question, so it is hard to provide a valuable answer. However, you seem to imply the question How does Windows map user space memory?

First off, the low virtual memory space—from zero to 64K or more—is left unassigned to catch NULL-based pointer dereferencing. These are common programming errors which we want to know about immediately. The program almost certainly should terminate if one occurs. By leaving this space unmapped, Windows' equivalent of SEGFAULT occurs. Very useful.

Typically, code and constant space is allocated next. Once a program has begun running, there is usually no need for this space to change, so it is set to readonly, and parts of it are marked executable—usually the first portion, which can be 99% of the space. If there are shared code libraries, those are mapped in after the primary code (usually), often with small gaps so that the library code segment is page aligned (perhaps 4K, perhaps 64K or larger) for efficient memory management register usage. There is rarely a need to conserve virtual memory space.

After those is data space. That can be initialized memory, or uninitialized. It all has to be read-write. And it needs to have space reserved above it so it can grow for heap space growth.

Way above data space is stack space. It has to be read-write and have room below it so it can grow. All modern CPU stacks grow toward low memory.

And above the stack is system space.

If the process requests access to shared memory (with other processes), the size of the mapped window dictates where in the memory map it can fit. Mapped too close to where the heap grows is a problem, and too close to potential stack growth is also a problem. Fortunately, fairly simple placement algorithms solve this for the vast majority of programs. Just think about the various needs and you can probably figure out why the operating system does what it does.

wallyk
  • 56,922
  • 16
  • 83
  • 148
1

Not all memory is available for use by applications. For example, some types of hardware require memory so the system (BIOS or OS) will allocate a block of physical memory and leave it for the hardware to manage itself. That memory may not be directly readable (or writable) because performing such operations would affect the hardware. The hardware itself may have its own restrictions about what memory ranges it can use.

If you're in Windows, you can't go writing to arbitrary memory locations - the OS won't let you (in usermode at least) and will have paged the memory anyway, so the address you think you're looking at (the virtual address) won't match the actual physical memory address.

In general, you should only read and write to memory that has been requested and allocated to you by the OS.

adelphus
  • 10,116
  • 5
  • 36
  • 46
  • Yes it probably is paged memory and that's why I don't understand why is the map like this instead of continous block of virtual memory. – Pyjong Jan 26 '12 at 16:39
  • @stupid_idiot maybe fragmentation; maybe MS decided to do it like this in their algorithm – Adrian Jan 26 '12 at 17:26