企业官网建设流程全解析

简介：面向在 Windows 10 环境下学习 x86 汇编、需要搭建本地编译工具链的初学者与系统级编程爱好者，这是一份可直接使用的 MASM 汇编器与 Link 链接器工具合集，用于解决新版系统中缺少 16 位/32 位汇编编译与链接程序、难以完成 asm 源码到 exe 转换的问题。压缩包共 11 个文件，以 9 个 exe 可执行工具为主，涵盖 MASM.EXE、LINK.EXE 以及 LIB.EXE 库管理、MAKE.EXE 构建、CREF.EXE 交叉引用、EXEPACK.EXE 与 EXEMOD.EXE 可执行文件处理等配套程序；另附 1 个 html 页面与 1 份 README.DOC 说明文档，用于介绍工具用途与配置方法，整包约 173KB，体积小巧便于拷贝到实验机或虚拟机中使用。资源已有 1056 人学习下载，适合配合汇编课程实验、课后作业与底层机制自学，帮助读者省去在 Visual Studio 与 SDK 中翻找独立工具的麻烦，快速打通编写、汇编、链接、运行的完整流程，并为后续理解段结构、外部符号引用与内存布局打下基础。

1. 在 Win10 上跑通 16 位汇编：问题不在编辑器，在 masm.exe 和 link.exe

一个写着INT 21H的 .asm 文件，在 Win10 上打开方式换了一圈都没用——它缺的不是编辑器，也不是什么 IDE，而是两个只有几十 KB 的 DOS 可执行文件：汇编器masm.exe和链接器link.exe。把这两个文件摆到位，再把命令行调通，一行masm hello.asm;加一行link hello.obj;，就能拿到能跑的 .exe。这份资源解决的就是这个「缺一环」的问题：它不提供语法教程，提供的是让经典 16 位汇编代码在今天的机器上重新能够编译、能够链接、能够执行的那套工具链和摆放方式。适合正在跟着课程做汇编实验、手里有现成 .asm 却卡在「编译这一步」的人，也适合想弄清 OMF 目标文件、MZ 头、段重定位这些老概念到底怎么落到实处的从业者。

2. 两个 exe 的分工：从 .asm 到 .exe 中间隔着一次「地址悬空」

很多人把 masm 和 link 当成一个东西，觉得「编译一下就好了」。实际上它们处理的是两类完全不同的问题：masm 关心的是「这段代码里的符号在自己的段内偏移多少」，link 关心的是「这些段被放到内存的哪个基址上」。把这条边界分清，后面所有报错你都能一眼判断该找谁。

2.1 汇编器 MASM 干的三件事

masm.exe读入 .asm，做两遍扫描。第一遍建符号表，把标号、变量、段名登记进去并记下它们在第几次出现；第二遍才真正生成机器码。第一遍扫描的意义在于解决前向引用——你在第 3 行JMP AGAIN，而AGAIN在第 40 行才定义，靠的就是第一遍先把这个名字占位记下来。

产出的 .obj 不是纯机器码，而是 OMF（Intel Object Module Format）格式的目标模块。里面装了三样东西：代码段的原始字节、数据段的原始字节、以及一堆「待填」的记录。待填分两种，一种是段内偏移，masm 自己能算出确切数值，直接写死；另一种是跨段或跨模块的引用，masm 不知道对方最终在哪，只能留下一个空位，并附一条重定位记录说明「这里需要一个段基址」或「这里需要一个外部符号的偏移」。

第三件事是最容易被忽略的：masm 同时产出 .lst 列表文件和 .crf 交叉引用文件。列表文件把源代码、生成的机器码、段内偏移三栏并排印出来，是排查「某条指令到底汇编成了什么」的唯一可靠依据。很多时候你以为MOV AX, [BX]是两字节，实际列表里印出来的编码和你想的不一样，问题当场就清楚了。

2.2 链接器 LINK 补的是段基址和外部符号

link.exe拿到的是一到多个 .obj 加零到多个 .lib。它做三件事，顺序不能乱。

第一，段合并。把所有 obj 里同名的段、同 class 的段按顺序拼起来，算出每个合并后段的长度。这一步决定了最终 .exe 里代码段和数据段各有多大，也是后面L2041: stack plus data exceed 64K这类报错的来源——16 位实模式下单个段不能超过 64KB，拼过头了就装不下。

