NASM dead?

[[e-mail]]

I don't know the exact status of the NASM development team, but NASM
has been languishing in need of a rewrite for many years now (to get to
the fabled "v1.0" state)

Their todo list isn't that big, but I dunno how complex it would be to
implement. Most programs never reach the 1.0 "finished" stage anyways
(open source or otherwise). Not saying that's ideal, but realistically,
people lose interest when it gets to be too much work.

I think that's the concern of the OP.

I know some people (still?) use MASM, and there's a few forums for it,
but I somewhat doubt it's the most popular assembler. It seems to only
enjoy most of its use in the Windows sector.

Based on what I've seen, it is (by an order of magnitude) the most
popular assembler out there. MASM is the 800-pound gorilla, NASM is
the 80-pound gorilla, and everybody else is in the pounds or even
ounces region. As an evangelist for HLA, I talk to a lot of beginning
programmers and the vast majority of them know of MASM and think that's
the way to go. Outside of Linux, where NASM is quite popular, most
beginners haven't actually heard of NASM until they wander around
someplace like CLAX or ALA. Now maybe it's the case that I just hang
around the wrong people (:-)), but from where I sit, MASM is still king
of the heap. OTOH, it's also clear that this is strictly momentum from
the days when Microsoft sold a commercial version of MASM; MASM's
marketshare, despite the excellent efforts of people like Hutch, is
beginning to decline. But it has a long ways to go before it gets
eclisped. That's not to say that it can't happen -- look what happened
with TASM after Borland effectively abandoned it -- but because of
things like the Iczelion tutorials and the MASM32 project, MASM is
maintaining much of its momentum.

The thing that I see killing MASM is the fact that many hard-core
assembly x86 programmers are switching from Windows to Linux, meaning
that they have to switch to a different assembler (usually NASM or
FASM). I really suspect that Microsoft's direction with Vista (trusted
computing, JIT compilation, and no assembly) is probably going to push
more assembly programmers away from Windows and may be the ultimate
cause of MASM's "death" (or, at least, the thing the breaks its
inertia).

, so even if there isn't active development on the product, it's far from dead.
Many people believe that FASM will become the heir to NASM;

Different designs and goals: NASM supports aout, obj, rdoff, etc. and
lots of commandline parameters while FASM avoids the cmdline options
almost completely, supports 64-bit instructions, and can produce .EXEs
directly without a linker.

Personally, I don't see a lot of people making the decision for NASM
vs. FASM for these reasons. I'm sure there are lots of people doing so,
but the main reasons I see people picking NASM is because it comes with
every Linux distro out there and lots of Linux code (and Windows code,
for that matter) is written with NASM; and, of course, it helps that
there are two or three published books that use NASM (a *very* big
deal). The reason I see people using FASM is because the syntax is
reasonably close to NASM (making it easy to switch), the optimization
capabilities are quite good, the macro facilities are decent, and the
thing is blazing fast. If Julienne actually produces an assembly book
featuring FASM, I suspect that FASM could close the gap between itself
and NASM; the big problem with FASM right now is poor documentation and
nothing in the way of a beginner's tutorial/book.

The macro syntaxes for each are wildly
different (though FASM can emulate a bit of NASM's).
I know you know all this, though (from developing HLA). :-)

Sure. FASM's macro facilities are quite a bit more powerful than
NASM's.
OTOH, also speaking from experience, most people don't really care.
Only a small percentage of the population really writes advanced
macros. A shame, but that's the way it is.

but until FASM gets ported to as many OSes as NASM, I think that will be unlikely.

FASM runs on at least seven different OSes (Linux, Win32, DOS,
Unix/libc, MenuetOS, Dex4U, OctaOS), but it'll probably never be quite
as portable as NASM since the latter was written in ANSI C. Still, how
portable does an x86 assembler need to be??

Well, no offense to MenuetOS, Dex4U, and OctaOS, but I really doubt
that there are enough programmers of these OSes (outside of curiosity)
to really make a difference in the population of FASM programmers. More
likely, a FASM programmer decides to try out one of the OSes because
FASM supports it, not the other way around.

To me, one of the big draws of NASM is that it supports DOS (sort of),
Windows, Linux, FreeBSD, OpenBSD, MacOS, NetBSD, QNX, Solaris, SkyOS,
BeOS, and a few other first or second-tier OSes. Of all the features
various assemblers out there support, this is the one thing that I'm
jealous of (i.e., I wish HLA were as portable) and the thing that I'm
striving for (indeed, the port to FreeBSD is my current project).
Maybe I'm weird, and no one else cares about this portability, but the
ability to carry my assembly code around from OS to OS seems like a
really great idea.

Yes, it is a bummer that development on NASM isn't as active as many
users would like. The macros could use a bit of improvement and there
are a probably a few bugs here and there that could be squashed. But by
and large NASM has been remarkably stable for the past couple of years,
and that counts for something.

