os

Minoca operating system

2,719

232

2,719

View on GitHub

Top Related Projects

reactos

14,565

A free Windows-compatible Operating System

haiku

1,898

The Haiku operating system. (Pull requests will be ignored; patches may be sent to https://review.haiku-os.org).

redox

15,144

Mirror of https://gitlab.redox-os.org/redox-os/redox

Quick Overview

Minoca OS is an open-source, general-purpose operating system written from scratch. It aims to be a modern, lightweight, and efficient OS that can run on a variety of hardware platforms, including x86, ARM, and RISC-V architectures. The project focuses on providing a clean, modular design with a small footprint.

Pros

Lightweight and efficient, with a small memory footprint
Supports multiple architectures (x86, ARM, RISC-V)
Modular design allows for easy customization and extension
Open-source, encouraging community contributions and transparency

Cons

Limited software ecosystem compared to mainstream operating systems
May lack advanced features found in more mature operating systems
Smaller community and support base compared to popular alternatives
Potentially steeper learning curve for users accustomed to mainstream OSes

Getting Started

To get started with Minoca OS, follow these steps:

Clone the repository:

git clone https://github.com/minoca/os.git

Install the required build tools (varies by host OS)
Build the OS:
```
cd os
make
```
Create a bootable image:
```
make boot
```
Run the OS in an emulator or install it on supported hardware

For more detailed instructions and system requirements, refer to the project's documentation in the repository.

Competitor Comparisons

linux

180,417

Linux kernel source tree

Pros of Linux

Extensive hardware support and driver availability
Large, active community and ecosystem of tools/applications
Proven stability and performance in various environments

Cons of Linux

Complex codebase with a steep learning curve
Slower development cycle for major changes
Higher resource requirements for full functionality

Code Comparison

Linux (kernel/sched/core.c):

static void __sched notrace __schedule(bool preempt)
{
    struct task_struct *prev, *next;
    unsigned long *switch_count;
    struct rq *rq;
    int cpu;

Minoca OS (kernel/ke/sched.c):

KSTATUS
KepSchedulerEntry (
    PPROCESSOR_BLOCK Processor
    )

/*++

Routine Description:

    This routine implements the scheduler.

Arguments:

    Processor - Supplies a pointer to the processor block.

The Linux code snippet shows the core scheduling function, while the Minoca OS code presents the scheduler entry point. Linux's implementation appears more complex, reflecting its broader hardware support and features. Minoca OS's code seems more straightforward, potentially easier to understand for newcomers to OS development.

Both projects are open-source operating systems, but Linux has a much larger scale, community, and adoption. Minoca OS might be more suitable for educational purposes or embedded systems due to its simpler design and smaller footprint.

reactos

14,565

A free Windows-compatible Operating System

Pros of ReactOS

Larger and more active community, with more contributors and frequent updates
More comprehensive Windows compatibility, aiming to run a wider range of Windows applications
Better documentation and user resources available

Cons of ReactOS

Larger codebase, potentially more complex to maintain and contribute to
Slower boot times and higher system requirements compared to Minoca OS
Less focus on modern hardware support and optimization for newer devices

Code Comparison

ReactOS (C++):

NTSTATUS
NTAPI
NtCreateFile(
    _Out_ PHANDLE FileHandle,
    _In_ ACCESS_MASK DesiredAccess,
    _In_ POBJECT_ATTRIBUTES ObjectAttributes,
    _Out_ PIO_STATUS_BLOCK IoStatusBlock,
    _In_opt_ PLARGE_INTEGER AllocationSize,
    _In_ ULONG FileAttributes,
    _In_ ULONG ShareAccess,
    _In_ ULONG CreateDisposition,
    _In_ ULONG CreateOptions,
    _In_reads_bytes_opt_(EaLength) PVOID EaBuffer,
    _In_ ULONG EaLength)

Minoca OS (C):

KSTATUS
IoCreateFile (
    PCSTR Path,
    ULONG OpenFlags,
    FILE_PERMISSIONS CreatePermissions,
    PIO_HANDLE *Handle
    )

The code snippets show differences in API design and complexity between the two projects, with ReactOS closely mimicking Windows APIs and Minoca OS opting for a simpler approach.

serenity

30,569

The Serenity Operating System 🐞

Pros of Serenity

More active development with frequent updates and contributions
Broader feature set, including a graphical user interface and desktop environment
Larger community and more extensive documentation

Cons of Serenity

Higher system requirements due to its more comprehensive nature
Steeper learning curve for newcomers due to its complexity
Less focused on embedded systems compared to Minoca OS

Code Comparison

Serenity (C++):

ErrorOr<NonnullRefPtr<Process>> Process::create(RefPtr<Thread>& first_thread, const String& name, uid_t uid, gid_t gid, ProcessID ppid, bool is_kernel_process, RefPtr<Custody> cwd, RefPtr<Custody> executable, TTY* tty, Process* parent)
{
    auto process = adopt_ref(*new Process(name, uid, gid, ppid, is_kernel_process, cwd, executable, tty, parent));
    process->m_name = name;
    return process;
}

Minoca OS (C):

KSTATUS
PsCreateProcess (
    PCSTR Name,
    PKPROCESS Parent,
    ULONG Flags,
    PKPROCESS *NewProcess
    )

{
    PKPROCESS Process;
    KSTATUS Status;

    Process = MmAllocateNonPagedPool(sizeof(KPROCESS), PS_ALLOCATION_TAG);
    if (Process == NULL) {
        return STATUS_INSUFFICIENT_RESOURCES;
    }

    RtlZeroMemory(Process, sizeof(KPROCESS));
    Status = PspInitializeProcess(Process, Name, Parent, Flags);
    if (!KSUCCESS(Status)) {
        MmFreeNonPagedPool(Process);
        return Status;
    }

    *NewProcess = Process;
    return STATUS_SUCCESS;
}

haiku

1,898

The Haiku operating system. (Pull requests will be ignored; patches may be sent to https://review.haiku-os.org).

Pros of Haiku

More active development with frequent updates and contributions
Larger community and user base, providing better support and resources
More comprehensive documentation and user guides

Cons of Haiku

Higher system requirements compared to Minoca OS
Steeper learning curve for new users due to its unique interface
Less focus on embedded systems and IoT devices

Code Comparison

Haiku (kernel/scheduler.cpp):

void
Scheduler::EnqueueThread(Thread* thread, bool reschedule)
{
    ASSERT(thread->state == THREAD_STATE_READY);
    ASSERT(thread->queue == NULL);
    thread->queue = &fReadyQueue;
    fReadyQueue.Enqueue(thread);
}

Minoca OS (kernel/ke/sched.c):

KSTATUS
KepSchedulerEnqueueThread (
    PKTHREAD Thread
    )
{
    RUNLEVEL RunLevel;
    RunLevel = Thread->Priority;
    InsertTailList(&(KiSchedulerData.ReadyListHeads[RunLevel]),
                   &(Thread->SchedulerEntry));
    return STATUS_SUCCESS;
}

Both code snippets show thread enqueuing in the scheduler, but Haiku's implementation is in C++ while Minoca OS uses C. Haiku's code appears more object-oriented, while Minoca OS follows a more procedural approach.

harvey

1,443

A distributed operating system

Pros of Harvey

More active development with recent commits and releases
Larger community and contributor base
Better documentation and project organization

Cons of Harvey

Higher complexity and steeper learning curve
Less focus on portability across different architectures
Potentially slower boot times due to more features

Code Comparison

Harvey (Plan 9-inspired system calls):

int
sys_open(char *name, int omode)
{
    Chan *c;
    c = namec(name, Aopen, omode, 0);
    if(waserror()){
        cclose(c);
        nexterror();
    }
    fd = newfd(c);
    poperror();
    return fd;
}

Minoca OS (POSIX-like system calls):

KSTATUS
OsOpen (
    PSTR Path,
    ULONG OpenFlags,
    FILE_PERMISSIONS CreatePermissions,
    PIO_HANDLE *Handle
    )
{
    KSTATUS Status;
    Status = IopOpen(Path, OpenFlags, CreatePermissions, Handle);
    return Status;
}

Harvey uses a Plan 9-inspired system call interface, while Minoca OS follows a more traditional POSIX-like approach. Harvey's implementation involves channel-based I/O, while Minoca OS uses a simpler handle-based system.

redox

15,144

Mirror of https://gitlab.redox-os.org/redox-os/redox

Pros of Redox

Written in Rust, providing memory safety and concurrency benefits
Microkernel architecture for improved modularity and security
Active development with a larger community and more frequent updates

Cons of Redox

Less mature and stable compared to Minoca OS
Higher system requirements due to Rust's runtime overhead
Potentially steeper learning curve for developers unfamiliar with Rust

Code Comparison

Redox (Rust):

fn main() {
    println!("Hello from Redox OS!");
    let mut file = File::create("example.txt").unwrap();
    file.write_all(b"Hello, World!").unwrap();
}

Minoca OS (C):

int main(int argc, char **argv) {
    printf("Hello from Minoca OS!\n");
    FILE *file = fopen("example.txt", "w");
    fprintf(file, "Hello, World!");
    fclose(file);
    return 0;
}

The code comparison highlights the syntactical differences between Rust (used in Redox) and C (used in Minoca OS). Rust offers more built-in safety features and a more modern syntax, while C provides lower-level control and potentially better performance in some cases.

Both operating systems aim to provide lightweight and efficient alternatives to traditional OSes, but they take different approaches in terms of language choice, architecture, and design philosophy.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Minoca OS

Minoca OS is a general purpose operating system written from scratch. It aims to be lean, maintainable, modular, and compatible with existing software. It features a POSIX-like interface towards application software, and a growing suite of popular packages already built and ready to go. On the backend, it contains a powerful driver model between device drivers and the kernel. The driver model enables drivers to be written in a forward compatible manner, so that kernel level components can be upgraded without necessarily requiring a recompilation of all device drivers.

Minoca OS is event driven, preemptible, SMP ready, and network capable. It currently runs on x86 PCs and a range of ARM boards.

Screenshots

Installing Git on Minoca OS Memory Profiler Stack Profiler

Getting Started

If you're just looking to try out Minoca OS, head over to our download page to grab the latest stable images. The rest of this page describes how to use this repository to build your own custom image of Minoca OS.

Building Minoca OS

The paragraphs below will get you from a fresh clone to a built image.

Environment

The Minoca OS build environment is keyed off of a few environment variables you'll need to set in order to orient the build system:

SRCROOT - Contains the absolute path to the base source directory. This respository is expected to be in a directory called os inside SRCROOT. If the third-party or tools repositories are present, they should be in directories called third-party and tools respectively underneath SRCROOT. For example, if you had checked out this repository into ~/src/os, then in your shell you'd run export SRCROOT=~/src.
ARCH - Contains the architecture to build Minoca OS for (aka the target architecture). Valid values are armv6, armv7, and x86.
VARIANT - Contains the architecture variant, if any. Leave this unset most of the time. Currently the only valid value is q for the x86 architecture, which builds for the Intel Quark.
DEBUG - Describes whether to build Minoca OS for debugging or release. Valid values are dbg for debug or rel for release. We always build dbg.
PATH - You'll need to have $SRCROOT/$ARCH$VARIANT$DEBUG/tools/bin in your path to build successfully.

Prerequisites

To build Minoca OS you'll need a Minoca-specific toolchain for the particular architecture you're building. Prebuilt toolchains can be found here. If you want to build the toolchain from sources, you'll need to check out the third-party repository and run "make tools" in there.

Note: If you want to build your own toolchain on Windows, you may find the tools repository helpful, as it contains a native MinGW compiler, make, and other tools needed to bootstrap a toolchain on Windows.

Build

Run make to build the OS for the particular architecture you've supplied. Parallel make is supported. The final output of the build will be several .img files located in $SRCROOT/$ARCH$VARIANT$DEBUG/bin/*.img. For example, the PC image is usually located at $SRCROOT/x86dbg/bin/pc.img. This is a raw hard disk file that can be applied directly to a hard drive or USB stick to boot Minoca OS. The image install.img is a generic installation archive that the msetup tool can use to create new Minoca OS installations on target disks or partitions.

Object files are generated in $SRCROOT/$ARCH$VARIANT$DEBUG/obj/os. You can run make clean, or simply delete this directory, to cause the os repository to completely rebuild. Alternatively, you can run make wipe to delete all generated files, including the third-party tools you built or downloaded. Running make wipe simply deletes $SRCROOT/$ARCH$VARIANT$DEBUG/. We usually stick to make clean since make wipe requires a complete rebuild of the toolchain.

A note for macOS users: We've managed to build successfully using both GCC from XCode 8 (really clang) and Homebrew GCC, both using the 10.12 SDK. Some users have reported that they need to export SDKROOT=$(xcrun --show-sdk-path) to build properly.

Running

To boot your built images, you can write the appropriate image for the platform you're trying to boot to a USB flash drive or hard disk. On Windows, you can use the Win32DiskImager tool (included in the tools repository under win32/Win32DiskImager). You can also use the msetup tool to build custom images. If you use the msetup tool to install Minoca OS onto a partition of a disk containing other partitions that you care about (such as on the same machine you're building from), we highly recommend making a complete backup of your disk. Minoca OS is still new, and we wouldn't want a bad bug to wipe out all your data.

If you're building Minoca OS on Windows and have downloaded the tools repository, several shortcuts have been set up to allow you to quickly run a Qemu instance with the images you've just built. Make sure you fired up the development environment with the setenv.cmd script. Type run, then dx to fire up an x86 Qemu instance of pc.img with a kernel debugger attached. We use this internally for faster development. If building for ARM, it's runarm and da.

Nickel Tour

Below is a brief orientation of a few of the directories in the repository. Check the Makefile in each directory for a more detailed description of what that directory contains.

apps - User mode applications and libraries
- ck - Chalk, an embeddable scripting language
- debug - Debugger application
- libc - The Minoca OS C Library
- osbase - The Minoca kernel API library
- setup - The msetup build tool
- swiss - POSIX tools in a box
boot - Executables used during system boot
- mbr - The Master Boot Record
- fatboot - The Volume Boot Record for FAT file systems
- bootman - The Minoca Boot Manager
- loader - The Minoca OS loader
- lib - Libraries shared across multiple boot executables
drivers - Device drivers
- acpi - ACPI platform driver, with AML interpreter
- fat - FAT file system driver
- gpio - GPIO core library and SoC drivers
- net - Networking support
  - ethernet - Wired ethernet controller drivers
  - net80211 - Core 802.11 support
  - netcore - Core networking support (TCP, UDP, IP, ARP, etc)
  - wireless - 802.11 wireless controller drivers
- pci - PCI support
- sd - SD/MMC support
- spb - Serial Peripheral Bus drivers (I2C, SPI)
- special - Special devices (/dev/null, full, zero)
- usb - USB support
  - ehci - EHCI host controller support
  - usbcomp - USB composite device support
  - usbhid - USB HID support
  - usbhub - USB hub support
  - usbkbd - USB keyboard support
  - usbmass - USB mass storage support
  - usbmouse - USB mouse support
- input - User input drivers
- videocon - Video terminal console driver
images - Recipes to create the final images for each supported platform
include - Public header files
kernel - The Minoca OS kernel
- ke - High level executive functions
- mm - Memory management
- io - Input/Output subsystem
- kd - Kernel debug support
- hl - Low level hardware layer support
- ob - Object management
- ps - Process and thread management
- sp - System profiler support
lib - Common libraries used throughout boot, kernel, and user mode.
- basevid - Library for drawing text on a framebuffer
- fatlib - FAT file system library
- im - ELF/PE image library
- partlib - Partition library
- rtl - General runtime library (printf, date/time, memcpy, etc)
- termlib - Terminal support library
tasks - Internal automation configuration
uefi - Minimal UEFI implementation for platforms supported by Minoca OS.
- core - Platform-agnostic UEFI firmware core
- dev - UEFI device libraries
- plat - Recipes and code for specific platforms
  - beagbone - BeagleBone Black firmware
  - bios - UEFI over BIOS firmware
  - integcp - Integrator/CP firmware (for ARM Qemu)
  - panda - TI PandaBoard firmware
  - rpi - Raspberry Pi 1 firmware
  - rpi2 - Raspberry Pi 2 and 3 firmware
  - veyron - Asus C201 Chromebook firmware
- tools - Tools used in building final firmware images

Contributing

Submissions are welcome! See our CONTRIBUTING.md page for details, or our WISHLIST page for suggestions. Bugs can be reported here on Github.

License

Minoca OS is licensed to the public under the terms of the GNU General Public License, version 3. Alternate licensing options are available. Contact info@minocacorp.com if your company is interested in licensing Minoca OS. For complete licensing information, see the LICENSE file in this repository.

Contact

Email: minoca-dev@googlegroups.com
- Contact security@minocacorp.com for security related issues.
- Contact info@minocacorp.com for private or business inquries.
Website: http://www.minocacorp.com/
Github: https://github.com/minoca
Gitlab: https://gitlab.com/minoca
IRC: ircs://irc.oftc.net:6697/minoca-os

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot