Similar presentations

2 ReactOS is (not) WindowsReactOS is WindowsRuns Windows applicationsRuns Windows driversLooks like WindowsReactOS is not WindowsReactOS is a free, open source projectReactOS reuses open source code from other projectsYou can make “your own Windows”

5 ReactOS is WindowsReactOS has the same identical architecture as Windows, for maximum compatibilityWindows drivers require a Windows kernelMany applications (firewalls, antivirus, media players, PDA sync software, etc.) come with special driversWindows architecture is quite different from Linux and not as well knownLet’s start from the basics…

8 Microkernel architectureA note on microkernelsA monolithic kernel abstracts all hardware resources. All subsystem run together in supervisor mode. Almost all operating systems are monolithicA microkernel only abstracts CPU time (scheduling). Kernel subsystems are regular applications running in user mode, for more stability at the cost of performance. Very few operating systems are pure microkernels (too impractical, almost all CPU architectures are designed for monolithic kernels, etc.). Windows is not a microkernel (more on that later)Regular (monolithic) architectureMicrokernel architectureApplicationsApplicationsKernel subsystemKernel subsystemKernel subsystemSchedulerSchedulerKernel subsystemKernel subsystemKernel subsystemKernel

9 Linux architecture Monolithic kernel. No kernel ABIUNIX process management and security modelNative networking supportSockets, pipesselect, poll, etc.Filesystem abstraction (VFS)UNIX API (libc) on top of a small UNIX-like system call and signals interfaceOther APIs (audio, application setup, desktop environment integration, cryptography, etc.) are de facto standards from third partiesThe graphic subsystem (X server) is in a category of its own. The kernel has “backdoors” to let the X server talk directly to the hardware, to keep the complexity of video drivers outside of the sensitive environment of kernel mode

11 Windows (NT) architectureMonolithic kernel. Relatively stable kernel ABIKernel design is almost identical to DEC RSX-11 and VMS, with DOS, OS/2 and Windows 95 influencesRSX-11, VMS and Windows NT were designed by the same engineer (Dave Cutler)Windows NT was initially developed as a new kernel for OS/2No device abstraction in the kernel itself. Abstraction is provided by standard system drivers (class or port drivers)No network support in the kernel itself. select/poll is not a system call, but an ioctl to the “socket filesystem”Sockets and pipes are provided by two special filesystemsFurther user-mode layer of abstraction sockets: Winsock used to be a third-party component (e.g. Trumpet Winsock)Native graphics and windowing subsystems (running in kernel mode) with a standard APIRich, high-level APIs of all sorts (cryptography, desktop environment, etc.)

12 Is Windows (NT) a microkernel?Was initially designed as a microkernel. Deemed impractical; turned into a monolithic kernel long before releaseMicrokernel legacy in Windows:Kernel is still logically split in two:Kernel, which implements the schedulerExecutive, which implements everything else (process management, I/O, security, etc.)Executive calls Kernel, but never the other way aroundUntil Windows NT 4, the graphics and user interface subsystems (USER and GDI) ran in user modeMany system APIs are provided by user-mode services

13 Unique Windows architecture featuresChipset devices (timer, interrupt controller, power management, buses, firmware, etc.) are abstracted by a kernel component called Hardware Abstraction Layer (HAL)ACPI vs non-ACPI is just a different HALThe ReactOS port to the XBox was a regular x86 ReactOS with an XBox-specific HALNo signals; standard exception model instead (“SEH”, shared with VMS, OS/2 and Tru64)Reverse system calls (callbacks): windowing and graphics subsystem can call back into user modeThe user-mode and the kernel-mode parts of the subsystem used to run in shared memory in their original implementation (Windows 95)Too unsafe for Windows NT; emulates a secure but compatible shared memory environment with some “tricks” (like callbacks)

16 ReactOS is (not) Wine “If ReactOS is just a kernel for Wine…… what do we need it for?”… why isn’t it finished yet?”As always, things are more complicated than they appear…

17 Wine and ReactOSReactOS has a lot in common with Wine, and we can share a lot of code with them…Enough common goals:Installing Windows applicationsRunning Windows applications… but…Too many different goalsRunning on Linux vs running on hardwareWhether to support Windows drivers

18 Wine on LinuxWindows applications can only be loaded by a Wine utility (the Wine loader)Windows applications and DLLs are dynamically linked to Wine reimplementations of Windows system DLLsMost Wine DLLs are regular Windows DLLs compiled as Linux codeSome are internally Linux libraries, depending on other Linux libraries. Linux libraries are transparent to Windows applications – they act as system calls in all respectsA service process (Wine Server) replaces the Windows kernel for the management of shared resources

20 Wine on Windows ReactOSWindows applications are loaded directly by the Windows ReactOS kernelWindows applications and DLLs are dynamically linked to Wine and ReactOS reimplementations of Windows system DLLsWe can only use Wine DLLs that don’t depend on Linux librariesThis includes important libraries like user32 & gdi32 (windowing and graphics APIs, depending on X server on Linux), wininet (HTTP and FTP client, depending on OpenSSL on Linux for HTTPS), etc.ReactOS reimplements a true Windows kernelCan support applications and drivers

