www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/09/09/10:46:18

Date: Mon, 9 Sep 1996 17:28:45 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Claudio Santia` <c_santia AT net4u DOT it>
Cc: djgpp AT delorie DOT com
Subject: Re: Are there strong debuggers for DJGPP?
In-Reply-To: <3233514C.6061@net4u.it>
Message-Id: <Pine.SUN.3.91.960909171902.8698B-100000@is>
Mime-Version: 1.0

I will try to answer the questions, but experience shows that different
people use debuggers in vastly different ways, so I advise you to try the
available debuggers yourself before you decide what's good enough for you,
and not rely on opinion of others alone. 

> 1) Are there any alternatives to these two mentioned debuggers?  I will
> prefer a source-level, full-screen debugger similar to Turbo Debugger
> (to make an example).

The next release of RHIDE, the IDE for DJGPP, will include an integrated 
debugger, which is a just a GDB in disguise.  So you should be able to 
enjoy both the power of GDB and the convenience of a full-screen 
environment.

> 2) Which are the real limitation of FSDB?  I do a lot of code in C++ and

The only *real* limitation (IMHO) is that you cannot examine complex data 
structures easily (you need to use the [name+offset] notation).  The user 
interface is *very* similar to TD.  Since the C source code is shown 
together with the assembly, I don't see that as a real limitation.

> 3) At first I cosidered buying WATCOM to develop Extended-DOS games.  Is
> there any reason I would buy WATCOM instead of using DJGPP (I intend to
> write games as a professional developer, so I need all the tools to
> write and debug code as faster as possible)?

Does the fact that id software went from Watcom to DJGPP when they began 
developing Quake answer your question?

- Raw text -


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