A modular OS featuring to include some interesting features,
It will include the features in Features.
- Dynamic Program loading and sanitation
- Static, Dynamic and Automatic Memory control and Allocation,
- Memory Protection
- Modular GUI object creation,
- System calls,
- At set intervals a checksum is compiled from a Program's code, for Kernel Programs this checksum validates that the Program has not been overwritten, such as by goonrepo.
-
- These are short 30 char names that can be used to represent Executable Paths. The Path struct's Path contains the whole Path. A Path executable must contain the signature "_start(uint8_t *args, size_t arglen)" function which will contain args.
-
Goonrepo is a NOT IMPLEMENTED! Program that will raise a Program's Admin level.
-
- Oh my gosh, Spheres?!?!?!!! So blasphemous. Use the sphos command with goonrepo for it to clear out RAM, killing the OS, causing the OS to crash.
-
Option 1:
The Program defines a Stream, The Buffer is zeroed, It takes the returned Pointer and decrements the size_t address, it does this till it meets the starting point of the Stream object A string Path and a Buffer. The Path is overidden to point to the OS's text(Code), the address is set to point back to the buffer, The buffer reads from the grippy cli Executable, goonrepo will override the grippy cli in RAM with the inputted Program's code. The Program's size will be capped to how much of the grippy cli has been loaded to RAM. The cli may crash due to the execution suddenly changing, or being executed whilst being written to, goonrepo may repeat this instruction multiple times until the rewrite has function properly.
Option 2:
The
-
Note
Remember this cli, It is NOT IMPLEMENTED!!
-
- This will automatically allocate Memory by a prediction of how much Memory a program or a function will use.
- This will allow Functions to allocate more data during Runtime, generally this should not be met as Static allocation should already allocate enough Memory for the function's needs.
- This will run every few Render Pages and free Memory Pages that have not been referenced frequently or Un-pointed.
- Programs can at Runtime to Un-point memory via a System call, freeing to for other programs to use it.
- Memory blocks use two properties to handle thier protection and how they are handled, An unsigned integer and a Boolean value.
-
-
Objects can be created and rendered, these objects are self-contained and closed Systems.
This will allow them to be Modular.
-
Objects can be created and rendered, these objects are self-contained and closed Systems.
-
-
Programs can call pre-defined Exceptions to cause certain events to occur, these Exceptions can take Parameters or will peek into a function's Memory to retrieve expected info, if the expected info is not found an ACTUAL exception may be called.
- Explicit Execution requires the Psarameters to be inputted as arguments when the function is being called.
- Implicit Execution does not require the Parameter to be inputted as arguments, the arguments can be loaded into a specific Memory Adress or stored in a variable with both the expected Type and a double dollar sign ($$) before the name.
[!NOTE] See Exception List.
-
Programs can call pre-defined Exceptions to cause certain events to occur, these Exceptions can take Parameters or will peek into a function's Memory to retrieve expected info, if the expected info is not found an ACTUAL exception may be called.
- The OS comes with a pre-built, binary tree describing each function and it's dependencies. This tree can be loaded directly into memory without parsing as it will be constructed from the OSses binaries. This tree will define a config to use for isolating functions, this will be the core of spawning secure kernel threads, where the funcction itself will be isolated from the OS. The OS will use this to spawn isolated threads that can be considered priviledged however will not beexpected to last, these threads will not be protected, they will be de-spawned if nor used in 10 Process frames, the fathering Process/thread is informed of this.
Note
I use the phrase "spawning bytes" to loosely describe the process of bytes being loaded to memory.
-
Headers describe a data block and Context about the data stored there, this simplifies how data blocks are regarded and how they are accessed.
Headers are not directly stored in RAM, instead the Data is stored in RAM, with the Header's starting address and it's Context stored in RAM.
- A block of memory at the end of RAM stores the starting addresses(as size_t pointers) of data blocks in RAM. This allows for quic access to the data blocks, whenever neccessary rather than having to search through RAM.
-
-
Each program has it's performance graded in it's CPU Usage: CPU Frames, and GPU Usage: GPU Frames.
- CPU Frames are measured in how much of it's time allocation is actually used.
- GPU Frames are measured in how long it takes for each GPU request to be processed, with the longest times compared to the lowest times.
-
Each program has it's performance graded in it's CPU Usage: CPU Frames, and GPU Usage: GPU Frames.
-
- Binaries can be loaded into the OS's Program Files, the chenges actually come into effect on next start-up as the Program will be available to load it on Start-Up. More information is more available at OS Programming. In order to maintain integrity NO Programs are allowed to edit the Program Files, aside from a specific Program.
- Data that may be accesssed frequently is stored at publicly available adrresses that are updated on every Interrupt.
- 100 times per second an Interrupt occurs, allowing Low-Priority Instructions to be run etc.
- Programs are loaded into RAM, they will have OS-dependent binaries swapped out for a supported alternative.
- Streams are read-only Memory buffers, being Kernel write-only Data blocks. They consist of a
