thelogo

Clicker features

last review 2.3.2





Open Software

I believe in Open Source and Clicker has been made possible thanks to open source softwares like NASM, DJGPP, Linux, mozilla, Dia, XMMS and much more.
However, i can't force people to join the FSF and ignore the fact that some code to live, while others live to code ...
As a result, the microkernel of Clicker has been made OpenSource and is (and will be) distributed under GPL. This do not mean that the whole OS will have to be open-source: If SGI decide to port their closed GUI to Clicker, that must be legally possible. Components that communicate with the microkernel are not part of the microkernel and therefore aren't concerned by the microkernel license. The system specification (how components talk together) should - however - be made public as often as possible.

Micro-kernel based system

As Mach and the first versions of SkyOS, Clicker32 plans to be a microkernel-based system. This means that most of the system services are running independently from each other in some dedicated address space.
Microkernel architectures are known to gives better results in terms of system stability. The microkernel is a small piece of code (typically under 256K) that ensure base services (like physical memory management or task switching) and communication between user programs and servers.


Preemptive multihreaded kernel

Clicker gives the best of what you could expect from your CPU by implementing at kernel level a multithreaded environment, leading to reduced overhead when new tasks are started. Unlike most hobby OSes, Clicker is from early versions a preemptive system, which means it doesn't rely on user programs to have a correct multitasking (not unlike Win3.11 and MacOS 8). The usual 'time slicing' model should be improved with a support for events - giving the ability of having fast response from user-level code to some hardware or software condition.

Modular architecture

One of the major approaches of Clicker architecture is its native support for modules - pieces of software that can be loaded dynamicly in the microkernel. Those modules can be demonstrations, debug plug-ins, system add-ons (as support for new programming environment), device drivers or even a new scheduler.
It's quite an unusual feature of having modules facility in a microkernel system. The idea is to let system operator (superuser) whether he prefers to have a service within the kernel or aside of it based on the trust he puts in the service.

Integrated Debugging tools

A powerful debug system is provided with the kernel, mainly made of multilevel configurable logs and of interactive supervising consoles giving the system operator the ability to kill process, monitor memory usage, start and stop modules by simply browsing some information pannels .
Developers also have the opportunity to make the kernel run 'step by step' by placing anykey() function in the code. A special flag __DEBUG__ can control the generation of debug information to switch between easily debuggable or lightning-fast microkernel at compile time.

Highly dynamic informations and linking system

A unique component - Kernel Dynamix System - provide information exchange between all the system's components. It can be used to link modules, to store supported video modes as well as for identifying the loaded modules or the number of available CPUs. Some extensions should appear soon to extends that component into a user-queriable database that could support object abstractions.


Secure Memory Model

Clicker uses the full power of the x86 MMU architecture to provide a more secure programming environment, using protection at both paging and segmentation units (unlike most system actually do). This don't only protect the kernel from being corrupted by a user-level program, but it also guarantees that nothing wrong will happen due to a kernel stack overflow and that attacks like buffer or stack overflow can't do any harm to the system by strongly separating the writable and the executable bits.
Recent readings on other processors architectures convice me that such functionnality could be extended to other architectures like Sparc or PowerPC machine with little overhead.


Tunable OS abstraction


Many of the system components can be re-instanciated by some system developers. The whole system philosophy is to keep the implementation free: the system only describes the MULTIPLEXING of resources by some standardized API and provides default abstractions (implementations) of these resources, but the system operator has the power to define new implementation and to define which precise implementation of a service an application should get.
Memory objects, file classes, volumes, etc. are all based on this concept. call it a microkernel, exokernel, or whatever: this is just the Clicker kernel.


Device Drivers Framework


The system is at least ready to host your device drivers. A demonstration IDE devices scanner and a small read-only ATA PIO disk driver have been made available. A rationale broker model has been used to identify features offered by the devices, and which of them are supported or required by the drivers (so that we can easily have "USB device require a driver with VID=8086" or "driver requires a disk that can deal with LBA addressing" or "driver utility +20 if the disk can support ultra-dma") and helps selecting the driver that will be the most "useful" for a given device.

Are you Ready For the New Generation ?