delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/04/16/16:34:58

Message-ID: <3717ACCC.A601E9D1@lycosmail.com>
Date: Fri, 16 Apr 1999 17:34:04 -0400
From: Adam Schrotenboer <ajschrotenboer AT lycosmail DOT com>
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: DJGPP: the future is... forward?
References: <009801be85f4$60c39f20$af52989e AT default>
Reply-To: djgpp AT delorie DOT com

Arron Shutt wrote:

> Greetings!
>
> After my last post about what could be the future of djgpp, I've had some
> more thoughts about what could be another way forward. It now seems that
> supporting Linux directly is not perhaps in the remit of djgpp.
>
> It would appear to me that the path ahead is to now actively replace as much
> proprietary user/development software (MS? :-)) as possible on the Dos/Win
> platforms with free GPLed versions. We already have the programming tools to
> do this with the gcc compiler and others. The Gnu Project has done this with
> the Unix platform, and I think that we can produce similar results with the
> Dos/Win platform..
>
> The secondary objective would be to then to port the packages to as many
> platforms as possible. This will help remove obsolesence, there is no reason
> why there should not be Dos/Win/X/Linux/Mac versions of the software and
> this will certainly bring djgpp to a much bigger audience.
>
> This give djgpp software a much wider user base, but in the event that one
> platform is discontinued/locked out, we push ahead on the others..We can
> also target schools and universities, confident that it will work on
> whatever hardware and OS they may be running..
>
> The format of the source I imagine would be like MESA and the version of
> Allegro (V4) under development. The source is broken into platform specific
> and generic code. The advantage of this is that code is only rewritten where
> necessary, and one install suits everyone. It should make the source easier
> to maintain and to work on...
>
> To save time and effort, we should try to use already existing GPLed
> applications as a basis for the development. The potential amount of work
> ahead makes the existing djgpp code look like a weekend hack by comparision
> :-) so I would try and make life easy for ourselves if we decide to go ahead
> with this..
>
> Having the ability to add/remove features by plug-ins (or compiling the code
> required) is a good way of tailoring all the the applications to suit the
> user. I personally don't need a dancing wire entity popping up to tell me
> how to type at the keyboard, but I can see how it would be a good incentive
> to encourage young children into learning a package. This ability is unique
> for DOS/Windows software (perhaps because the source code is not
> available..)
>
> I'm not sure how to proceed on this, but I would suggest making a list of
> common applications which are required, what exists already which could be
> used to start on the project, working out which projects are highest
> priority and try to get done first, and coordinate effort by use of DJ's
> 'virtual company' to focus development where it is required. I think that
> there should be some kind of specifications for the larger projects, so that
> we can see how things are progressing..
>
> Eli Zaretskii came up with the following objectives during the discussion
> that I had with him, and I think that they sum up the goals I had in mind as
> well..
>
>   - make DJGPP more visible to the masses (schools would be a good
>     place to begin);
>   - add applications that could be used as replacement for MS software;
>   - continue development of core DJGPP to make it up to date with
>     technology (the upcoming C9X standard, internationalization, etc.).
>
> I would also add to these that having well written user and technical
> documentation is also extremely important. We should try and write this as
> we develop the code, rather than leave it as a afterthought. It may seem a
> tougher option to follow, but if we are going to try to attract new user and
> developers, I think that free documentation is also important to bring
> people up to speed and start helping us out in our noble quest :-)
>
> Open standards should be used wherever possible, but supporting proprietary
> file formats is paramount to get users to use the software and be confident
> of sticking with it.. By supporting everyone, we don't discriminate and
> maximise the user base...and appeal to as many people as possible.
>
> Anyway here are my list of applications we could work on. Feel free to add
> and comment on anything you see. if you know of ports in progress, or sites
> where info can be found, then post it. I have only one set of eyes and a
> large modem phone bill, so I can't be everywhere at once :-)
>
>  I have two classes of applications - support and user programs..
>
>
> 9. GIMP
>
> I don't know whether this has been ported (in progress?) to Dos/Win...
>

In reference to GIMP, as I understand, there is a port to Windows, but it uses
Visual C++, (which I really dislike, being bound to M$). As for DOS, I'd guess
that because there is no DOS GUI other than Windows, a DOS port is not even
being considered. It probably would be if a port of X was done, however.

- Raw text -


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