第二，符号解析。把每个 obj 里「待填」的外部符号，去别的 obj 和 .lib 的公共符号表里找对应定义，找到就把偏移填进去，找不到就抛 L2029 unresolved external。这一步是唯一能解决跨模块引用的地方，masm 阶段永远发现不了这类问题，所以「汇编通过但链接失败」是常态而不是异常。

第三，生成可执行文件。它给输出加上 MZ 头（那个以4D 5A开头的 EXE 头），写入代码段和数据段的实际长度、初始 CS:IP 和 SS:SP、以及一张重定位表。DOS 加载 .exe 时先把整个映像搬到内存，再按重定位表把段基址加进去，程序才能跑。这也是 .exe 和 .com 的本质区别：.com 没有头和重定位表，必须从 100H 开始且总长不超过 64KB，所以 LINK 只有加/TINY才能直出 .com，而且要求代码段在前、无堆栈段。

2.3 两代版本的搭配：masm 与 link 不能随手混

这一点是真正会让人卡半天的地方。16 位这套工具链跨越了很长时间，不同代的汇编器和链接器在 OMF 记录、段对齐默认值、大小写处理上都有差异，混搭就会出一些看上去莫名其妙的错。常见的分发包大致是两代，选型时对照着看：

A 组最稳，几乎所有老教材代码都是按这一组的默认行为写的；B 组功能全，但默认行为变了，不加/Zm打开 5.x 兼容模式时，那些依赖默认大小写、默认段属性的老代码容易出 A2xxx 错误。C 组的ml.exe是 32 位控制台程序，在 x64 上能直接跑，这是它的优势；但它产出的是 32 位 COFF，不是 16 位 OMF，想要 16 位 DOS 的 .exe，仍然要回到 A 组或 B 组，在 DOS 环境里走一遍。

提示：判断手上的包属于哪一组，最简单的办法是直接敲masm不带参数，看它打印的版本行和帮助文本里的开关列表。5.x 的帮助很短，6.x 会列出/Zm、/Cx、/Cp这些只在 6.x 才有的开关。

3. 把它跑起来：目录布局、挂载和三条命令

工具齐了不等于能跑。16 位 DOS 程序在 64 位 Win10 上没有 NTVDM 这个中间层，双击只会黑框一闪。所以真实可行的路径是：把工具目录挂进 DOS 环境，用命令行一条条敲，先把单文件流程走通，再固化成批处理。

3.1 目录布局与运行环境选择

目录结构上，我一般按「可执行文件、头文件、工作目录」三段分开，避免把源码和工具混在一个文件夹里，重装工具时不用搬代码：

C:\ASM\ ├─ BIN\ masm.exe link.exe （可能还有 exe2bin、lib 等） ├─ INCLUDE\ *.inc └─ WORK\ hello.asm hello.obj hello.exe

工作目录名一律用短的英文大写，最长不超过 8 个字符。原因很实在：DOS 环境里路径带空格或中文时，link打开 obj 会失败，报出来的还是一句很模糊的 cannot open，查起来费时。

运行环境有两种常见做法。一是 DOSBox 这类模拟器，把C:\ASM挂成虚拟 C 盘；二是 32 位虚拟机，直接原生跑 DOS 程序，速度更快但配置更重。日常调试我用前者，因为挂载和切换目录都是一行命令的事：

REM 在 DOSBox 里执行：把宿主机 C:\ASM 挂成虚拟 C 盘 MOUNT C C:\ASM C: CD \WORK SET PATH=C:\BIN;%PATH%

MOUNT把宿主目录映射成 DOS 盘符，C:切过去，CD \WORK进工作目录，最后一行把BIN加进搜索路径。这一步不做的话，你在WORK目录里敲masm会直接返回Bad command or file name，看起来像文件丢了，其实只是找不到。

3.2 第一条命令：masm 的四个位置参数

先准备一个最小可编译的源文件，老式段定义写法，A 组和 B 组加/Zm都能过：

