64位Win10运行masm.exe：16位汇编工具链与DOS模拟器配置

简介：面向Windows 10环境下汇编语言开发与实验需求整理的工具包，适合正在学习x86汇编、需要搭建MASM编译与链接环境的初学者及系统级编程爱好者，重点解决汇编源码从编译到生成可执行文件所依赖的基础工具缺失问题。压缩包共11个文件，以9个exe可执行程序为主，辅以1份doc说明文档和1个html页面，整体约173KB，体积轻量，便于在本地快速取用与留存。已有1056人浏览学习，说明其在汇编入门工具需求中具有一定参考价值。包内除核心汇编与链接程序外，还包含若干配套实用工具及说明材料，可帮助读者补齐传统汇编实验所需的基础组件，并借助文档了解各程序用途，适合课程实验、自学练习和底层原理探究时作为工具资料留存。

1. 为什么 masm.exe 在 64 位 Win10 上双击就提示"无法运行"

把课程资料里的 masm.exe 和 link.exe 拖到桌面，双击，弹出来的通常不是熟悉的命令提示符窗口，而是一句"此应用无法在你的电脑上运行"。很多人第一反应是文件被杀毒软件吃了、压缩包没解压干净，或者权限不够，折腾半天重下一遍还是一样。真正的原因只有一句话：这两个是 16 位的 DOS 程序，而 64 位 Win10 早就把运行 16 位程序的子系统（NTVDM）整个去掉了，只剩 32 位 Windows 还留着它。

所以这条链路的关键不是"缺文件"，而是"缺运行环境"。想在这类机器上用汇编走完masm.exe → link.exe → .exe的完整闭环，只有两条路：给 16 位程序造一个能跑的环境，或者换成 32 位工具链。下面会讲选型依据、目录怎么摆、masm和link的关键开关怎么设置、用批处理固化参数，以及在链接阶段最常出现的五类报错怎么查。

2. 工具链选型：16 位 masm.exe 与 32 位 ml.exe 到底该用哪一套

2.1 两组 exe 名字相同，实际是完全不同的两个东西

初学者最容易踩的坑，是把不同来源的 masm.exe、link.exe 一股脑塞进同一个目录。16 位时代的link.exe和 32 位工具链里的link.exe文件名一模一样，但一个是 MZ 格式、只能链接 16 位 OBJ，另一个是 PE 格式、只认 32 位 COFF 目标文件。放到一起，后放的覆盖先放的，然后masm编出来的 obj 怎么都链不上，报错还牛头不对马嘴。

选型的判断标准不是"哪个新"，而是"你要交的东西跑在哪"。课程作业要求写 8086 实模式、用int 21h输出字符串、最后交一个能在 DOS 里跑的 exe，那就绕不开 16 位这套；要做的是带窗口、调系统接口的 32 位程序，直接上 ml.exe，别在模拟器里绕远路。

2.2 64 位系统跑不了 16 位程序，兼容模式也救不了

有人在 exe 上右键属性，把兼容性调到"Windows 98"，再双击，还是那句提示。兼容模式改的是 API 行为和显示缩放，它不会凭空把 NTVDM 装回来。64 位 Windows 里那个负责给 16 位程序做指令翻译的子系统整个不存在，缺了它，任何 16 位 DOS 程序都没有执行入口。

常见的三种绕法，实际用下来差别很大：

第一种是装 32 位系统或开 32 位虚拟机。能跑，但为了几百行汇编作业维护一整个系统镜像，成本收益完全不成比例，而且每次开机得多等一分钟。

第二种是用 DOS 模拟器。它自带指令翻译和中断模拟，把宿主目录挂成模拟器里的 C 盘，然后在里面敲masm、link，产物也在模拟器里直接运行验证。这是目前最省事的做法，也是后面第 3 章展开的路径。

第三种是干脆换工具链，写 32 位汇编。绕开 16 位这道坎，代价是要重新学一套调用约定和段/节概念。

还有一种"半吊子"做法值得提醒：有人找了个 16 位模拟层的小工具，把 masm.exe 单独包一层跑起来。汇编这一步确实过了，但生成的 obj 是 OMF 格式，你手上的 32 位 link.exe 根本不认，等于把问题从第一步推到了第三步，白折腾。要么整条链都在模拟环境里，要么整条链都换成 32 位，不要混搭。

