React OS

http://www.reactos.org/media/screens...r/shell_02.jpg
Introduction

The ReactOS architecture is based on that of Microsoft Windows NT 4.0. Although Microsoft claims that the architecture is a modified micro-kernel (combining aspects of both micro-kernels and layered operating systems), at ReactOS we have a different definition of the architecture. The NT, and therefore ReactOS architecture, is modular and layered. The small traces of microkernel architecture are not enough for it to be described as a modified micro-kernel. At the lowest layer is the Executive. The executive includes everything that runs in kernel mode. Above the executive are the Protected Subsystems. These subsystems provide implementations of different Operating System personalities.

The Executive

The Executive is all the code that runs in kernel mode. The executive can roughly be broken up into the following components: Hardware Abstraction Layer (HAL), Device Drivers, The Kernel, System Services (including the Win32 subsystem) These components all run in kernel mode. The HAL, Kernel, System Services and Device Drivers are collectively referred to as the Executive.
http://www.reactos.org/media/screens..._qemu_mini.png http://www.reactos.org/media/screens...an_01_mini.jpg
Hardware Abstraction Layer

The HAL makes it possible for the x86 ReactOS kernel and HAL to run on different x86 motherboards. The HAL abstracts motherboard specific code from the kernel, so that different motherboards do not require changes in the kernel. Examples for different hardware designs are the standard PC, the Japanese NEC PC98 or x86 SGI workstations.
Device Drivers

Device drivers are hardware specific extensions to the ReactOS Executive. They allow the Operating System to interact with certain devices and visa versa. ReactOS currently aims to implement the Windows NT 4.0 device driver model. The Windows Driver Model (WDM) is also a concern for the immediate future. WDM is a set of rules for writing portable Windows drivers.

Communication

Device drivers use packets to communicate with the kernel and with other drivers. Packets are sent via the IO Manager (System Service) and make use of IRPs (IO Request Packets).

Kernel

The kernel design is based on that of Microsoft Windows NT 4.0. It implements kernel mode Asynchronous Procedure Calls (APCs), Deferred Procedure Calls (DPCs), processes, threading, mutexes, semaphores, spinlocks, timing code and more.

System Services

System services include: IO Manager, Configuration Manager, Plug and Play, Power Manager, Memory Manager, Executive Support, Object Manager, security reference monitor, process structure, local procedure call, Win32 Subsystem.
http://www.reactos.org/media/screens...shop3_mini.jpg http://www.reactos.org/media/screens...oe_01_mini.jpg
Protected Subsystems

The Protected Subsystems allow different Operating System personalities to run on top of the ReactOS Executive. The initial target for ReactOS was the Win32 subsystem -- however, the Win32 subsystem runs in kernel mode as part of the Executive and is not featured here. User mode subsystems in the works: POSIX, OS/2 Potential Protected Subsystems for the future: DOS (Possibly a port of the FreeDOS Operating System), Many more raphical Interface for Subsystems via the Win32 Subsystem: The Windows NT graphics device drivers are tightly integrated in design with the Win32 subsystem. Due to this it is impractical for a user mode subsystem to interact directly with the graphics drivers. For this reason, a subsystem should make use of the kernel mode Win32 subsystem for a graphics interface. Such a subsystem need not depend on the Win32 Window Manager, but can instead just use the graphics primitives provided by the Win32 subsystem.

Native API Architecture

The Native API Architecture calls for user mode code to call kernel mode services in a standard manner. It is the equivalent to the System Call Interface used by most UNIXes. Microsoft Windows NT/2000/XP does not document the Native API Architecture for programmers, they must use the Win32 APIs instead. Since ReactOS is Open Source, our Native API Architecture is open to the application programmer. The Native API Architecture is implemented in NTDLL.DLL. Aside from containing Native API user mode entry points, NTDLL.DLL also contains process startup and module loading code. These entry points call KiSystemService in kernel mode, which looks up the kernel mode service in a system table - KiSystemServiceTable.

Compatibility Targets

