Nativeapp基本工作原理.docVIP

Native app 程序开发 By microDebug 程序类型 关于程序级别的分类，大概可以分为三层： 应用层程序，即普通的APP程序； Native App程序，如常见的chkdsk工具，PQ分区工具等，都属于这类，它是在win子系统未启动起来就执行的程序，执行环境比较纯净，只能调用ntdll.dll导出的函数； Driver 内核驱动程序，内核态程序；native app在项目开发中用的较少，所用的函数接口MS也均未公开，开发难度和驱动相当，所以很少有人问津。但是，事实上，在某些应用场景下，用native app来实现是非常完美的，比如：接管winodws的开机启动界面和密码输入界面，需要native app；在开机前，执行磁盘修复，需要native app；开机前，执行杀毒，或者磁盘整理，因为此时环境比较纯净，需要native app。诸如此类~ 最近，开发一个Native App项目，其规模和复杂度也不一般。期间遇到很多问题，在逐一解决的时候也收获了很多东西Native app 基本工作原理 这里，只想简单的描述下。 Windows的设计是基于分层模型的，在设计之初，内核NT支持三个子系统，OS/2,posix,win32,这些子系统同属于一个层面上，它们公用windows nt提供的系统API和例程。其中，在某一个子系统上的API调用，都会经过NT”native”API同windowsNT进行通信。这些native API就是ntdll.dll导出的函数，因为它导出的大部分函数都只是起一个从子系统到NT内核的转发传递作用，所以也成为stub函数，这些函数的原型大多是未公开的，在早期的DDK里会有相关的描述，但是现在没了，取而代之的是内核实现的zw*,nt*开头的驱动函数。这里表明了MS的一个态度，不希望第三方在native app上干涉windows的太多工作，比如，接管了开机启动系统，接管了登录密码界面:D. 后来，因为种种历史原因，对OS/2和posix子系统的支持逐渐被淡忘。但是这种分层模型仍然存在，native app就是工作在子系统未启动之前，此时的系统环境很纯净，权限也相对较高；另外，对操作系统来说，支持native app也是一种必须，因为在子系统启动之前，很多功能的程序只能以native app来呈现，比如登录界面，CSRSS~ 具体的启动时机： Native app由启动会话管理器(smss.exe)来启动，如果想通知smss来执行一个native app程序，只需要修改一个注册表项，smss在每次启动的时候会去检查该项，确保该项下面的每个native app程序依次执行。注册表项为：HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute ，其类型为MULTI_SZ, 又是MS玩的一种字符串类型—多字符串类型，也就是说，这个MULTI_SZ字符串包含多个以\0结尾的子字符串，而整个字符串以\0\0结尾。在该注册表项后面添加要注册的native 程序名和参数就可以了。 关于native app的更多详细介绍，可以参考Mark Russinovich的一篇关于native的文章。 开发相关 Native app程序结构 Native app程序结构很简单，就好像我们写hello world，需要写一个main函数入口一样，native app的入口函数是NtProcessStartup，形如： void NtProcessStartup( PSTARTUP_ARGUMENT Argument ) 其中，参数PSTARTUP_ARGUMENT是一个结构体，用来存放传入参数。 程序退出时，主动调用函数NtProcessTerminate退出，它不会像普通应用程序一样一个返回return就退出了。 基本的结构就是这样了： void NtProcessStartup( PSTARTUP_ARGUMENT Argument ) { // do something else NtProcessTerminate(?NtCurrentProcess(), 0?); } 当然现在还没有包含头文件之类的。 开发语言及第三方的库 Native app支持的开发语言有C/ASM/C++,并且完美的支持C++的类特性,不过要像编写驱动一样，需要重载new,delete等内存分配函数。 在内存使用上，可以使用两套接口：堆函数接口，以及虚拟内存函数接口，但是根据我的经验，使用堆函数接口，更高效并且内存bug出现的频率会大大降低。举个例子：我在调试native app的时候，一切正常，且全部通过，但是双机调试的时候，功能代码都运行完了，