My operating system design (open to suggestions)
Posted: Tue Jun 05, 2018 1:41 am
Hello,
I have had this idea brewing for the past year or so. I want to write an operating system which is powerful and elegant at the same time. I want to call it nOS, short for "next Operating System". Call it a throwback to the NeXTSTEP systems, as I was also inspired by it in parts. The reason I am creating this thread is not to get people to create my operating system for me, but rather to get my design peer reviewed, in case I am missing something or other, or there is a flaw that I don't see but others might.
Philosophy
nOS should be designed with elegance in mind. While performance is also a concern, the elegance of the system should not be cut back. This elegance not only applies to the general user experience and the graphical interface, but also the programming environment of nOS; it should be fun to program an application for the nOS environment. The nOS programming environment should provide as much support as possible for programmers with many native libraries (sound, graphics, networking, ...) provided with a consistent, namespaced and standard interface.
If a compromise must be made from elegance for performance reasons, the user should be given both options.
Kernel Design
The nOS kernel, codename Spark, will be based on the microkernel architecture. Services should lay on the userspace (unless the required functionality is crucial to system performance), and can provide anything; including drivers, timers, watchdogs, regular daemons, etc.
The nOS programming environment will provide a standard set of services for accessing the hardware. Additionally, new services can be created and added just like the native ones, to access new hardware.
The kernel should, ideally, consist of system bring-up code, a scheduler, and memory management. Additional parts can be added based on CPU architecture and hardware.
The kernel (?) should also provide a system-wide bus which services and programs use to communicate to each other. The bus should be as high performance as possible.
(Just an idea: should the scheduler try to move a service that has been called by the running task at the top of the task list right after the current running tasks? This way service request latency could be minimized.)
nOS Programming Language and Environment
The nOS programming language will be nLang (currently not public, and syntax not finalized), which is a managed programming language. Here is a hello world program:
For a more complex example, here's a GUI window (pseudo-code):
nOS Standard Library
The nOS Standard Library is not POSIX compatible. A compatibility shim will be provided, and C programs should still work, but the system does not aim to be POSIX compatible.
The standard library should contain as many native faculties as necessary for the full programming potential of the entire system. A list of what should be provided (inconclusive):
Containers (list, map, vector, ...), string manipulation, I/O, 2D canvas drawing, 3D context drawing (OpenGL), sound libraries, windowing system, networking, type reflection, service access, bus access, IPC, regular expressions, authentication system, ...
The Windowing System
The windowing system is codenamed Crystal. The windows and UI elements should use the frosted glass effect when appropiate, to give depth. Shadows should also be used. Font kerning and anti-alias is allowed, to some degree. The menus should be quickly accessible and well organized. The window system should be able to switch between tiled and floating windows at will. 3D can be used to denote depth, and subtle animations should be used where appropiate.
The boot sequence should be seamless. After the boot sequence ends, the log-in screen should fade in, and ideally after the user logs in, the windowing system should slide in.
The Standard Library API
This was my main gripe with a lot of systems, so this is something that I want to fix with my operating system's standard library. Many operating systems' APIs (be it Win32, POSIX, etc.) suffer from a lot of backwards compatibility kludges, which are kept because the operating system wants to keep compatible with old programs while new versions are still released. My idea is to specify which version of the operating system is wanted, through some means.
Here's an example: say my operating system's API version 1 has a function which is deemed buggy, and the fix would require code change. The next version of nOS API (version 2) would fix this function, and new applications written for nOS would specify they want API 2. API 1's buggy function would have a workaround that would not require code change, while API 2 would have a proper fix. I believe this is already used by Google's Android, which has a different API version for each minor and major release of its OS.
This was an hour of typing, hopefully it is mostly coherent. I will add more as I collect my thoughts.
I have had this idea brewing for the past year or so. I want to write an operating system which is powerful and elegant at the same time. I want to call it nOS, short for "next Operating System". Call it a throwback to the NeXTSTEP systems, as I was also inspired by it in parts. The reason I am creating this thread is not to get people to create my operating system for me, but rather to get my design peer reviewed, in case I am missing something or other, or there is a flaw that I don't see but others might.
Philosophy
nOS should be designed with elegance in mind. While performance is also a concern, the elegance of the system should not be cut back. This elegance not only applies to the general user experience and the graphical interface, but also the programming environment of nOS; it should be fun to program an application for the nOS environment. The nOS programming environment should provide as much support as possible for programmers with many native libraries (sound, graphics, networking, ...) provided with a consistent, namespaced and standard interface.
If a compromise must be made from elegance for performance reasons, the user should be given both options.
Kernel Design
The nOS kernel, codename Spark, will be based on the microkernel architecture. Services should lay on the userspace (unless the required functionality is crucial to system performance), and can provide anything; including drivers, timers, watchdogs, regular daemons, etc.
The nOS programming environment will provide a standard set of services for accessing the hardware. Additionally, new services can be created and added just like the native ones, to access new hardware.
The kernel should, ideally, consist of system bring-up code, a scheduler, and memory management. Additional parts can be added based on CPU architecture and hardware.
The kernel (?) should also provide a system-wide bus which services and programs use to communicate to each other. The bus should be as high performance as possible.
(Just an idea: should the scheduler try to move a service that has been called by the running task at the top of the task list right after the current running tasks? This way service request latency could be minimized.)
nOS Programming Language and Environment
The nOS programming language will be nLang (currently not public, and syntax not finalized), which is a managed programming language. Here is a hello world program:
Code: Select all
[[$]] hello_world.
$<[[io]]::print.
;; Top level instructions are executed directly; no need for a main. The argument handling is different from Unix-likes, more on that in detail later.
;; Functions take a single argument. Functions that take multiple arguments will use tuples.
$::print"Hello World!".
Code: Select all
[[$]] my_window.
$::[[containers]]::M. ;; map factory instance. overrides operator `[]` to generate a map from and to (types are objects). See below.
$<[[ui]]::[Window Text Button Event].
$<[[io]]::print.
;; note: strings are first class objects.
;; a little more about the language: the language supports complete type reflection, runtime variables. However dynamic methods and dynamic members are not supported.
window := $::Window::new!. ;; Function`!` is shorthand for func {} (calling function with empty tuple). Optimized by the compiler.
window::child {$::Text::new {
content = "Hello GUI!"
anchor = window::anchor::top_center
position = [0 20] ;; X Y, anchored from the top center edge of the window. [] is array; type of the position attribute is i32[2]
}}.
window::child {$::Button::new {
text = "Close Window"
events = M[string][%{Event}->bool] { ;; %{Event}->bool is function taking an Event and returning a bool. the boolean means whether to propagate the event to objects the button is contained in.
"click" %({e: Event} bool -> ;; The compiler will capture all variables that the function uses. No eval, so static analysis can determine. VM ensures window stays alive while captured.
window::close!.
false) ;; Last evaluated expression is the return value.
}
anchor = window::anchor::bottom_center
position = [0 -20]
}}.
;; The window will configure its own buttons, and signals from the windowing system.
window::wait_for_events!.
The nOS Standard Library is not POSIX compatible. A compatibility shim will be provided, and C programs should still work, but the system does not aim to be POSIX compatible.
The standard library should contain as many native faculties as necessary for the full programming potential of the entire system. A list of what should be provided (inconclusive):
Containers (list, map, vector, ...), string manipulation, I/O, 2D canvas drawing, 3D context drawing (OpenGL), sound libraries, windowing system, networking, type reflection, service access, bus access, IPC, regular expressions, authentication system, ...
The Windowing System
The windowing system is codenamed Crystal. The windows and UI elements should use the frosted glass effect when appropiate, to give depth. Shadows should also be used. Font kerning and anti-alias is allowed, to some degree. The menus should be quickly accessible and well organized. The window system should be able to switch between tiled and floating windows at will. 3D can be used to denote depth, and subtle animations should be used where appropiate.
The boot sequence should be seamless. After the boot sequence ends, the log-in screen should fade in, and ideally after the user logs in, the windowing system should slide in.
The Standard Library API
This was my main gripe with a lot of systems, so this is something that I want to fix with my operating system's standard library. Many operating systems' APIs (be it Win32, POSIX, etc.) suffer from a lot of backwards compatibility kludges, which are kept because the operating system wants to keep compatible with old programs while new versions are still released. My idea is to specify which version of the operating system is wanted, through some means.
Here's an example: say my operating system's API version 1 has a function which is deemed buggy, and the fix would require code change. The next version of nOS API (version 2) would fix this function, and new applications written for nOS would specify they want API 2. API 1's buggy function would have a workaround that would not require code change, while API 2 would have a proper fix. I believe this is already used by Google's Android, which has a different API version for each minor and major release of its OS.
This was an hour of typing, hopefully it is mostly coherent. I will add more as I collect my thoughts.
What's the codename? nCube? iYayay? AquaX? 
](./images/smilies/eusa_wall.gif "Brick wall"){kind=small}