中国DOS联盟

不錯, 給你加分了

谢谢加分！我会继续努力的！！

Re All:
预告：下一版的汉字替换规则将进行简化，以方便字模和文本的合并！更多功能在添加中！！名称将改为VTFmagic.COM，程序结构模仿DEBUG，并允许汉字串中加入行内控制码(如字库选择、下划线、横扩、反相等)、支持文本文件的输入和自动替换、字模文件与载入程序的分离与合一甚至不生成文件而直接替换字模、在保持显示模式的前提下的恢复常规字形的扩展ASCII字符、允许字形现场编辑等。现在，一切还只是设想，要等一段时间才能推出。在此期间，请大家提出各种意见和建议！

版主willsort的建议非常规范、周密，并具有启发意义，在此特致感谢！！！

[ Last edited by 本是 on 2005-11-7 at 12:29 ]

挺牛X的了!

Re 本是:

（http://www.cn-dos.net/forum/viewthread.php?tid=6916#pid104147）

这一版的替换是把每个汉字拆成两个ASCII扩展字符，分别位于C0h和80h开始的左、右半字模区，所以新汉字内码必须是C0h+n和80h+n（n＝不重复的汉字序号）的组合

　　根据你的这点提示，我想到另外一种字模替换方案，即直接替换汉字GB码的两个字节所对应的扩展ASCII字符的字模，比如“启动（C6 F4 B6 AF）”，即分别替换"C6 F4 B6 AF"这四个扩展ASCII字符的字模。

　　这样做的优点是，汉字在中文系统和VTF环境下使用同样的编码，具有高度的兼容性，也具有相当强的可阅读性；而缺点则是无法同时显示有相同字节的两个汉字，比如“真正（D5 E6 D5 FD）”，其中的 D5 的无法同时显示“真正”二字左半字模。

　　那么，新版程序中是否可同时采用两种方案，先尝试以上方案，如果检查到了非相同字的相同字节，那么我们再改用顺序替换扩展ＡＳＣＩＩ字符集的方案。当然，这会更大程度上增加程序的复杂性，是否采用决定权仍然在你。

在保持显示模式的前提下的恢复常规字形的扩展ASCII字符

　　你的意思是否是指：恢复字模可以不用置模式，还是置使用前的模式？

　　如果是前者，那么是否有这样的可能性：相邻两行的相同字符可以对应不同的字模？即在使用程序修改一字符的原字模后，本屏以前所显示的这个字符仍然不变。

　　如果真有如此理想，那么理论上应该可以实现用改一行，显示一行的方法，在屏幕上逐步显示出所有的汉字，而非仅仅６４（或者１２８）个汉字，这个限制仍然会在单行内存在，但是每行通常最多显示４０个汉字，所以可以不用理会。

RE willsort:
1.你说的“另外一种字模替换方案，即直接替换汉字GB码的两个字节所对应的扩展ASCII字符的字模“行不通，原因是比如“启动（C6 F4 B6 AF）”，即分别替换"C6 F4 B6 AF"这四个扩展ASCII字符的字模之后，C6 F4 B6 AF分别重组的其它汉字（“破贫漂羝趑舳舣镀遏抖”）就麻烦了！我们要记住：此时不在汉字系统下面，没有谁处理双字节，西文下是处理单字节的－－一个西文字符代表半个汉字，所以VGA TEXT SCREEN下的被替换字符会乱点鸳鸯谱：乱配汉字！！
当然保证没有其同胞的时候勉强可以。

2.“恢复字模可以不用置模式”是完全可能的，其实就是用standard font去替换当前字符集。这儿要区分一下：视频模式和VGA字符点阵8或9点模式（“无缝或有缝”汉字由此而来），改变视频模式当然彻底改变一切，而改变VGA字符点阵8或9点模式并不需要一定改变视频模式。

3.字符只要同屏显示，就必须对应相同的字模！因为这是由字符生成器（硬件）生产出来的，除非你做一个多字节系统或在图形方式下显示字符，效率和资源占用就完全两样了！！

4.但是，我们却可以显示16X16点阵的汉字横扩成16X32点阵的字符，不过要占用4个西文字符，24点阵汉字需要6个西文字符，32点阵汉字需要8个西文字符，……。黑白反相字、带上/下划线/波浪线、加框、颠倒、镜相、旋转、平移等效果，都可以。甚至纵扩字－－即一个汉字纵向上要占用超过一行－－也能做到！