I can't blame 'em, really, it's complicated. But, it is a bit silly
that the website is broken. :-/

I can't blame them either. I know how much work is involved in
maintaining a product over a decade; if you're not getting any benefit
from that work (i.e., getting paid), it's hard to keep it up.

Cheers,
Randy Hyde

Long live NASM! :-)

Like MASM, NASM has achieved critical mass and has considerable
momentum. It will live for quite some time even if another line of code
is written inside the compiler.
Cheers,
Randy Hyde

[s***@crayne.org]

Hey again, :-)

Post by ***@earthlink.net

I don't know the exact status of the NASM development team, but NASM
has been languishing in need of a rewrite for many years now (to get to
the fabled "v1.0" state)

Their todo list isn't that big, but I dunno how complex it would be to
implement. Most programs never reach the 1.0 "finished" stage anyways
(open source or otherwise). Not saying that's ideal, but realistically,
people lose interest when it gets to be too much work.

I think that's the concern of the OP.

What feature is it that he really needs or wants *right now* that NASM
doesn't support? I suspect he's just impatient (like me). He should
grab the latest version from CVS if he can't wait for a proper release.
(Me personally, I don't have an Intel Mac, so I don't need it).

Post by ***@earthlink.net

I know some people (still?) use MASM, and there's a few forums for it,
but I somewhat doubt it's the most popular assembler. It seems to only
enjoy most of its use in the Windows sector.

Based on what I've seen, it is (by an order of magnitude) the most
popular assembler out there. MASM is the 800-pound gorilla, NASM is
the 80-pound gorilla, and everybody else is in the pounds or even
ounces region. As an evangelist for HLA, I talk to a lot of beginning
programmers and the vast majority of them know of MASM and think that's
the way to go. Outside of Linux, where NASM is quite popular, most
beginners haven't actually heard of NASM until they wander around
someplace like CLAX or ALA. Now maybe it's the case that I just hang
around the wrong people (:-)), but from where I sit, MASM is still king
of the heap. OTOH, it's also clear that this is strictly momentum from
the days when Microsoft sold a commercial version of MASM; MASM's
marketshare, despite the excellent efforts of people like Hutch, is
beginning to decline. But it has a long ways to go before it gets
eclisped. That's not to say that it can't happen -- look what happened
with TASM after Borland effectively abandoned it -- but because of
things like the Iczelion tutorials and the MASM32 project, MASM is
maintaining much of its momentum.

MAME uses NASM, not MASM. Same with Quake 3 Arena. I'm sure most people
have heard of those. If someone hasn't heard of NASM, then we need to
tell 'em. That's what we're here for, right?

Yeah, the MASM32 project still gets lots of mentions, and I suspect its
forums are a main source of info regarding MASM. Still, it seems only
popular for Windows programming (since its EULA won't allow its use
elsewhere perhaps?).

BTW, I believe most (if not all) of the Iczelion tutorials have been
ported to FASM. If you (still?) read the FASM forums, you'd see there
are plenty of people switching (at least partially) to FASM from MASM.

Post by ***@earthlink.net
The thing that I see killing MASM is the fact that many hard-core
assembly x86 programmers are switching from Windows to Linux, meaning
that they have to switch to a different assembler (usually NASM or
FASM). I really suspect that Microsoft's direction with Vista (trusted
computing, JIT compilation, and no assembly) is probably going to push
more assembly programmers away from Windows and may be the ultimate
cause of MASM's "death" (or, at least, the thing the breaks its
inertia).

, so even if there isn't active development on the product, it's far from dead.
Many people believe that FASM will become the heir to NASM;

Different designs and goals: NASM supports aout, obj, rdoff, etc. and
lots of commandline parameters while FASM avoids the cmdline options
almost completely, supports 64-bit instructions, and can produce .EXEs
directly without a linker.

Personally, I don't see a lot of people making the decision for NASM
vs. FASM for these reasons. I'm sure there are lots of people doing so,
but the main reasons I see people picking NASM is because it comes with
every Linux distro out there and lots of Linux code (and Windows code,
for that matter) is written with NASM;

There's plenty of FASM code, at least on the FASM forums: all the
MenuetOS stuff, translated Iczelion tutorials, uFMOD, Kelvar, Linux GTK
examples, Linux AMD64 examples, Win64 drivers examples, Win32 SysTray,
Mandelbrot benchmark, some simple games/demos, and a billion other
things I can't remember. There is no lack of FASM code for Windows.

Yeah, the Linux distros don't usually come with FASM, but even if they
did, they'd be outdated since FASM is so frequently updated. :-)

