Message-ID: <009401be86db$fe444780$af52989e@default> From: "Arron Shutt" To: Subject: Re: DJGPP: the future is... forward? Date: Thu, 15 Apr 1999 02:04:11 +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 >[big amount of text sniped] >> I have two classes of applications - support and user programs.. >> >> 10. Database > >I personally have good experience with Borland Delphi/C++ Builder. >IMHO their concept of Visual Class Library is *very* good - it has >classes for visual interface, report printing as well as non-visual >classes for doing "background things" (timers, threads, database). >Database classes are tightly bind with DB-aware versions of user >interface components. This way I'm able to write (not too complex) >invoicing application in 3 days from scratch. > A modular system was something I was thinking about since it is easier to develop. Some of the database stuff I've written in the past gets very complicated very quickly, and I want to keep things as simple as possible. Supporting OBDC seems to be a good step, since that gives connectivity to other proprietary systems. After a search on the net, I didn't see a lot of information on programming databases, so I think that if the code is well written, documented and easily portable, we have a good resource for Computer Science courses to teach with. This helps with my broad objectives :-) >10. Database >maybe port of MySQL or PostgeSQL from Linux platform? I can't imagine >how much work it is. MySQL seems to be 'Open Source' (at least the Client source is) although they may go over using GPL at some point. It probably is going to be a lot of work to port one of these, but since the vast majority of the code is going to hardware independant, we should only need to do it the once.. Or may be collect "drivers" for different DB formats >and write "roof" over them to present same interface to applications. I think the goal to support as many file/database formats as possible is important, but I thought that Access and Paradox seem to use OBDC for interchange of data. I'm not a professional software developer (I'm a scientist) so my knowledge of the current industry 'standards' for these if limited. If the projects such as the ones I suggested to go ahead, then I have a lot of reading to do and discussions on the best way to implement them.. Thanks for the feedback. I'm still interested in what people think on the ideas I had, and whether they see it as a possible future for djgpp. Especially with those with more experience and knowledge with djgpp than I have (which is most of you I guess... :-)) --- 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