中国DOS联盟

处理Windows 95的长文件名中断详解 很多朋友在DOS环境下写过程序，而且有许多和文件处理有关。众所周知， DOS下的文件名为8.3的格式，而Windows 95开始使用长文件名格式，以前的 DOS下的程序只能按8.3格式来处理这些长文件名，读取文件或目录名时还好， 最多只是看起来有些不顺眼（都变成PROGRA~1、MYPROD~3.EXE这样的文件名 了），要创建新的目录和文件时就麻烦了，因为以前的DOS下的开发环境（如 Tubro C 2.0, Borland C++ 3.1, Turbo Pascal等）没有处理长文件名的 函数，所有的长文件名在以前的函数中都被截尾处理了。找了一些资料，发现 Windows 95提供了处理长文件名的中断，翻译并整理成文，希望对大家有点 帮助。 本文介绍的所有功能都是通过INT 21H来调用的。 Windows 95是通过21H号中断的71H子中断来处理长文件名的，列表如下： AL值 功能 ===== ========================================== 0DH 重置驱动器 39H 创建子目录 3AH 删除子目录 3BH 改变当前目录 41H 删除文件 43H 读取/设置文件属性 47H 得到当前目录 4EH 查找第一个符合条件的文件(findfirst) 4FH 查找下一个符合条件的文件(findnext) 56H 移动（改名）文件 60H TRUENAME 6CH 创建/打开文件 A0H 读取卷信息 A1H 结束文件查找(findfirst/findnext) A6H 读取文件信息 A7H 时间转换 A8H 产生短文件名(8.3格式) A9H 服务器创建/打开文件 AAH 开始/结束SUBST 中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 说明: 如果返回出错代码7100H，说明不支持此功能，将调用老式的中断 为与老版本DOS兼容(7.0以前)，在调用前先将CF置位以确认在退出 时它被置位 另外还有几个功能是未公开的：AL=A2H，A3H，A4H，A5H，其中AL=A2H的 功能已知，与AL=4FH功能类似，这几个功能是Windows内部使用的，在本文就 不介绍了。 一、重置驱动器 入口：AX = 710DH CX = 0000H 将文件系统缓冲区(buffer)实际写盘，并重置驱动器 0001H 将文件系统缓冲区(buffer)和缓存(cache)实际写盘， 并重置驱动器 0002H 重新挂接DriveSpace卷 DX = 驱动器号（00H = A:，01H = B:，等等) 出口: CF清零 对应老式的调用：AH=0DH 二、创建子目录 入口：AX = 7139H DSX -> 长目录名（ASCIZ串） 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 对应老式的调用：AH=39H 三、删除子目录 入口：AX = 713AH DSX -> 要删除的长目录名（ASCIZ串） 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 对应老式的调用：AH=3AH 四、改变当前目录 入口：AX = 713BH DSX -> 要设为当前目录的长目录名（ASCIZ串） 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 对应老式的调用：AH=3BH 五、删除文件 入口：AX = 7141H DSX -> 要删除的文件的长文件名（ASCIZ串） SI = 通配符和属性标志 0000H 不支持通配符，搜索属性也被忽略 0001H 支持通配符，只有名字和属性匹配的才删除 CL = 搜索属性 CH = 必匹配(must-match)属性 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 对应老式的调用：AH=41H 六、读取/设置文件属性 入口：AX = 7143H DSX -> 文件名（ASCIZ串） BL = 00H 读取属性 返回：CX = 文件属性 01H 设置属性 CX = 文件属性 02H 读取压缩文件的物理大小 返回：DX:AX = 文件的实际使用磁盘空间字节数 03H 设置最后写入日期/时间 DI = 新的最后写入日期 CX = 新的最后写入时间 04H 读取最后写入日期/时间 返回：DI = 最后写入日期 CX = 最后写入时间 05H 设置最后访问日期 DI = 新的最后访问日期 06H 读取最后访问日期 返回：DI = 最后访问日期 07H 设置创建日期/时间 DI = 新的创建日期 CX = 新的创建时间 SI = 百分秒数 08h 读取创建日期/时间 返回：DI = 创建日期 CX = 创建时间 SI = 百分秒数 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 成功时返回值请参看本小节的“入口”部分 对应老式的调用：AH=43H 请参考：附一、附二、附三 七、得到当前目录 入口：AX = 7147H DL = 驱动器号 (00H = 当前驱动器，01H = A:，等等） DS:SI -> 用于存储目录名（ASCIZ串）的内存区 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 目录名将存储于DS:SI指向的内存区 说明：返回的目录名不包含驱动器字母、冒号或打头的反斜杠，而且不一 定是长文件名，这个功能返回的是用于改变的此目录的路径，可能 包含长短文件名混合的字符串。 提供的内存区（DS:SI指向的）的最小空间应该由AX=71A0H功能测 定。 对应老式的调用：AH=47H 八、查找第一个符合条件的文件 入口：AX = 714EH CL = 允许的属性（位0和位5忽略） CH = 必须的属性 SI = 0000h 使用Windows 95的64位文件时间格式 0001h 使用MS-DOS的日期/时间值，在双字中日期为高位， 时间为低位 DSX -> 带通配符的文件名（“*”和“*.*”都区配所有文件） ESI -> 用于存储FindData结构的空间 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 成功时返回：AX = filefind handle （用于继续搜索） CX = Unicode转换标志 位0 返回的长文件名含有无法转换的Unicode 字符，被下划线替代 位1 返回的短文件名含有无法转换的Unicode 字符，被下划线替代 说明：这个功能仅当IFSMgr运行时有效，而不是DOS 7.0纯DOS模式 应用程序应在搜索完成后立即调用AX=71A1H功能结束搜索 对应老式的调用：AH=4EH 请参考：附一、附二、附三、附四 九、查找下一个符合条件的文件 入口：AX = 714FH BX = filefind handle（由功能AX=714EH来） SI = 0000h 使用Windows 95的64位文件时间格式 0001h 使用MS-DOS的日期/时间值，在双字中日期为高位， 时间为低位 ESI -> 用于存储FindData结构的空间 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 成功时返回：CX = Unicode转换标志 位0 返回的长文件名含有无法转换的Unicode 字符，被下划线替代 位1 返回的短文件名含有无法转换的Unicode 字符，被下划线替代 说明：这个功能仅当IFSMgr运行时有效，而不是DOS 7.0纯DOS模式 对应老式的调用：AH=4FH 请参考：附二、附三、附四 十、移动（改名）文件 入口：AX = 7156H DSX -> 旧的文件名（ASCIZ） ESI -> 新的文件名（ASCIZ） 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 说明：文件可以改名到不同的目录，但必须是同一驱动器。 对应老式的调用：AH=56H 十一、TRUENAME 入口：AX = 7160H CL = 00H 获取规范路径 01H 获取短文件名 02H 获取规范化长文件名或路径 CH = SUBST扩展标志 00H 返回的路径是不包含SUBST的盘符的真实路径 80H 返回的路径可以包含SUBST的盘符 DS:SI -> 文件或路径名（ASCIZ串），长短均可 ESI -> 261字节的存储区用于存放规范路径或长文件名 (CL=00H或02H） 或67字节（可能是128字节）的存储区用于存放短文件名 (CL=00H或02H） 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 出错码：02H 目录中找不到此文件（目录）或仅指定了盘符 03H 无效路径或无效盘符 成功时ESI指向的存储区写入了返回的路径或文件名 对应老式的调用：AH=60H 十二、创建/打开文件 入口：AX = 716CH BX = 访问模式和共享标志（附五） CX = 属性 DX = 打开模式（附六） DS:SI -> 文件名（ASCIZ串） DI = 别名提示（在短文件名为了消除二义性的数字） 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 成功时：AX = 文件句柄 CX = 0001H 文件被打开 0002H 文件被创建 0003H 文件被替换 对应老式的调用：AH=6CH 请参考：附一，附五，附六 十三、读取卷信息 入口：AX = 71A0H DSX -> 根目录名（ASCIZ串），如“C:\” ESI -> 存储文件系统名的内存区（一般32字节就够了） CX = ESI指向内存区的大小 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 成功时：BX = 文件系统标志 CX = 文件名最大长度（通常是255） DX = 路径名最大长度（通常是260） ESI指向的内存区被填充为“FAT”、“NTFS”、 “CDFS”等 BUG：Windows 95 SP1中此功能对于CD-ROM会返回DX=0000H 对应老式的调用：无 请参考：附七 十四、结束文件查找 入口：AX = 71A1H BX = filefind handle (从功能AX=714EH来) 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 说明：由功能AX=714EH开始文件搜索后必须调用此功能来释放filefind hadle 这个功能仅当IFSMgr运行时有效，而不是DOS 7.0纯DOS模式 对应老式的调用：无 十五、读取文件信息 入口：AX = 71A6H BX = 文件名柄 DSX -> 用于存储文件信息的内存区 CF置位 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 成功时DSX指向的内存区被写入文件信息 对应老式的调用：无 请参考：附八 十六、时间转换 入口：AX = 71A7H DS:SI -> QWORD格式文件时间 BL = 00H 文件时间到DOS时间 返回：CX = DOS时间 DX = DOS日期 BH = 百分秒数 01H DOS时间到文件时间 CX = DOS时间 DX = DOS日期 BH = 百分秒数 返回：DS:SI指向的内存区被填充 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 成功时的其余返回数据请看“入口”部分 说明：BL=00H时，如果文件时间不在01/01/1980和12/31/2107之间失败 对应老式的调用：无 请参考：附八 十七、产生短文件名(8.3格式) 入口：AX = 71A8H DS:SI -> 长文件名(ASCIZ串)，允许不带路径 ESI -> 用于存储短文件名(ASCIZ串)的内存区 DH = 短文件名格式 00H 11字符/FCB文件名格式 01H DOS 8.3 DL = 字符集 位7-4：短文件名的字符集 位3-0：长文件名的字符集 00h Windows ANSI 01h 当前的OEM字符集 02h Unicode 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 对应老式的调用：无 十八、服务器创建/打开文件 入口：AX = 71A9H BX = 访问模式和共享标志（附五） CX = 属性 DX = 打开模式（附六） DS:SI -> 文件名（ASCIZ串） DI = 别名提示（在短文件名为了消除二义性的数字） 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 成功时：AX = 全局文件句柄 CX = 0001H 文件被打开 0002H 文件被创建 0003H 文件被替换 说明：仅用于实模式服务器 对应老式的调用：无 请参考：附一，附五，附六 十九、开始/结束SUBST 入口：AX = 71AAH BH = 00H 开始SUBST DSX指向的内存区用于输入 01H 结束SUBST 不用指定DSX 02H 查询SUBST DSX指向的内存区用于输出 BL = 驱动器号 (00H=默认，01H=A:，等等） DSX -> 与驱动器关联的路径名（ASCIZ串） 出口：中断调用后CF置位表示出错(AX存储出错代码)，CF清零表示成功 说明：只有BH=00H时BL才可为00H 对应老式的调用：无 二十、最后说明 本文的原始资料来源于Ralf Brown's Interrupt List（英文版），这 个中断大全包含的内容相当丰富，实在是一份很好的编程参考资料。 由于本人水平有限，加上时间匆忙，翻译和整理得不是很好，不尽人意之 处，请多多包含。若有不正确的地方，请指正。 大家可以将本文随意传播，以服务于更多朋友，但敬请各位传播本文时务 必保持其完整性，多谢了。 过些时间我可能会写一些应用这些中断调用的例程，作为对本文的补充， 完成后，会通过邮件列表geprogram（金鹰的程序员天地）发布，有兴趣的朋 友可以加入此邮件列表，方法是： 1、发一封空邮件到 sml-geprogram-subscribe@mylist.soim.com 2、回复您收到的一封确认信 与我联系，请Email至：goldeagle@cmmail.com 或：pengyin@yeah.net Gold Eagle 　Nov.26,1999 于广东东莞 附一：文件属性各位的意义： 位 描述 ==== ================================= 7-8 保留（在Novell Netware中被使用） 6 未使用 5 存档(A) 4 目录(D) 3 卷标 2 系统(S) 1 隐藏(H) 0 只读(R) 附二：文件日期格式 位 描述 ==== ================================= 15-9 年份减去1980 8-5 月 4-0 日 附三：文件时间格式 位 描述 ===== ================================= 15-11 小时(0-23) 10-5 分 4-0 秒/2 附四：Windows 95长文件名FindData结构 偏移 长度 描述 ==== ====== ============================ 00H DWORD 文件属性 位0-6为标准文件属性 位8：临时文件 04H QWORD 文件创建时间（从1/1/1601开始的100ns数） 0CH QWORD 最后访问时间 14H QWORD 最后修改时间 1CH DWORD 文件长度（高32位） 20H DWORD 文件长度（高32位） 24H 8 BYTEs 保留 (apparently unused) 2CH 260 BYTEs 长文件名（ASCIZ串） 130H 14 BYTEs 用于向后兼容的短文件名（ASCIZ串） 说明：在Windows95B中，如果目录结构中不包含长文件名信息，则返回的短 文件名为空。由于这个原因，请使用长文件（偏移量2CH）。 附五、Windows 95的访问/共享模式 位 描述 ==== ================================= 2-0 文件访问模式 000 只读 001 只写 010 读写 100 只读，且不改变文件的最后访问时间 6-4 文件共享模式 7 不继承标志 8 不缓存数据（需要所有的读写精确到物理扇区） 9 不压缩文件，即使此卷通常对文件进行压缩 10 使用DI中指定的数字作为别名的尾部数字 12-11 未使用??? (0) 13 打开文件时产生严重错误返回错误码而不调用INT 24H 14 每次写操作均提交(commit)文件 附六、Windows 95长文件名文件打开模式 位 描述 ==== ================================= 0 打开文件（如果文件不存在则失败） 1 如果文件存在则清除（如果文件不存在则失败） 4 如果文件不存在则创建新文件（如果文件存在则失败） 说明：位0和位1不可同时设置 附七、长文件名卷信息标志 位 描述 ==== ================================= 0 搜索时区分大小写 1 目录中保存了大小写信息 2 在文件和目录名中使用Unicode字符 3-13 保留(0) 14 支持DOS长文件名功能 15 卷被压缩 附八、Windows 95文件信息结构 偏移 长度 描述 ==== ====== ============================ 00H DWORD 文件属性 04H QWORD 创建时间 (0 = 不支持) 0CH QWORD 最后访问时间 (0 = 不支持) 14H QWORD 最后写入时间 1CH DWORD 卷的序列号 20H DWORD 文件长度（高32位） 24H DWORD 文件长度（低32位） 28H DWORD 文件的链接(link)数 2CH DWORD 唯一文件标识（高32位） 30H DWORD 唯一文件标识（低32位） 说明：在文件打开时，文件标识和卷的序列号一起唯一标识了一个文件，这 个标识在系统重启或文件第一次打开时可能改变。

REM 喜欢DOS，因为它的简单 REM 喜欢OS/2，因为它不再矫饰 REM 喜欢BASIC，因为它并不幼稚 REM 喜欢GNU，因为它杂乱无章

向高手致敬。

辛苦辛苦啊,支持一下!

我(QB45)的照片与简历 www.programfan.com/club/showbb ...

以下这段话是乱说：

“众所周知，DOS下的文件名为8.3的格式，而Windows 95开始使用长文件名格式，以前的DOS下的程序只能按8.3格式来处理这些长文件名，读取文件或目录名时还好， 最多只是看起来有些不顺眼（都变成PROGRA~1、MYPROD~3.EXE这样的文件名 了），要创建新的目录和文件时就麻烦了，因为以前的DOS下的开发环境（如 Tubro C 2.0, Borland C++ 3.1, Turbo Pascal等）没有处理长文件名的 函数，所有的长文件名在以前的函数中都被截尾处理了。”

谁说DOS下的程序只能按8.3格式来入处理长文件名？？？“超级MS-DOS 7.10启动盘“、“MS-DOS 7.10完整安装版”、ROM-DOS 7.10等等不全都本地支持长文件名吗？不支持长文件名的DOS是仅指旧版本的DOS吧。。关于DOS下的开发环境，DJGPP不是可以在纯DOS下有LFN API的情况下直接使用长文件名吗？？？

[此贴子已经被作者于2003-10-15 22:40:53编辑过]

Wengier - 新DOS时代 欢迎大家来到我的“新DOS时代”网站，里面有各类DOS软件和资料，地址： wendos.mycool.net/ E-Mail & MSN: wengierwu AT hotmail.com （最近比较忙，有事请联系DOSroot和雨露，谢谢！）

这是一片转贴的文章了，很抱歉。我也不是高手。。。。。 关于站长的反驳，我感到很意外。其实到了MS-DOS7。1还是不支持长文件名的啊。 只有在加了DOSLFN等外挂后，纯DOS才支持长文件名，DJGPP的确是支持长文件名的。 但是需要几个条件。（DJGPP） DOS7。1+DOSLFN，在LFN=Y情况下可以使用长文件名。 DOS7。1无DOSLFN 不能使用长文件名。 WIN95 DOS BOX 使用的是128字符的长文件名，且没有3时间戳。DJGPP也绕不过去。 WIN98 DOS BOX 使用256字符长文件名，3时间戳（需要FAT32才可以） 最后需要声明的是，DJGPP只是对以上资料中所提到的调用作了封装而已。 它的C标准函数调用一个非ANSI标准的_open函数，然后_open函数调用一个DPMI保 护模式的INT调用来访问LFN API。 而在没有加载DOSLFN的情况下（即文章前提到的INT 21H的 71H子中断），DJGPP会自动 判断出LFN=N（LFN是一个DJGPP运行时的环境变量，每一个经过DJGPP编译的程序都会自动判断这个环境变量的值），然后调用一个特殊子例程来进行 “截断”的工作。 截断的工作和上面提到的一样，和一个QB45的长文件名实现也一样（这个实现糟透了，在 很多QB编译器上都会报错，而且是针对WIN95的长文件名实现，它只是把文件名做了截断， 源程序中充斥着大量的外部命令“DIR”的调用。。。。晕） 当打开文件时，DJGPP会自动截断你提供的长文件名，成为8。3文件名，然后打开。 但是遗憾的是，DJGPP却无法在没有加载LFN API的情况下创建长文件名文件。 这些都是我在使用的DJGPP编程，并参看了它的标准C库得出的经验，有什么错误的地方 请指正。 ================================== 我提供这份资料的意思是，鼓励ASM高手写一些库，为QB4。5，TC2。0等老编译器 写出新的调用函数（本人在看过DJGPP的实现后却写不出来，惭愧啊，因为它实在是 调用了太多的DPMI并使用了太多的头文件，我看得头晕眼花啊！！） 其中，还可以借鉴DJGPP的思想，在探测到没有LFN API加载的情况下，起码提供一个 折中的裁剪方案。提供高度的兼容性。 =================================================== 最后，我还发现的一个现象是。很多DJGPP早期（其实是特指DJGPP2。01+WIN95）时期 编写的程序，在处理长文件名上有很多怪异的行为。开始， 猜想是WIN95和以后的WIN98 、DOSLFN提供的LFN API上有一些不一样，看过这个时期的源代码、和DJGPP关于长文件名 的实现后发现。没有不一样！！！！！ 但是那个时代的程序都多了一个检测LFN API是否存在的函数，而这个函数似乎又无法检测出 DOSLFN的存在。在TEDIT中最为明显，我最终将所有的这个函数的调用都删去，强制用 ASSERT假设LFN=Y，在DJGPP2。03下程序才工作正常了（以前无法访问上级目录，只能打开 当前目录中的文件。。。） 这个现象很奇怪，但是我没有继续研究下去。。。。很可惜。

REM 喜欢DOS，因为它的简单 REM 喜欢OS/2，因为它不再矫饰 REM 喜欢BASIC，因为它并不幼稚 REM 喜欢GNU，因为它杂乱无章

站长的DOS是绝对支持长文件名的。 不支持长文件名的是老的编译系统，它们的FOPEN（）或者OPEN命令 在打开长文件名时，要么什么都不做，要么干脆报错，说此文件不存在。 郁闷啊。 DOS7。1的DIR命令就是长文件名的一个很好的实现，在有DOSLFN，WIN95或者WIN98的 情况下，都会很正确的处理问题。 有LFN API时，它显示两列文件名。一列8。3，一列长文件名。 没有时，它的显示和DOS6。22的DIR命令一样。作到高度兼容的典范啊！！！！！

REM 喜欢DOS，因为它的简单 REM 喜欢OS/2，因为它不再矫饰 REM 喜欢BASIC，因为它并不幼稚 REM 喜欢GNU，因为它杂乱无章

如果有人愿意用QB（4。0、4。5、7。1）来编程（比如说想做一个工具什么的），我愿意根据你的这篇技术文档资料编写一个库！

我(QB45)的照片与简历 www.programfan.com/club/showbb ...

如果你愿意的话，写一个出来先啊！！！！ 因为QB45+ALLEGRO+这个库，可以实现一个很好的安装界面。 退一步，也可以做出来为QB7。1工作（因为这些编译系统都不是保护模式的， 现在最适合用来做界面工作了，可是在实际工作中发现。他们的函数都不支持 长文件名，很郁闷。其实QB45，我对QB也着迷了一阵呢，：） 其实，开发一个库，本身就是一个做工具的过程啊！ 如果你写好了，我愿意使用它开发实际的东西。

REM 喜欢DOS，因为它的简单 REM 喜欢OS/2，因为它不再矫饰 REM 喜欢BASIC，因为它并不幼稚 REM 喜欢GNU，因为它杂乱无章

MS-DOS 7.x其实本身是知道如何去使用长文件名的，不过要真正使用长文件名，需要一个叫作LFN API provider的驱动程序，即DOSLFN。而MS-DOS 6.x则不一样，由于它本身就不支持长文件名，所以即使有了LFN API也没有用。类似，以XMS为例，DOS本身是知道如果去使用XMS内存的，但是，要真正使用XMS内存，必须要有XMS API provider，这就是HIMEM.SYS。所以，MS-DOS 7.x绝对是一个支持长文件名的DOS，只要有了LFN API就可以真正使用了。 相比之下，ROM-DOS 7.10则将LFN API都包含在了DOS内核中，所以它只要启动就能本地支持支持长文件名了，而不用再加载其它的LFN API provider，比如DOSLFN。

Wengier - 新DOS时代 欢迎大家来到我的“新DOS时代”网站，里面有各类DOS软件和资料，地址： wendos.mycool.net/ E-Mail & MSN: wengierwu AT hotmail.com （最近比较忙，有事请联系DOSroot和雨露，谢谢！）

其实关键并不是DOS是否认识LFN，因为即使是DOS6。22+DOSLFN+LFNDIR，这类专用的 包，用起来还不是一样？ 关键是使用的工具是否支持LFN，即使DOS认识LFN，可是如果像EDIT这类基本的工具不认识 LFN的话，用起来还是很不方便啊。 所以说，为老编译工具开发一个LFN库，还是很有意义的。 另外，最近发现一个GNU的工具，很好用，向大家推荐。 GRCODE， 对各种字符集的支持很好。UTF-8等等。 同时还是一个编程库。

REM 喜欢DOS，因为它的简单 REM 喜欢OS/2，因为它不再矫饰 REM 喜欢BASIC，因为它并不幼稚 REM 喜欢GNU，因为它杂乱无章