感谢网友无心的指点，这个问题有了满意的答案啦！
解答 为何写显存比读显存速度要快
16条回复
分类目录归档：OS Study
为什么写显存比读显存速度快？
我在写游戏的时候使用了显存双缓冲，即创建两个视频位图，video1和video2。当前显示的为video1的时候，那么就把对象位图就拷贝到video2上，然后调用显存操作函数，把显示页面设置为video2，这样就不会出现拷贝对象时屏幕闪烁的问题，也不需要在内存里开辟一个内存位图的缓冲区。
最近在写一个屏幕渐亮和渐暗（Fade in and Fade out )，用于切换场景，需要对当前屏幕的位图进行alpha拷贝输出，但是我发现直接在显存上进行alpha拷贝时，速度慢得可怜！
My Partitions
这是在Windows7上看的磁盘分区图，磁盘0是笔记本上的，磁盘1是移动硬盘的。 可爱的Debian就安装在移动硬盘上。本本的BIOS优先从USB引导，所以开机时候需要手动选择才能进入Windows7 。
不知道联想为什么给windows系统盘分配了50G那么大。按照这种状况的话，我就习惯把所有软件都安装到系统盘去了，哈哈~~~ 然后programs里存放代码，home里存放多媒体资料。
那个OEM分区永远也不会用到，而且我也一键还原给卸载了，碍手碍脚。以前在同学机子上把那个分区给删了，结果机子要送厂，因为BIOS要检测那个分区。。。真BT~
对了， 移动硬盘上的资料分区也都是ntfs了，主要是为了方便给同学传文件。移动硬盘比起U盘要方便很多，传1GB的东东，也不用一两分钟。U盘就慢死了，要是去到一个usb1.1的电脑，哈哈。
不知道使用ntfs收不收钱呢。有点担心微软有一天来找我要钱了。幸好现在的办公软件一直用OpenOffice。
好久没被这样的bug玩过了
今天在两个小bug上花了很多时间。几乎整个晚上都在寻找bug的来源~！
当我真正地找到bug的所在处时，大吃了一惊！唉，当年的恶梦重演了。。。太粗心大意了！
第一个bug：
Line 106，应该是 if( p!=NULL ) 才对。。。
我早就怀疑某个地方有点不对劲，今晚证实了，添加了MAP_ZERO参数，却没有生效。
mo是指针，初始化mo结构的内容，用到sizeof时候，应该是 sizeof(*mo) 或者 sizeof(PeModule)才对。
我真悲剧！
– –
以此为鉴，今后写代码慎重！
VESA服务程序搞定！
哈哈~~ 从sgos1.0移植过来的vesa驱动，不费吹灰之力啊，仅仅1个小时，成功编译后运行马上能够使用了。并没有预想之中的出现一大堆麻烦。也多亏之前的vm86写的相当不错~~
PS：键盘驱动也可以正常工作了！
下一步，一个简单的tty驱动~~~SimpleConsole！
read和_read？
昨晚把uname函数解决了，成功地在模拟的cygwin兼容层上运行了GNU uname程序。接着又尝试了一个比较简单的程序—cat。
在运行的过程中，还需要下面两个函数_read和_write。
其实这两个函数和read、write有什么区别呢？
我懒得去翻GNU的源代码了，_read和read的函数声明是一样的，所以我估计_read是cygwin内部使用的函数。于是，直接在read中调用_read，在_read里实现真正的读取操作的代码。
在基本实现了fstat功能后，我发现里面有一个指出块大小的变量。我把这个变量设置为一个页面的大小4096之后，惊奇地发现每次调用_read的时候都是4KB对齐的。真好，看来我在api层的FsReadFile函数里又设置了一下页面对齐有点多余的感觉。
附一个运行cat程序显示一个文本文件startup.txt的内容的截图。
下一步准备实现标准输出输入了。写一下tty和kdb的驱动。
Cygwin学习笔记
为了在最短的时间内掌握Cygwin原理，我选择了MSYS的源代码来进行分析研究。
以下内容仅为阅读代码时做的笔记，非文献。
当一个Cygwin程序运行时，首先到达mainCRTStartup ()这个入口函数，属于newlib，在newlib的crt0.c里。
mainCRTStartup ()调用msys_crt0或者cygwin_crt0，并传递main函数的地址。
msys_crt0调用了_msys_crt0_common 和 dll_crt0__FP11per_process。
在_msys_crt0_common()里，主要给per_process结构分配空间，然后初始化结构的数据内容。
进入dll_crt0__FP11per_process()后，就不会再返回了。
接着来到_dll_crt0()，获取环境变量和进程信息，通过set_console_handler设置终端IO文件。随后调用dll_crt0_1()
在dll_crt0_1里，设置了异常处理函数，初始化resourcelocks和threadinterface，似乎给线程都分配了名字。
调用了host_dependent.init ()，不知道干了什么。
调用memory_init()，若是第一次加载dll，会创建一片共享内存区域。
调用events_init()初始化。
如果是使用fork创建的子进程，则跳到指定的地址去执行。否则，执行下面初始化：
Cygwin进程列表初始化，dtable初始化，信号处理初始化，tty初始化。
对命令行参数的路径进行转换。
调用stdio_init()设置标准的输出输入描述符表。
至此，基本上完成了Cygwin的数据初始化。
最后调用dlls.init ()，调用各个premain函数。调整到user_data->main去执行。
至此，我大致已经清楚了Cygwin的启动流程，可以去尝试自己写一个运行库了 
经过一晚奋战，结果如下，成功执行MSYS的env.exe程序。
Cygwin Makes Me Crazy?
前几天在忙着编写kernel32.dll以支持msys-1.0.dll。后来发现有点问题了。
首先，要实现的函数数量比较多，起码有100个以上。其次，我对win api不熟悉，也不感冒，对于每个api都要去msdn获取资料，相当麻烦。另外，某些api是非常难实现，例如编码转换，acl那些。
因此，我从昨天开始停止了继续编写kernel32了，而是转向msys-1.0.dll。msys和Cygwin是差不多的，其实就是一个简化版的Cygwin。而且使用了newlib，可移植性很好。
在编写msys的时候，又遇到问题了，我发现了里面有很多Cygwin的专用结构。对于这些结构我还不是很了解，所以基本上都没有实现。同时，我对Cygwin的工作流程也不是怎么熟悉。
为了让原计划继续进行，无论如何我也要把msys运行库写出来。
下一步先熟悉一下msys的源代码！！
A Bug
今晚花了8个小时1杯咖啡调试sgos2一个bug，最终还是解决了。
在时间消耗上很不划算，不过总算学到东西。
昨晚出现了一个怪问题，尽管我把代码改了又改，还是不知道问题出在哪里。怪问题如下：
SGOS2 进程管理器 大部分完成了！
通过进程管理器调用运行了一个可执行文件。
执行两个同样的程序，测试COW功能。