I installed the first beta of .NET the other day because I was curious what fuzz is all about. :eek: I was looking through all docs and online help as well as the current apps trying to find information about MASM. All I could find was a few naming conventions of assembly but no word about ML.EXE or MASM itself. Does anybody have any idea or want to take a wild guess on what the future holds for MASM after .NET is released into the wild?
Posted on 2001-02-25 00:03:00 by rainbird
Zero. No change at all. You might as well ask if users switch from Coke to Pepsi what the effect will be on MASM. If there is anything useful in the net dll's, you can be sure some clever lads will find it and post tuts. But it's going to be OPTIONAL if you wish to use it.
Posted on 2001-02-25 00:25:00 by Ernie
Thomas, About the only thing important about .NET is that you don't hold your breath waiting for it to take over the world. The connection between the Microsoft vision for the world and the way the world will be is getting thinner by the day. I think 32 bit assembler will be with us for some time yet as it is still needed for some of the 32 bit windows environments. If IA64 ever gets off the ground, we all may need to learn 64 bit assembler but it would be wise not to hold your breath on that either. The computing world did not fall for COM, DDE, OOP or any other of the Microsoft gimmicks so I doubt that it will fall for .NET either. Just make sure it does not slow the development of your asm IDE. Regards, hutch@pbq.com.au
Posted on 2001-02-25 00:26:00 by hutch--
DDE was just dumb. A Win16 leftover. Let it rest in piece. COM is in more places then you may be aware. Growing everyday, as it's role in inter-app and inter-machine communications grows. It's alot more then just drag and drop controls for VB. And as far as OOP goes, try and find a straight C programming book for windows anymore. You'll be lucky if he doesn't jump complete into MFC.
Posted on 2001-02-25 01:04:00 by Ernie
I was more wondering if MS will continue to update MASM in the future.
Posted on 2001-02-25 11:11:00 by rainbird
I they will not continue MASM....we will have to write our own ASSEMBLER..thats all...or use NASM or SPASM...or GASM..or.. ...where is Betov...eh? if we all make a decent effort we should be able to make a MASM like assembler in a few months up to one year :D
Posted on 2001-02-25 12:16:00 by BogdanOntanu
Actually, you'd be surprised to know, that .NET uses a new one called "MSIL" (Microsoft(tm) Intermediate Language". The new "assembly" language of .NET is "IL". It's fully documented on the msdn website (or January 2001 Platform SDK). But as its name implies, it's not true machine code. Its akin to Java bytecode. I'm sure for VC++.NET there will still be some native code generation, same for the other languages. But to be true .NET, it must work with the CLR (Common Language Runtime) which, this, is "IL"... Thus, with .NET, assembly programmers are really Intermediate Language programmers... programming a type of byte-code (or psuedo-code) instead. _Shawn
Posted on 2001-02-26 11:15:00 by _Shawn
Yeah. Having been whipped by Sun in court, it seems Microsoft is now developing C# and .NET as a direct competitor/replacement for Java and a general-purpose internet-oriented tool for world domination, respectively. Personally, the last thing I think the world needs is another pointerless language without the goto statement. (Actually, C# does support pointers in a kind of back-door way as an "extension" to the language.) I don't think that .NET will leave us any more out in the cold than we've already been for years; and anyway, its success is far from a sure thing. I agree with Bogdan. Microsoft isn't going to be supporting Masm any more than Borland will be supporting Tasm. At best, the DDK will include an ancient version of Masm for the few driver writers who still need to write occasional asm code. And rather than fretting about an asm IDE, it would make more sense to round up specifications for a new and improved assembler and just develop it from scratch. Probably best to wait awhile though, to decide how to support the new CPU's (Pentium 4 SSE, 64-bit Itanium, ...) in addition to 32-bit programming. Else any new assembler might quickly become obsolete (Intel has said it intends to discontinue the Pentium III, but will it really dare?). Writing it would be a big project, but an even greater problem would be to ensure continued support in the future.
Posted on 2001-02-26 12:30:00 by marmoset
Hm. Isn't IA64 *quite* different from IA32? I think an assembler should be written for *one* CPU, to avoid something as bloated as the GNU assembler. After all, assembly is pretty CPU specific. Writing the "bindery" code (source file parsing, preprocessor, etc) generic would be good, so the same skeleton can be used to create another specific assembler (hmm, sounds like I'm contradicting myself a bit here). As for supporting pentium4 SSE (and -perhaps- other future extensions): that shouldn't be too hard as long as we're still on IA32. "Just" extend the opcode tables and add support for the new instructions. Can't be much harder than writing it in the first place, due to the "wonderful" hack-and-patch approach intel has followed while developing their CPU architecture. As for features, I would aim at a mix of NASM and MASM. The high-level constructs from masm, and the wonderful simplicity and control from nasm. Like, always requiring , never needing OFFSET, the ability to control opcode generation specifics. But NOT the "you-must-always-specify-everything" that nasm has because it cannot remember types - you should only have to give size specifiers if you want to override the default size, or the size is unknown. Oh yes, "dword [0xf00c0de]", not "dword ptr [0xf00c0de]". Support for many output formats (using intermediate "rich" representation, which an output driver can write as the format you choose. In a way that is less chunky than the GNU BFD, but still offers rich extandability).
Posted on 2001-02-27 08:45:00 by f0dder
Its my view that MASM as we know it will be with us for as long as win32 is with us and the latest version is 6.15 and it is reasonably recent. ML.EXE is a very mature piece of software and it still has its uses to Microsoft, thats why it survives. I doubt that there will be an assembler for IA64 for some time to come, if and when its released. A completely new platform will have very little going for it in terms of development tools for a long time to come. It may be tempting to look to the future of processor development and operating system design but it is well known that the large scale consumer market is showing signs of fatigue in terms of the rate of forced change. Microsoft profits are down and it follows from a drop in demand so I suggest that win32 will be the main operating system for consumer market for a long time to come. Regards, hutch@pbq.com.au
Posted on 2001-02-27 09:06:00 by hutch--
>> I doubt that there will be an assembler >> for IA64 for some time to come Hmm.. I think Intel might disagree with you there Hutch :- IAS Assembler for Itanium Architecture It's the source code to their assembler :-) umbongo Added: And of further inspection it's for linux, but I'm sure with a little fiddling we could make it run on windows. Still the fact remains we have the bulk of an assembler there. This message was edited by umbongo, on 2/27/2001 10:29:13 AM
Posted on 2001-02-27 09:36:00 by umbongo