简介DJGPP 2.04 是一套面向 DOS 环境的开源 C/C 开发工具链由 GNU 工具移植而来适合需要在 DOS 下编写、编译与调试程序的开发者以及研究早期操作系统和复古计算场景的读者使用。压缩包共 372 个文件、约 6.95MB以 127 个 h 头文件、52 个 exe 可执行程序和大量 info/readme 文档为主同时包含汇编器、链接器、Make、库文件与配置脚本基本覆盖从源码到可执行文件的完整构建流程。已有 404 人学习下载体积虽小但内容相当完整。借助其中打包的 GCC 编译器、GNU 调试工具和示例代码读者不仅能在 DOS 环境下搭建 GNU 编译环境也能通过配套文档理解早期 Linux 内核分析、操作系统教学中的实际动手环节体会在没有现代操作系统支持时完成系统软件开发的思路。1. 为什么 2025 年还在折腾 DJGPP 2.04老 DOS 程序员的后悔药如果你最近在翻老代码或者逆向古董软件大概率撞上过 DJGPP 这个词。它是 DOS 下最完整的 32 位 C/C 开发工具链本质是 GCC 的 DOS 移植版用它在实模式下启动、在保护模式下跑 32 位程序专门解决 16 位编译器放不下大内存、跑不动复杂运算的老大难问题。DJGPP 2.04 是其最后一个稳定大版本至今仍是维护老项目、研究 DOS 程序内部机制、甚至写复古 demo 的主力工具。适合三类人一是手里有十几年前 DOS 源码必须重新编译的维护者二是教学场景里想让学生看真实寻址和中断处理的老派教师三是研究老游戏和 DOS 可执行文件结构的逆向爱好者。这篇笔记就是按我落地一个实际项目的顺序从环境搭建、结构原理、编译参数到坑点一次说清保证你照着走能跑通。2. DJGPP 是什么从 GCC 移植到 32 位保护模式的完整链路2.1 核心架构GO32V2 扩展器、CWSDPMI 和 DPMI 的关系DJGPP 不是把 GCC 直接搬到 DOS 就完事的玩具它的核心难点在于DOS 本身只能寻址 1MB而 DJGPP 编译出的程序是 32 位扁平寻址能访问多达 4GB 内存。这个跳跃靠的是GO32V2 扩展器它才是真正让 32 位程序能在 DOS 上活下来的底层机制。GO32V2 是个 DOS 可执行扩展器负责在程序启动时做三件事把 CPU 切换到 32 位保护模式、建立描述符表、把程序装载进扩展内存。启动后程序拿到的是一个完整的保护模式环境可以随心所欲用 32 位寄存器和线性地址。但它不是凭空变出内存而是依赖 DPMIDOS 保护模式接口服务——DJGPP 自带的 CWSDPMI 就是一个最小的 DPMI 服务端在内核没有 DPMI比如纯 MS-DOS时自动顶上。换句话说DJGPP 程序是这么跑起来的先以实模式小程序启动由 GO32V2 接管 CPU切换保护模式加载你编译好的 32 位代码再跳进去执行。整个过程是自动的但理解它才能明白后面所有坑的根源——比如为什么有的程序在 Windows 9x 命令行能跑在纯 DOS 下反而出错以及为什么某些扩展内存管理软件和 DJGPP 程序会打架。2.2 工具链完整清单编译器、汇编器、链接器和辅助工具的协作DJGPP 2.04 不是单文件编译器而是一整套工具链。我实际重新部署时装过这套组件gcc.exeC/C 编译器实际是 DJGPP 移植版 GCC 2.95.3这是让我意外的地方版本比较老但针对 DOS 优化得很好。as.exeGNU 汇编器直接把汇编源码变成 COFF 目标文件。ld.exeGNU 链接器负责把目标文件链接成最终的可执行文件。stubedit.exe修改 DJGPP 可执行文件与扩展器相关的头部信息。redir.exe解决 DOS 重定向问题的辅助工具后面专门讲。patching tools比如 patch.exe在老项目里经常要打补丁。库文件libc.a标准 C 库、libstdc.aC 库、libm.a数学库以及大量头文件。实际运行机制是你在命令行输入gcc -o hello hello.cgcc 先调用 cpp 展开头文件和宏然后让 cc1 生成汇编再让 as 组装成 .o最后 ld 链接成 COFF 格式的可执行文件。但注意这还不是最终能在 DOS 上跑的 exe——链接器输出的是一个不完全的程序还必须经过stub扩展器存根处理把 GO32V2 的启动代码拼接在前面才能生成真正的可执行文件。DJGPP 的 gcc 驱动在链接时自动加了这一层所以你平时感觉不到。这个编译流程对应的常见命令是gcc -O2 -Wall -o hello hello.c逻辑说明这条命令做了完整编译三步曲-O2 开启优化-Wall 显示所有警告。参数说明-o 指定输出文件名如果写成gcc -c hello.c就只生成 hello.o 目标文件常用于分模块编译最后用gcc -o app main.o util.o链接所有目标模块。注意用-O2而不是-O3因为 DJGPP 的 GCC 2.95 在 -O3 下容易产生危险的内联老项目经常踩这个雷。2.3 版本辨析DJGPP 2.04 和 2.04 beta、2.05 的边界在哪里网上能搜到 DJGPP 2.04 的正式版也有 2.04 beta、以及年份更新的 2.05 分支WATCOM 相关的东西也常被误归进 DJGPP。我的建议是正式追稳定就用 2.04 发布版它的 GCC 内核是 2.95.3libc 版本稳定在 2.04。2.05 主要是社区维护的新版支持了更新的头文件和更好的 C 标准兼容但很多老项目在 2.04 上编译得好好的换 2.05 反而因为头文件变更把代码改坏了。另一个常见误解是拿 DJGPP 和 Open Watcom 比。DJGPP 是 GNU 血统、依赖扩展器Watcom 直接自带 DOS4G 风格扩展器两者的可执行文件结构不同链接脚本差异很大老项目里不要乱切换编译器代码对编译器特性的依赖比想象中大得多——尤其是内联汇编和段属性这种底层细节两个编译器写法完全不同。3. 搭建可用的 DJGPP 2.04 环境下载、目录布局与第一个 Hello World3.1 完整目录结构与环境变量配置下载 DJGPP 2.04 发行包后解压得到的目录布局大致如下以 djgpp 为根目录为准目录内容bin/所有可执行工具gcc.exe、as.exe、ld.exe 等include/C/C 头文件按 GNU 风格分 cpp 子目录等lib/链接库文件libc.a、libm.a、crt0.o 启动代码lib/gcc-lib/GCC 内部运行时库和规范文件info/GNU 文档man 风格share/文档和示例代码contrib/第三方移植代码和辅助工具环境变量重点设置两个一个是DJGPP它的值不是指向 djgpp 根目录而是指向根目录下特定的环境文件DJGPP.ENV这是新手常踩的坑——网上有些教程说设置 DJGPP 为根目录那是不对的DJGPP.ENV 里才存着路径映射和默认编译器行为。另一个是PATH把 djgpp\bin 加进去让命令可以直接敲。我通常把环境变量写进 DOS 批处理文件 djgpp.bat内容如下echo off set DJGPPE:\DJGPP\DJGPP.ENV set PATHE:\DJGPP\bin;%PATH%逻辑说明这个批处理把 DJGPP 环境变量指向 E 盘 DJGPP 目录下的 DJGPP.ENV 文件同时把编译工具路径放进 PATH。参数说明如果你解压在 D:\djgpp把路径改成实际位置最好放在8.3 短文件名路径下不要放在带空格或长文件名的目录因为 DJGPP 内部对长文件名的处理逻辑在纯 DOS 下有兼容性问题。验证环境是否正常在命令行输入gcc -v 21 | more正常会输出 GCC 版本 2.95.3、配置目标为 i586-pc-msdosdjgpp 等信息。注意用more分页防止输出滚屏在 Windows 命令行窗口可以不用。3.2 Hello World 的编译运行全程演示写个最简单的 C 程序测试工具链#include stdio.h int main(void) { printf(Hello DJGPP\n); return 0; }这段代码没什么特殊纯粹验证从预处理到链接的整个工具链通路是否完整。保存为 hello.c执行编译命令gcc -O2 -Wall -o hello.exe hello.c编译完成后、运行前用 file 命令分析生成的程序file hello.exe正常情况下输出类似hello.exe: MS-DOS executable, MZ for MS-DOS ... DJ2K stub说明这个可执行文件已经被正确加上了 GO32V2 的扩展器存根而不是裸的 COFF。DJGPP 程序在纯 DOS 下运行需要 DPMI 服务CWSDPMI 会在没有 DPMI 的 DOS 上自动加载。运行hello.exe输出 Hello DJGPP。到这里环境确认可用。但这里有个隐藏问题如果你在 Windows 9x/Me 的命令行窗口里运行背后有系统自带的 DPMI 支持如果在纯 DOS 下运行CWSDPMI 会出场而它需要足够的内存和磁盘空间写临时交换文件否则启动直接失败。3.3 stubedit 和文件头部DJGPP 程序为什么对内存要求有差异DJGPP 可执行文件的头部由 stubedit 控制它决定程序启动时的默认行为。你可以查看和修改这些参数stubedit hello.exe这是个交互式界面最关键的两项是运行模式run mode默认是 CWSDPMI 自动模式可以改成直接使用系统 DPMI、或不使用 DPMI 的实模式运行大多数程序不能这样跑。最大内存maximum memory指定给程序的最大内存默认通常很大但某些老游戏需要主动调低来避免内存检测失败。最小内存minimum memory程序启动时必须保证的最小内存调高会导致环境内存不够时拒绝启动。动态内存dynamic memory决定程序能使用多少扩页内存。历史上我维护过一个 DOS 下的科学计算程序换机器后在内存 8MB 的工控机上跑不起来后来用 stubedit 看发现是默认最小内存要求过高。把最小最低内存改成更小的值之后程序就能启动了因为老机器在 DOS 下整个内存不到 8MB 时DJGPP 的启动代码计算内存不够就拒绝执行。4. 编译参数与内存模型DJGPP 2.04 的真实选型逻辑4.1 保护模式下的平坦内存模型和指针寻址细节DJGPP 程序运行在保护模式下内存模型是平坦的代码段数据段都从基地址 0 开始大小为 4GB 的线性地址空间。这一点和普通 32 位程序类似但有一个关键不同程序运行在 DOS 中访问硬件必须回到实模式或调用 DPMI 服务。这意味着纯 C 程序可以自由 malloc 大量内存可达数百 MB但操作硬件端口、访问常规内存地址、调用 DOS 中断时必须使用特殊封装。常见做法是直接用_dos_ds等宏配合farptr库访问物理内存。例如读取内存 0xB8000 处显存的场景#include sys/farptr.h #include go32.h unsigned short read_video_mem(unsigned offset) { unsigned short val; _farnspokew(_dos_ds, 0xB8000 offset, val); return val; }逻辑说明_farnspokew从指定段和偏移读取一个 16 位值这里 _dos_ds 是 DOS 数据段选择子0xB8000 是彩色文本模式显存的物理起始地址。参数说明_farnspokew 函数参数顺序是段选择子, 偏移地址, 指向要接收数据的指针常见错误是把参数顺序写反。4.2 编译优化参数-O2、-march 与内存模式的取舍DJGPP 的 GCC 2.95.3 支持很多 Pentium 时代指令集选项在维护老项目时我通常会显式指定 CPU 型号而不是靠默认值gcc -O2 -marchpentium -Wall -o myprog.exe myprog.c-marchpentium针对 Pentium 指令集生成代码。对古董 486 设备请改成 -marchi486否则会有非法指令错误。-marchi386 未优化代码比 i586 慢很多而很多年代久远的 DOS 程序实际跑在 386SX 上这时 -O0 反而运行更稳。-O2 是 DJGPP 2.04 时代优化效果和稳定性最好的档位-O3 在复杂浮点运算时可能引入精度差异。-funroll-loops 可以增加速度但程序体积明显膨胀不适合 16MB 以下内存的老机器。链接时的内存对齐参数gcc -O2 -Wl,--heap1048576 -Wl,--stack262144 -o app.exe main.o-Wl 会把参数传给链接器--heap 设置堆大小字节--stack 设置栈大小。这个在 DJGPP 里格外重要因为默认栈可能不够特别是 C 里大规模递归时而默认堆可能太大在内存紧张的老电脑上导致启动失败。建议明确指定不要信任默认值。4.3 C 特有问题libstdc 版本与模板代码的兼容性DJGPP 2.04 自带的 C 库是 libstdc 3.0 时代之前的老版本C 标准和现代编译器有差距。历史经验是把现代代码挪到 DJGPP 下编译会遇到大量异常规范和 std:: 命名空间缺失问题。比如在 C11 下随便用的std::auto_ptr在 DJGPP 里应该换成裸指针管理std::string的很多方法存在但实现老vectorbool的引用行为也和现代标准不同。更头疼的是 GNU 旧版头文件和 C 库的头文件有冲突。实现策略很简单要么代码里为 DJGPP 做#ifdef保护用旧式 C 风格字符串函数sprintf、strcpy代替 C stream要么放弃 C用纯 C 重写——很多老游戏后期的修修补补确实是纯 C 做的这也是 DJGPP 项目 C 代码占比反而低的原因。5. DJGPP 2.04 避坑指南编译链接、内存与运行环境的六个真实问题5.1 编译链接报错找不到 crt0.o 与启动文件路径混乱现象在命令行执行gcc -o hello hello.c时直接报错cannot find crt0.o或startfile not found甚至连标准头文件都找不到。原因最常见的是 DJGPP 环境变量设置错误——把 DJGPP 指到了根目录没指向 DJGPP.ENV或者路径包含长文件名导致旧版 GCC 的规范处理找不到库路径。解决确认环境变量精确指向DJGPP.ENV文件位置目录名改成 8 字符以内。还可以用gcc -v看具体搜索路径如果发现 include 和 lib 的搜索路径都不是实际位置就检查是否多余设置了这个LIBRARY_PATH或C_INCLUDE_PATH有就删掉。5.2 程序在纯 DOS 下启动时黑屏或卡死CWSDPMI 无法初始化现象程序在 Windows 9x 命令行窗口运行正常换到纯 DOS如 MS-DOS 6.22启动就直接黑屏或死机。原因纯 DOS 下 CWSDPMI 需要一块连续的扩展内存来建立 DPMI 环境如果被 EMM386、QEMM 等内存管理器占用了高端内存映射或 BIOS 提供的扩展内存信息不正确DPMS 初始化失败。解决先用mem看当前内存布局确认有连续 XMS 可用。然后尝试在 CONFIG.SYS 中把 EMM386.EXE 的NOEMS改成RAM给 DPMI 留出空间。最后用 stubedit 把运行模式改为CWSDPMI with System DPMI让 DJGPP 程序先把 CWSDPMI 加载进内存再交给系统 DPMI。5.3 运行时报错 Out of memory但物理内存明明足够现象在内存 32MB 的 486 上跑 DJGPP 程序显示 out of memory程序拒绝启动。原因DJGPP 需要的是连续的扩展内存块如果内存碎片化严重或者按 XMS 规范只能申请到小的块程序就会认为内存不足。还有一个原因是 CWSDPMI 会尝试创建交换文件而磁盘剩余空间不足导致初始化失败。解决在用 stubedit 检查程序的最小内存要求基础上把 DOS 启动配置中加载的 TSR 程序鼠标驱动、光驱驱动挪到高端内存释放更多常规和扩展内存。同时检查 C 盘剩余空间CWSDPMI 可能要写一个临时交换文件。对于内存很少的机器可以试试在 stubedit 里把zero flag memory关掉有时能减少一定启动内存需求。5.4 程序的 stdout 输出无法重定向到文件DJGPP 的 stdout 重定向问题现象执行myprog.exe out.txt生成的 out.txt 是空的但屏幕上有输出。原因DJGPP 的可执行程序通常被 stub 包装标准输出重定向依赖底层 DPMI 环境提供的文件处理接口很多 DOS 环境不支持对扩展器 stub 部分重定向。解决使用 DJGPP 自带的redir工具正确命令是redir myprog.exe out.txtredir 会接管输出再写文件。另外 C 程序里用 freopen 重定向 stdout 也能解决问题只是不够方便我一般写脚本时优先用 redir 方式。5.5 浮点运算结果异常旧式 x87 指令和中途精度丢失现象一个常规数学函数比如 sqrt、sin计算结果的精度和预期不一致尤其在 486 DX2 或 Cyrix CPU 上。原因GCC 2.95 的浮点代码生成默认使用 x87 协处理器指令而 486 时代部分 CPU 的浮点实现有历史 bug另外 DJGPP 2.04 的 libm 实现的数学函数精度和现代版本有差别。解决强制使用软件浮点模拟库链接时加-lsoftfloat你的 DJGPP 发行版需要包含它。代码里也可以用-ffloat-store强制浮点结果存到内存再读取避免中间值的 80 位扩展精度与预期 64 位不一致。我维护的物理计算程序最终就是用 -ffloat-store 解决的所有 CPU 上结果不一致问题。5.6 链接时提示 undefined reference to__djgpp_section_init等内部符号现象链接自己编写的目标文件时报缺失 DJGPP 内部符号。原因链接顺序错误导致库文件没有被正确查找。DJGPP 的 gcc 驱动在链接时把 crt0.o 加入顺序有讲究如果你手动用 ld 链接就缺少关键启动对象。解决不要手动调用 ld直接用 gcc 做最终链接gcc -o app.exe a.o b.o c.o -lm。必须用 ld 的场合参照 DJGPP 工具链手册手动把crt0.o、libc.a、libgcc.a按正确顺序写全。6. 进阶技巧把 DJGPP 2.04 当成研究 DOS 程序的入口6.1 使用 DJGPP 自带的 info 文档与物理内存调试挂钩除了编译DJGPP 还提供了info格式的完整文档里面最有价值的是libc 库的完整 API 参考和FAQ。老项目遇到奇怪问题时直接搜索 info 文档经常会找到答案。另一个实用的技巧是用add-symbol-file配合gdbDJGPP 移植版来调试保护模式程序但这个对新手来说门槛较高。实际上我更推荐先学会使用物理内存访问宏走通基本流程#include sys/farptr.h #include go32.h void peek_poke_example(void) { unsigned char value; _farnspeekb(_dos_ds, 0x400, value); /* 读取 BIOS 数据区 0x400 处 */ _farnspokeb(_dos_ds, 0x400, value | 0x01); }逻辑说明_farnspeekb从给定段和偏移读取一个字节_farnspokeb写入一个字节。参数和前面的 nspokew 一样第二组是物理地址。这组接口是 DJGPP 下直接访问底层内存的基本功。6.2 调用 DOS 中断和实模式回调的完整姿势DJGPP 里调用 DOS 中断有专门的封装需要构造__dpmi_regs结构体并调用__dpmi_int#include dpmi.h #include go32.h int dos_get_clock(void) { __dpmi_regs r; r.x.ax 0x2C00; /* DOS 获取时间中断 */ __dpmi_int(0x21, r); return r.h.ch * 3600 r.h.cl * 60 r.h.dh; }逻辑说明r.x.ax 是 AH0x2C 和 AL0x00调用 DOS 21h 中断后返回时间存放在 CH小时、CL分钟、DH秒寄存器。参数说明__dpmi_int 第一个参数是中断号第二个是寄存器状态的输入输出结构。注意保护模式程序里不要直接调用 int 指令必须走 __dpmi_int 或 int86 封装否则 CPU 会因特权级错误崩溃。进阶一点如果需要让 DOS 环境回调你的保护模式函数比如时钟中断处理就要用__dpmi_allocate_real_mode_callback_iret分配实模式回调地址。这块操作复杂度较高项目正文没有展开但如果你研究 DOS 游戏时钟驱动迟早会遇到。6.3 宏替换技巧用 -D 参数在编译期适配 DOS 环境维护跨平台老项目时最常见的做法是在编译命令里用-D给代码传宏。我维护一个同时需要 DJGPP 和 Linux 编译的计算程序时会在代码里写#ifdef DJGPP分支然后 DJGPP 侧编译加-DDJGPP。这比维护两份源码高效得多也能避免条件编译头文件在不同编译器下行为不一致带来的陷阱。6.4 一个真实调试教训stub 的「最大内存」参数影响 malloc 上限的诡异行为早年调一个用 DJGPP 编译的大规模图论程序分配 64MB 内存时有时候成功有时候失败。后来反复排查确认与编译优化无关而是 stub 头部里 max memory 参数默认值不够高。打开 stubedit 手动把最大内存调大到 128MB 之后malloc 1024 * 1024 * 100 就稳定成功了。从那以后我每次用 stubedit 都会强制把所有内存参数明确写一遍不让它用默认值——宁可多一行命令也不让诡异的内存分配问题消耗半天时间。希望帮到你。本文还有配套的精品资源点击获取