22 Wine and ReactOS: summaryWine was designed to run Windows applications on Linux. Linux-specific dependencies are:… invisible to applications… an integral part of Wine designReactOS was designed to be Windows:Needs to take as much as possible from WineNeeds to reimplement what Wine implements in a Linux-dependant wayImplementation cannot just be “functionally equivalent”: must be “binary-compatible”, because in Windows everything is an APINot a lot of code can be reused from other projectsReactOS is complex and irreplaceable

24 ReactOS is not WindowsAll the parts of Windows that aren’t in Wine must be reimplementedThis means the kernel and all kernel mode subsystems (graphics, sound, USB…). It sounds hard and it isWho was stupid brave enough to take this task, and did they succeed?

25 The ReactOS crew A truly “international” project No formal trainingFounded by Jason Filby from South AfricaMost early developers and the first ReactOS foundation from the USAToday, a Russian foundation and project coordinator, most developers from Germany and the USA, and a community spanning the globeNo formal trainingAlmost all developers learned Windows internals while working on ReactOSSadly for the project (but happily for them), the best developers are “snagged” by Microsoft and other large companiesVery little information available to the public“Inside Microsoft Windows” is the reference on Windows design and internals… but it’s not enough information for ReactOS development

26 The ReactOS kernelMany developers alternated developing the ReactOS kernel and subsystem, with mixed resultsGood quality:Scheduler, HAL, process and thread manager (thanks Alex Ionescu!)Fair quality:I/O subsystem, configuration manager (registry), security managerSecurity manager is good enough to support a prototype implementation of Mandatory Access Control (MAC) I did for my BS thesisPoor quality:Memory manager, cache manager, filesystem support library: three tightly coupled components that have been our “white whale” since the beginningNon-existing:Power managementNevertheless, the ReactOS kernel is…

28 The windowing subsystem (USER)Another long-time “white whale” sub-projectMany developers tried and failedThree separate rewrites, one still ongoingThe original implementation is a very good hack…Windowing subsystem comes all the way back from Windows 1.0The port to Windows NT introduced memory protection, but the API implies shared memorySeveral dedicated hacks to simulate shared memory safely – user32.dll is not just a library, but the user-mode half of the windowing system… but a really poor designImpossible to give an good, high-level description of the architectureNobody documents all of it, neither officially nor unofficially

29 The graphics subsystem (GDI)Tightly coupled with the windowing subsystemMuch simpler, better designgdi32.dll is a partial user-mode reimplementation of the subsystem, to run user-mode display drivers (i.e. printer drivers)Drawing algorithms are well isolated in a simple APIAll our font drawing code comes from FreeType (a third-party, open source project)Efforts concentrate on the more complex (and visible) windowing subsystem, howeverDirectX graphics is a whole another matter entirely…

30 Networking The networking stack in Windows is outside the kernel… but the stack is split into independent layers, with many documented APIs between them:WinsockTDINDISEach part has to be implemented in a Windows-compatible way… but many parts are complex enough inside to make it possible to wrap a large third-party implementation in a Windows-compatible “shell”Our TCP/IP driver is almost 100% FreeBSD code“Good enough” quality

31 ReactOS present and futureWhat are we working on, what we will work onReactOS present and future

33 USBWe used to use a port of the Linux Cromwell stack, but it “bit-rotted”Used in the XBox port (XBox only supports USB input)We currently use a USB compatibility layer for Windows NT 4“Good enough” for light use (USB keyboards, mice, etc.)Windows NT 4 lacked kernel features to properly support USB, so the compatibility layer is very different from “real” USB supportOur I/O subsystem is not ready yet for full, “real” USB support

34 Audio subsystem It works! … but it’s very incompleteReactOS can play audioThe audio subsystem prototype successfully played several hours of streamed MP3 audio through Winamp… but it’s very incompleteHard to find people with experience in Windows audio

35 Kernel subsystems Cache manager rewrite is in progressThe ARM port resulted in a large cleanup of the memory managerOverall quality improvements

36 Development tools We don’t support the Windows kernel debugger… yetWe only support compilation with gcc, which doesn’t play nice with Windows toolsWe contribute to the development of the Windows port of gcc (MinGW) because we are probably its largest user (and we find a lot of bugs in it!)MinGW was never expected to compile a kernel!I’m working on a build environment and source code clean-up to support compilation with Microsoft Visual C++More accessible to new developersBetter integration with Windows development tools

38 Summary Windows is a pretty normal operating system, after all!ReactOS…… is (not) Windows: it’s a 100% open source reimplementation of Windows… is not Linux: it runs Windows drivers… is not Wine: it uses Wine, but Wine is only part of itReactOS is complex and uniqueReactOS is a lot of work