X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Thu, 16 May 2002 22:25:06 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: sandmann AT clio DOT rice DOT edu
Message-Id: <4949-Thu16May2002222506+0300-eliz@is.elta.co.il>
X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: lauras AT softhome DOT net, djgpp-workers AT delorie DOT com
In-reply-to: <10205161727.AA12999@clio.rice.edu> (sandmann@clio.rice.edu)
Subject: Re: emacs under w2k
References:  <10205161727 DOT AA12999 AT clio DOT rice DOT edu>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: sandmann AT clio DOT rice DOT edu
> Date: Thu, 16 May 2002 12:27:58 -0500 (CDT)
> 
> Oh wait, EMACS does that dump thing, so unixy sbrk() will really be
> a requirement

I don't think so.  The dumped executable starts its allocation anew
when it runs; the old heap is converted into .data and its free memory
chain forgotten.  (Most allocations before dumping are done in the
.data segment anyway, by redirecting malloc to allocate off a special
static array instead of from the heap, so the heap itself is actually
very small when Emacs dumps itself.)

In addition, our library is unexec-safe, so no special precautions
should be needed for running the dumped Emacs.  However, perhaps this
bug will show that I'm mistaken here...

I actually used Emacs built with the library malloc and the default
sbrk for some time during the early days of DJGPP v2.0 (that's why
it's so easy to switch), because the relocatable allocator caused a
hard-to-debug bug I described elsewhere in this thread.  So I know it
works, or at least used to work, although the memory footprint grows
rather quickly (so don't think about running it for a month or so ;-).

> unless someone stops that
> insanity at least for initial dumps. :-)  Since it has it's own malloc()
> it just might require unixy sbrk() anyway.

That happens automatically: you will see that src/msdos.c in the Emacs
sources notes when GNU malloc and relocatable allocator are used, and
sets the Unixy sbrk bit in _crt0_startup_flags.  At the time I did the
DJGPP v2 port, I didn't believe the relocation code could cope with
non-contiguous DPMI memory madness, so I decided to play it safe.  But
I never actually tested that, so who knows...  (It looks like the
Emacs sources actually have code to deal with that.)