Command Line Compiling With ml

[Fred Harris]

Still working on it hard and making slow progress!  Here's where I'm at.  I'm trying to compile this from the command line with ml...

Code Select Expand


include \masm32\include\masm32rt.inc

.Data
szMessage db 'Hello World!', 0
szPath    db 'Output.txt',   0
szMode    db 'w',            0

.Code
Main Proc
  LOCAL fp : DWORD

  invoke crt_fopen, ADDR szPath, ADDR szMode
  mov fp, eax
  invoke crt_fprintf, fp, ADDR szMessage
  invoke crt_fclose, fp
  invoke  crt_getchar
  invoke  ExitProcess, 0
Main Endp
End  Main


ml /SUBSYSTEM:CONOLE /coff Test3.asm

LINK : fatal error LNK1221: a subsystem can't be inferred and must be defined

Above is my command line and the error I'm getting.  Can someone help me fix it please?  As you can see from the code, I'm using msvcrt functions.  Its compiling and working perfectly with Hutch's QEditor.  I just want to know how to do command line compiling with ml.

[Vortex]

Hi Fred,

The correct sequence is :

Code Select Expand

D:\masm32\bin>ml /c /coff test.asm
Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997.  All rights reserved.

Assembling: test.asm

***********
ASCII build
***********

D:\masm32\bin>link /SUBSYSTEM:CONSOLE test.obj
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

[Fred Harris]

Thanks Vortex!

So the assemble / link needs two seperate steps?

Fred

[jj2007]

So the assemble / link needs two seperate steps?

Not necessarily:
C:\Masm32\bin>ml /coff \Masm32\test.asm -link /subsystem:console

This works (note it is started from the bin folder, to avoid setting a path environment variable).
However, nobody uses it. A second command line for the linker is more flexible.

[Fred Harris]

Thanks jj.  I'll try it out!

Fred

[dedndave]

you may view the command-line options with

ml /? or ml /help (some versions may not support both)

the /c switch is used to disable the link step, so that it may be done seperately
as Jochen mentioned, the link command alone is more flexible

[dedndave]

some time ago, i wrote a batch file that handles different types of builds - it's what i use

http://masm32.com/board/index.php?topic=1770

[Vortex]

Hi Fred,

As Jochen wrote, you can build the executable with only one line where all the parameters are supplied to ml.exe Separated two lines, one for the linker  is easier to read and maintain.

[Fred Harris]

Thanks a lot guys!  Got it working.  Turns out I  have two versions of ml on my boxes and they both work - Hutch's and the one came with VC9 - Visual Studio 2008 Pro.  I also have VC6, but didn't see any ml in there.  I had figurred out the ml /? thingie, but didn't have it just right.  Got it now!

Guess I need to check out what the situation is with x64.  I'm pretty sure on my x64 Win7 there is a \bin directory for x86 and another for x64, with different cl s in each. 

I've been working hard at this - but got plenty more work to do!

Found my boxed set of TASM today - like 20 years old!  Might play with that too.  Its on 3 floppy disks!

[jj2007]

Found my boxed set of TASM today - like 20 years old!  Might play with that too.  Its on 3 floppy disks!

Don't waste your time with nostalgia, Fred. Have a thorough look at \Masm32\Examples, or check this two-pager for a quick start.

Re x64: some are quite active here, but the learning curve is steeper than for x32, and the added value is not that great. 16->32 was an immense improvement, 32->64 is hardly worth the effort, except for high end graphics maybe.

[hutch--]

JJ is right here Fred, TASM from 20 years ago was well left behind by MASM just slightly after. You need to get the swing of MASM Intel notation which is a bit different to TASM. In the short term the version of ML that comes with MASM32 will get you a lot of code written that is important to learn, mainly addressing (complex addressing mode), the base for MASM macros that are truly nasty old pigs but it means you can routinely shift to either later versions of ML or JWASM.

API calls are basically trivial in MASM, the real action is in algorithm design as it is here that you will see the big performance gains once you get it right. Something that is important to understand, MASM comes with no runtime library at all and many make the mistake of starting from scratch with a bare assembler/linker but this means you have to start by writing your own runtime library which is a complex task. While you are slugging through the code in MASM32 and playing with test pieces, use the existing MASM32 runtime library and macro support as it will get you up and going a lot faster and over time as you become more familiar with how it all hangs together you can start writing your own modules and macros.