5.另外还可以同屏显示双字符集字符，即512个字符，也就是说，可以最多显示256个汉字！EGA最多可以同时载入4个字符集，VGA最多可以同时载入8个字符集，但同屏只能最多显示2个字符集，而且要对字符加属性显示才行！（比较复杂了！！！）

[ Last edited by 本是 on 2005-11-9 at 18:22 ]

Re 本是:

1、我在讨论这种替换方案时，也考虑到你所说的“同胞”汉字问题，所以我才有先检查是否存在“同胞”的提议；或者也可以将它用在一种特殊的环境下，确定只在一屏显示很少的汉字，而且这些汉字均是不“同胞”的，比如config菜单中。这样，将此功能单独做为一个参数，由用户判断汉字是否同胞，并决定是否采用这种兼容性替换方案。

2、那么你所会所说的“恢复字模”是否可以理解为，重置的并非显示模式，而是字符集fon？而之所以重置模式可以恢复字模，也是因为它也附带重置了字符集font？

3、同屏显示不同字模的情形，我也预测到可能实现起来并不是我猜测的那样。另外，我曾在UCDOS等智能识别表格线字符的汉字系统中见到这种情形：同一个字符如果其后没有跟随对应的表格线字符，则字模改变；反之则不变。这是否就是你所说的多字节系统？

5、我确实没有听说过“多字符集”的存在，我仅知道屏幕缓冲区存在多页，以此实现了无闪烁的屏幕切换。

Re willsort:

1.同胞汉字的比对和保持原内码的替换，在技术上并不更难：可以一个字符一个字符地换。

2.你的恢复字模的理解是正确的！而视频模式的恢复要复杂得多－－涉及几十个寄存器的值！

3.n字节系统是指用“n字节”定义一个字符或字的系统，即将“n字节”看成一个整体代码来映射“字符”集系统(“字符”集系统之“字符”与对应于“字”的“字符”不是同一个概念！！)。这“n字节”是不能拆开来用的，否则要乱码！

4.UCDOS等汉字系统的智能识别表格线字符功能，正是n字节内码中出现的与单字节符的冲突，这是代码系统不完善的表现。智能识别正是对此进行补救的一种后悔药。

5.“多字符集”确实存在，但又不是通常意义上的含义。它是指内存中可以同时载入“多”“字符集，但只能同屏使用“单”或“双”字符集。这是对E/VGA而言的技术上的规定。讲E/VGA硬件的书上都是这么介绍的。我也曾经试过双字符集同屏显示，要重设调色板并带属性显示字符－－也不是复杂得不行，当然也不简单。

学习一下，看来我的知识太少了。

等待成熟的版本和实例教程。

喜讯：
　　VTHZ.COM将能用原汉字内码显示VGA文本屏汉字！如果你的汉字串中每个字节都没有重复出现－－不要自我克隆！
　　示例载入汉字字模的程序是VTHZ2.COM，显示原汉字内码中文信息的是VTHZ22.BAT。
　　对比载入汉字字模的程序是VTHZ1.COM，显示新汉字内码中文信息的是VTHZ11.BAT。
　　有趣的是：VTHZ1.COM和VTHZ2.COM除了替换内码不同(9个汉字共18字节)外，程序其余部分完全一样！！！
注意：
　　使用液晶屏的朋友，请带任意参数运行VTHZ1.COM和VTHZ2.COM，如VTHZ1 A或VTHZ2 /。否则可能产生死机现象！

请耐心等待生成如上程序的母程序！

[ Last edited by 本是 on 2005-11-18 at 12:27 ]

Sorry. Deleted.

[ Last edited by 本是 on 2005-11-21 at 11:22 ]

Re 本是:

首先，提供我对 demoVTHZ 包的测试结果。我将包中的测试批处理合并（代码见后），其中 mode 一句在 MSDOS 中去注释，在 XPCMD 中会保留注释。

报告：

1、在 XP CMD/COMMAND 下使用效果相同，结果见引用内容。

2、在虚拟机中使用，尝试了 MSDOS6.22/7.10，正常启动/F5启动，VTHZ1.COM/VTHZ2.COM，直接调用/加参数调用 的各种情况，均在清屏后不再有任何动作，尝试敲入 mode co80 后屏幕恢复。运行测试批处理，在按下两次回车键之前，屏幕均无任何显示，无论是否加参数均是如此。