2.3 先花五分钟判定手里的 exe 是哪一种

在动手配置之前，先用一段脚本把手上文件的格式确认清楚，比出事之后再回头查要省太多时间。MZ 头的 0x3C 偏移处存放着指向 PE 头的偏移量，如果那个位置读出来不是PE\0\0，基本可以断定它是纯 DOS 程序。

# 判定一个 exe 是 16 位 DOS 程序，还是 32/64 位 PE 程序 import struct import sys path = sys.argv[1] with open(path, 'rb') as f: head = f.read(0x40) # 读 DOS 头，固定 64 字节 if head[:2] != b'MZ': print('不是 MZ 可执行文件，可能是压缩包或损坏文件') sys.exit(1) # 0x3C 处 4 字节小端整数 = PE 头相对文件起始的偏移 e_lfanew = struct.unpack_from('<I', head, 0x3C)[0] f.seek(e_lfanew) sig = f.read(4) if sig == b'PE\0\0': print('PE 程序，能在 64 位 Win10 上直接运行') else: print('16 位 DOS 程序，必须进模拟器或用 32 位系统')

脚本里有两个参数值得记一下：head[:2]校验的是 MZ 魔数，压缩包解压不完整的文件经常连这两个字节都对不上；e_lfanew是 DOS 头里唯一一个指向 PE 头的字段，如果它算出来的偏移超过了文件长度，说明文件被截断过。跑完这段，你对手上这套 masm.exe 到底是什么东西就有底了，后面配置时才不会出现"以为装好了其实一直没跑起来"的玄学情况。

2.4 三种典型需求对应的组合，照着选就行

血泪经验是：不要为了"看起来更现代"去强行迁移一套 16 位源码。段寄存器、assume、org 100h这些东西在 32 位模型里语义全变了，改起来的坑比重新写一遍还多。

3. 用 DOS 模拟器跑通 masm.exe 与 link.exe 的最小闭环

3.1 目录约定：宿主侧只放三类东西

先把目录结构定死，后面所有命令都能照抄。在宿主磁盘上建一个d:\masm（换成任何没有中文、没有空格的路径都行），里面放三样东西：

第一层放 masm.exe 和 link.exe 本体。第二层建个SRC子目录，所有.asm源码丢这里。第三层建个OUT子目录，专门接.obj和.exe。

把可执行文件和源码分开的理由很实际：模拟器挂载之后，masm默认会把 obj 生成在当前目录，如果你的源码和工具混在一起，del *.obj这类清理命令很容易误伤；而且有些老版本 link 在处理同目录下几十个文件时会因为目录项太多而变慢。

注意：路径里绝对不能出现中文和空格。模拟器对长文件名的支持是有限兼容，一旦路径里有空格，挂载之后的盘符映射经常变成只读，报错信息还完全看不出是路径问题。

3.2 挂载与切换盘符：两条命令把环境立起来

启动模拟器后，先执行挂载，把宿主的d:\masm映射成模拟器里的C:。

rem 把宿主目录映射为模拟器 C 盘 mount c d:\masm rem 切到 C 盘，后续所有命令都在这里执行 c: rem 确认工具在位 dir masm.exe dir link.exe

mount c d:\masm里第一个c是模拟器内部的盘符，可以随便取（比如mount d ...），后面的路径必须是宿主侧的真实路径。这条命令是"一次性"的，模拟器关掉就失效，所以熟练之后一般会把它写进配置文件的自动执行段，省掉每次手敲。

dir masm.exe那两行不是走流程，而是确认一个经常翻车的点：很多人把 masm.exe 放进了SRC子目录，然后c:切过去执行却提示"Bad command or file name"，回头查半天以为是权限问题。先dir一下，能列出来再往下走。

3.3 写第一个 hello.asm 并汇编成 obj

先写一个最小可跑通的 16 位程序：用int 21h的 09 号功能输出一串以$结尾的字符，再用 4Ch 功能返回 DOS。