MASM is addictive but its like having a sharp knife to carve things up, not a bag of marshmallows.

[jj2007]

MASM comes with no runtime library

Just for clarification:
MASM = the official Microsoft macro assembler: only ml.exe and link.exe
Masm32 = the "private" package downloadable from this site, which includes an old version of ml.exe and link.exe but has also a big runtime library and many more features.

[Fred Harris]

Thanks for that list of getting started (re-started?) stuff jj2007.  I will check it out.  Never even knew about www.masmforum.com.

I really want to thank you for all the work you've done putting this site and the whole masm32 package together Hutch.  I doubt if I'd be attempting this again without it.  I'm simply amazed at all your work.

I particularly enjoyed this comment in your Masm Help on Invoke...

Why use invoke ?

Popular legend has it that true low level assembler is written only at the mnemonic
level and the rest is for people who do not properly understand what low level
programming is about. The problem is for people who espouse this view is that they
never produce anything much and when they do, it is usually of little consequence.

That's pretty much right on the mark, and pretty much describes about a whole year I spent with assembler about 20 years ago.  I was writing page after page of movs, leas, jmps, cmps, etc., etc., taking hours and hours doing it, and when I'd finally get it working it was something I could have done in C or PowerBASIC in about a minute.  So the runtime library code available here is a real help.  In this very topic where I asked about command line compiling, if you look at my little code blurb, I was using crt_fopen and crt_fprintf to open and write to a text file.  I don't think I ever even got that far in my whole year spent at this back in the mid 90s.

I'm really wanting to do this.  I made a false start about five years ago, but the press of other coding responsibilities and matters forced me onto other things.  I'll be retiring in about another year, and at this point I'm not doing much development work - simply writing piles of documentation on what I've coded the past 20 years!  So doing this will keep me interested.

What got me looking at the file writing business as I was saying above is I was wondering what to do about debugging.  I looked at your recommendfations that came with masm32 and it looked like all that outfit did was log output to an output log.  Nothing wrong with that really, and truth be told its the major way I've debugged all my code all my life.  However, I recall with TASM many years ago there was a fantastic stepping debugger, which allowed you to see the flags in the cf register change as you stepped through the code.  Tremendous for learning what's going on.  But jj2007's link above mentioned about the 'Olley Debugger'  Perhaps I ought to look into that. 

[jj2007]

Olly is a great debugger, but I launch it only when I am really stuck. Before that point, the deb macro is a powerful tool:

include \masm32\MasmBasic\MasmBasic.inc      ; download
  SetGlobals fct:REAL8
  Init
  fldz      ; zero the FPU
  mov ecx, 3
  For_ fct=0.0 To 0.1 Step 0.01
      movlps xmm0, fct      ; move double counter to xmm0
      cvtsi2sd xmm1, ecx      ; convert ecx to double
      subpd xmm0, xmm1      ; subtract: fct-ecx
      dec ecx
      deb 4, "Debugging a loop", fct, f:xmm0, ST(0), flags
      fadd FP4(0.01)
  Next
EndOfCode

Output:
Debugging a loop
fct             0.0
f:xmm0          -3.000000000000000
ST(0)           0.0
flags:          czso

Debugging a loop
fct             0.01000000000000000
f:xmm0          -1.990000000000000
ST(0)           0.009999999776482582092
flags:          czso

Debugging a loop
fct             0.02000000000000000
f:xmm0          -0.9800000000000000
ST(0)           0.01999999955296516418
flags:          cZso    <<<<<< ecx is zero here

Debugging a loop
fct             0.03000000000000000
f:xmm0          0.03000000000000000
ST(0)           0.02999999932944774627
flags:          czSo

[Vortex]

Hi Fred,

Lazy Assembler (Lzasm) is a Tasm ideal mode clone ( not supported anymore ) :

Lazy Assembler (LZASM) is an x86 assembler for DOS and Windows that handles the TASM (Turbo Assembler) IDEAL mode and produces OMF OBJ files. Supports MMX, SSE, SSE2, SSE3 (PNI), SSE4 (MNI), and 3DNow!Pro instructions.

http://www.phatcode.net/downloads.php?id=308