P.S. I've noticed a lot more people saying they have 64-bit processors
nowadays, and FASM (currently 1.66, June 24 revision) supports these
since 1.64 (unlike NASM), so I'd bet that the migration will continue
due to the increased sales of these. I've heard MASM supports 64-bit,
but does that mean MASM32 (8.0?) or just the latest in the VC++
package?? The only other assembler (besides those two) that I know of
which supports 64-bit is YASM.

Post by ***@earthlink.net
and, of course, it helps that
there are two or three published books that use NASM (a *very* big
deal). The reason I see people using FASM is because the syntax is
reasonably close to NASM (making it easy to switch), the optimization
capabilities are quite good, the macro facilities are decent, and the
thing is blazing fast. If Julienne actually produces an assembly book
featuring FASM, I suspect that FASM could close the gap between itself
and NASM; the big problem with FASM right now is poor documentation and
nothing in the way of a beginner's tutorial/book.

FASM has two IDEs under Windows (not counting RADasm). One comes
standard with the Windows build (FASMW), and has FASM built-in. The
other is called Fresh, still alpha, but interesting nonetheless. It
also has FASM built-in. They're both written in FASM. So, take that,
NASM, MASM, etc. :-P

FASM's macro facilities are more than decent: they are extremely
powerful (but also a bit confusing, IMO). FASM comes with quite good
documentation, and there's more on the official site (not counting the
forum message archive). It is still in a state of flux, improvements
will be made, but it is NOT lacking, that's for sure. In fact, one big
complaint from Tomasz is that nobody reads it all the way through, top
to bottom. Heh, it's way too long to do that, IMO, but anyways. ;-)

Post by ***@earthlink.net

The macro syntaxes for each are wildly
different (though FASM can emulate a bit of NASM's).
I know you know all this, though (from developing HLA). :-)

Sure. FASM's macro facilities are quite a bit more powerful than
NASM's.
OTOH, also speaking from experience, most people don't really care.
Only a small percentage of the population really writes advanced
macros. A shame, but that's the way it is.

Really? It seems "newbies" (pardon the term) love to use macros because
(I guess) they're used to HLLs. In Windows, you seem to almost have to
have 'em. There are a few people, though, who hand-code everything
(e.g., won't use "invoke", manually write their own resources). Still,
lots of people love those "if", "case", "switch" HLL constructs, even
in assembly!

Post by ***@earthlink.net

but until FASM gets ported to as many OSes as NASM, I think that will be unlikely.

FASM runs on at least seven different OSes (Linux, Win32, DOS,
Unix/libc, MenuetOS, Dex4U, OctaOS), but it'll probably never be quite
as portable as NASM since the latter was written in ANSI C. Still, how
portable does an x86 assembler need to be??

Well, no offense to MenuetOS, Dex4U, and OctaOS, but I really doubt
that there are enough programmers of these OSes (outside of curiosity)
to really make a difference in the population of FASM programmers. More
likely, a FASM programmer decides to try out one of the OSes because
FASM supports it, not the other way around.

Well, I was just being fair, trying to mention valid OSes that support
FASM. Menuet, in particular, relies on FASM for all its stuff. They may
not be the most popular OSes, but they do exist. FASM is indeed quite
portable, even though it assembles itself.

Post by ***@earthlink.net
To me, one of the big draws of NASM is that it supports DOS (sort of),
Windows, Linux, FreeBSD, OpenBSD, MacOS, NetBSD, QNX, Solaris, SkyOS,
BeOS, and a few other first or second-tier OSes. Of all the features
various assemblers out there support, this is the one thing that I'm
jealous of (i.e., I wish HLA were as portable) and the thing that I'm
striving for (indeed, the port to FreeBSD is my current project).
Maybe I'm weird, and no one else cares about this portability, but the
ability to carry my assembly code around from OS to OS seems like a
really great idea.

FASM says it supports OpenBSD (and maybe other *BSDs??). I do not
follow it, though, or QNX, Solaris, SkyOS, etc. so I dunno personally.
I would consider them in the same group as the ones I mentioned (maybe
not as popular but still valid for some people). If someone wants to
port FASM, go ahead! Who would complain? Portability is nice. FASM has
taken the title of "portable assembly" away from C, IMHO. :-)

P.S. Heh, what does (sort of) mean? NASM supports DOS fully, AFAIK. In
fact, NASM beats FASM in this regard: support for OBJ.

Post by ***@earthlink.net

Yes, it is a bummer that development on NASM isn't as active as many
users would like. The macros could use a bit of improvement and there
are a probably a few bugs here and there that could be squashed. But by
and large NASM has been remarkably stable for the past couple of years,
and that counts for something.

I can't blame 'em, really, it's complicated. But, it is a bit silly
that the website is broken. :-/

I can't blame them either. I know how much work is involved in
maintaining a product over a decade; if you're not getting any benefit
from that work (i.e., getting paid), it's hard to keep it up.

Cheers,
Randy Hyde

Long live NASM! :-)

