Message-Id: <199704210823.KAA00779@math.amu.edu.pl>
Comments: Authenticated sender is <grendel@[150.254.113.14]>
From: "Mark Habersack" <grendel AT hoth DOT amu DOT edu DOT pl>
Organization: PPP (Pesticide Powered Pumpkins)
To: Lorier <lorier AT ihug DOT co DOT nz>
Date: Mon, 21 Apr 1997 10:24:21 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Usage of directory entries
Reply-to: grendel AT hoth DOT amu DOT edu DOT pl
CC: pierre AT tycho DOT com, opendos-developer AT delorie DOT com
In-reply-to: <m0wIORZ-000FkaC@hn.planet.gen.nz>
Precedence: bulk

Once upon a time (on 19 Apr 97 at 12:55) Lorier said:

> >> What are they currently?  And how different is NASM? the difference of
> >> AT&T -> Intel? or is it just formatting? :)
> >OD sources use TASM (several versions), RASM (an internal DRI assembler)
> >and MASM (also several versions). All Intel syntax.
> 
> They didn't get the rights to RASM perhaps? Hmm... Ah well, possibly write a
> TASM klone and port everything to that :)
;-)) I've just discovered another NASM limitation. It does not produce debug 
information, nor line information nor source file information in the 
generated .obj file. I use Soft-Ice for debugging and need the .map files to 
contain that exact information: source file and lines. Does anyone have 
OMF .obj format handy? I would then patch NASM to output such information. 
For know I have created a set of DJGPP CPP macros to enable generation of 
source compatible with TASM and NASM. I compile under TASM for debugging and 
under NASM for release ;-))
==================================================
Stand straight, look me in the eye and say goodbye
Stand straight, we drifted past the point of
  reasons why.
Yesterday starts tommorow, tommorow starts today
And the problems seem to be we're picking up the
  pieces of a ricochet...