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
From the Microsoft Macro Assembler Programmer's Guide for version 6.0:
Quote
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.
Hi,
Quote(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.
Then of course is 32-bit OMF used by Linear Executables in Windows 3.x, 95 and OS/2
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
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>
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
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.
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
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
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
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
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
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.......
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
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 (http://download.microsoft.com/download/9/0/f/90f019ac-8243-48d3-91cf-81fc4093ecfd/1830_usa_ddk.iso) (~230MB).
Here is a listing of the bin16 directory:
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.
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.
I'd have to dig through the archives in the bat cave to figure which install disks 6.11a came off of. In an initial search I did come across the 6.11 disks on 3.5" media, I didn't get to the 5.25" ones. Some of the versions came from original releases, others from BBS downloaded patch files, and others from SDK/DDK/MSDN betas and releases. I don't have a full recollection of why the releases occurred, but they generally addresses specific failings that would otherwise prevent the DDK's building properly, or had additional instructions/directives, or just addressed outright bugs. I recall doing some regression testing back in the day.
During that period Microsoft had a number of releases and patches, as noted the 6.10's DOS Extender and wrapper aren't viable as the PE file today, and more likely the "WIN32" API functions were in flux. 1993 being the dawn of NT.
Renamed for my own purposes, but dates should be correct
01/19/1993 05:05 PM 360,992 ML610A.EXE
09/23/1993 11:25 PM 388,608 ML611.EXE
04/15/1994 06:12 AM 382,976 ML611A.EXE
10/28/1994 12:00 PM 381,952 ML611C.EXE
05/26/1995 10:57 AM 388,096 ML611D.EXE
06/13/1997 04:41 PM 366,080 ML612.EXE
10/29/1997 07:04 PM 351,744 ML613.EXE
03/29/1999 06:45 PM 372,736 ML614.EXE
03/16/2000 04:20 PM 385,072 ML615.EXE
07/27/1997 06:20 PM 374,784 ML620.EXE
The problem with BSCMAKE.EXE probably comes from the fact that CREF.EXE normally tries to run BSCMAKE, and this might fail if the path is wrong/absent, the DOS Extender binding is wrong/inconsistent, or the wrong version (older 16-bit, newer 32-bit). Certainly the 6.12-6.15 releases are absent all the attendant files, although contemporary files could undoubtedly be pulled from the compiler releases.
Some of the patches are here
ftp://ftp.microsoft.com/softlib/mslfiles/ML611D.EXE
ftp://ftp.microsoft.com/softlib/mslfiles/ML612.EXE
ftp://ftp.microsoft.com/softlib/mslfiles/ML613.EXE
ftp://ftp.microsoft.com/softlib/mslfiles/ML614.EXE
http://support.microsoft.com/kb/228454
ftp://ftp.microsoft.com/softlib/mslfiles/LNK100.EXE
ftp://ftp.microsoft.com/softlib/mslfiles/LNK562.EXE
ftp://ftp.microsoft.com/softlib/mslfiles/LNK563.EXE
Hello Anunitu, MichaelW, and Clive,
Thanks very much for the material you posted. Very generous, indeed. This is what makes this forum such a terrific place! I've not experienced anything close to this level of helpfulness on any other programming site.
Regards,
Mark Allyn