; hello.asm —— 16 位 DOS 下最小可运行示例 .model small ; 小内存模型：代码一段、数据一段，各不超过 64KB .stack 100h ; 声明 256 字节栈，缺了这句链接会报 no stack segment .data msg db 'Hello, MASM', 0Dh, 0Ah, '$' ; 0Dh/0Ah 是回车换行，$ 是 09h 功能的结束符 .code start: mov ax, @data ; @data 由汇编器替换成数据段段址 mov ds, ax ; 实模式下必须手动把段址装进 DS mov ah, 09h ; 09h：显示以 $ 结尾的字符串 lea dx, msg int 21h mov ax, 4C00h ; 4Ch：带返回码退出，AL=00 表示正常 int 21h end start ; end 后面跟入口标号，决定 exe 头里的 CS:IP

几个地方不能省：.model small决定了段的数量和大小上限；.stack 100h决定链接器是否写入SS:SP；end start里的start是程序入口，如果只写end，链接出来的 exe 第一条指令位置就是随机的，运行必崩。

接着汇编：

rem /z 让错误信息带上出错行号；分号结尾表示后续交互提问全部取默认值 masm /z hello.asm;

masm默认是交互式的，会依次问你 obj 文件名、列表文件名、交叉引用文件名，连按三次回车才完事。命令行末尾那个分号就是"剩下的问题全用默认答案"的意思，加上它才是一条命令跑完。/z的作用是在屏幕上额外打印出错的那行源码，不带这个开关时只有冷冰冰的A2006错误码，查起来像开盲盒。

汇编成功的标志是生成hello.obj，并且屏幕上最后一行出现0 Warning Errors和0 Severe Errors。有一个 Warning 也要看一眼，16 位汇编里最常见的警告是段没有按预期对齐，早期不处理，后面链接时才爆出来。

3.4 link 把 obj 拼成 exe，并在模拟器里验证

rem 用默认参数链接；同样用分号跳过交互提问 link hello.obj; rem 直接在模拟器里运行验证 hello

link这一步做的事情，可以理解成三个动作：把所有 obj 里同名的段合并成一个；把mov ax, @data这类引用换成真实地址；最后在文件头写入 MZ 签名、CS:IP入口地址、SS:SP栈指针和重定位表。

命令行里如果出现unresolved external，说明某个符号在所有 obj 里都找不到定义，八成是函数名拼错或者漏了一个 obj 没参与链接；如果出现no stack segment，回去检查.stack那句是不是漏了；如果出现fatal error L1001，一般是参数写法不对，比如把link /TINY hello.obj;里的分号落在了选项中间。

hello这条命令只有在模拟器内部才有效。同一个hello.exe拿去 Win10 资源管理器里双击，还是那句"无法运行"，原因和第 1 章说的完全一样——它仍然是 16 位程序，模拟器只解决了"跑"的环境，没有改变产物本身的格式。

到这里，masm.exe → link.exe → .exe这条链路就通了。剩下的全部工作量，都在参数怎么配和报错怎么查上。

4. 参数配置：masm 与 link 的常用开关怎么配

4.1 masm 的七个开关，按用途记

/l生成的.lst文件被严重低估了。它按段分类列出每一行源码对应的偏移地址和机器码，你想确认mov ax, @data到底被汇编成了几个字节、int 21h是不是CD 21，翻这个文件比反汇编快得多。调试实模式程序时，它能替代大半个调试器。

/I的写法有个细节：路径里不要带引号，多个路径用分号隔开，而且路径必须是模拟器内部看到的路径，不是宿主的路径。

rem 正确：路径写模拟器内部的盘符 masm /z /I=C:\INCLUDE hello.asm; rem 错误：写成了宿主路径，模拟器里根本不存在 D 盘 masm /z /I=D:\masm\INCLUDE hello.asm;

最后这条错误写法能坑掉一整个下午，因为报错是Unable to open include file，看起来像文件丢了，实际上是路径视角搞错了——模拟器里只有你mount过的那些盘。

4.2 link 的六个开关，重点在 /TINY 和 /MAP

/MAP生成的映射文件里有两块内容最有用：一是段表，能看到每个段的起始地址和长度，段重叠或超出 64KB 一眼就看出来；二是符号表，能看到_printf这类外部符号是不是被解析到了某个具体地址。

/EXEPACK有个副作用要提前知道：压缩后的 exe 在某些模拟器上会因为解压头的内存占用而对不上原始栈设置，如果加了它之后程序行为变了，先把这个开关去掉再排查。

4.3 用 build.bat 把参数固化成一条命令

每改一行源码就手敲两条命令加三个开关，早晚会敲错。在SRC目录下放一个批处理，把名字和开关都固定下来：

