Memory map of a Windows process
in [Win32 API]
|
From: Sergei Zhirikov on 13 Feb 2010 19:44 David Given wrote: > On 13/02/10 09:54, nico wrote: > [...] >> It's managed by VMM : >> http://msdn.microsoft.com/en-us/library/ms810616.aspx > > Unfortunately that doesn't actually say how the user area is used --- it > merely describes (in commendable detail) how the VM manages the use > area, which isn't the same thing. > > There is an interesting reference to the fact that system DLLs are > loaded into the kernel area rather than the user area... does this mean > that if I can avoid loading any user DLLs, I get the entire user area to > myself? > System DLLs were loaded into the kernel area in Windows 95/98/ME. This in not true for Windows NT family.
From: Leslie Milburn on 13 Feb 2010 20:55 "David Given" <dg(a)cowlark.com> wrote in message news:hl7jjk$a9g$1(a)news.eternal-september.org... > On 14/02/10 00:33, Jeroen Mostert wrote: > [...] >>> What I've got is a big pile of statically compiled code that's expecting >>> to be run at a particular address. It's not relocatable. >> >> Are we talking about Win32 code? Because that's pretty bogus. > > No, it's not --- that's the problem! > Well then it must be a port from the TRS80 or Commodore 64 because this sort of logic is a load of garbage and is from the dark ages. Do you have the source code because if you do it needs reworking and if you don't it needs replacing.
From: Jeroen Mostert on 14 Feb 2010 04:50 On 2010-02-14 2:28, David Given wrote: [getting statically compiled code to appear at a particular address] > I've done some investigation of PE executables with objdump and I see > that they have a fairly standard section table: > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 0001f154 00401000 00401000 00000400 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 1 .data 000000b0 00421000 00421000 0001f600 2**2 > CONTENTS, ALLOC, LOAD, DATA > 2 .rdata 00020e1c 00422000 00422000 0001f800 2**5 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 3 .bss 00000d48 00443000 00443000 00000000 2**3 > ALLOC > 4 .idata 000013d8 00444000 00444000 00040800 2**2 > CONTENTS, ALLOC, LOAD, DATA > 5 .rsrc 0000b228 00446000 00446000 00041c00 2**2 > CONTENTS, ALLOC, LOAD, DATA > > It may be worth experimenting with adding a custom section. Building a fixed-address DLL from the code and importing that may be even more convenient than mucking with sections, but I don't know what format your code is in. If you do want to go the section route, you'll need tool support (you'll probably need that for the DLL approach too). The linker that comes with Visual Studio has no support for explicitly locating and sizing sections, as far as I can tell. You can use #pragma section from within source files to place variables in a custom section, but you cannot tell the linker to place the contents of a particular .obj in a particular section. You can use the mingw32 port of the GNU linker (ld), as it does have support for explicit sections (http://sourceware.org/binutils/docs-2.20/ld/Scripts.html). You can use objcopy from the same toolchain to change the sections of the object file. -- J.
From: Jonathan de Boyne Pollard on 14 Feb 2010 09:53
> > > Well then it must be a port from the TRS80 or Commodore 64 [...] > With 1GiB of RAM? That would have been some Commodore 64. |