Message-ID: <3717ACCC.A601E9D1@lycosmail.com> Date: Fri, 16 Apr 1999 17:34:04 -0400 From: Adam Schrotenboer 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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.