欢迎大家赞助一杯啤酒🍺 我们准备了下酒菜：Formal mathematics/Isabelle/ML, Formal verification/Coq/ACL2, C++/F#/Lisp
ReactOS/developer
(以内容'==简介== ReactOS 的架构是基于微软 Windows 2003 服务器。ReactOS 架构，就如 NT，是整体式但是能够载入模块。在最低层是可执行区。...'创建新页面) |
小 (→兼容性目标) |
||
| （未显示1个用户的1个中间版本） | |||
| 第2行： | 第2行： | ||
[[ReactOS]] 的架构是基于微软 Windows 2003 服务器。ReactOS 架构，就如 NT，是整体式但是能够载入模块。在最低层是可执行区。可执行区包括一切能够在内核模式里运行的可执行程序。在可执行区之上是受保护的子系统。这些子系统提供不同操作系统本身个性的实现。 | [[ReactOS]] 的架构是基于微软 Windows 2003 服务器。ReactOS 架构，就如 NT，是整体式但是能够载入模块。在最低层是可执行区。可执行区包括一切能够在内核模式里运行的可执行程序。在可执行区之上是受保护的子系统。这些子系统提供不同操作系统本身个性的实现。 | ||
| − | 可执行区 | + | |
| + | ==可执行区== | ||
可执行区就是那些在内核模式运行的代码。它大概可以分成几个组件：Hardware Abstraction Layer（缩写 HAL，硬件抽象层），设备驱动程序，内核本身，系统服务（包括 Win32k 子系统）。这些组件都能够在内核模式中运行。硬件抽象层，内核，系统服务以及设备驱动程序都统称为可执行区。 | 可执行区就是那些在内核模式运行的代码。它大概可以分成几个组件：Hardware Abstraction Layer（缩写 HAL，硬件抽象层），设备驱动程序，内核本身，系统服务（包括 Win32k 子系统）。这些组件都能够在内核模式中运行。硬件抽象层，内核，系统服务以及设备驱动程序都统称为可执行区。 | ||
| 第9行： | 第10行： | ||
就是硬件抽象层才能有 x86 ReactOS 内核并且是它才能让操作系统能够在不同的 x86 主机板中运行。硬件抽象层将从内核抽取内核特定的代码，如此一来不同的主机板就无需要内核的更改。不同硬件设计的例子就比如标准个人计算机，日本 NEC PC98 或 x86 SGI 工作站。 | 就是硬件抽象层才能有 x86 ReactOS 内核并且是它才能让操作系统能够在不同的 x86 主机板中运行。硬件抽象层将从内核抽取内核特定的代码，如此一来不同的主机板就无需要内核的更改。不同硬件设计的例子就比如标准个人计算机，日本 NEC PC98 或 x86 SGI 工作站。 | ||
| − | 设备驱动程序 | + | |
| + | ==设备驱动程序== | ||
设备驱动程序在 ReactOS 可执行区里是硬件特定的扩展。它们允许操作系统与某些设备互动以及反之亦然。目前 ReactOS 计划实现 NT 驱动程序模式，它是 Windows Driver Model (WDM) 的子集。WDM 是一套编写可移植 Windows 驱动程序的规则。在 Windows Vista 所引进的 Windows Driver Foundation (WDF) 也考虑为未来开发的功能。 | 设备驱动程序在 ReactOS 可执行区里是硬件特定的扩展。它们允许操作系统与某些设备互动以及反之亦然。目前 ReactOS 计划实现 NT 驱动程序模式，它是 Windows Driver Model (WDM) 的子集。WDM 是一套编写可移植 Windows 驱动程序的规则。在 Windows Vista 所引进的 Windows Driver Foundation (WDF) 也考虑为未来开发的功能。 | ||
| 第16行： | 第18行： | ||
设备驱动程序使用包与内核和其他驱动程序通讯。这些包是通过输进、出管理器（系统服务）所发送并且使用 IRP（输进、出要求包）。 | 设备驱动程序使用包与内核和其他驱动程序通讯。这些包是通过输进、出管理器（系统服务）所发送并且使用 IRP（输进、出要求包）。 | ||
| − | 内核 | + | |
| + | ==内核== | ||
这个内核的设计是基于微软 Windows 2003 服务器的。它实现内核模式的 Asynchronous Procedure Calls（缩写 APC，异步过程调用），Deferred Procedure Calls（缩写 DPC，延迟过程调用），进程，线程， mutexes（互斥），semaphores（信号），spinlocks（自旋锁），timing code（定时器代码），还有更多。 | 这个内核的设计是基于微软 Windows 2003 服务器的。它实现内核模式的 Asynchronous Procedure Calls（缩写 APC，异步过程调用），Deferred Procedure Calls（缩写 DPC，延迟过程调用），进程，线程， mutexes（互斥），semaphores（信号），spinlocks（自旋锁），timing code（定时器代码），还有更多。 | ||
| 第36行： | 第39行： | ||
关于 ReactOS 原先对驱动程序和应用程序兼容性的目标是微软 Windows NT 4.0。自从此时，微软 Windows 2000, XP, 2003 服务器，和 Vista 也接二连三的发布了。这些都是 Windows NT 的后代。为此，我们能够逐步提升我们的兼容性目标而无需担忧架构出现过多的更改。事实上，Windows 2000 的内部报告版本为 Windows 5.0，XP 为 Windows 5.1，2003 服务器为 Windows 5.2，以及 Vista 为 Windows 6.0。目前 ReactOS 团队锁定 Windows 2003 服务器为官方兼容性目标。在当中现有的发布中，2003 服务器已经证明自己是当中最坚固的。这并不表示那些功能只出现在后续基于 Windows NT 版本的操作系统将不会在 ReactOS 里实现并且我们将持续努力实现较新的 API。 | 关于 ReactOS 原先对驱动程序和应用程序兼容性的目标是微软 Windows NT 4.0。自从此时，微软 Windows 2000, XP, 2003 服务器，和 Vista 也接二连三的发布了。这些都是 Windows NT 的后代。为此，我们能够逐步提升我们的兼容性目标而无需担忧架构出现过多的更改。事实上，Windows 2000 的内部报告版本为 Windows 5.0，XP 为 Windows 5.1，2003 服务器为 Windows 5.2，以及 Vista 为 Windows 6.0。目前 ReactOS 团队锁定 Windows 2003 服务器为官方兼容性目标。在当中现有的发布中，2003 服务器已经证明自己是当中最坚固的。这并不表示那些功能只出现在后续基于 Windows NT 版本的操作系统将不会在 ReactOS 里实现并且我们将持续努力实现较新的 API。 | ||
| − | [[ | + | [[category:developer]] |
| + | [[category:ReactOS]] | ||
2013年2月21日 (四) 14:23的最后版本
目录 |
[编辑] 简介
ReactOS 的架构是基于微软 Windows 2003 服务器。ReactOS 架构，就如 NT，是整体式但是能够载入模块。在最低层是可执行区。可执行区包括一切能够在内核模式里运行的可执行程序。在可执行区之上是受保护的子系统。这些子系统提供不同操作系统本身个性的实现。
[编辑] 可执行区
可执行区就是那些在内核模式运行的代码。它大概可以分成几个组件：Hardware Abstraction Layer（缩写 HAL，硬件抽象层），设备驱动程序，内核本身，系统服务（包括 Win32k 子系统）。这些组件都能够在内核模式中运行。硬件抽象层，内核，系统服务以及设备驱动程序都统称为可执行区。
[编辑] 硬件抽象层
就是硬件抽象层才能有 x86 ReactOS 内核并且是它才能让操作系统能够在不同的 x86 主机板中运行。硬件抽象层将从内核抽取内核特定的代码，如此一来不同的主机板就无需要内核的更改。不同硬件设计的例子就比如标准个人计算机，日本 NEC PC98 或 x86 SGI 工作站。
[编辑] 设备驱动程序
设备驱动程序在 ReactOS 可执行区里是硬件特定的扩展。它们允许操作系统与某些设备互动以及反之亦然。目前 ReactOS 计划实现 NT 驱动程序模式，它是 Windows Driver Model (WDM) 的子集。WDM 是一套编写可移植 Windows 驱动程序的规则。在 Windows Vista 所引进的 Windows Driver Foundation (WDF) 也考虑为未来开发的功能。
[编辑] 通讯
设备驱动程序使用包与内核和其他驱动程序通讯。这些包是通过输进、出管理器（系统服务）所发送并且使用 IRP（输进、出要求包）。
[编辑] 内核
这个内核的设计是基于微软 Windows 2003 服务器的。它实现内核模式的 Asynchronous Procedure Calls（缩写 APC，异步过程调用），Deferred Procedure Calls（缩写 DPC，延迟过程调用），进程，线程， mutexes（互斥），semaphores（信号），spinlocks（自旋锁），timing code（定时器代码），还有更多。
[编辑] 系统服务
系统服务就包括：输进、出管理器，配置管理器，即插即用，电源管理器，内存管理器，可执行区支持，对象管理器，保安引用检视器，进程结构，本地过程调用，Win32 子系统。
[编辑] 受保护的子系统
受保护的子系统将允许操作系统不同的个性在 ReactOS 可执行区之上运行。ReactOS 的初始目标是 Win32k 子系统 – 可是，Win32k 子系统作为可执行区之一在内核模式里运行也就因此在这里将不会被提起。关于其他图形子系统，那里确实存在一个为子系统通过 Win32k 子系统的界面。Windows NT 的图形设备驱动程序在设计上是与 Win32k 子系统紧密集合。因此这样，要一个用户模式子系统直接与图形驱动程序互动是不切实际。为此原因，一个子系统在图形界面上就应该利用 Win32k 子系统的内核模式。这些子系统并不依赖于 Win32k 窗口管理器，但是可以直接使用 Win32k 子系统所提供的原始图形。
[编辑] 原生 API（应用程序编程界面）架构
在标准行为下原生 API 架构调用用户模式的代码来调用内核模式的服务。这与多数 Unix 的 System Call Interface（系统调用界面）相似。微软 Windows NT/2000/XP 并没有为编程员记载原生 API 架构，所以他们必须使用 Win32 的 API。既然 ReactOS 是开源，所以我们的原生 API 架构是为应用程序编程员所开放。这个原生 API 架构是在 NTDLL.dll 里实现。除了包含原生 API 用户模式的入口点，NTDLL.dll 也包含进程启动和载入模块的代码。这些入口点在内核模式里调用 KiSystemService，从而在系统表 – KiSystemServiceTable 里寻找内核模式的服务。
[编辑] 兼容性目标
关于 ReactOS 原先对驱动程序和应用程序兼容性的目标是微软 Windows NT 4.0。自从此时，微软 Windows 2000, XP, 2003 服务器，和 Vista 也接二连三的发布了。这些都是 Windows NT 的后代。为此，我们能够逐步提升我们的兼容性目标而无需担忧架构出现过多的更改。事实上，Windows 2000 的内部报告版本为 Windows 5.0，XP 为 Windows 5.1，2003 服务器为 Windows 5.2，以及 Vista 为 Windows 6.0。目前 ReactOS 团队锁定 Windows 2003 服务器为官方兼容性目标。在当中现有的发布中，2003 服务器已经证明自己是当中最坚固的。这并不表示那些功能只出现在后续基于 Windows NT 版本的操作系统将不会在 ReactOS 里实现并且我们将持续努力实现较新的 API。
