From:	alaric AT abwillms DOT demon DOT co DOT uk (Alaric B. Williams)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: __djgpp_base_address
Date:	Wed, 12 Mar 1997 20:10:29 GMT
Message-ID:	<3325c197.1560353@news.demon.co.uk>
References:	<199703051831 DOT MAA141402 AT audumla DOT students DOT wisc DOT edu> <332200de DOT SANDMANN AT clio DOT rice DOT edu> <5g0ao0$sjl AT freenet-news DOT carleton DOT ca>
NNTP-Posting-Host:	abwillms.demon.co.uk
Lines:	40
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

On 10 Mar 1997 06:46:24 GMT, ao950 AT FreeNet DOT Carleton DOT CA (Paul
Derbyshire) wrote:

>Two questions:

>* This seems to say that something like this won't work:

>  char *the_ptr;
>  the_ptr=malloc(the_size);
>  _go32_lock_data_memory(the_ptr,size); (syntax? not sure)

>  because later the data may find itself moved somewhere (despite being
>  locked?) while the locked memory stays put?

No. The addresses of things can't change behind the scenes - a
restriction of the C language due to pointer casting problems - so
once you lock something, it's locked; you lock the *virtual* address
range, not the physical address, which is subject to change. Anyway,
the above code /is/ wrong - you must lock the pointer AND what it
points to!

>* What is sbrk()? It sounds like the "malloc behind malloc"... as in, the
>  routine to allocate more heap from the kernel or DPMI host, rather than to
>  allocate more for the app from the heap.

AFAIK, yes.


ABW
--

"Simply drag your mother in law's cellphone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."

(Windows for Early Warning and Defence User's manual P385)

Alaric B. Williams Internet : alaric AT abwillms DOT demon DOT co DOT uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>

- Raw text -