Re: [Nasm-devel] NASM 2.09.10 manual ("Introduction") -- slight update needed

[Frank K. <fbk...@my...>]

Rugxulo wrote:
> Hi,

Hi Rugxulo,

Sorry for the delay in getting back to you. (and Thanks for your work on 
FreeDos!!!)

>    Not sure if this is the right email (or right person or place ...

It'll do. I'll pass your concerns on to the developer's list (Hi list), 
but the relevant section of the manual is "historical" (perhaps this 
isn't made clear enough). It is Simon's rationale for writing Nasm in 
the first place. If taken as "Why should I choose Nasm *now*?", it would 
be quite out of date, as you point out!

Thanks for the feedback!

Best,
Frank

> or if even worth mentioning!!), but here's a small revision of the
> latest NASM manual. Apparently it still says some (slightly outdated)
> info. (Feel free to ignore this, I'm just rambling for completeness,
> to get it off my chest, so to speak.)
> 
> "
> a86 is good, but not free, and in particular you don't get any 32-bit
> capability until you pay. It's DOS only, too.
> "
> 
> **** DOS-hosted only, but optional OMF output means you could target
> other OSes, e.g. his AWIN package for Win95. Granted, it's not as
> convenient, but it sorta works.
> 
> "
> gas is free, and ports over to DOS and Unix, but it's not very good,
> since it's designed to be a back end to gcc, which always feeds it
> correct code. So its error checking is minimal. Also, its syntax is
> horrible, from the point of view of anyone trying to actually write
> anything in it. Plus you can't write 16-bit code in it (properly.)
> "
> 
> **** It can (more or less) write proper 16-bit code now, but it's
> kinda buggy (esp. 2.21 !!), esp. if you try to do anything like
> outputting raw (flat) binaries, which needs weird LD or OBJCOPY hacks.
> (And some people, God help them, actually "like" AT&T, *shudder*!)
> 
> "
> as86 is specific to Minix and Linux, and (my version at least) doesn't
> seem to have much (or any) documentation.
> "
> 
> **** Weird (incompatible) a.out variant, but there is a (kinda old)
> Dev86DOS hosted build that works with (similarly old) BCC (circa
> 0.16.2, not latest 0.16.18). It can target DOS, and Dev86DOS does
> indeed have a DOS C library and outputs .COM.
> 
> "
> MASM isn't very good, and it's (was) expensive, and it runs only under DOS.
> "
> 
> **** Heavily debatable whether it's any good, some people LOVE it! But
> they swear by MASM 5 or 6.14 or similar. I forget what it's up to by
> now, at least 10.0 or such (with x64 support). But true, it's free
> (and has been, more or less, for ten years, in various forms, mostly
> seemingly?? "non-commercial only", e.g. latest MS VC Express).
> Allegedly 5 is from 1987 or such and ran natively on both OS/2 and DOS
> (and was first to support 386 output) while 6 was heavily improved
> ("ml.exe", rewritten? no more EXE2BIN needed) from 1992 or such and
> ran on DOS (through 6.11d) 386s (via PharLap) and later Win32. So
> clearly it's not (nor was for a long, long time) DOS-only (esp. since
> COFF was never used on DOS by MS or similar tools). P.S. MASM has had
> a kinda bizarre history, and I don't claim to really understand or
> know it fully (by far)!! EDIT:  Wikipedia says "Stable
> release	10.0.30319.1 / April 12, 2010; 18 months ago".
> 
> "
> TASM is better, but still strives for MASM compatibility, which means
> millions of directives and tons of red tape. And its syntax is
> essentially MASM's, with the contradictions and quirks that entails
> (although it sorts out some of those by means of Ideal mode.) It's
> expensive too. And it's DOS-only.
> "
> 
> **** I don't know when the DOS-only ceased to be true, but at least
> with TASM32 5.3 (circa 2000), it was Win32 only (or perhaps their
> weird 32RTM / DPMI32BI hybrid). For a brief while, it was freeware
> included in CodeGear's Turbo C++ Explorer 2006, but eventually that
> was phased out when Embarcadero took over. IIRC, it only supported MMX
> and maybe 686 stuff, nothing newer. I read later that they maybe
> finally updated it to 5.4, but I don't know what that entailed. But (I
> think??) it indeed was still outputting OMF/OBJ. I still have a copy
> (from above 2006), so I could check if needed.
> 
>