DOS ain't dead

The NASM developers have released NASM version 2.03.01 on 17 June 2008.

Home page: http://nasm.sourceforge.net/
Download: http://sourceforge.net/project/showfiles.php?group_id=6208

Changes:
* Fix buffer overflow in the listing module.
* Fix the handling of hexadecimal escape codes in `...` strings.
* The Postscript/PDF documentation has been reformatted.
* The -F option now implies -g.

---
Forum admin

They released NASM version 2.04rc1 on 2008-09-09.

Changes:
* There are two DOS/DPMI/DJGPP binary downloads now, one (dos-upx) with UPX compressed and the other (dos) with uncompressed executables. Notice that the 2.03.01 DOS binary release only had compressed executables.

(following copied from the new Appendix C, "NASM Version History", of the user manual.)
> * Sanitize macro handing in the '%error' directive.
> * New '%warning' directive to issue user-controlled warnings.
> * '__utf16__' and '__utf32__' operators to generate UTF-16 and UTF-32 strings.
> * Fix bug in case-insensitive matching when compiled on platforms that don't use the 'configure' script.
> * Correct the handling of nested '%rep's.
> * Support for x87 packed BCD constants.
> * New '%strcat' directive to join quoted strings together.
> * Correct the 'LTR' instruction in 64-bit mode.
> * Fix unnecessary REX.W prefix on indirect jumps in 64-bit mode.
> * New '%use' macro directive to support standard macro directives.
> * Excess default parameters to '%macro' now issues a warning by default.
> * Numerous bug fixes, especially to the AES, AVX and VTX instructions.

---
l

> They released NASM version 2.04rc1 on 2008-09-09.

2.04rc2 is also released (although the main page doesn't mention it yet, see GIT repository). I don't expect it to take long before an official release; however, last time they went up to rc8 !!

EDIT: And BTW, no idea why they waste their time UPXing and still have a separate non-UPX'd build. UPX can unpack its stuff 99% of the time. And we should all know by now that there's a slight performance decrease (e.g. on Windows) when packed, but that shouldn't bother most people. Maybe 32LiTE would be better?? (Doubt it. BTW, looks like a new version of aPLib was released recently.)

> I don't expect it to take long before an official release;

I read in the mailing list that they're currently working on the Mach-O backend and that the final 2.04 probably is released when that is done.

> EDIT: And BTW, no idea why they waste their time UPXing and still have a
> separate non-UPX'd build.

Some people don't like UPX. (I'm not one of these. Heck, I'm currently thinking about whether RxDOSCMD could reload its transient part from a compressed executable.)

> UPX can unpack its stuff 99% of the time.

Well, you need UPX to do that.

> And we
> should all know by now that there's a slight performance decrease (e.g. on
> Windows) when packed, but that shouldn't bother most people.

Are the Win32 binaries packed as well? If they aren't, there's no reason to use dos-upx on Windows.

---
l

> > I don't expect it to take long before an official release;
>
> I read in the mailing list that they're currently working on the Mach-O
> backend and that the final 2.04 probably is released when that is done.

I thought they were still looking for a Mach-O backend maintainer?

> > UPX can unpack its stuff 99% of the time.
>
> Well, you need UPX to do that.

Yes, and so? It's not exactly a huge download (400k), and it's quite useful, IMO. (At the very least to unpack stuff if one hates it so much.)

> > And we
> > should all know by now that there's a slight performance decrease (e.g.
> on
> > Windows) when packed, but that shouldn't bother most people.
>
> Are the Win32 binaries packed as well? If they aren't, there's no reason
> to use dos-upx on Windows.

Is there a reason to use DOS non-UPX on Windows? Yes. At the very least, it can handle long commandlines even under DJGPP's bash or make. I'm not sure what compiler builds the Win32 .EXEs anymore (looks like MinGW, yet 0.98.39 for Win32 was Borland, and that was a lot slower than DJGPP). Besides, DJGPP has a newer GCC than MinGW. (And obviously I use the DOS version for DOS reasons, heh.)

> I thought they were still looking for a Mach-O backend maintainer?

Seems they've found one. Read the nasm-devel mailing list. From "Goals for NASM 2.04" (answer by Keith Kanios):

> [...]
>
> I'm not sure I can make MACH-O 64-bit support by 2.04rc, if the release
> candidate is supposed to happen soon.
>
> I've made progress with the general module, in that ld recognizes the
> object file produced. However, I still have to implement the different
> relocation types, possibly/probably including the GOT... as opposed to
> the more simplistic 32-bit version of MACH-O.

---
l

> > I thought they were still looking for a Mach-O backend maintainer?
>
> Seems they've found one. Read the
> nasm-devel
> mailing list. From "Goals for NASM 2.04" (answer by Keith Kanios):

I dunno, I'm not sure he's the guy. AFAIK, he was the guy they were looking for a replacement for! But I'm not "in the know", so I dunno really. But I think he's the main guy (or one of 'em, at least) who really helped push to 0.99 and 2.00 etc.

Anyways, 2.04rc3 is out (8 days ago), and there's even a small preproc fix since then (3 days ago) but nothing further. So who knows when an official release will happen, not that I really need it for my wimpy uses. (And all this AVX support seems a bit premature, to say the least.)

---
Know your limits.h

> So who knows when an official
> release will happen, not that I really need it for my wimpy uses.

Well, the RxDOS source I'm currently working on assembles with 2.04 snapshots/RCs only, hence a final 2.04 would be useful. (The main reason to use snapshots was that some bugs present in 2.03.01 did affect the source.)

---
l