Mail Archives: djgpp/1999/10/13/15:41:51
On Tue, 12 Oct 1999, Johnny Chan wrote:
> Actually, I am trying to do a FULL system memory scan and
> read/write test. I want to know where the code starts and where
> the data stays so that I can add some protection based on these
> information and my program will not over write any code or
> data or heap or others accidentially.
If you want safety, your program shall not write to any address below
what sbrk(0) returns, because some or all of the addresses in this
range are used by the code or the data of your program.
You *can* read from these addresses, though (except that reading from
the null page would ususally crash your program under CWSDPMI and
other DPMI v1.0 hosts, unless you set the _CRT0_FLAG_NULLOK bit in the
_crt0_startup_flags variable).
As long as you manipulate logical (as opposed to physical) addresses,
the above is all you should consider.
Note that, in general, you cannot access memory beyond the current DS
limit. You might use the near pointer hack to make all addresses
accessible, but if you really want to access all the physical memory,
that won't do. You need in addition to map all the physical memory
into your address space. One way of doing so would be to use the
method described in section 18.7 of the DJGPP FAQ list. If you go
that way, you don't need (and don't want) to use the nearptr hack; use
either movedata or the farptr functions instead.
> What will happen if my program does some memory read/write test
> on the memory area where is the loader located originally?
As I said: nothing will happen. A typical DJGPP program does that all
the time, when it reads/writes files, because the data is moved
through the transfer buffer. See section 14.4 (in particular, the
large footnote there) for more details about the transfer buffer.
- Raw text -