引言

一般的，我们在编写用户态程序(包括普通的应用程序、服务程序、用户态驱动、一些扩展插件)时，每当我们遇到一个不熟悉的API，我们就会打开开发文档，或者MSDN，查查每个参数是怎么填的。(我想你应该没把这些API给背下来了吧^^)

我们在调试时发现执行到这些API时是跟不进去的，那么你想过它们是如何进入操作系统里面工作的吗？它们又是如何在操作系统里面工作的？

比如文件系统的一个API：

HANDLE CreateFile(
  LPCTSTR lpFileName,
  DWORD dwDesiredAccess,
  DWORD dwShareMode,
  LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  DWORD dwCreationDisposition,
  DWORD dwFlagsAndAttributes,
  HANDLE hTemplateFile
);

那么这系列文章就是尝试弄清楚这些的一些问题。但是在实际摸索过程中我发现这些远比我想象中复杂，甚至经常迷失了。如果你发现文章有不对的或者可以改进的地方请不吝赐教。

在没有文档的情况下去研究CE的源码是件比较吃力的事，这就是我分享这一系列文章的原因。不管你是在CE平台还是在嵌入式Linux平台下面开发，深入一下CE内部都是件有趣并且有意义的事。而且这些知识对在CE上从事较靠近Kernel的开发以及对问题的深一层次追踪是非常有帮助的。

再说这些机制在不同操作系统上也大同小异(它们本身也会相互学习和借鉴)，熟悉一个之后这些知识能够很好的重用在别的地方。所以与只知道拖控件相比，知道How does xxx work?会更有意义。

概述

这篇文章就是对《Windows Embedded CE 6.0 Internals (4) The Mechanism of API》的进一步补充和深入，把一些迷糊的问题搞清楚点。

我大体罗列了这篇文章涉及的问题：

What is PSL(process server library)?
What is a Kernel-mode/User-mode server?
What is Trap?
What is Thunking?
How Thread Transition when API call?
以下API的作用以及意义：CreateAPISet/CreateAPIHandle/RegisterAPISet/RegisterDirectMethods/WaitForAPIReady(IsAPIReady)/GetAPIAddress/QueryAPISetID

在文章《Inside Windows CE API Calls》非常好的描述了CE的API机制，我在这里简单翻译和整理一下，以便先从整体上了解一下：

CE的API是由若干个服务进程(PSL)实现的：内核进程(NK.exe)、filesys.exe、gwes.exe、device.exe、services.exe(在CE6.0之前是这样的，而在CE6.0/7.0时这些exe大多已经被实现成dll，比如kernel.dll、filesys.dll、device.dll、gwes.dll等。并且PSL分成了Kernel-mode server和User-mode server，这个我在后面详细介绍。)

当我们的应用程序调用这些PSL的API时，我们一般会跳进这些PSL去执行对应的API实现。

大部分API都是从coredll.dll导出的，我们的应用程序会链接到这个DLL文件。当我们调用API时，比如GetTickCount，我们其实是调用coredll.dll导出的GetTickCount(coredll.dll相当于一个wrapper，我们经常也叫做“thunk”，kcoredll.dll在后面介绍。)：

DWORD xxx_GetTickCount()
{
    return GetTickCount();
}

你能从这里看到更多的thunk，并能看到更多的xxx_前缀的thunk(但并不是全部都是)：

%_WINCEROOT%\private\winceos\coreos\core\thunks\*

我们发现这里的函数名前面都有xxx_，但是实际我们在文档里看到的并没有xxx_前缀，这是因为在这里我们重命名这些API了：

%_WINCEROOT%\private\winceos\coreos\core\coredll.def

像这样：

GetTickCount=xxx_GetTickCount

在上面的xxx_GetTickCount函数里面我们就直接return一个函数：GetTickCount，那么这个函数到底是什么呢？从这里你能找到答案：

%_WINCEROOT%\public\common\oak\inc\*

它其实只是个宏定义，像这样：

define GetTickCount    COMPLICATED_MACRO(..., SH_WIN32, W32_GetTickCount, ...)

SH_WIN32在SDK中被定义成0(GetTickCount所在的API set table所在的ID)，而W32_GetTickCount在另一个OAK头文件中被定义成13(GetTickCount在API set table里面的索引)。

为了思路清晰，COMPLICATED_MACRO我们不再展开了，实际上当调用这个宏时它就会跳转到一个地址，一个什么地址呢？在文章《Windows Embedded CE 6.0 Internals (4) The Mechanism of API》中提到了KDataStruct这个结构体，其开始地址是固定的PUserKData，对于ARM处理器是0xFFFFC800，而其它处理器是0x00005800。恩，就是跳转到偏移PUserKData一定量的位置，不管是0xFFFF…还是0x0000…，都是个特殊的位置，这些位置都是Trap，向这些Trap的跳转会产生Exception，《Inside Windows CE API Calls》用一句小幽默解释道：

All exceptions go to the kernel first, and the kernel says,"A-ha! I know this invalid address. It's the encoding for an API, index 13 of API table 0."

之后Kernel会去做一些工作：marshals (maps) arguments, adjusts permissions, flushes cache and TLB(页表缓冲)，如果需要的话。一起都准备好之后，请求的API所在的PSL进程里的线程将会被执行。

可以参考：

%_WINCEROOT%\private\winceos\coreos\nk\kernel\x86\fault.c, Int20SyscallHandler.
%_WINCEROOT%\private\winceos\coreos\nk\kernel\objdisp.c, ObjectCall()

当PSL进程里的API调用执行完之后，调用返回时会触发另一个Exception(Kernel设置了返回地址为另一个指定的代码地址)，Kernel再一次adjusts arguments, permissions, and other state，比如必要的话。就这样CPU执行权再一次返回到原调用进程。

可以参考：

%_WINCEROOT%\private\winceos\coreos\nk\kernel\x86\fault.c, ServerCallReturn.

从应用程序开始的API调用的一个简单的流程我们搞清楚了。(实际上整个操作系统的API调用机制是非常复杂的，这里说的只是最一般的情况。)

文章《Inside Windows CE API Calls》后面关于KMODE部分的介绍是针对CE 6.0之前版本的，在CE 6.0时有较大变化。另外作者说到：

In Windows CE, "kernel mode" threads have permission to access memory addresses outside of their own process.

这是不准确的(你从后面的留言中能够了解到更多)，这在CE 6.0/7.0上就更不准确了，因为连slot都没有了。

后续内容

在下一篇文章中我将扩展开来介绍API的机制，包括更多的API调用情景，比如：

从应用程序(或者User-mode server)调用Kernel-mode server
从Kernel-mode server调用Kernel-mode server
从应用程序调用User-mode server
从Kernel-mode调用User-mode server
从Kernel调用Kernel

在调用中遇到的Calling back & forward问题，以及如何Mapping指针以及访问其它进程的内存和API是如何注册的。我把在学习过程中得到的收获拿出来跟大家分享和讨论，请大家能够指正我的错误。

Windows Embedded CE 6.0 Internals (5) The Mechanism of API

引言

概述

后续内容

更多参考