2.2.4  MASM，TASM还是NASM

既然编写Win32汇编可以使用的编译器有这么多种，那么我们究竟使用哪一种呢？单从编译器的角度来说，用MASM写汇编程序是最方便的，支持@@标号，用invoke调用子程序，支持局部变量和有 .if/.else /.endif高级语法等优点就已经是足够的理由了，更不用说有Microsoft这个强大的后盾了，这是其他的编译器所无法比拟的，但使用MASM的不方便之处是它从来就不是当做一个完整的软件包发售的，要开始用MASM写Win32程序还要费很大的周折。

首先是不同版本的MASM软件包中都没有包含资源编译器，资源编译器是当做Windows SDK的一部分发行的，或者要从Microsoft Visual Studio软件包的Common目录中找，更有甚者，和MASM软件包一同发售的Link程序竟然不是32位的，只能用来链接DOS程序，即使是6.11以上版本中也是如此。迄今为止，MASM软件包中附带的链接程序全是Segmented Executable Linker，Incremental Linker只能在Microsoft Visual Studio软件包的Visual C++目录中找到。

其他一些有用的工具也没有包含在软件包中，如库管理工具和make工具等，所以要使用MASM进行Win32汇编编程就要对软件包进行改造：一方面舍弃MASM软件包中附带的Link程序；另一方面，需要到其他地方去找资源编译器和32位的链接器等工具软件。

对初学者来说，连Win32汇编的开发要哪几个步骤及需要用什么软件都还没有底，就更不用说从不同的工具包中寻找需要的软件了（而且必须是合适的32位版本）；另外，Win32编程用到的导入库在MASM软件包中并没有包括，同样要到Visual C++中去找；最大的障碍在于：MASM软件包中没有头文件，也不可能直接使用Visual C++的头文件，所有这些头文件必须自己根据资料以及参考Visual C++的 .h文件整理出来，而Windows的数据结构和预定义的数据是出了名的多，所有这些让使用MASM编写Win32汇编程序非常难以下手。

从工具包的完整性来说，TASM和NASM相对来说要好一点，TASM软件包中包括了32位的资源编译器和链接器，也有一个32位的导入库文件，这样，用户不用添加任何其他软件就可以直接用TASM写出完整的Win32程序。但TASM软件包中也没有Windows数据结构和预定义的头文件，所有资料同样需要用户自己整理。

另一方面，与MASM相比，TASM在优化方面做得不是很好，简单举几个例子：比如TASM无法处理大量的预定义，如果用户把所有的预定义整理到Windows.inc文件中，然后在源文件中包括进来，编译的时候就会出现“Out of hash space”错误，结果每次只好把要用到的定义分拣出来写成一个小的include文件；再比如在源程序中用extrn定义API函数，不管在程序中实际有没有用到这个函数，TASM都会在最后 .exe文件的导入表中加上这个函数名，这就意味着无法用偷懒的办法把所有的API函数声明写到一个include文件中去，除非用户可以忍受可执行文件中无效的字节数比有效的多得多！还有一个缺点是：TASM在定义结构的时候，不同的结构中不能有同名的字段，而Windows的数据结构定义出奇的多，结果不同结构中的同名字段要在前面加上一些前缀以示区别，这就会使源代码中的结构定义和参考资料中的结构定义在字面上不符合，使用时还要不停地去看结构中的字段究竟是怎么定义的。这些小缺点使TASM在使用时程序员做的无效工作比有效工作还多。

NASM的优点就是学到的语法可以直接用在Linux的汇编中，缺点也是显而易见的，就是免费软件往往缺乏强大的后盾，开发的力度肯定不如大的软件公司，具体就表现在NASM中几乎没有一点可以帮程序员省心的高级语法，而这些恰恰是编写高可维护性程序所必须具有的特征。而且，用NASM编程同样存在用户自己整理数据结构定义和预定义的问题。

比较这些编译器，可以发现很难找到直接拿来就可以开始写Win32汇编程序的软件包，因为每个软件包中都没有关键的头文件，而用户自己整理头文件不仅使程序的可移植性大打折扣，而且工程量之大使程序员只能写很小规模的程序，所以，理想的软件包应该是这样的：

●   包含所有所需工具，如汇编编译器、资源编译器和链接器等。

●   编译器支持高级语法，使源程序便于维护。

●   包含完整的头文件，如Windows的数据结构定义和预定义等。

●   包含齐全的导入库。

●   有大量的例子和说明文档。

有这样的汇编软件包吗？有！MASM32软件包就是我们的选择。