Message-ID:	<3CF6ABDC0FE3D2119CEA00A0C94B9A0A8733@rj01mai01.informatica.telerj.net.br>
From:	=?iso-8859-1?Q?Jos=E9_Paulo_Vidal_Amaral?= <josepva AT telerj DOT com DOT br>
To:	djgpp AT delorie DOT com
Subject:	RE: DJGPP: the future is. . .?
Date:	Tue, 30 Mar 1999 09:41:34 -0300
MIME-Version:	1.0
X-Mailer:	Internet Mail Service (5.5.2448.0)
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id IAA28321
Reply-To:	djgpp AT delorie DOT com

> I like very much that discussion! Thanks DJ to open that!
> 
> I see many ports of gcc to many different Operational systems and to many
> different microprocessors, but each implementation of gcc acomodates the
> differences for each OS/MP without worring about creating a similar
> interface that should help people to migrate from one OS/MP to another.
> The other problem is that if you want to create a program for Linux you
> will need Linux and gcc for Linux, if you want to create a program for DOS
> you will need DOS and DJGPP, etc ... So, if you want to create a
> multi-plataform application, for each OS/MP that your application will
> support you need each OS/MP and each implementation of the gcc and
> certainly you will need a computer for each implemenation you want.
> 
> My suggestion for DJGPP survival is,
> 
> 1 - Create a standart way for DJGPP create programs for others OS/MP than
> DOS and intel family. This way, should be generic enough even to acomodate
> any kind of new OS/MP that appears everywhere and should be well
> documented for make life easier for people that wants to create a new
> OS/MP implementation.
> 
> 2 - Create a standart interface that should be used for every different
> OS/MP implementation. I suggest Turbo Vision for doing the job, see that
> i'm not talking about reuse Turbo Vision code, but reuse Turbo Vision
> Interface, if the OS/MP needs specific code, so rewrite Turbo Vision
> respecting the standartizantion for that OS/MP in a manner that the
> application programmer do not have to worry about anything except the
> application code, but leting him /her free to use the OS/MP especific code
> if he/she wants.
> 
> So the first think to do, if my suggestions is appreciated, is to open a
> discussion for stablish the standarts, if we'll be able create a good
> standart the rest should be easy, as the programming part have to follow
> the standarts.
> 
> I know it should be a real BIG job to do, but, DJ, you said that we should
> think BIG.
> 
> José Paulo
> 

- Raw text -