ReactOS怎样实现系统调用
毛德操
 
 有网友在论坛上发贴，要求我谈谈ReactOS是怎样实现系统调用的。另一方面，我上次已经谈到兼容内核应该如何实现Windows系统调用的问题，接着谈谈ReactOS怎样实现系统调用倒也顺理成章，所以这一次就来谈谈这个话题。不过这显然不属于“漫谈Wine”的范畴，也确实没有必要再来个“漫谈ReactOS”，因此决定把除Wine以外的话题都纳入“漫谈兼容内核”。
 ReactOS这个项目的目标是要开发出一个开源的Windows。不言而喻，它要实现的系统调用就是Windows的那一套系统调用，也就是要忠实地实现Windows系统调用界面。本文要说的不是Windows系统调用界面本身，而是ReactOS怎样实现这个界面，主要是说说用户空间的应用程序怎样进入/退出内核、即系统空间，怎样调用定义于这个界面的函数。实际上，ReactOS正是通过“int 0x2e”指令进入内核、实现系统调用的。虽然ReactOS并不是Windows，它的作者们也未必看到过Windows的源代码；但是我相信，ReactOS的代码、至少是这方面的代码，与“正本”Windows的代码应该非常接近，要有也只是细节上的差别。
下面以系统调用NtReadFile()为例，按“自顶向下”的方式，一方面说明怎样阅读ReactOS的代码，一方面说明ReacOS是怎样实现系统调用的。
 
首先，Windows应用程序应该通过Win32 API调用这个接口所定义的库函数，这些库函数基本上都是在“动态连接库”、即DLL中实现的。例如，ReadFile()就是在Win32 API中定义的一个库函数。实现这个库函数的可执行程序在Windows的“系统DLL”之一kernel32.dll中，有兴趣的读者可以在Windows上用一个工具depends.exe打开kernel32.dll，就可以看到这个DLL的导出函数表中有ReadFile()。另一方面，在微软的VC开发环境(Visual Studio)中、以及Win2k DDK中，都有个“头文件”winbase.h，里面有ReadFile()的接口定义：
 
WINBASEAPI
BOOL
WINAPI
ReadFile(
 IN HANDLE hFile,
 OUT LPVOID lpBuffer,
 IN DWORD nNumberOfBytesToRead,
 OUT LPDWORD lpNumberOfBytesRead,
 IN LPOVERLAPPED lpOverlapped
 );
 
 函数名前面的关键词WINAPI表示这是个定义于Win32 API的函数。
在ReactOS的代码中同样也有winbase.h，这是在目录reactos/w32api/include中：
 
BOOL WINAPI ReadFile(HANDLE, PVOID, DWORD, PDWORD, LPOVERLAPPED);
 
 显然，这二者实际上是相同的(要不然就不兼容了)。当然，微软没有公开这个函数的代码，但是ReactOS为之提供了一个开源的实现，其代码在reactos/lib/kernel32/file/rw.c中。
 
BOOL STDCALL
ReadFile( HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead,
 LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverLapped )
{
 ……
 
 errCode = NtReadFile(hFile,
 hEvent,
 NULL,
 NULL,
 IoStatusBlock,
 lpBuffer,
 nNumberOfBytesToRead,
 ptrOffset,
 NULL);
 
 ……
 return(TRUE);
}
 
我们在这里只关心NtReadFile()，所以略去了别的代码。
如前所述，NtReadFile()是Windows的一个系统调用，内核中有个函数就叫NtReadFile()，它的实现在ntoskrnl.exe中(这是Windows内核的核心部分)，这也可以用depends.exe打开ntoskrnl.exe察看。ReactOS代码中对内核函数NtReadFile()的定义在reactos/include/ntos/zw.h中，同样的定义也出现在reactos/w32api/include/ddk/winddk.h中：
 
NTSTATUS
STDCALL
NtReadFile(
 IN HANDLE FileHandle,
 IN HANDLE Event OPTIONAL,
 IN PIO_APC_ROUTINE UserApcRoutine OPTIONAL,
 IN PVOID UserApcContext OPTIONAL,
 OUT PIO_STATUS_BLOCK IoStatusBlock,
 OUT PVOID Buffer,
 IN ULONG BufferLength,
 IN PLARGE_INTEGER ByteOffset OPTIONAL,
 IN PULONG Key OPTIONAL 
 );

void write_syscall_stub(FILE* out, FILE* out3, char* name, char* name2,
 char* nr_args, unsigned int sys_call_idx)
{
 int i;
 int nArgBytes = atoi(nr_args);
 
#ifdef PARAMETERIZED_LIBS
 ……
#else
 fprintf(out,"__asm__(\"\\n\\t.global _%s\\n\\t\"\n",name);
 fprintf(out,"\".global _%s\\n\\t\"\n",name2);
 fprintf(out,"\"_%s:\\n\\t\"\n",name);
 fprintf(out,"\"_%s:\\n\\t\"\n",name2);
#endif
 fprintf(out,"\t\"pushl\t%%ebp\\n\\t\"\n");
 fprintf(out,"\t\"movl\t%%esp, %%ebp\\n\\t\"\n");
 fprintf(out,"\t\"mov\t$%d,%%eax\\n\\t\"\n",sys_call_idx);
 fprintf(out,"\t\"lea\t8(%%ebp),%%edx\\n\\t\"\n");
 fprintf(out,"\t\"int\t$0x2E\\n\\t\"\n");
 fprintf(out,"\t\"popl\t%%ebp\\n\\t\"\n");
 fprintf(out,"\t\"ret\t$%s\\n\\t\");\n\n",nr_args);
 ……
}
 
 代码中的’\t’表示TAB字符，读者阅读这段代码应该没有什么问题。这段代码根据name、nr_args、sys_call_idx等参数为给定系统调用生成stub函数的汇编代码。那么这些参数从何而来呢？在ReactOS代码的reactos/tools/nci目录下有个文件sysfuncs.lst，下面是从这个文件中摘出来的几行：

NtAcceptConnectPort 6
NtAccessCheck 8
NtAccessCheckAndAuditAlarm 11
NtAddAtom 3
……
NtClose 1
……
NtReadFile 9
……

这里的NtAcceptConnectPort就是调用号为0的系统调用NtAcceptConnectPort()，它有6个参数。另一个系统调用NtClose()只有1个参数。而NtReadFile()有9个参数，并且正好是这个表中的第153行，所以调用号是152。
 
 用户空间的程序一执行int 0x2e，CPU就自陷进入了系统空间。其间的物理过程这里就不多说了，有需要的读者可参考“情景分析”或其它有关资料。我这里就从CPU怎样进入int 0x2e的自陷处理程序说起。
 像别的中断向量一样，ReactOS在其初始化程序KeInitExceptions()中设置了int 0x2e的向量，这个函数的代码在reactos/ntoskrnl/ke/i386/exp.c中：

确实不错.大力支持一下
rabbit