M$ support for ml64.exe

[habran]

hey Japheth,

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

there is a "bug" in this sentence ;)

it should be :

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

here is an explanation I found on the web:

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.

                 

[dedndave]

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

[habran]

that 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  

[japheth]

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.

[Vortex]

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

[ernie.cordell]

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)?

[dedndave]

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

[ernie.cordell]

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. :)

[dedndave]

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

[Vortex]

Hi Ernie,

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

[ernie.cordell]

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  ;)

[fkenn1999]

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

[jj2007]

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

When 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