Like MASM, NASM has achieved critical mass and has considerable
momentum. It will live for quite some time even if another line of code
is written inside the compiler.
Cheers,
Randy Hyde

Or even if not another line is written. :-)

[unknown]

Post by ***@earthlink.net
The thing that I see killing MASM is the fact that many hard-core
assembly x86 programmers are switching from Windows to Linux, meaning
that they have to switch to a different assembler (usually NASM or
FASM). I really suspect that Microsoft's direction with Vista (trusted
computing, JIT compilation, and no assembly) is probably going to push
more assembly programmers away from Windows and may be the ultimate
cause of MASM's "death" (or, at least, the thing the breaks its
inertia).

Randy, is Vista really going to make it difficult for asm programmer
to write for it? The inability of producing binary code is a big
mistake on microsoft side since optimization would jump through the
window.

Post by ***@earthlink.net
Like MASM, NASM has achieved critical mass and has considerable
momentum. It will live for quite some time even if another line of code
is written inside the compiler.
Cheers,
Randy Hyde

John

[santosh]

Post by unknown

Post by ***@earthlink.net
The thing that I see killing MASM is the fact that many hard-core
assembly x86 programmers are switching from Windows to Linux, meaning
that they have to switch to a different assembler (usually NASM or
FASM). I really suspect that Microsoft's direction with Vista (trusted
computing, JIT compilation, and no assembly) is probably going to push
more assembly programmers away from Windows and may be the ultimate
cause of MASM's "death" (or, at least, the thing the breaks its
inertia).

Randy, is Vista really going to make it difficult for asm programmer
to write for it? The inability of producing binary code is a big
mistake on microsoft side since optimization would jump through the
window.

I'm sure optimisation was never resident at Redmond, for it to jump out
of the window :)

Seriously though, AFAIK, assembly will be possible under Vista, though
more cumbersome and obsoleted. But Blackcomb, (code name for Windows
2010), would probably hammer the final nail in the coffin of assembly
programmers, unless something intervenes.

[r***@earthlink.net]

Post by santosh
I'm sure optimisation was never resident at Redmond, for it to jump out
of the window :)

Actually, Rico is one sharp guy and he's been in Redmond for quite some
time:
http://blogs.msdn.com/ricom/archive/2004/04/28/122503.aspx
Cheers,
Randy Hyde

[r***@earthlink.net]

Post by unknown
Randy, is Vista really going to make it difficult for asm programmer
to write for it? The inability of producing binary code is a big
mistake on microsoft side since optimization would jump through the
window.

Vista will still allow assembly code, but the protection mechanisms MS
is putting into Windows makes such code "second class". It's also clear
that MS has eventual intentions of not allowing it at all.

With Vista, for example, you will not be allowed to install unsigned
drivers (in previous versions of Windows you got a warning and that was
it). If this is any indication, Vista is the first step towards
disallowing insecure binaries (e.g., binary machine code).
Cheers,
Randy Hyde

[santosh]

Post by r***@earthlink.net

Post by unknown
Randy, is Vista really going to make it difficult for asm programmer
to write for it? The inability of producing binary code is a big
mistake on microsoft side since optimization would jump through the
window.

Vista will still allow assembly code, but the protection mechanisms MS
is putting into Windows makes such code "second class". It's also clear
that MS has eventual intentions of not allowing it at all.
With Vista, for example, you will not be allowed to install unsigned
drivers (in previous versions of Windows you got a warning and that was
it). If this is any indication, Vista is the first step towards
disallowing insecure binaries (e.g., binary machine code).

What is a "secure" binary? VM bytecode, or native machine code
explicitly "certified" by Microsoft, or both?

[r***@earthlink.net]

Post by santosh
What is a "secure" binary? VM bytecode, or native machine code
explicitly "certified" by Microsoft, or both?

Or, perhaps, VM Byte code that has been JIT'd into native machine code.
Cheers,
Randy Hyde

[geletine]

There is a article on
http://www.eweek.com/article2/0,1895,1983037,00.asp
about a prototype rootkit on vista by bypassing the digital signature
mechanism

[johnzulu]

Post by r***@earthlink.net

Post by unknown
Randy, is Vista really going to make it difficult for asm programmer
to write for it? The inability of producing binary code is a big
mistake on microsoft side since optimization would jump through the
window.

Vista will still allow assembly code, but the protection mechanisms MS
is putting into Windows makes such code "second class". It's also clear
that MS has eventual intentions of not allowing it at all.
With Vista, for example, you will not be allowed to install unsigned
drivers (in previous versions of Windows you got a warning and that was
it). If this is any indication, Vista is the first step towards
disallowing insecure binaries (e.g., binary machine code).
Cheers,
Randy Hyde

I am now sad..... :( Not going to be easy to write drivers for
Windows.

Thanks
Randy.