I started, last year, an operating system.
Today i'm presenting you that modular project.
Because yes, it is mostly based on modularity, its folders make think about Windows.
But enough speaking, i arleady written an introduction in the README, let me adapt it
Some example image: image
Fuchas haves a lot of libraries inside it. (like shin32 or shinamp which are in the same order for multi-tasking and misc operations and for audio), the "NT" part is basically just the boot/init part, originally called by init.lua or the content inside driveinit.lua if on a unmanaged drive.
Fuchas is based on drivers instdead of APIs directly interfacing with components (except for components sure they are present and core to the operations), it allows for user drives, and mostly, having programs compatible with hardware from addons mod supported by Fuchas, that's a great step forward considering that without Fuchas, each software (even on MineOS) has to support the hardware themselves. For that, Fuchas will load the most relevant hardware for the configuration (e.g., for sound, if Computronics Sound Card present, use it instdead of PC Speaker), however in case of conflicts, (following is not yet implemented) it will be able to load multiple drivers and supply them, up to the program to choose the best (or to the user if it prompts for).
Fuchas is also multitasking, it works with a "main thread" (originating from the boot), it cycles through all active processes and execute a "tick" of them, processes's tick should only last a short time (a "tick", best around 20ms or lower, 50ms max for stability). (TODO ->) Long-term (more than 50ms) blocking operations (like I/O) gets a part (like 10 bytes of a file, can be set via priority) of the work time. Basically Fuchas uses cooperative multitasking.
Well i hope it makes it a bit interesting, however, multi-tasking is supported, but some things (like event listening) are still synchronized and blocking (for now, it's gotta change very soon)!
Also, it doesn't have any installer for now, sorry guys, i was mostly interested by the "under the hood" part
GitHub link of the OS
I understand some people might just dislike another booting method, even if implementations should be compatible with original one. And as the document might seem "empty", any criticisms (good or bad) and/or suggestions are welcomed.
Note: "Application" refers as init scripts for OEFI booting.
Due to the limitation of current OC booting method which basically searches for an init.lua file, a new and open specification has been made: Open Extensible Firmware Interface. The limitation OEFI fix in BIOS booting in OC is:
- In BIOS booting, there is only one init script per filesystem, while in OEFI there can be multiple applications per filesystem.
- The operating system, once launched, cannot return back to the BIOS (or here, the OEFI), while OEFI have oefi.returnToOEFI()!
- Since BIOS booting doesn't have any native support for multiple applications. An OS that want to boot another one need to manually check for init.lua files in all filesystems, OEFI has oefi.getApplications() method for it
Every OEFI should be backward-compatible with OC original booting method which is basically booting init.lua.
OEFI must also create a standard API available to the OEFI program as the first argument (of "..."), the API must implement at minimum the following:
oefi.getApplications() - Return an application table as described below
oefi.getAPIVersion() - Return API version number, current = 1
oefi.getImplementationName() - Returns implementation name
oefi.getImplementationVersion() - Returns implementation version number
oefi.returnToOEFI() - Recalls the OEFI program, most of _G structure should remain as it was at boot. Meaning that if for example, component API needs "require(...)" function, this will just crash.
oefi.execOEFIApp(drive, path) - Boot another OEFI app by using the implementation routine
computer.getBootAddress() - Return the filesystem address from which the application booted
computer.setBootAddress(addr) - Provided for compatibility, does nothing
Implementations can create implementation-specific methods that can be used by applications and OSes launched by them.
The application table must contains tables as entries.
The tables must contains the drive address with "drive" key and the path (from drive) with "path" key
OEFI Applications can be found on any sort of drives, from disk drives to floppy, with raids, only if they contains a ".efi" directory.
The OEFI should search in that ".efi" directory, and add every .lua or .efi files to its application table. ".efi" directory name has been chosen for being hidden by default on POSIX systems.
(EEPROM) Data Format:
Booleans are a single character value, they are equals to "T" if true, or "F" if false
1-Byte Numbers are also single character values, they are corresponding to the ASCII character of the number (use string.char(number)), these are limited to 255 as maximum value
As of API version 1:
The data (512 bytes) should be written in the following format (in the same order!) :
- 1-byte number, equals to the API version of the implementation (current is 1), having it at start will allow for config conversion in case of new version
- Last booted application filesystem component id (always 36 bytes) (like 68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b)
- 1-byte number, equals to the length of the last booted application path (next value)
- Last booted application path
- 1 boolean for weither it should allow the OS to return back to OEFI or not
Example (line breaks should NOT be included):
(ASCII character 1)
(ASCII character 15)
I never needed them in my own setup (I prefer piston-based doors), so I saw no point in supporting them. That was before this script was published here. Later I've been thinking about adding new modules, including the one responsible for controlling security doors, but that would require a quite large modification of the core script (the ability to run more than 4 modules simultaneously). I didn't know if anyone used The Guard, so I didn't want to rush into this (partly because the lack of time).
The dark theme was never tested, but I'll try to make it work. I'll add a new post when a patch is ready.
thx, for the quick fix! I think this program is very versatile due to its modular construction.
You are not supporting doors and the SecurityBlock?
I saw there is an option for a "Dark Theme". When i enable it it says "restart the program" but the design remains the same.
Yes, I can confirm it's still maintained, but due to a lack of interest support is currently limited to bug fixes only.
I have fixed the bug, just update the library:
arpm install gml