读过的介绍一下大致的框架结构，o(∩_∩)o...

reactOS Whitepaper翻译 选择自 leeews 的 Blog关键字 reactOS Whitepaper翻译出处 内容列表 1 介绍 2 执行层 2.1 硬件抽象层 2.2 设备驱动 2.3 内核 2.4 系统服务 3 保护子系统 4 本地API架构 5 兼容性目标1 介绍 reactOS的架构基于Microsoft Windows NT 4.0。虽然Microsoft宣称其架构为改进的微内核（综合了微内核和分层操作系统各方面的优点），但reactOS对该架构有着不同的定义。NT架构，以及由此而来的reactOS架构，是模块化和分层的架构。不能因为仅有的一点微内核架构的踪影就称其为改进的微内核架构。 在最底层是执行层，执行层包括在内核态运行的所有代码。执行层之上是保护子系统。该子系统提供不同操作系统的特点的实现。2 执行层 执行层所有代码都运行在内核态。执行层可以大略的分成下面几个组件。 硬件抽象层（HAL） 设备驱动 内核 系统服务（包含win32子系统） 这些组件均运行在内核态。HAL、内核、系统服务和设备驱动的集合称为执行层。 2.1 硬件抽象层 HAL使得reactOS x86内核和HAL可以运行在不同的x86母板上。HAL为内核抽象母板的特定代码，这样不同的母板就不需要改变内核。例如标准PC、日本的NEC PC98、以及x86 SGI工作站等不同的硬件设计。 2.2 设备驱动 设备驱动是reactOS执行层的硬件特定扩展。他允许操作系统与设备交互。 reactOS当前目标是实现Windows NT 4.0的设备驱动模块。Windows驱动模块（WDM）也将实现。WDM是编写便携式的Windows驱动的规则的集合。 通信： 设备驱动通过packets与内核和其他驱动通信。packetsIRP 利用IRP(IO Request Packets)通过IO Manager(系统服务)发送。 2.3 内核 内核的设计是基于 Microsoft Windows NT 4.0的。实现了内核态异步过程调用、延迟过程调用、进程、线程、互斥、信号量、转锁、时序代码等。 2.4 系统服务 系统服务包括： IO管理器 配置管理器 即插即用 电源管理 内存管理 执行层支持 对象管理器 安全参考监视器、进程结构、本地过程调用 win32子系统3 保护子系统 保护子系统允许不同操作系统的特点在reactOS的执行层上运行。最初的目标是win32子系统。然而win32子系统作为执行层的一部分运行在内核态，所以在此就不作为特性列出。 已实现的用户态子系统： POSIX OS/2 未来可能的保护子系统： DOS（可能是FreeDOS的一部分） 更多 win32子系统中为其他子系统提供服务的图形接口： Windows NT的图形设备驱动设计时紧密地集成在win32子系统中。因此在其他子系统中直接与图形驱动交互是不可能的。所以某个子系统应当为了图形接口而使用win32子系统。4 本地API架构 本地API架构允许用户态代码用标准方式调用内核态服务。它和大多数UNIX使用的系统调用接口是等价的。 Microsoft Windows NT/2000/XP并未对程序员提供本地API架构文档，使得他们必须使用win32 API来代替。因为reactOS是开源的，所以我们的本地API架构对应用程序开发者是开放的。 本地API架构在NTDLL.DLL中实现。另外NTDLL.DLL包含本地API用户态进入点，还包括进程启动和模块载入代码。这些进入点在系统表KiSystemServiceTable中查找内核态服务并在内核态调用KiSystemService。5 兼容性目标 ReactOS驱动和应用程序兼容性的最初目标是Microsoft Windows NT 4.0。后来Microsoft Windows 2000和Windows XP发布了。Microsoft Windows 2000和Windows XP都是Windows NT的后续版本。这样我们就可以逐步改变我们的兼容性目标而不用过于担心架构的改变。事实上，从本质上讲，Microsoft Windows 2000的版本是Windows NT 5.0而Windows XP是Windows NT 5.1. ReactOS小组决定保持Windows NT 4.0作为官方的兼容性目标。这是因为大部分的资源、文章、和Windows NT/2000/XP技术书籍均是为Windows NT 4.0而写。但这并不意味着在今后版本的特性描述中以Windows NT为基础的操作系统不会在reactOS中实现。作者Blog：http://blog.csdn.net/leeews/相关文章reactOS Whitepaper翻译

http://www.gywz.gz.cn/zb/modules/news/images/Architecture.gif

