YY船长博客

前天迷茫在最最基础的字符移动处理中，最终还是发现，在windows上，Rtl方法是最快的。

Rtl的3个方法：COPY，Fill，Zero。

这时候又带出了一个问题，因为我发现Rtl方法其实是在DDK里面的。对我来说，driver一直是很神秘的东西，给我的感觉有点像引擎，或者是心脏。

而这个可恶的windows用编程做出了几个层次，平时写应用程序的时候，可能感觉不出来，但是在测试速度的时候，就会很惊讶。

用汇编来说，在应用程序的代码上，执行速度是最快的。

但是对于windows来说，应用程序被放在一个最低的层次上，会受其他应用程序的影响。

但是kernel-mode 的Rtl方法似乎被放到了一个更高的层次，从而减少了一些应用程序的影响。

这一点我解释不清楚，本以为在应用层次上，所有方法受到的影响是一样的，但是似乎windows对于内核方法会提高一定的优先级。

似乎又和IRQL有关，涉及到这种虚拟的中断，实在是不清楚。

以后也知道了，要做方法比较，不能和kernel-mode里面的API来比，应用程序和Driver程序的级别相差太大了。

所以说，以后蹂躏windows的API，要找SDK里面的方法。嘿嘿！

——————>

如何更好的使用工具？

这个问题应该慢慢作为我学习的重点的。

——————>

性能和稳定性都是程序需要考虑的。但这个是结果。

过程中代码的良好阅读性是非常重要的，这也利于以后代码的修改。写成dll是非常好的选择

——————>

在处理字符串的时候，主要面对3种编码类型：ANSI类,unicode类。

ANSI(American National Standards Institute)应该是当年提出ASCII码的组织吧。所以所有以ASCII作为扩展的字符集，都用ANSI作为统称。

ASCII是现代美语字符，每个字符是8位(American Standard Code for Information Interchange)

ISO-8859-1是西欧字符，它是在ASCII基础上，多了一些字符，不过依然是8位，在unicode中表示为16位。

GB2312，GBK也是扩展自ASCII，他们是中文字符，GB代表的意思是国家标准。K的意思是扩展。他们把中文作为2个字节来显示了。

而unicode的编码就很不同，它是自成体系的。对于各国的文字，他们的编码都不一样。

unicode是用来做万国字符的一个统一字符集，所有的字符都是16位。它表示同样的字符也要比ASCII多一个字节。

UTF-8是在unicode的基础上，做了一定的修改，后来被推广到网络上，用得很广泛了。

——————>

我现在使用的操作系统因为是中文版的，他的字符集是GB2312。

所以用TCHAR的时候，得到的是ANSI的编码。

之所以我们能看到日文，是因为GB2312里面也包含了一些其他文字的编码。但是韩文就不行了。这个要借助韩文的编码库了。

NotePad中，我们看到的中文，其实都是UTF-8格式的，它是隐藏式的转换了，这是百度百科上说的。

不过我觉得也有可能是unicode，但我没看过微软相关的文档，只是猜测而已。

——————>

文件的查找有2个方法：

FindFirstFile和FindNextFile

这里都是返回一个WIN32_FIND_DATA格式的数据。(string是返回到string buffer，某格式数据自然要返回到某个格式的buffer中)

用FindFirstFile来确定是不是有文件，然后循环的时候使用FindNextFile

要查找文件，需要用嵌套函数，当然了，我们还得穿透子目录，还得把找到的’.'和’..’目录给剔除，这两个分别表示当前目录和上一级目录。

找完之后，CloseHandle就可以把handle给注销。

——————>

这时候还碰到个问题就是’.'和’..’的判断问题。

我们就用简单的字节判断就可以了，因为这两个的首字节都是’.’

判断的数据类型当然没有字符串了，因为字符串本身就不是数据类型，这是一串字符加上个0结尾字符。

——————>

最后，想找个主要玩宠物的游戏。。不过我玩游戏都容易大段时间就花费在上面。没办法做到平时玩少量时间。

除了那种小小战争之类的。。但是小小战争不好玩。。

但是

读文件的操作是：

ReadFile

BOOL ReadFile(
  HANDLE hFile,                // handle to file
  LPVOID lpBuffer,             // data buffer
  DWORD nNumberOfBytesToRead,  // number of bytes to read
  LPDWORD lpNumberOfBytesRead, // number of bytes read
  LPOVERLAPPED lpOverlapped    // overlapped buffer
);

Parameters

异步的操作也可以用这个来做，前提是CreateFile的时候用了FILE_FLAG_OVERLAPPED。

并且写了个一个OVERLAPPED结构

这个结构需要一个event。那么我们还得写个event结构，这得用CreateEvent来创建。。。

麻烦死了。。

所以说。要处理异步读取文件内容，还是用专门的ReadFileEx来做吧。

异步。应该是操作系统给我们开了一个线程吧？？

——————>

nNumberOfBytesToRead。这个可以设为缓存区的大小，足够大就可以了

lpNumberOfBytesRead。这个是存储到底读了多少个字节。

返回值如果是0，就代表读取文件失败。

如果为非0，但是lpNumberOfBytesRead结果是0，就说明遇到了EOF position

——————>

WriteFile其实差不多的。但是过程可能会受到操作系统的调度，windows有维护的一个internal 缓存，我们的数据先是存到这些缓存区中的，然后windows再统一写到磁盘上。

为了保证万无一失写入了磁盘，那么，可以用FlushFileBuffers强迫把这个internal buffer的数据写到硬盘上。

也就是我们执行完WriteFile之后，再执行Flush。

——————>

可以使用LockFile和UnlockFile进行排他性数据读取写入操作。

这个排他，是指排除其他进程对该文件的操作。

这个可以防止文件在写入数据的时候被某个其他进程读取这一段数据。当然，这个很严格，是完全排除写和读了，用在这里有点浪费。这里有一句话：

File locks are not inherited by processes created by the locking process

我对进程创建进程还不清楚，以后来看看。

我们也可以使用LockFileEx和UnlockFileEx。

BOOL LockFileEx(
  HANDLE hFile,                   // handle to file
  DWORD dwFlags,                  // lock options
  DWORD dwReserved,               // reserved
  DWORD nNumberOfBytesToLockLow,  // low-order word of length
  DWORD nNumberOfBytesToLockHigh, // high-order word of length
  LPOVERLAPPED lpOverlapped       // contains starting offset
);

我对Ex程序都比较感兴趣。

这里的lock flags可以设定：

LOCKFILE_FAIL_IMMEDIATELY

LOCKFILE_EXCLUSIVE_LOCK

第一个是单线程操作用的，立即返回值的话，异步IO就没用了

第二个的话，是排他锁，完全禁止access。不设置的话，就是共享锁，可以读但不可以写。

lpOverlapped里面必须要包含加锁的开始offset.

event当为文件打开时为同步IO(同步IO的意思是执行完IO方法再执行进程里其他的方法，而异步IO指进程里的其他方法会继续执行，不等待IO的返回值，IO的返回值会在event里面有个回调函数来执行。)的时候，就可以为NULL。

当文件打开时为异步IO，就要写好event了。

——————>

同步IO比较简单哦，异步的话，还没接触过。

这里的共享锁和排他锁，使我想起了以前上过的操作系统。。。

这个两个词貌似是以前学过来的。

现在终于知道了windowsAPI中的方法。

你说吧，把MSDN翻译过来放到中文教材里面，还只讲理论，这个，有意义么？？好SB啊。