@echo off rem 用法：build.bat 源文件名（不带扩展名） if "%1"=="" goto usage set NAME=%1 rem 先清掉旧产物，避免链接到上次的 obj 造成"改了没生效"的错觉 if exist %NAME%.obj del %NAME%.obj if exist %NAME%.exe del %NAME%.exe rem /z 显示错误行，/l 出列表文件便于核对机器码 masm /z /l %NAME%.asm; if errorlevel 1 goto fail rem 生成普通 exe；若要 com 文件，换成 link /TINY %NAME%.obj; link /MAP %NAME%.obj; if errorlevel 1 goto fail echo BUILD OK: %NAME%.exe goto :eof :fail echo BUILD FAILED exit /b 1 :usage echo Usage: build.bat filename_without_ext

if errorlevel 1判断的是"上一条命令返回码大于等于 1"，所以失败判断写1就够，不需要写neq 0。del前面加if exist是为了在第一次编译时不让"找不到文件"的噪音混进输出。exit /b 1让批处理把失败状态传出去，将来要把编译接进别的脚本时，这个返回码是唯一的判断依据。

参数说明：%1是第一个命令行参数，%NAME%展开后不带扩展名。批处理里不要用中文注释以外的中文内容做文件名，DOS 环境下中文文件名会变成乱码，del和link都对不上。

4.4 生成 .com 而不是 .exe：/TINY 不是随便加的

.com文件没有文件头，代码、数据、栈全挤在同一个 64KB 段里，加载时被直接放到100h，所以源码必须改成这样：

; hello_com.asm —— 生成 .com 的写法 .model tiny ; 代码和数据合并到一个段 .code org 100h ; 告诉汇编器：第一条指令从偏移 100h 开始 start: mov ah, 09h lea dx, msg ; .com 里 DS 已经等于 CS，不用手动装载 int 21h ret ; .com 用 ret 返回 DOS，而不是 4Ch msg db 'Hi$' end start

配套命令是masm /z hello_com.asm;加link /TINY hello_com.obj;，产物扩展名是.com。

两处差异必须同时改：漏了org 100h，所有标号偏移都会差 256 字节，lea dx, msg指到垃圾数据上；漏了ret，程序执行到末尾会直接跑飞。反过来，如果源码写的是.model small却加了/TINY，链接器会直接报错，因为小模型天然要求至少两个段，塞不进 com 的单段结构。

5. 五个高频报错：从 A2006 到 LNK1104 的排查路径

5.1 现象：双击 masm.exe 提示"此应用无法在你的电脑上运行"，或在 cmd 里报"不是有效的 Win32 应用程序"

原因：这是 16 位程序，64 位系统里没有对应的运行子系统。跟文件权限、杀毒软件、路径都没关系。

解决：先按 2.3 的脚本确认格式，确认是 16 位之后就不要再在宿主侧尝试执行，直接进模拟器。有一个容易混淆的分支：如果报的是"不是有效的 Win32 应用程序"而不是那句"无法在你的电脑上运行"，说明你是在命令提示符里手动敲的，错误来源是同一个，处理方式也一样。别去改兼容性设置，那是浪费时间。

5.2 现象：masm 报Unable to open include file: XXX.INC，但文件明明就在旁边

原因：三种可能，按出现频率排序——/I路径写成了宿主路径（见 4.1 的错误写法）；文件用了小写名而源码里写了大写，模拟器在某些配置下大小写敏感；文件确实在，但放在了SRC之外没被挂载到的目录里。

解决：先把.inc文件和.asm放同一个目录，去掉/I试试，能过就说明是路径问题；确认能过之后再把 include 统一挪到C:\INCLUDE，命令行改成/I=C:\INCLUDE。查大小写用dir *.inc看清楚实际文件名，别凭记忆写。

5.3 现象：A2006: undefined symbol或A2008: syntax error

原因：A2006是符号没定义，最常见的是end start里的标号和实际入口标号不一致，或者用了外部符号却没写extern。A2008是语法错，实模式代码里出现 32 位寄存器（eax、ebx）却忘了在文件开头加.386，或者段声明顺序写反了（.data放在.code后面）。

解决：先看/z打出来的出错行，逐字对比；用了 32 位寄存器就在.model之前加.386；入口标号统一用一个名字，别在start和main之间反复改。

