Design differences from UN*X and POSIX systems

No fork(), no exec()

In traditional UN*X, new processes are created by duplicating the resources of the current process via a call to fork(). Forking a process will, among other things, clone the current thread of that process. After fork(), both threads typically test whether they are the parent or the child instance. Very often, the child thread makes a call to exec() to load a new program. Calling exec() replaces the contents of the address space of the entire process with the new content of the loaded program. As can be seen, especially without heavy optimizations such as copy-on-write allocation of memory pages and non-duplicating variants of fork() such as vfork(), the procedure of spawning a new program is quite wasteful. This is the reason why UN*X standards introduced posix_spawn() which should be the way forward, but fork()/exec() will probably remain for backward compatibility (forever?)

In HelenOS, there is no fork() or exec() or any variant thereof. Programs are simply spawned by calling task_spawn(), which creates a separate new task for the loaded program and allows the caller to continue to run. Likewise, new threads and thread-like entities are created by calling thread_create() and fibril_create().

Running in background

When you run a command in the shell, it starts the command and waits for it to terminate / return exit status. In UN*X a process that wants to return control to the parent shell and continue running in the background (typically a daemon) does a fork(), the parent immediately exits (thus returning exit status) and the child continues running. In HelenOS there is no fork(). Instead it is possible for a task to return status to the caller without exiting. A HelenOS server usually initializes and registers itself with some naming service, then it calls task_retval() which returns status to the caller (effectively returning command line to the user) without terminating the task. After that the server usually enters the main message loop.

No signals

To Be Improved.

Although HelenOS does not have the concept of signals, it is possible to pin-point their HelenOS equivalents for some of them. For example, SIGKILL is implemented as a dedicated system call. Some of the signals are replaced (or would be) by dedicated IPC calls. For example, SIGUSR1 is sometimes used to ask a server to reload its configuration. But that is actually abusing of the signals and it makes more sense to have a special (control) interface available through IPC where it is possible to explicitly say what the server shall do. As a matter of fact, similar concept can be traced to more signals, e.g. graceful termination (SIGTERM).

Lexical dot-dot resolution

When the HelenOS file system layer sees a reference to '.' (current directory) or '..' (parent directory) in a file system path, it does not resolve it by traversing through the corresponding special directory entries, but rather makes use of its knowledge of the used absolute paths. Upon accepting the path from the user, HelenOS resolves references to '.' and '..' lexically by leaving out all occurrences of '.' and 'component/..' from the path. This represents a simplification of individual file system servers and allows file systems that do not explicitly understand the notion of the current and the parent directory in their directory entries to be supported.

Lexical dot-dot resolution removes the potential for an ambiguous behaviour when the child directory is entered using an alternate path. This ambiguity is inherent to UNIX-like systems and, if not dealt with by the shell, the following scenario is possible:

[jermar@gorgo tmp]$ mkdir -p foo/bar/foobar
[jermar@gorgo tmp]$ ln -s foo/bar bar2
[jermar@gorgo tmp]$ csh
[jermar@gorgo /tmp]$ cd bar2
[jermar@gorgo bar2]$ cd ../bar2
../bar2: No such file or directory.
[jermar@gorgo bar2]$ pwd
/tmp/foo/bar

With lexical dot-dot resolution we see the following bash session output:

[jermar@gorgo tmp]$ bash
[jermar@gorgo tmp]$ cd bar2
[jermar@gorgo bar2]$ cd ../bar2
[jermar@gorgo bar2]$ pwd
/tmp/bar2

No serial terminals

In the world of UNIX-like operating systems command-line applications can make use of a pseudo-graphical UI via [n]curses or a similar library. This provides commands like move cursor, set color, etc. Conversely keyboard input (including some control keys like arrows, Page Up, etc) can be retrieved by the application. However only a dumb serial line / character device is assumed to connect the application to the console.

Therefore all the pseudo-graphical commands are marshaled into a character stream (escape sequences) by the curses library and unmarshaled by the console. Conversely the keyboard input is marshaled by the console and unmarshaled by the curses library. This is the common cause of many problems.

In HelenOS the application talks directly to the console via an IPC interface.

No X

Linux is already moving away from X and no, HelenOS won't have X. We have our own compositing display server, just as Linux will probably have in the near future.

No legacy API burden

POSIX still contains a lot of old interfaces that are sometimes known to be broken in certain ways. Many interfaces such as ctime() are not thread-safe so the standard defines a fixed thread-safe interface suffixed with _r(). Other interfaces are dangerous to use because they make potentially space-unconstrained modifications to a buffer, for example gets() or strcpy(). There are interfaces intended to fix some of these issues, for example strncpy(), but unfortunately they turn out to be dangerous or at least problematic to use just as the original interface was. Even though it comes with a limited compatibility library, HelenOS does not have to be compatible with all this brain-damaged and insecure stuff. The HelenOS native libc does not provide any of these (or it is a bug). Instead, it attempts to learn from the mistakes of others and provides new clean interfaces where applicable.

Universal character set only

HelenOS uses the Universal Character Set or UCS (as defined by ISO/IEC 10646) for representing characters throughout the system. This is in contrast to the common UNIX system where characters are encoded using ASCII or some language-specific extension thereof.

No BSD sockets

To be written.