DJGPP 2.04在DOS下搭建32位GCC开发环境：DPMI原理、避坑与调试指南

简介DJGPP 2.04 是一款专为 DOS 环境打造的 C/C 开发工具集由 GNU 工具链移植而来面向希望在老式操作系统上编写程序、钻研操作系统原理或复现早期开发流程的开发者与学习者。该版本整合了 GCC 编译器、汇编器、链接器、GNU Make、调试器等完整构建链路无需现代操作系统也能完成从源码到可执行文件的全部工作。资源为 zip 压缩包共 372 个文件约 6.95MB以 h 头文件、exe 可执行程序、info 文档、a/lib 库文件及 readme 说明为主结构紧凑且便于在软盘或虚拟机中部署。包内不仅能安装配置 DJGPP 环境还收录了 gcc、ld、cpp、as 等核心工具的手册页方便查阅命令用法。已有 404 人学习适合作为《Linux0.01内核分析与操作系统设计》等课程的辅助工具帮助读者理解无现代系统支持时的程序编译与底层运行机制也可用于复古计算、系统编程教学与历史研究。1. 2025 年为什么还要用 DJGPP 2.04DOS 系统早就远离桌面可 DOS 上的开发需求一直没有消失。维护老式工控机的工程师、复刻经典游戏的爱好者、在 DOSBox 里搭教学环境的学生手上多半有一批 32 位 C 源码希望继续在 DOS 环境里编译运行。DJGPP 2.04 正是这条路径上最完整的工具链它把 GCC、binutils 和一套接近 POSIX 的 C 库搬到 16 位 DOS 上编出来的程序自带保护模式引导从 Windows 的退役命令提示符到 FreeDOS 都能跑。这篇文章会从零搭一套 DJGPP 2.04 环境讲清楚 DPMI 内存模型再列出会卡住新手的五个高频问题最后给出一套调试习惯。2. 搭好 DJGPP 2.04 最小环境四个包、两个环境变量、一条编译命令2.1 DJGPP 2.04 的定位一套把 GNU 工具链搬进 DOS 的发行版DJGPP 是 DOS 下少数仍由 GNU 工具链打底的 C/C 编译环境。所谓 2.04严格说是整个发行版的版本基线对应的是该套件整合的 GCC、binutils、libc 与启动代码的稳定组合。在复古开发群体里大家口中的 DJGPP 基本就是指 2.04 这套基线因为它最后期的稳定性最高遗留资料和第三方库也最全。和 Turbo C、Open Watcom 相比DJGPP 最明显的优势是标准库行为更接近 Linux/Unix。比如 dirent、opendir、readdir 这类 POSIX 接口在 DJGPP 的 libc 里可以直接用许多老 Unix 源码只需改掉文件路径分隔符就能编过。对正在维护 90 年代遗留项目的人来说这一点能省下大量改代码时间。另外DJGPP 的编译产物是 32 位保护模式程序单个进程能使用扩展内存不像 16 位 DOS 程序被 640KB 限制卡死这在处理大数组、大缓冲时体验完全不同。不过 DJGPP 也有代价它依赖 DPMI 服务运行环境里必须能切换保护模式。DOSBox、FreeDOS、Windows 9x 的命令提示符都能提供这种支持纯 DOS 真机上则要由随包分发的 CWSDPMI.EXE 充当 DPMI host。后面第 3 章会专门讲清这层关系这里只需要明确一个问题选 DJGPP 不是因为它的编译命令多花哨而是因为它能把 Unix 风格的老代码以最小改动带回 DOS。2.2 四连解压与两个环境变量不要直接跑 installerDJGPP 2.04 最常见的分发形式是按功能拆分的压缩包核心包包含 DJGPP.ENV 与基础头文件另一个包是编译器本体还有汇编器/链接器包和附加库包。安装的核心思路是把它们解压到同一个根目录再设置两个环境变量。我一般不会去跑包里自带的安装脚本因为脚本会把一堆通配路径塞进 PATH后续和 Open Watcom、MASM 混用时会互相干扰。在 Windows 的命令行或者 DOSBox 里解压命令是同一组。先确保手上有 unzip.exe 或 7z 的 DOS 版本再执行mkdir C:\DJGPP cd C:\DJGPP unzip C:\download\djgpp204_core.zip unzip C:\download\djgpp204_gcc.zip unzip C:\download\djgpp204_binutils.zip unzip C:\download\djgpp204_libc.zip这里压缩包名用占位写法具体以下载到的文件名为准。每个压缩包都必须解压到同一个根目录因为 DJGPP 默认通过 DJGPP.ENV 里的路径拼接规则去定位 include、lib 和 bin目录不一致会让编译器在预处理阶段就报错。解压完成后手动设置环境变量set PATHC:\DJGPP\BIN;%PATH% set DJGPPC:\DJGPP\DJGPP.ENVDJGPP这个变量名不是指整个程序目录而是精确到 DJGPP.ENV 文件本身少写文件名或者写错大小写都会让 GCC 找不到 cpp 预处理程序。PATH里的BIN目录存放 gcc.exe、ld.exe、make.exe、objdump.exe 等工具必须放在最前面否则系统有可能先找到一个无关的 gcc。如果你是在 DOSBox 里跑建议在dosbox.conf的[autoexec]区段提前写好配置而不是每次手动敲[autoexec] mount c: /home/user/dos set PATHC:\DJGPP\BIN;%PATH% set DJGPPC:\DJGPP\DJGPP.ENV c:参数说明mount c: /home/user/dos把宿主机目录映射成 DOS 的 C 盘路径请按实际环境改在[autoexec]里设置环境变量保证每次启动 DOSBox 后工具链直接可用省去反复输入命令的麻烦。这里有一个极其隐蔽的坑DJGPP 所在路径不要带空格C:\Program Files\DJGPP在多数 DOS 环境里会引发奇怪的文件访问失败这是新手最容易碰到又最难发现的坑装包时务必使用纯短路径。2.3 用一条命令验证工具链写 hello.exe 并观察它的文件结构环境变量配好后用一个最小程序验证工具链是否真的能工作。新建hello.c/* hello.c - 验证 DJGPP 2.04 是否进入 32 位模式 */ #include stdio.h int main(void) { printf(DJGPP alive, pointer %d bit\n, (int)sizeof(void *) * 8); return 0; }关键点在sizeof(void *)如果当前确实是 32 位保护模式指针宽度是 4 字节输出pointer 32 bit如果是 16 位实模式编译这个值会变成 2。编译命令与运行结果预期如下gcc -Wall -o hello.exe hello.c hello.exe-Wall打开常规警告能提前暴露指针截断和类型不匹配问题。-o hello.exe指定输出文件名DOS 下不加-o默认也会生成a.exe但与后续调试器配合时显式起名更方便。编译完成后用dir hello.exe看一眼文件大小。DJGPP 的产物通常在 20KB 以上比 Turbo C 生成的 16 位 exe 大不少。这不是编译器浪费空间而是 exe 头部嵌入了一段 16 位 stub 和一些 DPMI 相关的启动数据。若文件只有两三千字节多半不是 DJGPP 编出来的需要回到环境变量检查。最后用gcc -v确认编译器版本与前端的实际路径gcc -v输出里的Target: i586-pc-msdosdjgpp之类字样能帮你判断当前是否拿到了 DJGPP 的 GCC而不是把 Windows 本机的 GCC 误当成了目标。这一步看着啰嗦但是能有效排除“编译器路径不对但命令刚好能执行”的隐患。3. 原生 DPMIDJGPP 为什么能在 DOS 下跑 32 位程序3.1 go32 引导时的 DPMI 协商过程DOS 本身是个 16 位实模式操作系统GCC 编出来的却是 32 位指令两者能接上靠的是可执行文件最前面那段很小巧的启动引导DJGPP 里叫 go32。程序被系统加载后这段实模式代码先接管控制权检查当前有没有可用的 DPMI 服务有就直接进入保护模式没有则尝试把 CWSDPMI.EXE 加载进来再进入保护模式。整个过程对 C 语言层是透明的在 main 函数被调用之前处理器已经工作在 32 位保护模式下了。这里最容易混淆的一点DJGPP 没有自己实现完整的 DPMI而是坐等环境提供。Windows 9x/Me 的 DOS 窗口自带 DPMI 服务所以当年的 exe 在 Windows 下跑得挺好但把同一个 exe 拷到没有加载 EMM386 的纯 DOS 真机上可能会直接报错退出。区别其实不在编译器而在目标机有没有 DPMI host。不同环境下 DPMI host 的来源不同表现也稍有差别运行环境DPMI host 来源注意事项Windows 9x 命令提示符系统内置兼容性较好可用内存较多Windows NT/2000 命令提示符系统内置 NTVDM老 exe 可能被 NTVDM 限制DOSBox / 虚拟机模拟层或 CWSDPMI需要在 PATH 里能找到 cwsdpmi.exe纯 DOS 真机CWSDPMI 或 EMM386确认扩展内存管理和 HIMEM 已加载这张表不是用来背的而是定位问题。遇到“同一份 exe 换个机器就起不来”先别怀疑编译器去确认当前环境到底是谁在为程序提供保护模式切换很多老程序的诡异故障最后都归结为 DPMI host 来源不一致。3.2 32 位平坦内存下 malloc 的真实上限进入保护模式后C 语言的指针是完整的 32 位线性地址空间理论上有 4GB。但问题是DOS 环境里线性地址空间和物理内存不是一回事。DJGPP 的 malloc 底层调用 DPMI 的内存分配功能DPMI host 根据自己管理的扩展内存池决定给多少。说白了malloc 返回 NULL 并不代表机器内存不够而是 DPMI host 没能分出一块足够大的连续线性地址区间。写个压力测试可以直接观察到这个边界/* memtest.c - 一步一步测试 DJGPP 能把多少内存交给 malloc */ #include stdio.h #include stdlib.h int main(void) { unsigned long blocks 0; while (malloc(1024 * 1024)) blocks; printf(allocated %lu MB before fail\n, blocks); return 0; }逻辑说明每次申请 1MB直到 malloc 失败或系统资源耗尽。循环跳出后打印实际能拿到的兆字节数。注意这个数字不是机器内存总量而是 DPMI host 愿意给这个进程的连续分配量。参数说明1024 * 1024一次申请一兆字节blocks用unsigned long防止计数溢出。在多任务 DOS 扩展器比如 DESQview 一类的环境里这个测试结果差别很大千万不要拿它当物理内存检测工具。若你的程序真的需要一次性申请大块内存常见的做法是启动时一次性malloc一个大池子再在自己的代码里做内存池管理避免反复向 DPMI 要零碎内存。3.3 x87 浮点模拟与 -mno-80387 的取舍DJGPP 默认按装有 x87 协处理器来生成浮点代码这在 486DX 以后的机器和 DOSBox 里都没问题但在 486SX、早期 386 或某些模拟器精简模式下程序一碰到浮点运算就异常退出典型症状是SIGILL。这不是库函数坏了而是 CPU 没有 x87 单元执行到fld、fstp这类指令时直接触发非法指令异常。常见的处理手段是在编译时显式关闭硬件浮点gcc -O2 -mno-80387 -o calc.exe calc.c-mno-80387让 GCC 不再生成 x87 指令浮点运算改用编译器插入的软浮点函数调用代价是速度明显下降加法和乘法可能慢一个数量级。如果目标机器只是偶尔跑一下批处理程序这通常是可接受的如果要做密集的数值计算最好先在模拟环境里确认目标 CPU 是否支持硬件浮点而不是一上来就关掉。还有一个不太起眼但容易踩的点某些老的 DOS 游戏工程喜欢用 long double 类型。在软浮点模式下long double 的模拟开销远大于 double运行时差异非常明显。保守起见移植老代码时可以把 long double 全局替换成 double再对比运算结果误差一般不会影响到游戏逻辑。4. 链接 COFF 与工具链选型DJGPP 和 PE 是两套思路4.1 DJGPP 的可执行格式COFF、crt0 与 ld 的分工DJGPP 的编译产物不是 Windows 的 PE 格式也不是 Linux 的 ELF而是 DJGPP 定制的 COFF 变体。编译得到的目标文件是 COFF 节区结构链接器把 crt0.o、libc 和用户目标文件合并再由 stub 把最终产物包装成 DOS 可执行文件。这一步对日常开发是透明的但排查链接错误时得知道报错信息里出现的节区名如 .text, .data, .bss和 ld 脚本有关和 PE 格式里的节区意义不完全相同。用 binutils 自带的 objdump 可以观察产物内部结构objdump -h hello.exe-h参数打印节区头信息你会看到 text、data、bss 等节区的地址与大小。文件头里 DJGPP 特有的签名能让你立刻确认这是 DJGPP 产物而不是别的 DOS 编译器生成的 MZ 格式。手动编写链接脚本非常罕见只有在追求极小的 DOS 启动镜像时才会动-Wl,--script普通开发用默认脚本即可。4.2 在 Linux 上交叉编译 DJGPP 程序一条命令出 exe很多老程序员维护旧项目时主力机器早已是 Linux。DJGPP 官方工具链虽然是为 DOS 设计的但同样有对应的 Linux 交叉编译版本。常见的交叉编译前缀是 i586-pc-msdosdjgpp工具名会带上这个前缀。确认交叉编译器装好后编译命令和本机 GCC 几乎一致i586-pc-msdosdjgpp-gcc -O2 -Wall -o hello.exe hello.c file hello.exefile是 Linux 下的文件类型识别命令如果输出里包含 DOS/Windows 可执行程序说明产物已经被 DJGPP 的 stub 包装过。-O2在这里值得多说一句DOS 环境资源有限开优化能显著缩小代码体积但若兼容老机器优先用-Os优化体积。对复古游戏这类目标体积和内存占用往往比运行速度更敏感所以交叉编译时有多少老编译器选项都可以照搬到这条命令上。4.3 和 Open Watcom、Turbo C 怎么选一张对比表接手老项目时经常需要在 DJGPP、Open Watcom、Turbo C 之间做选择。三个工具链都能编 DOS 程序但侧重点差别很大工具链程序位数标准库风格调试工具适合接手的项目DJGPP32 位保护模式接近 POSIX能跑不少 Unix 代码fsdb / GDB老 Unix 移植、网络/文件处理类Open Watcom16/32 位可选自有 C/C 库兼容性一般自带调试器需要同时出 16 位和 32 位版本Turbo C16 位经典 C89库较简陋Turbo Debugger简单教学项目、小工具我的习惯是先看源码是否依赖 unistd.h、dirent.h、socket 这类 POSIX 接口。若依赖较多直接选 DJGPP因为它的 libc 对这些接口覆盖最好反之如果目标程序必须在 8086 上运行没法用保护模式那就只能走 Turbo C 的 16 位路线。Open Watcom 适合需要让同一个源代码分别产出 16 位和 32 位两个版本的情况但在 POSIX 兼容上没有 DJGPP 省心。5. DJGPP 2.04 避坑指南5 个高频问题与排查流程跟 DJGPP 打交道这几年我总结出的排查顺序是先环境变量、再 DPMI、最后才看代码。下面这五个问题基本覆盖了新手从安装到链接会遇到的绝大多数故障每一条都按现象、原因、解决的顺序写清楚。5.1 gcc 报“cant find cpp”先查 DJGPP 环境变量现象在一台全新机器上装完 DJGPP刚敲gcc hello.c就报cant find cpp或者cannot find libgcc看起来像是压缩包没解压完整。原因DJGPP环境变量没有指向正确的 DJGPP.ENV 文件GCC 通过它去定位预处理器、头文件和标准库。变量漏掉文件名或路径里带了空格都会让工具链找不到它需要的配套文件。这个问题在 Windows 命令提示符里尤其常见因为很多教程只写了set DJGPPC:\DJGPP少了.ENV后缀。解决执行echo %DJGPP%确认输出确实是C:\DJGPP\DJGPP.ENV这类完整路径如果你是在 Windows 命令提示符里调试注意环境变量是会话级的重开窗口后需要重新set。DOSBox 用户则把配置写进[autoexec]段别依赖手动输入因为手动输入很容易在路径转换时把反斜杠写丢。5.2 换了环境后程序起不来CWSDPMI 不在 PATH现象同一个 hello.exe在 Windows 9x 的命令提示符里正常运行复制到 FreeDOS 或纯 DOS 后一运行就退出甚至没有任何提示好像 exe 文件损坏了一样。原因DJGPP 程序启动时要找 DPMI host。Windows 9x 的 DOS 窗口系统自带纯 DOS 下就需要 CWSDPMI.EXE 在 PATH 里或者当前目录下能找到它。很多人只拷了 hello.exe忘了把 cwsdpmi.exe 带上程序找不到 DPMI 服务go32 引导阶段直接失败。解决把整个 DJGPP 发行包里的 cwsdpmi.exe 复制到 exe 同目录或者放到 PATH 中的任意目录也可以用 DJGPP 自带 stubedit 工具把 cwsdpmi 嵌入 exe这样单个文件就能在纯 DOS 下运行。后一种做法适合分发给终端用户但会增大文件体积适合做正式发布版。5.3 malloc 大块内存失败DPMI host 分配碎片化现象程序里malloc(几十MB)有时成功有时失败而mem命令显示可用 XMS 还有不少排除了“内存不够”这个常规解释让人怀疑是不是 libc 移植有 bug。原因DPMI host 按描述符分配内存它对连续线性地址区间的管理有自己的碎片策略多次申请-释放后不见得还能给出一个很大的连续块。这不是 DJGPP 的 bug而是保护模式 DOS 下的固有规律在很多 DPMI 实现里都有同样的表现。解决程序启动早期就申请大块内存尽量一次要够后续由自己的分配器切小块避免“用完就 free过一会儿再申请更大块”这种释放模式。要观察描述符分配情况可用 DJGPP 的_go32_dpmi_allocate_memory底层函数打印每次实际分到的线性地址定位到底是谁卡住了分配。5.4 浮点指令非法目标 CPU 没 x87 协处理器现象程序在开发机上跑得好好的拿到老 486SX 或某些模拟器精简模式上一执行浮点运算就报SIGILL或显示非法指令。程序运行到一半突然中断没有别的报错信息比这更让人摸不着头绪。原因默认编译会生成 80387 浮点指令目标机没有对应硬件单元也没提供模拟CPU 执行时触发非法指令异常。这类问题很容易被误判为内存问题因为表现同样是程序突然中断而且不固定发生在同一段代码。解决对目标平台重新编译加-mno-80387使用软件浮点也可以先用 CPU 检测代码判断当前处理器是否有 x87再在运行时决定是否执行硬件浮点路径。选择-mno-80387后一定要重跑一遍数值用例误差会因软浮点实现而略有改变。5.5 undefined reference to __main启动文件版本混用现象编译时大量出现undefined reference to __main或者undefined reference to _go32_dpmi_allocate_memory一类链接错误。看起来像是代码里的函数名写错但其实和用户代码无关。原因DJGPP 编译器会在 main 函数前插入一段初始化代码__main它由配套的 libc/startup 提供。若你用了新版 GCC 却链接到旧版 libc或手动指定了-nostartfiles就会缺这一定义。这类错误和常见的 PE 项目缺导入库是两码事别往 Windows 方向查。解决确认 gcc.exe、ld.exe、libc 三者来自同一套 DJGPP 2.04 基线不要混用旧版 DJGPP 2.0x 的库尽量别手动指定-nostartfiles除非你已经知道要用自己的启动代码并能补上__main调用。可通过gcc -v和ld --version对比版本号是否匹配。6. 在 DOS 里把程序调稳GDB、fsdb 与启动标志调试 DOS 程序比调试 Linux 程序麻烦但 DJGPP 提供了裁减过的 GDB以及一个轻量级调试器 fsdb。日常调试我一般用 GDB 做断点与变量查看用 fsdb 做单步和内存观察。gdb hello.exe (gdb) break main (gdb) run (gdb) next (gdb) print totalGDB 的 DOS 版本不支持 attach 到已经运行的进程调试要从头跑但支持 core 文件分析程序崩溃时生成的 core能用gdb hello.exe core直接查调用栈。fsdb 启动更快占用内存小适合在资源受限的机器上用常用命令与 GDB 类似但符号表处理不如 GDB 完整。还有一个长期实用的启动标志技巧。DJGPP 程序在主函数之前会读取全局变量__crt0_startup_flags控制启动阶段行为。常见需求是程序退出后屏幕内容不要被清掉方便查看运行结果/* keep_screen.c - 程序退出后保留屏幕输出 */ #include crt0.h int __crt0_startup_flags __crt0_remember_screen;这段代码必须在 main 函数前定义并初始化链接器才会把变量放在可执行文件的启动数据区。加了这一行后无论你是从命令行跑还是调试器里退出最后的 printf 输出都会留在屏幕上不用截屏或滚动缓冲。最后说一个我自己的教训。最早在 DOSBox 里折腾 DJGPP折腾了半天gcc始终找不到头文件甚至怀疑压缩包没解压完整后来才发现是DJGPP环境变量少写了.ENV后缀等于没设置。现在不管换到哪台机器第一件事永远是echo %DJGPP%。环境变量正常再看别的别一上来就查源码玄学这是少走弯路的顺序希望帮到你。本文还有配套的精品资源点击获取