.386 ; 想在实模式里用 eax 一类寄存器，这行必须有 .model small .stack 100h

.386必须写在.model之前，写在后面不生效，而且不会报错，只是继续按 8086 规则汇编，然后你会在A2008上卡很久。

5.4 现象：链接报unresolved external或no stack segment

原因：unresolved external表示某个符号在所有参与链接的 obj 里都找不到定义，通常是拼写不一致（汇编器对符号大小写敏感）、漏了一个 obj 没写进命令行、或者.model声明和实际用法冲突。no stack segment则是源码里没写.stack，链接器不知道SS:SP该填什么。

解决：先 grep 一遍符号定义处和引用处，确认拼写完全一致；多文件项目把 obj 都列全：link /MAP a.obj b.obj;，然后打开 map 文件看符号表里有没有那个名字。no stack segment直接加.stack 100h，栈大小按实际需要调，递归深或局部数组大就往上加到200h、400h。

5.5 现象：切到 32 位工具链后，link 报LNK1104: cannot open file或LNK2001: unresolved external symbol

原因：LNK1104是找不到文件，多数是库路径没配或者 obj 根本没生成（上一步 ml.exe 失败但批处理没拦住）。LNK2001是符号找不到，32 位下常见于手写汇编调用 C 函数时忘了名字修饰规则，或者链接时被/NODEFAULTLIB把默认库关掉了却没手动补上。

解决：LNK1104先确认.obj存在，再检查库目录；批处理里务必用返回码中断，不要让链接在 obj 缺失的情况下硬跑。LNK2001用/MAP生成映射文件，对照符号表看链接器实际在找什么名字，通常会看到多了一个下划线前缀，那就是调用约定的问题。

rem 32 位链路：任一步失败就停，避免带着残缺产物继续链接 ml /c /coff /Zi hello32.asm if errorlevel 1 goto fail link /SUBSYSTEM:CONSOLE /DEBUG /MAP hello32.obj if errorlevel 1 goto fail

/c表示只编译不链接，/coff指定目标文件格式（不写这个，链接器读 obj 会直接报格式不认），/SUBSYSTEM:CONSOLE决定产物是控制台程序，漏了它链接器会警告并猜一个，猜错就变成双击闪退。

6. 把编译链固化下来：自动挂载、一键构建与产物校验

每次开模拟器手敲mount、c:、cd SRC、build hello，一天下来几十遍，早晚会敲错一次。真正省时间的做法是把这几步写进模拟器配置文件的自动执行段，启动后直接落在工作目录里：

[autoexec] mount c d:\masm c: cd \SRC echo Ready. Run: build.bat hello

这段配置里没有花哨的东西，但顺序不能变：mount必须在c:之前，cd必须在切盘之后。有人把cd \SRC写在c:前面，结果切过去之后还在根目录，然后怀疑是自动执行没生效。

宿主侧再包一层，用模拟器的一次性命令参数把整个构建过程串起来，双击一个 bat 就能出结果：

@echo off rem 启动模拟器，自动挂载、切目录、执行构建、退出 dosbox -c "mount c d:\masm" -c "c:" -c "cd \SRC" -c "build.bat hello" -c "exit" if errorlevel 1 echo 构建失败，回到模拟器里看 masm 的输出

-c参数的语义是"启动后按顺序执行一条命令"，最后那条exit保证跑完自动退出，不然窗口会一直挂着。这套写法的好处是构建过程可以完全脱离人工，适合一天改几十遍的小作业。

产物校验这一步大部分人直接跳过，但对 16 位程序特别值得做，因为很多错误不会让编译失败，只会让 exe 行为诡异。除了看/l生成的列表文件，还可以直接读 MZ 头验证入口地址：

拿hello.exe试一次，你会发现 0x14 处的 IP 值和.lst文件里start那行的偏移完全一致。对不上就说明end start写错了，或者链接时混进了别的 obj 抢了入口。这个校验我一般只在前几次写新程序时做，熟了之后靠.lst就够了。

最后说一个我自己吃过亏的习惯：所有实验性改动都在SRC下新建一个test_xxx.asm单独编，不要直接在主文件上改完再编。16 位环境下没有断点、没有调用栈，一次改动出问题，你手里连个能对照的"上一次能跑的版本"都没有，只能靠猜。留一份能跑的基线，比任何调试技巧都管用。希望帮到你。

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