1
 
Two messages from DANNYSOFT BBS, captured on 10/4/87.

Message #1448
  To ALL                                    09-17-87            
From CARLOTTA DECONCILIS                    Subject PROBLEMS WITH MASM V5.0
---------------------------------------------------------------------------
           ****   Courtesy of Glenn Dobratz   ****
The following is a description of the problems which I have
encountered in installing the V5.0 release of the MicroSoft
Assembler and its support utilities.
MASM
- The assembler does not detect certain illegal 386 instruction
  syntaxes and generates bad code for them.  Specifically, the
  386 now permits the syntax [EBX*n] for indexing, where n is 2,
  4, or 8.  This automatic scaling is supported only for the extended
  32-bit registers.  The syntax [BX*n] is not legal, but MASM accepts
  it and generates a junk instruction.
- The assembler no longer accepts the ASCII Form-Feed character as an
  equivalent to the PAGE directive.  If you have been using this to
  separate the subroutines in your .ASM files, you find that they are
  no longer on separate listing pages.  This is an undocumented
  difference from V4.0.
- PAGE directives are now listed on the first line of the new page
  instead of the last line of the current page.
  This change is undocumented.
- If you use the .386 directive to access the 80386 instruction set be
  forewarned that the default for the conditional-jump instructions
  (Jxx) changes from SHORT to NEAR and all of your conditional jumps
  which do not have explicit SHORT encodings now become longer and
  slower. This change is documented.
- If you use the .386 directive in some files and do not use it in
  others, there is no practical way to have neat header files such as
  DOS.MAC to define your segments.  This only affects .ASMs which you
  are trying to make be compatible with Lattice C; MSC is OK.
  The problem is that your 386 segments must include either USE16 or
  USE32 unless you use MicroSoft's default segment names, which
  Lattice does not.
  But if you do not use .386 then you are not permitted to put USE16
  or USE32 in your segment declarations.
  This makes it impossible to have one file, such as DOS.MAC, which
  will work properly regardless of whether or not .386 is present.
  There is also no way of testing whether or not .386 has been
  specified, so the .MAC file can't do its segment declarations
  conditionally.  Sigh.
LINK
- If you mess up your segment definitions and wind up attempting to
  combine two PUBLIC segments, one of which is USE16 and the other is
  USE32, then the link will fail with an error L1123 which has no
  associated text message to tell you what is wrong or where.
  L1123 is not documented in the manual either.
- The new format .EXE files which are generated by LINK are slightly
  larger than they were for the same program using the previous LINK.
MAKE
- They have made an undocumented change which breaks old MAKE files
  which use TOOLS.INI to define inferrence rules.  The V4.0 MAKE would
  not parse the text read from TOOLS.INI for macro replacement until
  it really needed to use the particular rule.  The new MAKE performs
  macro replacement on the TOOLS.INI text when it reads the file in,
  which is done before your MAKE file is read.
  This means that your program cannot define/redefine macros which are
  used in TOOLS.INI since the replacement is done before your macros
  are scanned. This makes it impossible for a MAKE file to
  'communicate' options, etc., via macros, to the inferrence rules in
  TOOLS.INI.
- The problem with the old MAKE that it does not conform to the
  documentation on how TOOLS.INI is scanned has not been corrected.
  Inferrence rules which are defined in TOOLS.INI are still mutually
  exclusive with the inferrence rules which are defined in your MAKE
  file. The documentation says that rules in your MAKE file have
  priority over the rules defined in TOOLS.INI.
If you encounter an problems which I have not enumerated above, I
would very much like to here about them.  You may contact me by
leaving a message for me on the Lattice BBS or at the phone number
below between 12:00 and 18:00 CT.
Glenn Dobratz
(312) 882-7305
LBBS(312) 916-1200(9600/2400/1200/300/8/N/1)

* * * * * * * * * * *

Message #1709
  To CARLOTTA DECONCILIS                    09-28-87             (Rcvd)
From FRANK HABER                            Subject (R)PROBLEMS WITH MASM V5.
---------------------------------------------------------------------------
How 'bout 'dis?

Fm: SysOp Chris Dunford 76703,2002
To: Don 73047,1113

The four bugs that I know about (courtesy of Bob Smith):

1. A problem with ASSUME.  Sometimes MASM fails to detect that none of
the
segment registers are set to address an data object and invalid code is
generated (a DS override where DS doesn't address the object).  No
warning or
error messages.

2. Sometime it computes the length of an instruction differently on the
two
passes and does not warn.  Then it outputs two object records for the
instruction.  LINK then adds nulls, rsulting in the execution of the
instruction ADD [BX][SI],AL.  No error messages, and the LST file
appears to
be correct.

3. Certain constructs cause no public records to be emitted for objects
declared to be PUBLIC.  (Bob says he reported this bug to MS in 1985,
with
sample code.)

4. Certain kinds of nested structures that should work, don't.

3 and 4 I can live with, but 1 and 2 are very nasty.
 1:1