.NET Compact Framework使用P/Invoke服务 （二）

三、 P/Invoke 的参数封送 我们知道，托管代码与非托管代码存在很大的差异， P/Invoke 在传递参数、返回值时需要先在托管类型和非托管类型之间进行转换，这整个过程有个专门术语，就叫做封送 (Marshal) 。 P/Invoke 可以为常规的数据类型进行正确地封送处理，如整型 int ，字节型 byte 。这些常规的数据类型被称为 blittable 类型，它们在托管代码和非托管代码中具有相同的表示， P/Invoke 在对它们进行封送时不需要进行任何特殊处理。因此使用 blittable 类型的非托管函数以用相同表示的托管类型导入其定义。假如有一个 DLL 中的函数的 C++ 签名为： int DllFunction_1(int index); 按如下方式导入定义： [DllImport("dllfile.dll")] public static extern int DllFunction_1(int i); 在这种情况下， P/Invoke 不需要进行任何特殊处理，可以正确地进行参数和返回值的封送。 具体 blittable 类型包括： 托管代码类型 C++ 代码类型 System.Byte unsigned char System.SByte byte System.Int16 short System.UInt16 unsigned short System.Int32 int System.Int64 long System.UInt64 unsigned long System.IntPtr 指针、句柄 System.Boolean bool System.Char wchar_t 或 TCHAR(16 位 UNICODE 字符 ) System.String* TCHAR * 或 LPWSTR(UNICODE 字符数组 ) 不仅以 blittable 类型本身作为参数或返回值的非托管函数可以用相同表示的托管类型导入其定义，只包含 blittable 类型（除标记 * 的 System.String 外）字段成员的构成的类或结构同样遵守这条规则。需要特别说明的是 System.String 是一个特例，它作为字段成员构成类或结构时不遵守这条规则。 然而，其它的类型无法不能直接按这种对应方式导入调用约定。假如有一个 DLL 中的函数的 C++ 签名为： double DllFunction_2(int index); 按如下方式导入定义： [DllImport("dllfile.dll")] public static extern double DllFunction_2(int i); 在这种情况下，会引发一个 NotSupportedException 异常。这是因为托管世界的 double 类型和非托管世界的 double 类型（这里是 C++ ）有着显著的不同， P/Invoke 无法正确地将返回值从非托管的 double 类型转换到托管 double 类型，因此调用失败。应该说， P/Invoke 同样无法正确的完成参数从托管 double 类型转换到非托管的 double 类型，但测试发现，实际上是可以完成的。如下 C++ 签名为： int DllFunction_3(double index); 按如下方式导入定义： [DllImport("dllfile.dll")] public static extern int DllFunction_3(double d); 作为参数值的托管 double 类型实际上可以被正确转换为非托管的 double 类型， P/Invoke 正确地完成了封送。但 MSDN 文档明确说明 .NET Compact Framework 的 P/Invoke 是无法支持对浮点类型通过值进行封送处理的，因此我们不能依赖作为参数的 double 类型可以被封送这个特例。在需要在托管世界和非托管世界之间传递 double 类型时，应该借助引用来对其进行封送，该引用将由 P/Invoke 封送为非托管世界的指针。下面是一个处理的例子 // 原有函数，由于返回值是 double 类型，无法被封送，需要改写 double DllFunction_2(int index); // 对 DllFunction_2 函数加上一个包装，改为以指针作为参数值递返回值 void DllFunction_Sub(int index, double * result) {       *result = DllFunction_2(index);// 这里调用原有函数 } 按如下方式导入定义，注意导入的函数是 DllFunction_Sub ： [DllImport("dllfile.dll")] public static extern void DllFunction_Sub(int index, out double result); 　　可以为托管代码的调用再增加一个包装，保持与实际调用函数具有相同的签名： public static double DllFunction_2(int index) { double result; DllFunction_Sub (index, out result); return result; } 通过增加一个包装这种间接的方式，我们利用 P/Invoke 可以对引用进行封送的特性，完成了对实际具有如下签名的非托管函数的调用： double DllFunction_2(int index); 四、使用 P/Invoke 调用 Windows CE 的 API coredll.dll 是 Windows CE 的核心模块，大致相当于 Windows 2000/XP 的 kernel32.dll 。 coredll.dll 是 Windows CE 系统最重要的文件，基本上每个 CE 系统都会在 ROM 中包括该文件。在 Pocket PC 2003 Second Edition(Window CE 4.2 ，以下简称 PPC) 系统中，其全路径为 /windows/coredll.dll 。由于该文件在 ROM 中，因此使用 PPC 自带的资源管理器无法看到该文件。可以通过 TotalCommander 查看该文件，但仍然无法复制该文件。在安装了 platform builder 后可以在安装目录下找到 coredll.dll 文件。 绝大多数的 Windows CE API 都是通过 coredll.dll 向外暴露。因此在使用 P/Invoke 调用 coredll.dll 中的 api 时，值得关心的是该文件中所包含的 api 函数。可以通过 dumpbin.exe 来查看其导出符号。 在无法直接得到 coredll.dll 时，可以通过该文件对应的 LIB 导入文件进行分析而获知 coredll.dll 包含的 api 函数。安装 vs2005 后，可以在 [ 安装目录 ]/SmartDevices/SDK/PocketPC2003/Lib/armv4 下找到 coredll.lib 文件，它就是 coredll.dll 对应的 LIB 导入文件。运行 vs2005 命令行工具，执行 dumpbin /exports [ 安装目录 ]/SmartDevices/SDK/PocketPC2003/Lib/armv4/coredll.lib 即可得到 coredll.dll 包含函数的列表。如果进一步需要得到某个 api 函数的参数及返回值类型则需要进行深入逆向工程分析了，就比较复杂。好在这些可以从微软的 MSDN 文档中得到某 api 的具体说明。 当需要确定其它 dll 中有什么函数时，同样可以通过使用 dumpbin 导出查看其中包含的函数。 文中代码全部在 vs2005(C# 智能设备 Pocket PC 2003 应用程序和 MFC 智能设备 DLL) 和 PPC 模拟器下运行通过。