Skip to main content.

Introduction

TinyKRNL is a three-phased Open Source OS Project based on the design of Windows NT. For each phase, specific goals have been set, with the ultimate goal being to provide a rich, open, and fully compatible alternative to Windows NT. TinyKRNL itself will be an answer to many educational, consumer and commercial demands, both in its final form, as well as through each of its specific development phases. TinyKRNL targets Windows NT 5.2.3790 Service Pack 1 for compatibility testing. This is the most advanced currently-available form of the NT Kernel, and it is highly optimized and scalable, sporting major Memory Management and I/O Improvements even over the Service Pack 0 (RTM) version itself.

Phase 1 will provide OS designers, developers and enthusiasts with a chance to understand the underlying principles of the NT Operating System. At its completion, its enthusiasts and power users will have access to a usable OS, with a minimal command-line interface.

Phase 2 will provide a much richer set of available functions to the TinyKRNL OS, including USB, Sound and Networking. These additions will continue to be documented as through Phase 1, which will now allow driver developers to gain a much more intricate knowledge of these kernel-mode frameworks. At its completion, enthusiasts and power or curious users will be able to use an OS allowing them MP3 playback, data storage and networking.

Phase 3 will provide, assuming a Windows installation media is available, a fully-fledged Windows OS running on the TinyKRNL components developed during the previous phases. By itself, it will have an implementation of core user-mode libraries and the Win32 subsystem, as well as a minimal graphics subsystem driver to demonstrate execution of user-mode Win32 applications.

^        TOP

Phase 1

At phase 1, TinyKRNL will be composed of 14 core drivers, a HAL, an NT-compatible Kernel and Native User-Mode Library with the minimum required services to run the drivers, a Subsystem Manager (SMSS) and a Native Command Line Interface (NCLI). The Kernel will also fully support the KD Protocol, and source-level debugging will be possible by using WinDBG, KD, or any other compatible tool.

Note that TinyKRNL might depend on NTLDR being present; it does not come with its own boot loader, but instead uses NTLDR for greater compatibility, as well as to provide educational information on how to write an OS which can be booted by it. Because TinyKRNL's compatibility target is NT 5.2.3790 SP1, TinyKRNL will be fully bootable on EFI platforms, such as Intel Macs. However, a compatible Boot Loader called TinyLoader is being planned during the course of Phase 1. It is not an official part of the project, and is being worked on during free time. If it does become available, then the dependency NTLDR on will be removed.

During Phase 1, two technical articles will be written and posted electronically, which will detail the core startup process behind the NT Kernel, starting from the boot-phase all the way to the last initialization steps of the Executive. Additionally, a book which will be an in-depth implementation guide for the Memory Manager provided by NT will also be published in print form.

We expect this phase of the project to take between 9 and 12 months. For more information about ongoing Phase 1 development, visit the Phase 1 page, accessible from the side-bar and top menu.

^ TOP

Phase 2

At phase 2, TinyKRNL will receive significant updates to its Kernel, with the purpose of allowing many more drivers to execute inside the TinyKRNL OS. These drivers include the network stack and drivers, the USB stack and drivers, the Sound subsystem, etc. Video drivers will not be supported yet, but the Native Command Line Interface will be enhanced to provide basic networking support, sound playback and access to USB storage devices.

Furthermore, more drivers will be written by the team, including a mouse filter driver, a CD-ROM driver, a floppy driver, and a sound driver. Once the Microsoft Audio architecture is shown to work, efforts will be made to remove this dependency and provide our own compatible implementation. Parts of the Network stack will also be implemented by the team, but due to time constraints, the dependency on Microsoft's TCP/IP Stack (tcpip.sys) will remain.

During Phase 2, two more NT Kernel books will be published, detailing the implementation details of the Object Manager and Process Manager. Likewise, an article or two will now appear, documenting the internals of the Audio Architecture and Networking Stack.

We expect this phase of the project to take between 9 and 12 months. For more information about ongoing Phase 2 development, visit the Phase 2 page, accessible from the side-bar and top menu.

^ TOP

Phase 3

At phase 3, TinyKRNL will receive more updates to its Kernel to allow video drivers to execute inside the OS, as well as allowing Microsoft's win32k.sys to load. The Native User-Mode library (ntdll.dll) will also be enhanced so that the Microsoft kernel32.dll, advapi32.dll and other libraries can use it and load. At this point, TinyKRNL should be fully usable as a GUI OS, provided that a legal Windows installation media is available to copy files from.

Similarly to phase 2, after these original components are shown to work, the team will work on some basic video drivers (vga, vbe, cirrus, etc.) and make sure that big brand drivers (ATI/NVidia/Matrox) function fine. Additionally, a skeletal Win32K Video Subsystem (win32k.sys) driver will be implemented, with the accompanying Client-Server Runtime subsystem (CSR) and associated libraries (csrsrv.dll, basesrv.dll, winsrv.dll).

Due to the complexity of a graphics subsystem, the skeletal win32k.sys will only be able to show a blue desktop; no graphic APIs are planned. However, kernel32.dll and other core user-mode libraries will be implemented, and user-mode programs will be tested (they will be custom-made by the team, and provide input/output through the debugger interfaces).

At this step, the book collection will be completed by guides on the I/O Manager and the Cache Manager.

We expect this phase of the project to take between 9 and 12 months. For more information about ongoing Phase 3 development, visit the Phase 3 page, accessible from the side-bar and top menu.