3、在真实机的MSDOS中，通过 Grub 加载 Wengier 的启动盘，运行测试批处理后，结果正常，无论是否加载参数。

随后，我对 vtfse 包进行了测试，可用平台同 vthz1/2，在虚拟机的 config 环境中无法运行。 其功能参数未发现问题，但发现 vtfse 8 与 vtfse 效果相同。

讨论：

1、因为测试机是液晶屏，所以我对 参数/不加参数 做了些测试，未发现什么不同；所以，yaya 兄在主题 {6916}不加载汉字系统也可以显示汉字？ 中讨论的问题可能需要限定范围，比如限定在 config 环境中。我目前无法在真实机中测试启 config 环境，因此还需讨论。

2、虚拟机的不成功，可能是虚拟机环境出了问题，因为我在其中使用 debug 跟踪 vthz1/2.com 以及其他的 com 程序时，发现 p（roceed） 与 t（race） 指令均无法改变 IP 寄存器，而这是不正常的。但是在这个环境中，原来的 vthz.com 可以正常执行。

3、查看 vthz11.bat 所占用的编码空间，确实是前半字节按汉字出现顺序从 c0-c8 ，后半字节则是 80-88，共八个汉字+加一个全角感叹号，已经考虑了重复字符的问题，应该是手动处理的，应该还没有在生成阶段实现。但是，我仍不清楚前半与后半字节 “分区” 的意义何在？

4、在真实机测试成功后，vtzh1/2 的显示结果中的汉字类似于 袖珍中国龙（XZL）的曲线字体，那它应该不是取自 hzk16 吧？

5、vtfse 0 ，应该是直接置显示模式为 0 ，所以会清除原本的显示模式，比如背景色和前景色。

6、vtfse e "message" 的大小问题，我猜测可能是源于 DOS 本身的命令行分析代码；不轮是否如此，我建议在提示中强制用户给显示信息加引号，以封装了命令行大小写转换的复杂细节。

7、你上文中提到了有缝隙的汉字为 9*16 ，这我不太明白。我的理解中，640*480/80*25的显示模式下，每个字符在宽度上最多可分得 640/80=8 个像素的空间，而正常显示中，ASCII集字符屏蔽了最边上的一列像素，得 7*16 ，而显示汉字时，按照 ASCII基字符的显示途径，因为一列被屏蔽，导致汉字的前半和后半字节均被屏蔽，所以汉字出现缝隙和缺边（印象中是缺右侧边，也因此推测是ASCII显示屏蔽的是最右侧的一列像素）。

@echo off vthz1.com %1 echo 纮羴聜脙膭艆茊菄脙膭葓 echo Nei Ma = Gai Bian! echo. pause ::mode co80 vthz2.com %1 echo 不启动中文系统看中文！ echo Nei Ma = Bu Bian! echo. pause ::mode co80

└Ç┴ü┬é├â─ä┼à╞å╟ç├â─ä╚ê
Nei Ma = Gai Bian!

Press any key to continue . . .
▓╗╞⌠╢»╓╨╬─╧╡═│┐┤╓╨╬─úí
Nei Ma = Bu Bian!

Press any key to continue . . .

[ Last edited by willsort on 2005-11-20 at 14:21 ]

Re willsort:

关于“报告：2.”：
　　VTHZ1/2.COM只作字模替换，不显示字模。带不带命令行参数只是西文字符宽度设9/设8的不同。

关于“讨论：1.”：
　　我未用液晶屏，无法答复。

关于“讨论：2.”：
　　虚拟机测试我也做过，应该没有问题。

关于“讨论：3.”：
　　VTHZ1.COM中的新内码顺序是左字节=0C0h+字序-1，右字节=080h+字序-1，即左右字节各按顺序，目的是为充分利用制表符的自动扩展成9列显示，虽然只有32个字符；VTHZ2.COM中的新内码顺序是原常规内码垵字符串顺序，即无序，但方便－－原信息不用替换；“ vthz2.com 的执行后，vthz1 的显示结果仅变化了个别字节”纯属叠加造成的，即一次替换后的字模只要下一次未覆盖或恢复，就一直保持下来，如此造成的结果。我也纳闷过，但每次恢复字模或屏幕后再进行下一次试验，就没有字模暂留现象了。

关于“讨论：4.”：
　　字形确实象袖珍中国龙（XZL）的等线字体，我用它，不是因为它更好看，而是视觉识别更清楚。

