The MASM Forum

Is M$ still supporting ML.exe and ML64.exe?
They've stopped shipping with VStudio and  the last stable release was 2010. (wikipedia)

Thanks.

I would they are. They used it to build their O.S.s.

Andy

vengy,

I would not worry all that much, both ML.EXE and ML64.EXE are very stable applications that do not need to be changed all that often. Just use the latest releases and you will be fine.

I have a different information
I have found this in my Microsoft Visual Studio Express 2012 for Windows Desktop
http://www.microsoft.com/visualstudio/eng/products/visual-studio-express-for-windows-desktop (http://www.microsoft.com/visualstudio/eng/products/visual-studio-express-for-windows-desktop)

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64>ml64
Microsoft (R) Macro Assembler (x64) Version 11.00.50727.1
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: ML64 [ options ] filelist [ /link linkoptions]
Run "ML64 /help" or "ML64 /?" for more info



Many people use Ml.exe Ver. 6.14  and it's copyright is 1981-1997. to make 32-bit programs.

we don't need ml.exe or ml64.exe because we have Japheth's excellent JWasm  :t
I wouldn't be surprised if M$ very soon ask Japheth permission  to use JWasm for their programming  ;)

 :biggrin:

I would not hold your breath waiting, MASM has only been in development since 1981 so I doubt they would suddenly change anything in a hurry.

thank you for your concern hutch, I have quit smoking more than 20 years ago 8)
my lungs are in excellent condition and I can hold my breath for a pretty long time :biggrin:
ml.exe is a legend, but already obsolete  :icon14:
ml64.exe is crappy without a hll :icon13:
so, Jwasm is our present and the future :idea:
with a source code available :exclaim:

I apologize to other authors of assemblers/compilers for putting them behind the JWasm :biggrin:
my reasoning for that is that most of them are:
1. not supplying the source 
2. I don't understand why wee need [var] instead of simply var
3. hll not completely built in
4. macros different than we are used to

My jWasm copy hasn't got any lib,inc,etc within the package, don't know if there's a zip with all included... If it is so, I think that really this is what it need to be one of the main asm compilers out there. I have used it few times, but seems to be great... just this little detail, that would make it in one of my favorites  :t.

PD: [var] instead of "var" because somehow you must tell the compiler that you want the value of the variable, not its direction, or add the classic OFFSET.

Quote from: avcaballero on March 21, 2013, 09:13:46 PM
My jWasm copy hasn't got any lib,inc,etc within the package, don't know if there's a zip with all included

Well, there is WinInc (http://www.japheth.de/WinInc.html)
BTW, take note:

Quote
No library of helper functions (M32LIB in Masm32) is included, instead it is recommended (and supported) to use functions contained in C runtime libraries like libc, crtdll, msvcrt, ....

yah - the WinInc project is probably almost as much work to put together as JwAsm - lol
you can build your own lib's - especially easy with Vortex's tools   :P

Quote from: dedndave on March 21, 2013, 09:52:20 PM
yah - the WinInc project is probably almost as much work to put together as JwAsm - lol

Yes. This is intentionally - to keep the noobies out. I don't feel to explain in detail novices 100 times or more how to create a "hello world" or what a linker is good for. That's something where other people have better skills and patience.

Hi avcaballero,

You can use Masm32's libraries with JWasm.

I agree with Habran. JWasm is a very good tool.

Quote from: Vortex on March 22, 2013, 05:48:55 AM
I agree with Habran. JWasm is a very good tool.

And its author is a particularly nice person :t
Besides, JWasm assembles my favourite library more than twice as fast as M$ assemblers :t

hey Japheth,

QuoteYes. This is intentionally - to keep the noobies out.

there is a "bug" in this sentence ;)

it should be :

QuoteYes. This is intentionally - to keep the noobs out.

:biggrin:

here is an explanation I found on the web:

Quote
Contrary to the belief of many, a noob/n00b and a newbie/newb are not the same thing.
Newbs are those who are new to some task* and are very beginner at it,
possibly a little overconfident about it, but they are willing to learn
and fix their errors to move out of that stage. n00bs, on the other hand,
know little and have no will to learn any more. They expect people to do the work for them
and then expect to get praised about it, and make up a unique species of their own.

:biggrin: :biggrin: :biggrin:
                 

those are usually zeros in n00b - lol
the "bee" sound is made by spelling out the "b" - nu-bee

at any rate, what i meant was....
that the WinInc package is almost as much work for Andreas as JwAsm (not for the users)
a slight exaggeration, of course, but you get the drift
even with conversion tools, it takes a lot of work to put together a set of windows inc files for asm

Quotethat the WinInc package is almost as much work for Andreas as JwAsm (not for the users)

I also thought that you meant that but you haven't expressed yourself clearly
you have also had a "bug" in your expression
I can forgive you if English isn't your native tongue
otherwise you are in big trouble :badgrin: 

Quote from: dedndave on March 22, 2013, 11:57:23 AM
that the WinInc package is almost as much work for Andreas as JwAsm (not for the users)
a slight exaggeration, of course, but you get the drift

No. wininc maintenance is negligible compared to jwasm ... I estimate a factor of 30-40.

