After taking a look at MASM64 I began to think that Microsoft has finally decided to disable MASM completely, a more useless assembler is hard to imagine considering that I could find no way to make even a simple procedure with one parameter in it. The package has been severely and it appears intentionally crippled and is now only to allow using small optimized assembly routines for the x86-64 and nothing else and that only because AMD did not allow for inlining in it's C compiler. Even AMD is publishing it's include libraries for the x86-64 in NASM format now, I could find references to the MASM versions but when I downloaded them I was surprised to find they were all for NASM.

There are many assemblers that are a little more future oriented, GoAsm has the best Unicode support and Jeremy has started considering the 64 bit version. Bogdan is building a TASM (+MASM) compatible assembler that should have 64 bit as well. FASM/NASM/RoAsm are all excellent assemblers in their own right. More and more I am of the opinion that we should let it die, I am more and more frustrated by MASM and some of the bizarre things in that assembler. MASM32 is a mature package and is the showing signs that inevitably come about from growing old. There are inconsistencies in syntax and I can't even count the number of different ways you can reference a structure. No Unicode support and probably no legal way to write for other than Windows 32bit. Hell, the latest license agreement restricts it's use to drivers only.
Posted on 2003-12-31 04:19:16 by donkey

No Unicode support and probably no legal way to write for other than Windows 32bit. Hell, the latest license agreement restricts it's use to drivers only.

Ohno how terrible :eek: I won't be able to code elf binaries with masm64 -*- like ever would. (^~^)

I hope that in a not too far away future fasm will support AMD64.

Things are starting to head down hill for M$, they know it and appears to do anything to make their exit the EOF with a GPF.
Posted on 2003-12-31 08:49:17 by scientica
donkey,
I never use PROCS, so that won't bother me. I will feel the pain if it does not support MACROs, FUNCTIONS, STRUCs, and all instructions. Last week I heard on National Public Radio (NPR) that the US's Internal Revenue Service (IRS), the goverment's tax collecting agency, is hopelessly behind in software and hardware. Besides low funding by Congress and the complexity of the tax laws, they cited that most of their old software is written in COBOL and Assembler. Many of the programmers who know those languages and maintain that software are retiring fast. Anyhow, the reporter's interviewee called those two languages "old dinosaurs". From a usage standpoint and popularity, I would have to reluctantly agree, even though I am been thoroughly fossilized by ASM for years now, and can't imagine programming in any other language with the possible exception of POWERBasic. And that only as a desperate measure. Ratch
Posted on 2003-12-31 09:00:00 by Ratch
Besides i am writting an Assembler that will be compatible with TASM/MASM :grin:
so do not worry
Posted on 2003-12-31 11:09:28 by BogdanOntanu
Ratch, too bad they didn't write the stuff in proper languages ;)
Posted on 2003-12-31 12:39:37 by f0dder
What Microsoft is working on now is support of the new Intel Centrino processor. The next operating system will be designed around it's fuctionality. All this is, is embedded rf wireless internet hardware in the chip. I think they have their hands full right now especially since they have to think more linear. Lol bet they had to hire some new engineers for such a task.
Posted on 2003-12-31 23:27:20 by mrgone
BogdanOntanu, thanks in advance :alright:
if you need some help I'll try to help.
Posted on 2004-01-01 03:24:32 by Ultrano
Having seen a few knobbled versions of MASM in my time, I tend to think the problem with the state of 64 bit AMD MASM comes from the risk that 64 bit AMD will be an orphan so it may not be worth that much development time.

I personally doubt that the current versions of MASM will be ported to platforms like Itaniums as the processor instruction set is very different to x86.

I personally doubt that Intel will follow AMD in compatibility terms as they still control the major market share and it does not serve their interests to support an AMD initiative in hardware design.

Just a technical note, MASM has supported unicode since 1993 in what was the normal way to handle string data back then which was as resource strings. The technique has gone out of fashion with ANSI strings taking less storage room but resource strings have been unicode since early versions of 32 bit NT.

On the legality issue, there has always been a way to write anything you like in MASM, own your own copy and do what you like with it. Thats why you paid for it in the first place. You get the paper manuals as well which have always been very good.

I am pleased to see the other assemblers on their way but if you held your breath waiting for them to overtake MASM, you would certainly turn blue. :alright:

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-01-01 04:15:42 by hutch--

