Ore OS is an operating system that runs Ore code natively. At this time, it is built into a Runtime Environment, but will eventually be ported to a UNIX kernal for a bootable version.
Currently, Ore OS is divided up among 4 modules with 4 more modules that are either planned or already in development. These modules will bring more features. Current features of the operating system include a simple CLI, basic file manipulation, task scheduling, single-user mode with special privileges that are reserved for an elevated user-mode, multiprocessor support, and more.
As of the current version 0.1.3.7, process scheduling is FIFO (first-in, first-out), but scheduling will change to EDF (earliest deadline first) in a future release after the kernel module is implemented.
Ore OS is modular, so components of the operating system can perform independently, with specialized components that are set to handle various kinds of functionality. As of version 1.0, Ore has 4 components: Dictionary, Petroglyph, Ore, and Terminal.
The main component of Ore OS is the Ore module. This portion is the meat of the operating system, which handles all the various stacks, error checks, string and function interning, and variable table. Most input/output is handled directly within the Ore module, which includes file manipulation and command input. Commands and scripts are grabbed from the terminal and passed to Ore to be prepared for Petroglyph. Additionally, anything that is sent to the Terminal or shell is passed through Ore, first.
Petroglyph is the lexical analizer module of Ore OS. It interprets all commands being passed to it from the Ore module and responds with the proper set of instructions along with the order of operations. Additionally, Petroglyph interprets the Dictionary whenever Ore OS is booting up in order to set all aliases and function checks.
The Dictionary is a read-only component of Ore OS that contains definitions of all functions and aliases. It also contains information about some operators.
Whenever Ore OS starts up, the information is read by Petroglyph. The metadata for functions that is gathered in the process includes parameter data, input types, output types, availability, function descriptions, and more. Data for global variables and constants is much more simple as it only contains aliases, return values, and some other information.
This module is the main component for user interaction within Ore OS at this time, which is handled slightly differently in each runtime environment. This is because the Terminal is custom coded for each system and sandboxed in a Runtime Environment until the kernel-level version of Ore OS is released.
Ore's Terminal is very similar to most generic terminals: You type in the commands and code, and submit the instructions. Because the terminals are custom-coded for non-kernel environments, additional features can be included that will be removed as Ore becomes more independent, such as submitting files or viewing private Ore data.
Castle is a shell component that is scheduled for development and release in version 5.0 of Ore OS. It will be the default shell of Ore, which will be similar to other popular system shells. Features that it will include are: Simple user interface, multiple application windows, file explorer and customizable user experience.
The graphical processing in Ore OS will be handled by Mural, which will be available for use in version 3.0 of Ore OS. Initially, only 2D graphic capabilities will be available, but more advanced features will be developed and implemented in version 4.0 and beyond.
All network communications in Ore OS will be handled by the Mine Cart component. This module will allow ad hoc and internet networking features upon release of version 4.0 of Ore OS. Basic features will be available at release, but more advanced features will be developed afterwards as Ore OS grows.
Ore OS will eventually be built on top of a UNIX kernel to allow a bootable Ore OS environment. More information will be made available about this as version 5.0 approaches.
The folder structure for version 1.0 of Ore OS is given. As Ore is updated, this folder structure may change.
The alias file in Ore is at /sys/set/alias.set, which is a special file that holds user-defined aliases to programs or other commands using the alias command just like functionally assigned keywords. This command can also be used to output the current alias data in Ore. The alias file is loaded as a part of Ore's bootstrap, setting additional keywords that Ore can interpret.
The association file in Ore is at /sys/set/asc.set, which is a special file that holds user-defined filetype associations to a given programs using the asc or assoc command. These commands can also be used to output the association data in Ore. The association file is loaded as a part of Ore's bootstrap, setting the default program used to open given filetypes.
The bootstrap file in Ore is located at /sys/boot.ore, which is a special file that lists instructions for Ore to run whenever Ore is first booting up. This file can be later loaded using the boot command, but this is typically not advised.
The paths file in Ore is at /sys/set/paths.set, which is a special file that holds the default locations of system paths and special files. All of the default directories in Ore are specified in this file, but can be re-defined by the user using the paths command. Paths file information can be quickly displayed using paths, too.
Currently, Ore OS is built into a Runtime Environment that offers several additional features, depending on which system is running Ore RE. Windows and Android both have working variations of Ore RE, and will be made available on the Download page as soon as they are publically released.
These environments offer the ability to boot into Ore's CLI and use it as though you are running the operating system natively. This allows full use of Ore's modules and functions that you would normally have access to, so long as the system's administrative capabilities are not interfering. Simply type in some commands and go! Additionally, because Ore RE will be wrapped into executables, there will also be intents available, meaning that files can be opened with and sent over to Ore from Windows or Android.
The current plan for the runtime environments is to offer two separate modes of use: A sandboxed mode and a mode that has access to all files and locations in the system that is running Ore RE.