晕倒，跟WIN几乎没什么区别。。。。。

分析环境reactos0.3.1 ，i386体系]了解了windows的体系结构才知道reactos到底要干什么，以及如何干，因为reactos的目标是兼容windows。下面是windows的体系结构： 这是整个windows的体系结构的总览。从图上可以看出系统被分成内核模式和用户模式。内核模式的构成文件是系统的核心文件她包含： 1. hal.dll 2. ntoskrnl.exe 3. 设备驱动 4. 文件系统驱动 5. 图形设备驱动 6. win32k.sys1.首先来看第一层HAL（硬件抽象层） HAL使得reactOS 内核可以运行在不同的x86母板上。HAL为内核抽象母板的特定代码也许是对不同母板定义一种抽象的接口，向上提供一种标准的接口调用，这样不同的母板就不需要改变内核，思想上有点像驱动程序的设计，不过用在另外一个地方（具体的实现目前还不知道，以后边看代码边了解）。2.ntoskrnl（内核）内核又分成两层，第一层有的称为核心层（core）提供非常原始且基本的服务，如多处理器的同步、线程调度、中断分派等等。第二层是执行体（EXECUTIVE）内核执行体提供了系统的服务，这里的服务不是指windows服务管理器看到的那种服务，而是一些系统函数。而这些函数被划分成不同的类别：具备虚拟存储的内存管理：采用分段和分页以及虚拟内存的方式管理内存的使用。 1. 对象管理：采用面向对象的思想，用C来实现，在windows中一切资源都被抽象为对象。如文件对象，进程线程对象等。 2. 进程线程管理：负责创建和终止进程、线程。 3. 配置管理：负责管理注册表 4. 安全引用监视：在本地计算机上执行安全策略，保护计算机的资源 5. I/O管理：实现I/O的设备无关性，并负责把I/O请求分配给相应的设备驱动程序以进一步处理 6. 即插即用管理器（PNP）：确定设备应该由哪个驱动程序来支持并负责加载相应驱动。在启动时的枚举过程中，它收集每个设备所需要的硬件资源，并根据设备的需要来分配合适的硬件资源如I/O端口，IRQ，DMA通道之类，当系统中的设备发生变化时它负责向系统和应用程序发送通知消息。 7. 电源管理：协调电源时间，通过合理的配置，使得CPU降低电源消耗 8. 缓冲管理器：将最近使用过的数据留在CACHE中来提高系统的整体性能 9. 本地过程调用(LPC)管理 ReactOS因为兼容windows，因此在设计上也提供相同的功能，只是实现方法有所不同而已。 3.设备驱动程序 设备驱动程序是核心态可加载模块（以.SYS为扩展名，存放在system32\drivers），它们是I/O管理器和相关硬件设备的接口。设备驱动程序采用一种I/O管理所规定的接口标准来编写，因此可以被内核执行体的I/O管理单元调用来驱动硬件的工作。4.文件系统驱动程序文件系统驱动程序也是核心态可加载模块（以.SYS为扩展名system32\drivers），文件系统其实是强加给存储硬件的一种文件存放规则。某类文件系统其实就是按照他的文件存取规则在存储器上组织文件的信息。比如FAT32 按照FAT32的存储规则来存放文件ext2又按照ext2的文件规则存放文件。文件系统按照I/O管理的接口标准来实现一组存储规则，同时文件系统也可以将信息按照自己的存储方式请求I/O管理单元，让I/O管理单元通过这个设备的设备驱动程序将信息存放到该设备上。这样的方式使得文件系统只负责存储规则的定义。而驱动程序去处理硬件的调度（比如如何移动磁头臂，采用什么调度算法等）而I/O管理仅仅是他们之间的协调员，至于如何协调，I/O管理向外定义了自己的标准。5.图形设备驱动这个设备有点独特，从图上来看，（这个图是windows 2000的体系结构图）好像只有内核模式设备驱动也就是win32k.sys才能启动。图形设备驱动其实和其他的设备驱动程序我想也不会有太大的差别（以后看代码在了解）。不过有一点可以了解，那就是图形设备驱动是由win32k来驱动的，估计提供的也是硬件驱动。6.win32k这个东西应该是windows所说的win32子系统的内核部分（原生子系统，其他的子系统是可以分割的），如果没有这个子系统windows就不能运行？（好像微软是这么说的，原因好像是win32 的文档化的 API都是通过这个子系统实现的，据说最初的子系统都通过CSRSS来实现，这个东西最初好像包含至少3个子系统，1.win32，2.OS/2， 3.POSIX，随着win32的羽翼逐渐丰满，在发行时就不再包含其他两个。但是还是依然叫CSRSS，慢慢看代码才知道，这些都是道听途说）。win32k也被划分成两个部分，第一个是USER32，第二个是GDI32，ReactOS的win32K估计基本上都是通过wine移植过来的。USER32：包含了windows管理的操作吧，比如如何创建窗口，显示窗口，隐藏窗口，移动窗口排列窗口z轴，对拥有窗口的Z轴排序，Region（可视区域）操作，鼠标集中测试等。GDI32：包含图形设备的绘制操作（这些操作也可以叫服务），比如画点，画线，位图操作等，GDI会将一些复杂的绘图操作转变成简单的绘制请求发送给图形驱动程序（如果这个图形驱动程序不支持复杂绘制）还有就是一些设备无关的位图操作，有的可以保存在内存或文件，而如果将设备无关的位图输出的话就会被转换成设备相关的位图然后再输出。[如需转载请注明出处:(雄)blog.csdn.net/mickey139]