; hello.asm —— 16 位 DOS 程序，打印一行字符串后退出 DATA SEGMENT MSG DB 'Hello from MASM', 0DH, 0AH, '$' DATA ENDS CODE SEGMENT ASSUME CS:CODE, DS:DATA START: MOV AX, DATA ; 取数据段基址 MOV DS, AX MOV DX, OFFSET MSG ; DS:DX 指向字符串 MOV AH, 09H ; DOS 功能号 09H：输出以 $ 结尾的串 INT 21H MOV AX, 4C00H ; 功能号 4CH：带返回码退出 INT 21H CODE ENDS END START ; 入口点声明，缺了会警告

然后调用汇编器。masm 接受四个位置参数，顺序固定：

masm /Zi hello.asm, hello.obj, hello.lst, hello.crf

实际用的时候有个省事的写法：masm hello.asm;。结尾这个分号表示「后面全部取默认值，不要再问我了」。不加分号时，masm 会依次提示Object filename [hello.OBJ]:、Source listing [NUL.LST]:、Cross-reference [NUL.CRF]:，每步都要敲一次回车，写进脚本里就会卡住。这是很多人第一次把它塞进批处理失败的原因。

/Zi是生成 CodeView 调试信息，配合后面的/CO才能在调试器里看到源码行号。平时编译可以不加，排查诡异逻辑时再加，加了之后 obj 会变大一些，不影响执行。

3.3 第二条命令：link 的开关怎么选

link /NOI /NOD /CO /MAP hello.obj;

几个开关的含义值得单独说清，因为它们直接对应不同类型的翻车：

/NOD这条尤其值得解释。链接器默认会去翻一堆标准库，如果当前目录和 PATH 里没有那些 .lib，它会抛一个和你的代码毫无关系的「找不到库」错误，把真实问题盖住。纯手写汇编根本用不到这些库，直接/NOD关掉，报错信息立刻就干净了。

/NOI对应的是一个很隐蔽的坑：老式汇编代码里习惯写MOV AX, @DATA或MOV AX, DATA，大小写并不统一，而 link 在部分版本默认区分大小写，符号表里存的是DATA，你引用的却是Data，于是抛 unresolved external，你盯着源码看半天觉得名字一模一样。加上/NOI一劳永逸。

3.4 用批处理把两行命令固化下来

单文件跑通之后，第一件该做的事是把流程写成 .bat，否则每改一行代码都要重敲两遍命令，还要手动判断上一步成没成功：

@ECHO OFF REM build.bat —— 一条命令走完 汇编 -> 链接，失败立即中断 SET ASM_BIN=C:\ASM\BIN SET PATH=%ASM_BIN%;%PATH% SET INCLUDE=C:\ASM\INCLUDE IF "%~1"=="" ( ECHO 用法: build.bat 源文件名^(不带扩展名^) & EXIT /B 1 ) IF NOT EXIST %1.asm ( ECHO [ERR] 找不到 %1.asm & EXIT /B 1 ) DEL /Q %1.obj %1.exe 2>NUL masm /n %1.asm; IF ERRORLEVEL 1 GOTO FAIL link /NOI /NOD %1.obj; IF ERRORLEVEL 1 GOTO FAIL ECHO [OK] %1.exe EXIT /B 0 :FAIL ECHO [FAIL] 上一步返回非零，看上面的报错原文，不要看这一行 EXIT /B 1

逻辑上有三处刻意的设计。开头DEL /Q先删旧的 obj 和 exe，是为了防止「汇编失败但链接用了上次的 obj」这种假成功——这是最难查的一类问题，你以为改了代码，其实跑的还是上一版。中间两处IF ERRORLEVEL 1必须紧跟命令，因为 DOS 的 ERRORLEVEL 只保留最近一次外部命令的返回码，隔几行再判断就已经被别的命令覆盖了。最后的EXIT /B 1让批处理本身也返回失败码，这样它被更上层的脚本调用时能正确传播错误。

masm后面的/n是关掉列表文件里的符号表输出，纯粹为了让 .lst 小一点、翻起来快一点，对生成结果没有影响。

4. 报错即地图：A2xxx 和 L20xx 分别指向哪一层

报错信息不是噪音，它精确地告诉了你出问题的是哪一层。A 开头的来自汇编器，说明问题在单个源文件内部；L 开头（16 位是 L20xx，32 位是 LNK1xxx）来自链接器，说明问题在模块之间或段布局上。先把这条分界线记住，排查范围立刻缩小一半。

