masm.exe vs ml.exe

[allynm]

Hi everyone--

Would someone be kind enough to give me a bit of education on the differences betwen ml.exe and masm.exe?  The context for this question is that I was interested in getting a cross reference table for a silly little 16 bit program.  This led me to masm.exe as the program that would produce such a table.  This led then to the realization that I had no understanding at all of the relationship between ml.exe and masm.exe and why there are two different assemblers.  All the old 16 bit books (such as Norton and Socha or Alton Kindred"s splendid text) routinely assemble their code with MASM.  I really hadn't questioned why ML showed up and why we nowadays seem to use it in preference to MASM.  Obviously, from the number of options, ML does much more than MASM did.  But, it also doesn't do a XREF!  My history is very weak;  Whence cameth ML?  Why? Why didn't MASM v. xxx simply contain the same functionality as ML but with a higher version number?  A whole bunch of things showed up in ML that weren't in MASM, but also there was a program name change.  Why do these two programs continue to coexist in masm32 distribution?

Direct question:  If I assemble a 16 bit program with MASM does it "automatically" produce an OMF object?  If so, then why would I ever use ml.exe with the /omf switch rather than masm.exe?

I do believe this is a question that has Dedndave written all over it.  Basically, I need a history lesson!

Regards,
Mark Allyn

[MichaelW]

From the Microsoft Macro Assembler Programmer's Guide for version 6.0:

The name MASM has traditionally been used to refer to the Microsoft Macro Assembler. It is used in that context throughout this book. But MASM also refers to MASM.EXE, which has been replaced by ML.EXE. In MASM 6.0, the MASM.EXE is a small utility that translates command-line options to those accepted by ML.EXE.

BTW, MASM.EXE is a 16-bit app, where some time after version 6.0 ML.EXE became exclusively a 32-bit app (prior to this IIRC it was some sort of dual-mode app). And MASM.EXE in not present in any of the MASM32 installations I have, the oldest from ~7 years ago.

And I routinely assemble 16-bit DOS apps with ML.EXE without specifying the /OMF switch.

[FORTRANS]

Hi,

(prior to this IIRC it was some sort of dual-mode app).

   Yes.  Version 6.0 was a "family bound application" (IIRC).
That meant that it would run in either MS-DOS or OS/2.  Then
M$ and IBM had their hissy fit and 6.? was made a Win32
application (again IIRC).  Family applications used a subset of
MS-DOS and OS/2 functions so it could run under either.
Windows NT (and somewhat later {pre-XP?}) could run
OS/2 1.x programs as MS had sold their version of OS/2 for a
while.  Windows NT supported multiple API's using a subsystem
for each over (under?) the Windows kernel.  These supported
at least DOS, 16-bit Windows, 16-bit OS/2, and POSIX programs.
Esoterica.

Cheers.

Steve N.

[clive]

Then of course is 32-bit OMF used by Linear Executables in Windows 3.x, 95 and OS/2

[allynm]

Thanks all,

Yes, in my distribution of masm32 there is no MASM.EXE, as MichaelW points out.  I have, however, a distribution of MASM_6_14 in which MASM.EXE is present and is not just a small utility that translates command lines for use by ML.EXE.  It is this version to which I was referring in my initial post on this topic.  Since there is no /omf switch to be set, I have assumed that this is basically the same ("upgraded") 16 bit MASM.EXE that was referred to in the classic texts by, among others, Kindred (BTW, thanks again Fortrans for making me aware of this book).

The history of MSFT and IBM is strange indeed.  I was busy doing other stuff during this long period of conflict/cooperation and only now am beginning to see why it must have confused everyone horribly at the time it was evolving.

One final point for MichaelW.  I was under the impression that /omf had to be set in order to get ML to produce 16 bit objects.  It seems I'm wrong.  I'll try assembling without it and see what happens.  But, why then is there this option?  Under what circumstances must the /omf option be selected?

Regards,

Mark Allyn

[clive]

Well, at least until around MASM 9.x or so as I recall, MASM required a /coff option NOT to output in OMF. I mainly use 5.x and 6.xx, although most of the tools I use these days output ELF<G>

[allynm]

Hello everyone,

Well, it seems my earlier conclusion was incorrect.  In the 6.15 distribution of masm, the MASM.EXE command really is ONLY a quick means of calling ml.exe.  There is an option /c in MASM.EXE which, according to the help file supposedly will generate a XREF between line numbers and symbols.  But, this appears to be incorrect.  In fact MASM.EXE interprets the switch precisely the same way that ML.EXE does---generate an object file without linking.  Moreover, and this is really annoying, if you use MASM.EXE it does NOT generate an omf file.  In fact, it generates a coff file and will reject any attempt to use the /omf switch--says it doesn't recognize this option.  Wow. 

So, here is where matters stand as regards creating 16 bit symbol/line cross-references.  You can't do that anymore unless you're running earlier versions of MASM.EXE.  ML.EXE does not have that functionality, for either 16 or 32 bit code, and MASM.EXE is merely a quick and dirty way to invoke ML. 

I tried to get around this by assembling with the /Fr switch on to generate an .sbr file.  I was able to do that but CREF.EXE and BSCMAKE.EXE (both of which are in the masm615 distribution) choke and generate errors regarding a corrupt .sbr file.  My guess is that this is due to the fact that the assembler created an omf file, not a coff.

Oh well,
it's been really fun anyway.

Mark

[clive]

Ok, so with MASM 6.11a, and a contemporaneous BSCMAKE seem to work, generating an OMF object.
Initially it was finding BSCMAKE from 5.10 on the PATH, which choked on the versioning of the BSC file. MASM 6.10 wouldn't run, invalid Win32 executable.

CREF.DOC (6.10) tells you to use /FR for FULL browsing info, /Fr is a subset.

Code Select Expand

C:\MASM>!analysis

C:\MASM>c:\tools\masm61\bin\ml611a /c /FR ANALYSIS.ASM
Microsoft (R) Macro Assembler Version 6.11a
Copyright (C) Microsoft Corp 1981-1994.  All rights reserved.

Assembling: ANALYSIS.ASM

C:\MASM>c:\tools\masm61\bin\cref ANALYSIS.SBR, ANALYSIS.REF
Microsoft (R) Cross-Reference Utility  Version 6.10
Copyright (C) Microsoft Corp 1981-1985, 1987, 1992.  All rights reserved.

Microsoft Browser Database Maintenance Utility Version 2.0
Copyright (c) Microsoft Corp 1990-1992. All rights reserved.

Browser Data Base: C:\WINDOWS\TEMP\ANALYSIS.bsc ver 2.0.2


135 Symbols

Code Select Expand

Microsoft Cross-Reference  Version 6.10       Sat Jun 04 20:19:10 2011


  Symbol Cross-Reference     (#  definition) Cref-1

@code
    ANALYSIS.ASM . . . . . . . .   17#

@CodeSize
    ANALYSIS.ASM . . . . . . . .   17#

@data
    ANALYSIS.ASM . . . . . . . .   17#

@DataSize
    ANALYSIS.ASM . . . . . . . .   17#

@fardata
    ANALYSIS.ASM . . . . . . . .   17#

@fardata?
    ANALYSIS.ASM . . . . . . . .   17#

@Interface
    ANALYSIS.ASM . . . . . . . .   17#  1486

@Model
    ANALYSIS.ASM . . . . . . . .   17#

@stack
    ANALYSIS.ASM . . . . . . . .   17#

_DATA
    ANALYSIS.ASM . . . . . . . .   17#

Addrin
    ANALYSIS.ASM . . . . . . . . 1276#  1203#  1113#   547#   251#   170#
                                   98#    25#  1283   1210   1120    554
                                  258    177    105     32

Addrout
    ANALYSIS.ASM . . . . . . . . 1276#  1203#  1113#   547#   251#   170#
                                   98#    25#  1284   1211   1121    555
                                  259    178    106     33

amiga
    ANALYSIS.ASM . . . . . . . .  547#   511

amigaloop
    ANALYSIS.ASM . . . . . . . .  561#   589

amigaproc
    ANALYSIS.ASM . . . . . . . .  599#   597


[allynm]

Hi Clive,

Was distracted by other matters for two days and have only now been able to read your post.  Wow!  Thanks for taking on this investigation.  I hate loose ends, and this looks like it will close them up.  I had really reached an impasse.

Regards,
Mark

[allynm]

Hi Clive,

I tried your suggestion, but ran into problems.  Using the command c:\masm611\bin\ml /c /FR testnoc.asm  generates an SBR file.  However, when I invoke CREF as c:\masm611\bin\cref tstnoc.sbr,tstnoc.ref I get the following error:

X13 error executing pwbrmake.exe

So, you are assembling with ml6.11a and I'm using version 6.11.  Question is:  what is 6.11a?  I googled around and couldn't find any trace of it. 

Regards,
Mark

[allynm]

Just a clarification on my last post.

My command line was actually c:\masm611\bin\ml /c /FR tstnoc.asm  --not testnoc.asm.  Made a typing error.

Mark

[anunitu]

If I remember(it has been a while) when using MASM 5,MASM.exe(hell,it might have been a COM) the assembler was named MASM, I think after it became win32 compatable(or win3.1 with 32 bit compatability) is was named simply ML.exe. If you find a copy of MASM 5(only dos I think) then that is a full assembler. using MASM 5 in Dos could be a pain, you needed to aline your code by memory blocks.
When I first started playing around with assembler,I used edlin to assemble using the old debug. Enter code in edlin, and assemble by running debug to read your code and spit out your Prog.

Those were the good?? old days...............and you wonder why all of us OLD assembler coders are so strange.......

[allynm]

Hi Clive and Anunitu,

I finally got the darn thing to create a xref.  What I needed to do was an intermediate step invoking bscmake.exe on the .sbr file produced by the assembler.  Then, if I invoked cref.exe I could produce a cross reference file.  So that closes the loop.  Thanks, Clive.

Anunitu:  As a very old dog I understand completely what you are saying.  Except for a brief foray into MAC OS around 1990, I missed ALL the stuff that happened on every platform between 1981 and about 2 years ago when I had a chance to investigate developments in this field.  I have been very grateful to the MASM32 forum folks like Clive for helping me out.  What a terrific resource for us elderly novices!  BTW, I downloaded MASM 5.1 from PhatCode to run on DosBox, so I am truly on a mission to reverse time...to the good old days.  Some folks wonder why we bother with antiquated code and tools and the answer from some of us is Rip Van Winkle...We're not strange!...we woke up and we don't know how we got here... but we want to know. We're on a journey.

Regards,
Mark

[MichaelW]

A set of 16-bit tools, including MASM 5.1, used to be included in the DDKs. I think the Windows Server 2003 SP1 DDK that I have installed is still available here (~230MB).

Here is a listing of the bin16 directory:

Code Select Expand


03/18/2002  05:54p              39,255 bind16.exe
03/18/2002  05:54p              54,596 c1.err
03/18/2002  05:54p             333,312 c13216.exe
03/18/2002  05:54p             552,960 c1xx3216.exe
03/18/2002  05:54p             493,056 c23216.exe
03/18/2002  05:54p             332,800 c23pcd.exe
03/18/2002  05:54p             244,224 c33216.exe
03/18/2002  05:54p               1,717 cl.def
03/18/2002  05:54p               1,756 cl.err
03/18/2002  05:54p              91,648 cl.exe
03/18/2002  05:54p               4,279 cl.msg
03/18/2002  05:54p              91,648 cl16.exe
03/18/2002  05:54p               2,315 cvpack.err
03/18/2002  05:54p             169,472 cvpack16.exe
03/18/2002  05:54p               3,056 exe2bin.exe
03/18/2002  05:54p              46,277 exehdr.exe
03/18/2002  05:54p               8,711 fixexe.exe
03/18/2002  05:54p              27,648 gensig.exe
03/18/2002  05:54p              14,403 getsize.exe
03/18/2002  05:54p              22,581 h2inc.exe
03/18/2002  05:54p              10,199 index.exe
03/18/2002  05:54p             134,144 lib.exe
03/18/2002  05:54p             134,144 lib16.exe
03/18/2002  05:54p             131,072 link.exe
03/18/2002  05:54p             131,072 link16.exe
03/18/2002  05:54p             124,448 masm.exe
03/18/2002  05:54p              20,507 mkpublic.exe
03/18/2002  05:54p             275,216 mspdb41.dll
03/18/2002  05:54p               4,972 msym.exe
03/18/2002  05:54p              16,299 nosrvbld.exe
03/18/2002  05:54p             208,384 q23.exe
03/18/2002  05:54p              44,099 rc.exe
03/18/2002  05:54p              44,099 rc16.exe
03/18/2002  05:54p              46,605 rclater.exe
03/18/2002  05:54p              99,499 rcpp.exe
03/18/2002  05:54p              14,393 rcqq.err
03/18/2002  05:54p              99,481 rcqq.exe
03/18/2002  05:54p              15,635 reloc.exe
03/18/2002  05:54p               8,417 stripz.exe
03/18/2002  05:54p             168,960 vcpack.exe
03/18/2002  05:54p                 610 winstub.exe


BTW, also included is at least one 16-bit C compiler and a set of 16-bit CRT libraries.

[anunitu]

My first PC was a used low end 286,with a green screen monitor. I slowly added some extras, like a used ega monitor so I could use the mono monitor for a debugging screen. Had two graphic cards installed,also bought used. Then I snagged a used dot matrix printer and scored a box on continious feed printer paper, printed out a disassembly I did using Debug of the Dos command Print. It took forever to print. I poared over that printout for months following the logic to understand the functions. later I got a better system,good books on assembler and aquired a shareware assembler package known as A86,it also had its own debugger called D86. still later I got a MASM 5 package also bought used from a friend.

back then I learned by doing, in repairing things on the system. I re-alined a floppy from my Old Commadore system that got out of alinement from copy protection head banging. lucky for me I am very Mechanicaly inclined. When you are on the cheap.you learn to fix things. Came in handy later when I snagged a job that called for this talent.