reactos的目标本来就是要兼容winNT的撒。。。这位仁兄的博客上倒有不少较为底层的研究。。。http://blog.csdn.net/mickey139

ReactOS CRDOM 文件结构- - 大致分析 ReactOS make bootcd 后自动编译生成的 iso 安装光盘文件内容。虽然很久很久以前就把这些文件猜的八九不离十，但是我想我现在和那时一样，对于这其中的东东还有很多很多并不了解。先记录在案，慢慢探索吧～～～[boot]: freeldr/bootsect/isoboot.asm 这是 ISO 光盘引导程序，它负责载入 loader/setupldr.sys （或者修复并引导硬盘上的 freeldr.sys ？？）/: 根目录下面是一个 readme 文件，一个光盘显示图标和自动运行配置文件 reactos/bootdata/loader/: freeldr 引导器的目录，*.bin 文件是各种引导介质的引导程序（freeldr/bootsect/）。setupldr.sys 是 ReactOS 安装引导器，freeldr.sys 是正常启动用的（freeldr/freeldr）。setupldr.sys: freeldr/freeldr/reactos/setupldr.c 安装引导器，载入 ReactOS 一个简单的基本系统，并且根据 hive*.inf 建立系统数据库（注册表）。reactos/: ReactOS 基本系统和安装包。hive*.inf: 系统注册表数据库基本文件，setupldr.sys 利用其建立安装时基本系统需要的注册表信息。txtsetup.sif: 这个文件描述基本系统文件在正常系统所安装的系统目录。reactos/bootdata/txtsetup.sif*.nls: 基本系统的国家代码页支持，国际化（简体中文是否一样？？） reactos/media/nls*.sys: 基本系统所需的硬件设备驱动，blue.sys 应该是显示驱动（是不是跟正常系统崩溃的时候使用的蓝屏显示用的同一个驱动），其他的如 keyboard.sys 键盘 disk.sys 硬盘 vfatfs.sys FAT 文件系统 看名字即可知道内容。驱动源代码散布与 reactos/drivers/ 目录ntoskrnl.exe: 内核，reactos/ntoskrnl/ 系统安装程序也是运行在 reactos 系统下的，由内核提供基本系统。ntoskrnl 被 ldr 载入完成后，启动 smss.exe 会话管理器。hal.dll: 硬件抽象层，这是 win nt 的特性，介于内核和实际驱动之间的可加载内核模块，隐藏硬件细节，hal 根据处理器的不同应有不同的版本，reactos 只支持 x86reactos.cab: 系统安装包。这不是一个普通的 cab 文件，其头部包含有 reactos/bootdata/packages/reactos.dff 记录安装信息。welcome.exe: 欢迎程序，^;^ 学足了 windows 安装光盘，呵呵 reactos/subsys/system/welcome/reactos/system32: 系统目录，这里是系统安装程序所在地。ntdll.dll: 系统服务调度占位程序，子系统 dll 函数入口点，这是一个中转站，将用户模式的程序调用交给内核启用内核模式完成。smss.exe: "会话管理器"，注意这是一个假的，
正确的
名字是 usetup 系统安装程序，代码位于 reactos/subsys/system/usetup/ 。smss 是正常启动时在 ntoskrnl 后加载的，所以这里 usetup 伪装成 smss 进行系统安装工作。注意 console.c 文件，好像是 usetup 自己实现了 console 。usetup 并不能在正常系统下使用。- 作者： larryli 2004年08月2日, 星期一 22:03 加入博采