Message-ID: <009801be85f4$60c39f20$af52989e@default> From: "Arron Shutt" To: Subject: Re: DJGPP: the future is... forward? Date: Tue, 13 Apr 1999 22:26:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 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.. 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 standard... 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 X/Gnome... 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 well... 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. 9. GIMP 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 -- www.ashutt.demon.co.uk "You can jump all you like but it's the day of the cow" - Mike Keneally