关于“讨论：5.”：
　　vtfse 0，是用原显示模式进行重置，恢复一切包括字模、字符前背景色等。

关于“讨论：6.”：
　　vtfse e "message" 的大小问题之复杂是CONFIG.SYS被IO.SYS处理时遵循的规则决定的：即一切大写化。要简化，几乎不可能，因为CONFIG.SYS文本对程序而言全部被大写化后才“可见”，除非改写IO.SYS，否则是不可能“原样”显示信息的。Wengier的超级DOS启动盘中用的是ECHO.SYS显示方法还要麻烦，它是一个字符一个字符地加/号才能保持小写！这是MS的愚蠢和霸道！！！

关于“讨论：7.”：
　　字符显示的点数的“行总和”是个虚拟概念，实际上并不存在，因为字符的点数是另一个硬件概念！是由制表符的显示美观要求带来的调整，就象汉字制表符在汉字系统中也作了相应美化一样，与12hVGA文本屏的扫描行的象素数毫无关系。

BTW：
　　我的设备驱动、命令执行合一版VTFSE.EXE可是得益于版主回Wengier的帖子，谢谢！

[ Last edited by 本是 on 2005-11-20 at 22:01 ]

Re 本是：

　　讨论二：报告二中的主要内容便是，虚拟机的测试无法成功。而在讨论二中我将之归结为虚拟机问题，而之后使用另外一款虚拟机 Qemu 测试的结果正常，也证明了这一点；但是也有一则我曾提到的反证，就是我使用原版本的 vthzmk 生成的 vthz 却完全可以在 VPC 中正常运行。这似乎说明是虚拟机与新版本的 VTHZ 不太兼容的缘故。VTHZ1 方面，经单步跟踪测试， 问题出现在 Seg：129 处（第一次循环），猜测这里应该是后半个汉字的字形修改代码，在执行 int10 后，屏幕无显示，且不返回命令行。其中缘由就不得而知了。至于虚拟机方面，至今未找到原因，重装数次VPC和客户端系统未果。

seg000:011D mov dl,
seg000:011F xor dh, dh
seg000:0121 int 10h
seg000:0124 add bp, 10h
seg000:0127 mov dl,
seg000:0129 int 10h

讨论三：谢谢提醒，这个问题我已理解。再次顺便提供 BatTool 3.2 的帮助文档中关于此段内容的比较浅显的说明。很感谢这篇文档，它纠正了我对 VTF 和DOS显示模式的多个错误理解。

在英文文本方式下显示汉字或图形的原理是：ＶＧＡ03模式的字符是8*16点阵英文字符，通过ＢＴ生成的字库程序修改ASCII码128￣255的字符字形，把原来的英文符号改为汉字。因汉字是16*16点阵，两个字符合成一个汉字。这样，就可以显示64个汉字了（128个字符），虽然少了点，但在批处理中已足够了，而且不占内存！BT可以帮你生成一个可修改字符字形的COM文件，只要一运行它就把英文符号修改成汉字或图形。
ＶＧＡ03模式的扫描分辨率为720X400，而显示字符分辨率为80X25，这样每个字符实际是9X16点阵的，但用8X16点阵的字库，一般字符的第9竖行为空白，对于ASC值192到224的英文制表符第9竖行与第8竖行相同，这是为表格是连续的而不是一段段的。我们把从ASC192开始的字形改成每个汉字的第一个字符，从ASC128开始的字形改成每个汉字的第二个字符这样就组成了一个汉字，且每个汉字之间有一行相隔(第二字节的第9竖行)。注意当字符的ASC值超过224就不是制表符了，因此你输入的字数超过32个时，每个汉字中间会有一个竖道。BT将从屏幕上直接读取汉字字形(这是为了兼容倚天之类的中文系统)，因此你应先进入中文系统再用BT生成修改字形的.COM文件。你可用BTE M 恢复原来的字符字形。

引自 BatTool 3.2 帮助文档，作者：北京 王海澄

　　讨论六：经你提示，我也省起 IO.SYS 会在 CONFIG.SYS 加载过程中，将其全部大写化（除了多启动中的 set 语句）；但是一对引号是否是小写字母的“避难所”呢？我查看了相关的源代码，未得到这样的答案，难道你的程序中有特殊的处理吗？此外，我上文的原意是在参数说明中直接指出显示信息必须以双引号包含，而将未包含的信息会被大写化作为未公开的秘密（undocumented secret），这样使程序显得更简洁一些；甚而也可以直接以双引号作为显示信息的开关，代替原本的参数 E。

