Xref: utzoo comp.os.msdos.programmer:3574 comp.sys.ibm.pc.hardware:5919
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!world!jstone
From: jstone@world.std.com (Jeffrey R Stone)
Newsgroups: comp.os.msdos.programmer,comp.sys.ibm.pc.hardware
Subject: Re: Romable code with Microsoft C?
Message-ID: <1991Feb25.172558.23849@world.std.com>
Date: 25 Feb 91 17:25:58 GMT
References: <1991Feb22.155750.1404@wuphys.wustl.edu> <1991Feb22.211530.4528@nntp-server.caltech.edu> <1991Feb23.131631.21569@world.std.com>
Organization: The World @ Software Tool & Die
Lines: 67


In an earlier posting I offered to describe some bugs I had found in
Turbo Debugger.  Since I've had several requests, I am posting the
list here.  None of them is so serious as to make TD unuseable, but
one of them (the block-write bug) quietly causes bad data to be
written to a file.  I feel that Borland ought to have fixed this one
immediately and should have all notified registered users of its
existence.

This is not a diatribe against the company or its products.  I use TD 
personally and professionally and highly recommend it.  In spite of 
these bugs, it is still my personal and professional opinion that it is 
the best debugger available for software development targeted to 8086-
family processors.  I am offering this information to other users of 
Turbo Debugger who may benefit by not having to waste the time I did 
looking for non-existent bugs.  I would be appreciate hearing about 
other bugs and work arounds to them.

-jeff-
 

The list:

1. Block I/O in remote mode writes bad data.

   When using TD in remote mode, block I/O from between target memory 
   and a local file happens in 120-byte packets.  Unfortunately, the 
   memory pointer seems to be advanced only 110 bytes each time.  On 
   output, this causes the last 10 bytes of the first packet to be 
   repeated as the first 10 bytes of the second, and so on.  My remedy 
   was to write enough more data than I really wanted to make up for the 
   bytes wasted to repetition, then post-process the output files to 
   remove the repeated bytes.


2. Two-valued dialog boxes fail after using the assembler.

   Some dialog boxes request two inputs, such as starting address and 
   byte count for block writes, or port-address and data for output to a 
   port.  Once you have assembled instructions into memory using the 
   internal assembler, these dialog will fail with the message "Extra 
   input after expression".  The remedy is to patch in hexadecimal 
   (Yuck!) in a data window if you will want to to use any features that 
   use two-valued dialog boxes later in the session. 


3. Block I/O buffers aren't flushed when shelling out.

   While the buffers are managed OK at exit, I often wanted to shell out 
   to graph some data captured from the remote system, and then resume my 
   interupted program where it left off.  Requiring me to exit first 
   loses the states of the target program and the debugger.


4. TD won't inspect the value of functions written in assembler.

   It can inspect the value of C functions, so why not assembler 
   functions?  Not exactly a bug, but it seems an unnecessary and 
   useless restriction.


The follwing was supplied to me one of the respondents, for which I am
grateful.  I have not tested it.

  If a breakpoint condition is too long, the popup window that tries to 
  tell you about it will crash the whole machine.  It doesn't try to wrap
  the expression.