+- [Installation guide](docs/INSTALL.md)

+- [Memory map](docs/MMAP.md)

+- [Bootloader overview](boot/README.md)

+- [Kernel overview](kernel/README.md)

+- [Userspace overview](apps/README.md)

+- [Library overview](libs/README.md)

+# Userspace

+

+All files in this directory run in the userspace. By default, apps will run in ring 3 and can be executed using the `exec` syscall. The default process that runs after the kernel is done initializing everything is `init.c`. This initial process may call GUI programs or other processes that can reproduce themself. The `idle.c` app however is the special idling process which runs if no other process is running (called in the process scheduler).

+# Bootloader

+

+Hello there!

+

+This directory is the home of my self-written bootloader. It supports ATA disk detection, EXT2 loading, basic ELF parsing/mapping and much more! You can find more information about the general memory map in `docs/MMAP.md`.

+

+## Execution sequence

+

+The bootloader starts in the first stage at `0x7c00` - which is the location of the MBR - by clearing the screen, finding the disk, checking for basic addressing support and finally loading the second stage. The first stage has a max size of 512 bytes, thanks to some ancient BIOS standards. That's why not much is happening in here.

+

+The second stage searches and loads the third stage (`load.c`) using a very minimal ext2 implementation (still in assembly!). The second stage also loads the memory map and the VESA video map into memory and sets the highest available video mode. After the A20 line has been enabled and the GDT and TSS have been set, it's time to jump to the protected mode. After the computer arrived in protected mode, the third stage gets executed, with the memory and VESA map as its parameters. Finally.

+

+The third stage (`load.c`) installs a basic serial connection for logging purposes and probes ATA disk drives. After a suitable disk has been found, the third stage will load the kernel binary into memory using an EXT2 driver and basic ELF parsing/mapping. Ultimately, the bootloader will jump to the kernel. The rest is history.

+# Installation guide

+

+This document explains the testing/building/booting process and requirements. Everything is done using the virtual machine QEMU. I will not explain how you can install Melvix on real hardware as this is not recommended right now.

+

+## Test

+

+- Install the qemu i386 emulator

+- Download the `disk-img` artifact from the newest stable [GitHub Workflow build](https://github.com/marvinborner/Melvix/actions?query=branch%3Amain)

+- Unzip `disk-img.zip`

+- Run `qemu-system-i386 -m 256M -vga std -drive file=path/to/disk.img,format=raw,index=1,media=disk -netdev user,id=net0 -device rtl8139,netdev=net0`

+- Try entering `browser`, `files`, `mandelbrot` (or any other program in `apps/`) into the input field and press enter

+- Move windows using `ALT`+`Left click`

+- Enjoy, or try building it yourself!

+

+## Build it yourself

+

+- Use any system running GNU/Linux or OpenBSD

+

+- Install build dependencies

+

+ - General template: `[pkg_manager] [install] git binutils ccache gcc make bison flex gmp mpc mpfr texinfo curl nasm qemu inkscape` (package names may vary depending on your operating system)

+ - Ubuntu/Debian: `apt-get install -y build-essential bison flex libgmp3-dev libmpc-dev libmpfr-dev texinfo ccache curl nasm grub-common qemu qemu-kvm mtools ctags inkscape`

+ - OpenBSD: `pkg_add git ccache gcc g++ gmake bison gmp libmpc mpfr texinfo curl nasm qemu e2fsprogs inkscape`

+

+- Clone this repository using `git clone https://github.com/marvinborner/Melvix.git`

+

+- Switch to the stable `main` branch using `git checkout main`

+

+- Run `./run` (pure magic!)

+

+- If you need help: `./run to help`

+# Kernel

+

+The kernel is the interface between the computer hardware and the userspace. It handles everything from file and process management to resource allocation, computer interfaces like keyboards/mice and networking features. This interface is mainly established using syscalls (`features/syscall.c`).

+

+While the main goal of Melvix is definitely not the security aspect, the kernel should be fairly secure. It implements memory protecting features like paging and address validation, SMEP/SMAP, ASLR, ring 3 processes, protected memory sharing, process based syscall validation (abstraction to default, super and kernel processes) and much more.

+

+The directory structure consists of `drivers/`, the home of all hardware-interacting device drivers, and `features/`, the home of interfaces that are not directly tied to the hardware but rather to other features of the kernel or userspace. The `inc/` directory is the location of all kernel header files.

+# Library overview

+

+## libc

+

+This library is the main library that the kernel and userspace uses. It's userspace/kernelspace agnostic using the compilation flag `-DKERNEL` or `-DUSER`.

+

+The libc implementation in Melvix is different to every other libc you've probably seen. It doesn't comply with any GNU/POSIX/Unix/Linux/whatever standard at all, and that's intentional: As the syscalls and general kernel-userspace ABI is completely different than the one that e.g. Unix/Linux/Windows is using, it would be nearly impossible to use a standard libc layout (for example, Melvix doesn't have `open`, `close` or `fork` syscalls). I also believe that the libc standard is way too complicated and enrooted in ancient decisions that don't make sense today at all. Furthermore, the goal of Melvix isn't the support of third party software but on the contrary the creation of a modern and new standard for OS hobbyists. I'm well aware though, that some decisions I chose are probably completely brainlessly stupid, so feel free to propose changes to the libc layout using a pull request or issue.

+

+This libc is therefore constantly changing and has no support for older versions at all. Don't expect any stability in the near future.

+

+Other than that, Melvix' libc has many features that glibc, for example, has too. All the `str*` functions like `strlen` or `strlcpy` are located in the accordingly named `str.c` file with its header `str.h`. In this instance you can already see the changes I've previously talked about: Melvix does not support the almost always memory-unsafe `strcpy` and replaces it with `strlcpy`.

+

+Feel free to write more documentation here, but I believe that most features are self-explanatory if you look through the files in the `inc/` directory (they are quite small and comprehensible).

+

+## libgui

+

+This library is only usable in userspace and is the main GUI framework. This library includes the graphical drawing algorithms and widget wrappers (for example buttons) as well as window manager API connections and image/font loading. It also suffers from performance and security issues and is constantly changing for that reason.

+

+## libnet

+

+Libnet implements some basic userspace networking features such as IP/DNS/HTTP that interact with the kernel network implementations. It's not nearly finished and will change a lot in the future.

+

+## libtxt

+

+The main purpose of libtxt is the parsing of several file formats such as XML/HTML/JSON. Many features will be added in the future and bigger parsing implementations could be moved into a new library for that specific purpose.