4.1 A2xxx：语法、符号与段属性

这几个是绕不开的常客：

A2105值得单独说。16 位汇编里JZ、JNZ、JC这类条件跳转都是短跳（两字节，位移一个字节），最远只能跳 ±127 字节。中间代码稍微多写几行就越界，masm 直接拒绝。标准改法是取反条件，跳过一个JMP：

; 越界写法：JZ FAR_LABEL（目标超过 128 字节，汇编报 A2105） JNZ SKIP JMP FAR_LABEL SKIP:

A2026 phase error更隐蔽。它的本质是「第一遍认为这个符号是个未知地址，第二遍却发现它是个常量」，两遍生成的机器码长度不同，地址就全错位了。典型诱因是先把一个符号当变量用、后面又用EQU定义成常量，或者反过来。看到这个错误不要改指令，先检查符号定义的位置和方式。

4.2 L20xx 与 LNK1xxx：符号解析和段布局

链接阶段的报错只有两大类，一类是找不到符号，一类是装不下。

L2029: Unresolved external表示有个外部符号在所有 obj 和 lib 里都没找到定义。排查顺序是：先确认大小写（加/NOI），再确认那个模块的 obj 确实被写进了 link 命令（漏掉一个文件名是最常见的），最后确认符号有没有被声明成PUBLIC/EXTRN。三者都对了还报，那就是你引用的根本不是自己写的符号，而是某个库函数——这时候该加库，或者确认是不是误把 32 位代码混进来了。

L2041: stack plus data exceed 64K是段超限。16 位实模式的段内偏移只有 16 位，一个段最多 64KB。数据段里放了大数组、或者堆栈段开得太大，加起来越界就报这个。解法是把数据分到多个段，或者把大数组改成运行时动态申请。

至于LNK1104: cannot open file这类，是 32 位 link 的报错格式，出现它就说明你调用的是另一个链接器，不是 16 位那一套。同一个目录里放两个同名link.exe的处理方式很糟，容易按 PATH 顺序随机命中，我一般直接把 32 位的那份挪到别的目录。

4.3 用 /Zi、.lst 和 .map 定位到具体段

报错只给行号或符号名时，光看源码解决不了。这时候需要三个产物配合：

masm /Zi /Flhello.lst hello.asm; link /CO /MAP /NOI /NOD hello.obj;

打开生成的hello.map，会看到每个段的起止地址和长度：

Start Stop Length Name Class 00000H 00017H 00018H CODE CODE 00018H 0002DH 00016H DATA DATA 0002EH 0003FH 00012H STACK STACK

哪一段长得离谱，一眼就能看出来。如果 DATA 段长度是个异常大的数，多半是某个数组声明写错了维度；如果 STACK 段被单独列出来而且很大，就是.STACK后面的数值给多了。

再打开hello.lst，每条指令的偏移和机器码都并排列着。把它和 .map 里的段基址一对应，你就能算出某条指令在内存里的绝对地址，配合调试器下断点，比在源码里猜要快得多。

5. 避坑：Win10 上最容易翻车的五处

这套工具链老，老在它对环境极其敏感。下面五条都是实际踩出来的，按「现象 → 原因 → 解决」写，遇到时直接对号入座。

5.1 编译阶段的三处

现象一：双击masm.exe黑框一闪，什么都没发生；在 PowerShell 里敲也是同样的结果。原因很明确，这是 16 位 DOS 可执行文件，64 位 Win10 已经移除了 NTVDM 这个兼容层，系统根本没法加载它，连「找不到命令」都懒得报。解决方式是换运行环境：DOSBox 挂载目录后在里面敲，或者退回到 32 位虚拟机。别去改兼容性选项卡里的「以兼容模式运行」，那一栏对 16 位程序无效。

现象二：已经在BIN目录里，敲masm还是提示Bad command or file name。原因是没有把当前目录纳入搜索路径。DOS 和后来的 Windows 一样，只在 PATH 列出的目录里找可执行文件，不自动搜当前目录。解决办法是显式设置一次SET PATH=C:\BIN;%PATH%，写进 DOSBox 的启动配置里，省得每次重开都设。

