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.