www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/10/25/12:57:02

Date: Mon, 25 Oct 1999 13:52:20 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Davin McCall <DavMac AT iname DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: Just a few questions
In-Reply-To: <3813cd8d.15570356@newsserver.cc.monash.edu.au>
Message-ID: <Pine.SUN.3.91.991025135202.9200A-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Mon, 25 Oct 1999, Davin McCall wrote:

> Your points about the tiny model and flat model being essentially the
> same thing are correct, but I still maintain that the 16-bit version
> is called "tiny" and the 32-bit version is called "flat".

Both of these names are not accurate enough for describing the DJGPP
environment.  

The problem with "flat" is that it implies a linear address space
whereby all addresses used by a program present a linear array with no
segmentation.

However, this is not how the DJGPP runtime environment works.  The
DJGPP startup code creates several additional segments required for
proper program operation in the DPMI environment.  One of these
segments is widely known: that's the segment whose selector is stored
in _dos_ds.  Without this segment, a DJGPP program cannot do anything
useful because the entire interface with DOS/Windows needs it.

There are also other segment selectors created by the startup code,
which are mostly invisible from the application code, but nevertheless
required.  If you want the gory details, read the sources.

So it is not quite right to call the DJGPP environment "flat".  The
problem with "tiny" is that the word "tiny" has a connotation of small
memory space, but it does imply, quite correctly, the existence of
other segments, beyond the ``usual'' ones, where code, data, stack,
and the heap live.

Now, as long as we all understand the real nature of the DJGPP runtime
environment, as far as memory layout is concerned, we don't need to
argue about the names.

Btw, 64KB for code and data is not so "tiny": I've seen very serious
and non-trivial programs that fit into these constraints.  It is IMHO
an insult to every serious programmer out there that the current
powers-that-be succeeded to brainwash us to think this was true, just
because those very powers are so good at producing bloated software.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019