WinInc is a great work too. Converting the original .h files is a difficult task.

Quote from: Vortex on March 23, 2013, 07:18:11 AM
WinInc is a great work too. Converting the original .h files is a difficult task.

This is my first post to the forum:  I hasten to jump into the fray because of the need to legitimise myself per the forum rules.  However, I have chosen this subject because it is the area in which I have an interest and the least experience.  My first assembly experience was on the IBM 360/370 series using BAL usually in the 32-bit mode without the extended architecture.  I used the 16-bit addressing for z80 x8x processors with some adjustment between 1980-5, but I relied heavily on interrupts rather than coding from scratch.  I did use a Cyber 720 in school, but that was 60-bit COMPASS and it was a different world.  With x64/AMD64 (I'm using a p7350 right now) I'm struggling a lot. 

I have tested schoolboy pieces using gasp, as, masm and yasm and I think I've had about as much trouble determining formats, assembling and linking under Windows 7 and Fedora as I have anything else.  My principle approach would be to code uniquely suited modules in x64 assembly with C language support.  I'm not married to any specific toolset, so I welcome any of your recommendations.  One reason I picked this topic as a place to post (apart from Hutch's presence) is that I see you discussing a number of options such as WinInc and JwAsm which I have not tried. 

I used gasp piped into gas in one scenario, coded a little C and stole some pieces of the gcc -S output and struggled with the configuration and assorted command-line options for a version of ml64 that I had from a M$ SDK as well as some flat32 addressing examples run through the ml included under VS9.0 in the VC++ express download.  I think I found yasm less problematic, but I have to say that however I did it, I found linking more difficult, particularly where libraries are needed in the NT-style OSes. 

Having had years of programming experience and a reasonable amount of exposure to many different assembly environments, what toolkits might I be able to configure quickly and how might I best accustom myself to the differences between the 16-bit microprocessor models through the 32-bit and into a 64-bit world (preferably non-stop, lol)?

hi Ernie - welcome to the forum   :t

i don't have a 64-bit machine
i am pretty happy with my old 32-bit XP machine, actually - lol
and, i still have plenty to learn at that level

but, if i were to get into 64-bit, i would probably use JwAsm
the syntax is almost 100% masm-compatible
the macro support in 64-bit is probably better than with ML64
Andreas is continually updating and supporting it

as far as resources go, the 64-bit subforum is a good place to start
and - the old forum archive - same thing
http://www.masmforum.com/board/index.php?board=43.0 (http://www.masmforum.com/board/index.php?board=43.0)

Thank You, dedndave, and Greetings!

I was pretty happy with 16-bit chips, although putting together segment:offset made me beat my head against the wall occasionally (after using 32-bit mainframes with entry+displacement+base+index).  There are boxes of those chips lying around and since we don't use our machines as glorified typewriters, I was thinking that they'd make nice inventory control devices for things like vending machines.  I lived in a building that participated in a market test of machine-based movie rentals.  I feel as though I have room to breathe with flat32 -- but I still get that nagging feeling, "Don't one of those routines use that register?"

Thank You also for the advice.  I'll look at JwAsm right away. 

I appreciate your guidance. :)

well - on the bright side, you don't have to worry about segmented addressing anymore
win32 and win64 apps use a "flat" memory model
you rarely have to mess with the segment registers, at all

but, DOS was still easy to program under
you could almost memorize the INT 10h, INT 13h, INT 16h, and INT 21h function calls

in contrast, there are a seemingly endless number of windows functions, structures, and constants
there'll be no memorizing that - lol
you will constantly be looking at the documentation, either online or locally

Hi Ernie,

JWasm is one of the best assemblers and Japheth maintains continuously the tool.

Thanks, folks,

I got a chance to play with JWasm a little today.  I'd have had more time but I spent more time figuring out what I have to do to configure an environment.  I'd like to keep my stupid path structure and just account for it in my tools configuration.  In a way it's good because it forces me to know what I'm doing, but on the other hand, I'm not doing much assembly until I set up everything. 

Yeah, under DOS I could almost just type code without looking anything up:  It's amazing how many INT 21h functions are still floating around in my head (and trying to come out through my fingers).  I'm glad you mentioned the endless number of windows functions, structures, and constants -- I thought it was just me.  So I guess it's normal to keep looking that stuff up all the time.  I would worry that I'd  lost my mind, but we already know I chose to code in assembly  ;)

Visual Studio 2010 professional and 2012 Express and professional both support 64 bit programming.

Please check out the following video I posted that explains how to set up a Visual Studio project for 64 bit assembly language programming.

http://youtu.be/QWWTrdNkhBI

At what screen resolution can we actually see what you are talking about? 4000x3000? And how do you define "support"? That ML64.exe understands the basic 64-bit mnemonics? Or can it nowadays even interpret ".if rax" correctly?

M$ 5/11/2010 (http://connect.microsoft.com/VisualStudio/feedback/details/497805/when-ml-64-bit-support-invoke)

QuoteWhen the port of the Microsoft Macro Assembler (MASM) to the x64 hardware platform was undertaken we decided not to port the high level language construct support, which include INVOKE, .IF, .ELSE, .WHILE, etc