The original target for ReactOS, with regards to driver and application compatibility, was Microsoft Windows NT 4.0. Since then, Microsoft Windows 2000 and Windows XP have been released. Microsoft Windows 2000 and Windows XP are both descendants of Windows NT. As such we can gradually shift our compatibility target without worrying about the architecture changing too much. In fact, internally, Windows 2000 reports version information as Windows 5.0 and Windows XP as Windows 5.1. The ReactOS team have decided to maintain Windows NT 4.0 as the official compatibility target. This is because most of the resources, articles and books on Windows NT/2000/XP technology are written for Windows NT 4.0. This does not mean that features present in later versions of Windows NT based operating systems will not be implemented in ReactOS.

What is ReactOS?

ReactOS is a free and open-sourced operating system based on the Windows architecture, providing support for existing applications and drivers, and an alternative to the current dominant consumer operating system.

It would be perhaps important to start by saying what ReactOS -isn't-. It is not another wrapper built on Linux, like WINE. It does not attempt or plan to compete with WINE; in fact, the user-mode part of ReactOS is almost entirely WINE-based and our two teams have close ties. ReactOS is also not "yet another OS". It does not attempt to be a third player, like SkyOS or any other alternative OS out there. People are not meant to uninstall Linux and use ReactOS instead; ReactOS is a replacement for Windows users. As such, this has created a lot of misunderstanding from both sides. Linux users often wonder why create dillution in the free OS space by creating a Windows-alike OS; wouldn't that keep some people from switching to Mac/Linux? Windows developers, on the other hand, don't understand the need to reinvent the wheel by an OS that doesn't have the high quality and support that Windows has.

The raison-d'etre of ReactOS is the simple fact that some people, or especially companies, will -never- switch to Linux. No matter how much Linux gets better, or is better, it is not an option for them. Some people out there still use the 2.2 Linux Kernel and refuse to upgrade to a new version of the same OS; it is understandable that others will be totally unwilling to switch to a whole new OS. Until now, open source had no way to reach out to those people. Sure, other free applications could slowly get rid of the Microsoft applications, such as Office and IE, but the OS itself is hard to get rid of. This is the target and intended audience of ReactOS. Because of its compatibility and visual consistency with Windows, it removes much of the problems that people or companies face when switching to Linux: training everyone on the new OS, increased support costs, acquiring or writing new software, hardware incompatibilities, and the list grows. With ReactOS, all those worries vanish, except perhaps for the fact that any support contract with Microsoft will be rendered useless (however, any technician or 3rd-party personel in charge of this would have no problem). A good test for ReactOS, in its final version, would be to secretely install it on a grandmother's computer, and see if she notices the change. If she is still able to use the PC like before, then ReactOS has suceeded somewhere where Linux would've certaintly failed. Therefore, the fear that ReactOS will compete with other alternative operating systems is unfounded; it will only compete and take market share away from Windows.

Whilst ReactOS' source availability and current usage is mostly intended for programmers to expand and improve on, you don't need to be a rocket scientist to use it, and in its final state will be a completely friendly consumer OS. If you've used Windows before, you'll find yourself in a familiar environment with ReactOS. The learning curve should be minimal, if any at all, since ReactOS duplicates many of the Windows graphical environment applets, control panels and dialogs (Windows 2000/XP/2003's, not Vista's).

Focus at present is on developing ReactOS to a stage where it is capable of running most Windows drivers and applications "out of the box." This does not mean that ReactOS will stop there, however; as new features are added to Windows, our developers be striving to incorporate such new features in future versions of ReactOS. Once the compatibility level has been reached, we may even choose to improve ReactOS beyond its Windows roots. These changes would be external from the main OS, and totally compatible with Windows, but they would add an extra advantage. For example, one of our goals is to have built-in POSIX compatibility, much like Windows Services for Unix. It could also be as simple as natively supporting multiple desktops however, instead of requiring a powertoy.

Once a dream of those opposed to the monopoly Microsoft hold on desktop operating systems, more and more developers are joining the reaction that is known as... ReactOS.

ReactOS®™ is a registered trademark of the ReactOS Foundation.
Windows® NT™ is a registered trademark of Microsoft Corporation.

info lanjut di: http://www.reactos.org/xhtml/en/index.html