#137 From: Jason Filby <jasonfilby@...>
Date: Thu Feb 21, 2002 4:54 pm
Subject: Fwd: [freeos] ReactOS jasonfilby
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
To the OSFree people (not FreeOS).. heh.. here's a proposal for
ReactOS as the host kernel.
- Jason
Note: forwarded message attached.
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
To:
freeos@yahoogroups.com
From: Jason Filby jasonfilby@...
Mailing-List: list
freeos@yahoogroups.com; contact
freeos-owner@yahoogroups.com
Date: Thu, 21 Feb 2002 05:38:52 -0800 (PST)
Subject: [freeos] ReactOS
Hi all
I understand that FreeOS is also looking to develop OS/2
compatibility (as is/was OSFree). I've attached a whitepaper
describing the ReactOS architecture (to some degree). If you have any
questions then just post them to this list.
BTW -- ReactOS 0.0.19 is going to be released quite soon (next few
days). Don't be scared off by the 0.0.x thing -- there's a lot of
code in there and we're always improving.
Website:
http://www.reactos.com/
Tutorials:
http://www.reactos.com/rosdocs/tutorials/
- Jason
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
To Post a message, send it to:
freeos@eGroups.com
To Unsubscribe, send a blank message to:
freeos-unsubscribe@eGroups.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
TABLE OF CONTENTS
1 Introduction
2 The Executive
2.1 Hardware Abstraction layer
2.2 Device Drivers
2.3 Kernel
2.4 System Services
3 Protected Subsystems
4 Native API Architecture
5 Compatibility Targets
1 INTRODUCTION
The ReactOS architecture is based on that of Microsoft Windows NT 4.0. Microsoft
technical specifications define said architecture a modified microkernel (that
is, combining aspects of both microkernels and layered operating systems).
However, the research done by the ReactOS Kernel Team in this field showed that
the adoption of the microkernel paradigm in the Microsoft Windows NT 4.0
operating system is very limited, and therefore that this definition is
questionable. The design was found to be more appropriately described as a
modular and layered architecture.
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.
2 THE EXECUTIVE
The Executive is all the code that runs in kernel mode. The executive can
roughly be broken up into the following components:
o Hardware Abstraction layer (HAL)
o Device Drivers
o The Kernel
o 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.
2.1 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.
2.3 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).
2.4 KERNEL
The kernel 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.
2.5 SYSTEM SERVICES
System services include:
o IO Manager
o Configuration Manager
o Plug & Play
o Power Manager
o Memory Manager
o Executive Support
o object Manager
o security reference monitor, process structure, local procedure call [?]
o Win32 Subsystem
3 PROTECTED SUBSYSTEMS
The Protected Subsystems allow differnt 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:
o POSIX
Potential Protected Subsystems for the future:
o DOS (Possibly a port of the FreeDOS Operating System)
o Java Operating System (JOS: Open Source Java Operating System)
o OS/2 (FreeOS: Open Source OS/2 clone)
o Many more
Graphical 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.
4 NATIVE API ARCHITECTURE
The Native API Architecture is a set of functions that interface device drivers
and applications to system calls, that is calls to functions exported by the
Executive. This concept is similar to the concept behind the System Call
Interface found in some UNIX operating systems.
The Native API is:
o Portable across hardware architectures. Machine-specific details, such as the
method used to perform system calls, software interrupts, traps, callgates,
etc.), are conveniently hidden behind a standardized calling convention. To
developers who are not familiar with system calls, the Native API will appear
like any other programming interface, such as
the Win32 API.
o Consistent across different implementations of the operating system, as
different Executives may expose incompatible system calls.
The Native API of ReactOS, despite the praiseworthy efforts of the ReactOS
Kernel Team, may present slight incompatibilites with the Native API of
Microsoft Windows NT, since only a small part of the latter is documented
appropriately. Nevertheless, no such incompatibility is known, at the moment.
The Native API is implemented in NTDLL.DLL. This library also
implements:
o Basic process startup code.
o The PE (Portable Executable) Loader, a set of functions to load and manipulate
PE binary images in memory.
o the RTL (RunTime Library), a set of functions covering, among others, string
handling, heap management and process environment management. The RTL is
particularly useful to the developers of protected subsystems and language
runtime libraries.
o A small subset of the libc (C language runtime library). This currently
includes basic string handling and formatting.
5 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 is versioned
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.