Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE3D9797F@probe-2.acclaim-euro.net>
From: Shawn Hargreaves <ShawnH AT Probe DOT co DOT uk>
To: djgpp AT delorie DOT com
Subject: Re: DJGPP: the future is... ?
Date: Mon, 29 Mar 1999 12:05:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Reply-To: djgpp AT delorie DOT com

Mariano Alvarez writes:
> 1- To Integrate in the libc:
>     - Thread support.

I agree, proper multithreading would be very nice. Extremely hard to 
do well, though: this would require some major rewriting of libc, and
wrappers around every DOS call. Due to the bad design of DOS, it 
wouldn't be able to switch threads while a DOS call was in progress,
so the threading wouldn't be very smooth, either.

> 2- Make DJGPP a integrated enviroment (possible two flavours Emacs &
> Rhide).

It already is! Download Rhide, and you have one IDE. Download Emacs,
and you have another. Download neither, and you can have whatever
other system you personally prefer (myself, I use makefiles and FED).
The only way to go beyond the level of integration that Rhide already
provides would be if you started taking away people's freedom to use
other tools, which can never be a good thing.

> 3- Allegro, GRX & a X-server over the commons DJGPP graphics drivers.

Why on earth would you want to do that? Graphics drivers don't belong
in a compiler or C runtime. Depending on what you are trying to do,
it can be easier to code directly from your drawing routines to the
metal, in which case the driver must be included directly in the lib,
or you might prefer to use a standard driver interface, which is why
we have VESA and VBE/AF. Putting the video drivers directly into djgpp 
would gain us nothing over VBE/AF, and only make it impossible to
use them from other compilers or operating systems.


	Shawn Hargreaves.