Project Chameleon Work In Progress 10

现在的进展是，UMDF驱动的DeviceIOControl和Read、Write已经都能使用了，并且FX2LP的EP6IN也正常工作，下面是工作中的测试代码截图：

 

Project Chameleon Work In Progress 9

这个项目时间真是拖得太久了，种种原因不能尽数。其中最窝心的一个问题是，Cypress没有提供能在Win7 64位下面使用的cyload和cyusb驱动。于是再拖延了很久以后，我发现UMDF可以解决自制驱动难以签名这个问题。经过一上午的调试，我写的这个Cypress Fx2lp驱动已经可以完成A0下载固件了。

调试UMDF驱动

HyperIris原创文章，谢绝转载

相对于调试运行在最高特权级的WDM、KMDF驱动，调试运行在ring3的UMDF驱动难度大为降低，不需要双机调试，我们可以像调试普通应用程序和服务一样在一台电脑上完成。

调试方法：

1. 编译好需要调试的驱动（包括安装用的inf等），连接硬件，把需要调试的驱动安装上。然后断开硬件连接（对于USB设备来说直接拔出就可以了）。
2. 启动WinDBG，设置好符号路径，特别是被调试驱动的符号。详细设置可以参考Debugging Tools的文档。
3. 运行regedit，打开HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWUDFServices{193a1820-d9ac-4997-8c55-be817523f6aa}，如果之前从未调试过UMDF驱动，会发现HostProcessDbgBreakOnDriverLoad键值为0，这个键值的含义是延迟多少秒加载驱动对象。我们把它修改为15秒（十六进制0xF，如果手慢可以改得更大）。注意这个键值不影响DllMain，如果要调试DllMain，请修改HostProcessDbgBreakOnStart。
4. 插入硬件，并且在15秒内使用WinDBG的Attach to Process（快捷键是F6），找到UMDFHost.exe，attach即可。注意如果系统有多个使用UMDF驱动的硬件，就会有多个UMDFHost.exe进程，为了不致混淆，请提前移除不用的硬件。
5. 完成调试后，请恢复注册表（将延迟修改为0），以免正常硬件的驱动加载被延迟。

微软近期产品使用感受

Windows 7：非常棒的产品，除了explorer里面展开子目录会自动滚到到最下面这个bug以外，堪称完美。

Office 2010：和Office 2007相比，可谓是百尺竿头更进一步。

Visual Studio 2010：WPF重新定义了VS的UI，从语言到代码编辑器每一个改动都非常有用，比如按住Ctrl可以缩放代码编辑器，比如头文件目录现在是per-project，比如start页面加了一个“打开工程后关闭”的选项。

x86 vs x64

今天看到某青年的blog转贴, 那文章写得真是阎王爷打报告, 鬼话连篇. 现在网上的东西真不能看.

在这里我来写一点点关于x86和x64的东西。

i686 : Intel 686 ( Pentium II, Pentium III , Pentim 4, K7 级别CPU ) i786 是一个隐藏的新体系(后面有描述)

严格的说，没有i786这种东西，一般认为Pentium Pro, P II和PIII是P6，而Pentium 4是超长流水线架构，现在的Intel产品则是Core架构，在ICC中都有对应的编译选项。不同的架构会影响编译器的设计，也就是编译器后端代码生成部分的策略。针对长短流水线所需要的优化技术显然是不同的。

其实如果你有源代码，32位系统的源代码基本上可以直接在 64 位的系统上面编译成为 64 位架构可运行的软件（新的技术还是用不上）。

这里涉及到一个很复杂的，牵扯面很广的交叉编译问题。

1 在64位下，不同厂家的编译器对数据类型的实际长度有不同的解释，具体可以参考维基百科

仅仅这个表格就足以说明存在很复杂的交叉编译问题。更进一步说，对于我们常用的CC++语言，很多人喜欢用int来保存两个指针的差，甚至写int i = &j这样的代码，这样的东西在64位下面是难以正确工作的（至少我们不能说可能能用的算法就是正确的算法）。

64位地址带来的问题是，数学运算结果不能保存在32位长度变量中，如果地址被截断，那就会变得毫无意义。

2 如果源代码是精心设计编写，能够被交叉编译到x64系统上，那么x64所引入的体系架构增强会被自然的采用，这主要有两点：

A：64位巨大的地址空间，可以处理更多的数据

B：对于高级语言来说，编译器会利用额外的8个通用寄存器R8~~r15来用作函数调用实参传递和临时变量，并且在像Windows这样的系统上，默认的系统调用约定由stdcall变成了fastcall，优势不言而喻。

当然，额外的不利情况也会出现：64位的代码比较大，会对I cache、D cache都造成更大的压力。简而言之就是双刃剑。