= 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 interfaces 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.