Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Zen1th

  1. 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
  2. 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. Why: 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 Specification: 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. Application Table: 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 Example: { { "drive": "af58dbe2-ff8c-433a-a871-c08723e01f25", "path": ".efi/sampleos.lua" }, { "drive": "af58dbe2-ff8c-433a-a871-c08723e01f25", "path": ".efi/osOnSameDrive.lua" }, { "drive": "015f9d4c-cdfb-4686-91cb-bc8cf997f4ec", "path": ".efi/another_os.efi" } } Application Finding: 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) 68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b (ASCII character 15) .efi/fuchas.efi T
  3. As far as i know, no, i'm not a OpenComputers developer, however i have some knowledge in Forge modding, one problem they will have to encounter is that making OC compatible with 1.13.x would need changing most of the code (mostly because it makes usage of metadata, and some other things). So it will probably be hard and long to do, since it will be long, i think it will probably be in beta (or something like that) for 1.13, and finished when 1.14 However, this is only what i'm saying, it isn't approved by any of OpenComputers active developers, so considerate what i said as a possible option
  4. Due to how computers, in real life, so also in Lua works, it's logical, the number of bits to store on the number being also finite
  5. uhmm.. can't we have more information on it? Like version, modpack (if needed) ? edit: nevermind, i just didn't looked the title, it's using all the mods 3
  6. Making liburf (omg it can't be a oc implementation of URF)

  7. Yes i have discord, anyways if i mentionned GERT it's because i find interesting the idea of connecting minecraft servers each other. It allows for a OC "internet", since oc servers can now technically be acessed from any minecraft server having a GERT address. Which allows for endless possibilities in oc web.
  8. OHML is a markup language based on XML, it is a simpler, OC-graphics adapted version of HTML.Par Part 1: Why i got that idea? It all started when i noticed that most network programs/libraries were either DNS system, or Website system. I tought it was very important to maintain an universal language for webpages. It is the first step of having a stable and universal "OCnet", which will follow with server and client implementations. Protocols, etc.. To finally have it united. It would mostly be useful with GERT since it allow for one, global, routing technology. Part 2: OHML versions OHML patch versions (1.0.1, 1.0.5, etc.) minor changes (more understandable descriptions, new optional arguments) can be asked in comments section, might get accepted, and when features are froze, set as a new minor version of OHML specifications. OHML minor versions (1.2, 1.1, 1.42) will accept features (new tags, deprecations, rename of tags/arguments, etc.) can also be asked in comments, they will get a seperate title from their major version, and have the space feature-freeze process than patch versions. OHML major versions (2, 4, 5) can start from a little draft based on a major feature (removal fo tags, minor/medium changes in way how code is wrote, etc.), and then should be put in another OETF thread, to add new features, validate them, and polish them. OHML v1.0 tags: Table about all tags and their (XML) arguments is available in png format, attached to this topic. Examples: Image: <image file="blabla.pic"></image> = "blabla.pic" showen as PIC (MineOS image) format Text: <text>Hello!</text> <text>World</text> Script: <script lang="some_script_language">Some multi-line script</script> Hyperlink: <a href="/superdupernews.ohm">Show super duper news</a> OHML v1.0.1 revision: Tags can now have optional arguments "x", "y", "width", "height" and "relative" The "relative" argument is for using relative positions, vertical at first, and horizontal at last, we can use "up" (default) or "bottom", put a ";" for splitting, and add the horizental value that can be "left" or "right". Relative positions works that if for example the value is "bottom;right", and if x = -5 and y = -5, the element Y will be at the most bottom point of the page (meaning that bottom for a page with elements not going after 10 for y, the bottom would be 10), added -5, which is equivalent of minus 5, and the element X will be at most-right point (generally viewport width) and will have minus 5. Meaning that for a viewport with size of 80, 25, it would go at 75, 20 Part 3: HREF format An HREF format defined in <a> tag can be relative or absolute. If a href starts with any supported protocol name followed by "://" (ex: ohtp://), the link is fully absolute and should be coutned as the same than if the user inputed it as a website. It's a normal URL Then, if a href starts with "/", it is relative to the website host (can be ohtp://test.com), so, the full path is: {WEBSITE HOST} + {HREF} Finally, starts with nothing above, it is relative and should be appended to the actual URL URL are in the same format than real ones (protocol://host://webpage) OHML, being a markup language, will not support any kind of dynamic coding like <if> statements, <print> statements, etc., dynamic coding is handled by <script> tags and scripts languages supported by the browser. (Currently no script language has been made, it's coming). Anyway thanks for reading that long document about OHML, feel free to ask me things. I am actually making a protocol for it (OHTP) and then a basic server + client implementation. A OHML decoder hasn't been done yet, but since OHML is based on XML, any XML parser will do the job, then just show tags appropriate content and here it is! OHML is ready for any people making a script format and a web protocol. Community will choose by itself which one is used.
  9. Oh my god! The cases are so much amazing, way better than the ugly and blocky ones that had 2 textures. I can't wait for more cases. Good job!
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.