　　讨论七：此处你讲得较为抽象，我试图运用从 BT 文档中得到的知识解释得更浅显一些。

首先，80*25和640*480并非是同一种显示模式，前者模式号为02/03H（DOS命令行下通常为为03H），属于文本模式，分辨率单位为字符；后者模模式号为12/13H，属于图形模式，分辨率单位为像素。具体模式见下表。其中BT文档中提到的文本模式像素分辨率为720*400（注意：此说法未得到相关资料佐证，只能作为孤证），据此换算每个字符的像素分辨率确为9*16。

但是标准ASCII集中的字符为了显示起来有适当的间隙（美观的需要），因此其字体字形只使用了8*16的像素空间，同时，扩展ASCII集中的部分制表符号（192~223）为了水平线的无缝连接（同样是美观的需要），又使用了9*16的像素空间，第9列字形从第8列直接复制过来，即所谓“双边”特性，拥有此特性的字符暂且称之为“双边字符”。

而显示汉字时，因为前半个汉字只修改了8*16的字形空间，第9列被空置却仍然被显示出来，成为汉字的“缝隙”；而 BT 显示的无缝汉字，恰恰是利用了“双边字符”的特殊显示方法，将缝隙用缝隙左侧的列的字形弥合，因此，这种显示方式准确的说是“补缝”，而非“无缝”。当然 VTF 所采用的方式是不同的，下文再述。

模式 显示模式属性
00H 40×25 16色 文本
01H 40×25 16色 文本
02H 80×25 16色 文本
03H 80×25 16色 文本
04H 320×200 4色
05H 320×200 4色
06H 640×200 2色
07H 80×25 2色 文本
08H 160×200 16色
09H 320×200 16色
0AH 640×200 4色
0BH 保留 　
0CH 保留
0DH 320×200 16色
0EH 640×200 16色
0FH 640×350 2(单色)
10H 640×350 4色
10H 640×350 16色
11H 640×480 2色
12H 640×480 16色
13H 640×480 256色

以上引自《汇编语言》一书，略有格式调整

BT 与 VTF 原理上的异同

1、二者汉字字形获取方式相似：现在它们都是提示后在接受用户从键盘输入的汉字，而不支持命令行指定汉字，这样就会有一个缺陷，即采集字形通常需要进入中文系统，修改字形又必须退出汉字系统或更改显示模式，切换比较麻烦；但是二者字形获取源头不同：BT 是从屏幕上直接读取汉字字形，据作者所说，采用此方法是为了兼容倚天之类的中文系统，而 VTF 是从DOS汉字系统的字体文件中取得的。

2、二者默认的字形修改编码方案相同：前半个汉字占用 192～255 的编码空间，后半个汉字占用 128～191 的编码空间，这样可以充分地利用 192～223 这32个字符的“双边”特性；但是它们又各有一套不同的备选方案： BT 为了显示由位图转换而来的字形，而允许字形替换不实行分区，而全部使用 192～223 双边区字符；而 VTF 为了省略更改汉字编码的步骤，而允许按照汉字的原编码修改相应的字符字形。

另外，我注意到，192～224 并不是完全匹配于制表符号的，制表符号是从 179～218 共 40 个，而 179～191 制表符号因为没有其符号图形没有使用右侧边，所以没有享受“双边待遇”。与之恰好相反的是， 219～223 的这五个方块状字符因为用到了右侧边而依靠“裙带关系”而得享殊荣。

3、二者均实现了无缝汉字的显示，但是二者的实现方式不同：BT 通过使用32个“双边”字符实现，即所谓“补缝”显示，而 VTF 除了上述方法外，尚可以通过修改 EGA/VGA 寄存器实现字符的8*16方式显示，此种实现保证汉字不被变形，同时可显示的无缝汉字更多了。

参考文献：
BatTool 3.2 帮助信息
http://bbs.wwwfox.net/cgi-bin/printpage.cgi?forum=2&topic=11034

汇编语言网络课件-〉附录3 中断列表-〉BIOS中断-1 显示服务
http://www.mdjx.net/course/hep/huibianyuyan/Appendix/course.htm

ASCII 码表
http://www.asciitable.com/

[ Last edited by willsort on 2005-11-29 at 22:38 ]