现象三：源文件放在「我的文档」或桌面，路径带空格或中文，汇编直接报错。原因是 DOS 环境下的路径解析只认 8.3 短名，空格会被当成参数分隔符，中文更是完全不认。解决办法是统一放到C:\ASM\WORK这类纯英文短路径下。这条看起来是小事，但它是新手卡住时间最长的一类，因为报错信息往往指向源文件里的某一行，把人往语法错误上引。

5.2 链接与运行阶段的两处

现象四：汇编干干净净通过，链接抛 unresolved external，而那个符号确实在源文件里定义过。三种可能按概率排：一是大小写不匹配，加/NOI解决；二是那个定义所在的 obj 没被写进 link 命令，尤其是多文件工程，加文件时漏了；三是符号没标PUBLIC，默认是私有的，别的模块看不见。解决顺序就按这个来，先加开关，再查命令行，最后查声明。

现象五：改了 .asm，重新编译，运行结果却和改之前一模一样。血泪经验：多半是汇编那一步其实失败了（比如某个 A2xxx 被你忽略了），旧的 .obj 还在原地，link 拿它照常链接出一个「新的」旧 exe。解决办法是批处理里在编译前先DEL掉旧产物，并且每一行命令后面紧跟IF ERRORLEVEL 1 GOTO FAIL，不许跳步。从那以后我每次改完代码都会瞄一眼批处理输出的最后一行是不是[OK]，不是就绝不运行。

注意：不要用「把 link 的输出重定向到文件再看」来偷懒。16 位程序的输出走的是 DOS 中断，重定向在某些模拟环境下会丢内容，看起来像没有任何报错，实际上错误被吞了。

6. 进阶：把「能跑一次」变成「每次都一样」

单文件跑通只是起点。真正决定这套工具链好不好用的，是能不能在换机器、换目录、换代码之后仍然一次成功。我现在的做法是给工程加一个前置自检，把版本、路径、产物状态三件事在编译前全部确认一遍，再往下走。

@ECHO OFF REM check.bat —— 编译前的三道自检，任何一道不过就不往下走 SET ASM_BIN=C:\ASM\BIN SET PATH=%ASM_BIN%;%PATH% IF NOT EXIST "%ASM_BIN%\masm.exe" ( ECHO [ERR] masm.exe 不在 %ASM_BIN% & EXIT /B 1 ) IF NOT EXIST "%ASM_BIN%\link.exe" ( ECHO [ERR] link.exe 不在 %ASM_BIN% & EXIT /B 1 ) masm 2>NUL | FIND /I "Version" >NUL IF ERRORLEVEL 1 ( ECHO [ERR] masm 无法启动，检查运行环境 & EXIT /B 1 ) link 2>NUL | FIND /I "Version" >NUL IF ERRORLEVEL 1 ( ECHO [ERR] link 无法启动，检查运行环境 & EXIT /B 1 ) ECHO [OK] 工具链自检通过 EXIT /B 0

这三道自检分别对应三类典型失败：文件压根没摆进来、摆了但运行环境不认、能启动但版本组不对。第一类最好查，第三类最难——某些版本组合能汇编也能链接，但产出的 exe 一跑就崩，症状是执行到某条指令后直接返回 DOS，没有任何提示。有了自检，至少在动手改代码之前，你能确定问题不在环境里。

再往上一步是把它 makefile 化。多文件工程里，只改了一个 .asm 就全量重编一遍很浪费，用 nmake 写依赖关系，让 obj 只在源文件时间戳变新时才重编。写法和常见的 make 规则一样，只是命令换成masm $<;和link /NOI /NOD ...。这一步做完，整个流程就跟现代工具链的体验差不多了，区别只是产物是 16 位 MZ 格式。

还有个小技巧值得记：把.map文件纳入版本管理。它体积小，但记录了每次构建的段布局。某次改动之后程序突然跑飞，把新旧两份 .map 一对比，哪个段长了、哪个段起始地址挪了，问题基本就锁定了。这比翻代码比对快得多。

整套masm.exe、link.exe连同上面这几个批处理模板我都打在一个包里，取回去按第 3 节的目录结构摆一遍，把C:\ASM换成你自己的路径就能直接用。踩过的坑我都写在第 5 节了，剩下的就靠你自己多敲几遍命令——汇编这门手艺，看十遍不如亲手让它报一次 A2105 再改对一次。希望帮到你。

本文还有配套的精品资源，点击获取