Many of the programmers who know those languages and maintain that software are retiring fast.

Maybe there is job oportunities, don't they usualy cling onto old "know to work software" (aka "it's worked so far why start an costly uppgrade to new bugs/problems, and then have to re-train those who interface/work with it?" or "if it ain't broken don't fix it").
Posted on 2004-01-01 04:18:25 by scientica

I personally doubt that Intel will follow AMD in compatibility terms as they still control the major market share and it does not serve their interests to support an AMD initiative in hardware design.


Famous last words, the same uttered by some IBM exec when the PS2 was introduced I think. Intel will probably unveil it's x86-64 answer to AMD in a couple of months. They thought they were bigger than the market and rather than risk the same fate as IBM did with their disasterous foray into OS2 and the PS2, Intel appears to have yeilded:

http://www.xbitlabs.com/news/cpu/display/20031216070734.html

PS: Hutch, resource strings have nothing to do with MASM, they are built by the resource compiler, MASM has no Unicode support what so-ever. Using the resources is a Windows function not an assembler function.
Posted on 2004-01-01 04:43:02 by donkey

PS: Hutch, resource strings have nothing to do with MASM, they are built by the resource compiler, MASM has no Unicode support what so-ever. Using theresources is a Windows function not an assembler function.

Yes exactly, the OS requires unicode for resources and the technique was used for a long time in Windows 3.? when you wanted to be able to edit strings in an EXE file externally without recompiling it. Its just that resource strings have gone out of fashion and many did not like the idea of others editing the string data in their exe files.

MASM exe and dll files are capable of using the OS format of resource files so in the ordinary sense MASM is authodox by the old criterion of resource handling.

MASM has no data type to directly handle unicode as it is not in the normal sense a data type. I have seen it done using WORD arrays but it is a fudge. Proper unicode at the OS level is done in OLE string and the data apparently must be fed through an OS function to get it into that format.

Funny enough local string data within an EXE file's data section or code section has only come into vogue since flat memory model allowed it. The old segmented architecture enforced data and code segments.

As far as processors, I have seen Cyrix come and go and I have seen 3d-now technology that Intel did not follow so I have litle reason to think they will follow any standard that AMD set. The have had a 64 bit x86 in the works for some time but I don't yet know the specs for it.

While I would like to see AMD succeed, I still have my doubts that the Intel x86 will do other than suit Intels interests which is to maintain market control of the processor market.

Regards,

http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd

Here is a good link on the topic.

http://www.theregister.co.uk/content/3/33624.html
Posted on 2004-01-01 05:54:08 by hutch--
Many people have developed assemblers and some are currently in development. It will be interesting to see which direction people will go. There is much legacy code in existence, but a new idea should take hold in the spirit of assembly programming. Some sectors of assembly language programming have remained quite stagnant over the years. I see people still using AT&T syntax on x86 and I shudder at the archaic unreadablity of the code. I see people refusing to use inline data statements (through macros or built in to the assembler) and I understand why assembly programming remains an add-in for a HLL. I use assembers which do not give me the ease of optimization that I need (selecting instruction encoding, or code alignment) and I feel assembly programming is less valuable than it could be. Let us move on - let us expand our art. We have the depth to think beyond the surface of the instructions, to fluidly translate our ideas into code, or to digress at will for the benefits of software development. All we need is an assembler to meet those needs.
Posted on 2004-01-01 14:08:54 by bitRAKE
Hi bitRAKE,

I agree with the parts I understood :)

I think that Bogdan's approach of making a TASM/MASM assembler that looks to the future and allows us to consult directly with the developper is what you are looking for. I find that GoAsm works well for my needs, especially with the later improvements and additions. It is very close to masm in syntax making porting legacy code pretty much automatic, to the extent that it is distributed with a translator program.

The existence of a ~100% MASM compatible assembler is the alternative that everyone needs, no more worries about MS crippling it or not supporting this or that. No legal jargon to read through in the EULA and the output can be used anywhere you want. That is my great hope for Bogdan's assembler, that it will be compatible but better and incorporate some of the ideas found in the boards that would improve on what we have now.
Posted on 2004-01-01 14:52:33 by donkey
That is what i am trying to ;)
Posted on 2004-01-01 18:00:15 by BogdanOntanu
where can i get this masm64?
Posted on 2004-01-01 23:54:38 by Qages
Posted on 2004-01-02 04:49:25 by Odyssey