Mail Archives: djgpp/1999/04/13/17:26:53

Message-ID: <009801be85f4$60c39f20$af52989e@default>
From: "Arron Shutt" <version8 AT ashutt DOT demon DOT co DOT uk>
To: <djgpp AT delorie DOT com>
Subject: Re: DJGPP: the future is... forward?
Date: Tue, 13 Apr 1999 22:26:17 +0100
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Reply-To: djgpp AT delorie DOT com


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

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

  - 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..

1.  FreeDOS/FreeWin

I said enough on this already, but it would be cool to have a improved free
software foundation, with all of our favourite features built in as

2. BabelGnu (support library)

Sorry - The image of a Gnus head poking out of someone's ear was too funny
to resist. I have to thank Eli again for this idea since it was his, but it
has real advantages and a clear application for every programmer...

This is a library of import and export routines for all proprietary file
formats for MS and others, based on commonly available specs on what ever
sources we can find them. This should be a great library to build
application software on, since our user can then be sure that their
exisiting files will work fine. This should also help for 'tied-in' users to
break free of using a single package and use free software instead, sure
that they will be able to keep up to date with whatever the big bad software
companies decide to make their file format this week..

I actually started writing a QPW and Excel routine today at work, so I might
take the lead on this! :-)

3. X

Someone has mention porting X, and porting Gnome as well would give Dos/Win
users the advantages of using the API for porting across software using

4. mini-Gnome? (support library)

This is a mini single application version of the Gnome GUI for producing DOS
programs. The advantage I could see to this is that producing DOS versions
of packages would be easier from a Gnome version, plus it should make the
multi-platform code easier to write..and we have a nice interface :-)

5. Word Processor

Replacing the likes of Word, with a compatible multi-platform package that
is tightly written, fast, and less processor hungry is quite a challenge. It
should still retain the useful features such as spell checking and a
equation editor (please!).

6. Spreadsheet

Gnumeric is under development, and I can see that this would be a good start
for a port. It runs under Gnome, but other platforms can supported as

7. HTML creator

Something that has both 'document setting ability' (to win over the
Frontpage users) and a line editor (for efficient code) would suit
everybody. I know that Emacs has HTML capability, but more people are using
word processors to write web pages, because of click and drag. I prefer line
editors, but I can't speak for everyones preferences..

8. Graphical Web Browsers

I know we have Lynx for text mode browsing and Mozilla is Open Source, but
AFAIK, there is no GPLed equivalent of Internet Explorer.


I don't know whether this has been ported (in progress?) to Dos/Win...

10. Database

I personally don't know of any good GPLed databases, and since I am being
forced into using Access, replacing this would be a nice step...

11. Project management software / Personal Information Management / GPLed
Palm Top software

Information Managers are becoming more common, and might also help with this
organising this enomous amount of work in the djgpp 'virtual company'...I
know that there is a Palm Pilot development package for Linux using gcc, so
this might be a good start for the porting here...

12. Visual GCC?

Producing a interface designer for GUI such as Windows and X/Gnome would
speed up graphical program development across Windows, since the same design
could churn out 'form files' for every GUI going.

I've just mentioned a few of the more common apps, but I'm sure there are
many, many, others. This is designed as a discussion document and so I would
be interested in getting some feedback going. I have no problems with
getting shot down in flames, if I learn something during the process. So
don't hold back with any constructive criticism, especiallly if it leads to
constructive software writing and progress towards free software for all...

It's a big task, but we have the best programmers, and many of them. Users
around the world will benefit greatly from the fruits of our labours..

Over to you...

Arron Shutt
version8 AT ashutt DOT demon DOT co DOT uk --
"You can jump all you like but it's the day of the cow" - Mike Keneally

- Raw text -

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