改编后的TC在Windows下才绕，那篇文章作者估计没用过DOS下传统的TC，才会那样解释，但他测试的数据和现象应该是真实的。传统的TC绘图，是直接对显示卡内存写数据的，不是调用BIOS的，更不调用DOS中断。正因为它直接写硬件，所以才要绘图之前必须先Detect()和InitGraph()这样的操作，就是针对特定显卡的模式设置存储器读写地址，不同的卡、不同的显示模式，屏幕图形入口地址都不一样，这种操作，在MSC中的绘图库中是没有的。因此，TC的绘图库只支持特定的那几个分辨率，而MSC是只要显卡支持它就能支持。速度是TC的快，但兼容性是MSC的好。由于TC移植到Windows之后，Windows保护模式禁止了直接读写硬件，可能就强迫改良版的TC转用中断机制，这样就绕了，速度不慢才怪。本质上，改良版的TC那些绘图库，最终都是被Windows的DLL接管，改用API输出，所以才有那篇文章所说的那些测量结果。
其实，这篇文章揭示了一个道理，即不要想当然。旧思维下再精心设计的程序，在新系统架构下，极可能不是那么回事。比如，当今的机器有硬件优化，有自动抢先权，操作系统也提供缓冲甚至双缓冲功能，在这种架构下写程序代码，往往精心设计的优化手段实际上还不及老老实实写直观代码来得高效；在虚拟内存和文件镜像等手段之下，读写大型甚至巨型的文件，都可能根本不是以前以为那样需要申请内存、读入内存、动态分配内存等等的手段了，操作系统直接就把文件在硬盘上的数据当作内存了，你还真去申请内存读写，是自以为的高级技能而已，反而老老实实fopen()然后fseek()、fread()、fwrite()的，倒比那些技巧高效得多。毕竟现代的硬件和系统设计，目的就是为了用户直观使用的。
以前用VAX的时代，就曾经有这么个近似笑话的故事：学生在机房上机练习BASIC编程，输入? 1+1，敲回车之后可以把凳子转个圈到背后拿杯水喝一口，转回来时刚好看到出现结果2。这个故事只不过告诉我们，即使是1+1运算那么简单的操作，如果操作系统分时给你的权限低，再高效的指令也极可能等于零。
[
本帖最后由 TonyDeng 于 2012-3-5 02:30 编辑 ]
2012-03-04 15:09
