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

Zen1th

Members
  • Content Count

    13
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Zen1th

  1. I didn't finished the installer. However i added a VERY IMPORTANT FEATURE, before events were handled by programs and blocking. Now events are handled by the task manager. Meaning A process can pull event while another does something else. Which is very close to multi-tasking. However this feature is buggy and some events are skipped, this should be fixed by optimizing. Alongside this i might make a GUI soon to show the benefits of multi-tasking V.S. single-tasking (used by MineOS and tactiOS). Which would allow programs to be active (doing something without blocking GUI) rather than passive (waiting for GUI event)!
  2. OHML being complete, it just needed something next so the OHML specification is complete. And this thing is what is here: OHTP Definitions: Host - Any computer or machine with a OC-compatible modem attached to it Server - Host sending OHTP-valid data when an user attemps to connect Client - Host receiving OHTP-valid data from a Server OHTP - Open Hyper Text Protocol - Protocol used to transmit OHML - Open Hypertext Markup Language between Hosts. Specifications: The OHTP protocol doesn't take care of what is transporting it. Either it is using a socket API, going through modem, minitel or GERT. It assumes the API or transport layer you utilize supports sockets. Arguments in URLs: To put arguments inside URL, the url must end like normal, but have "?" at end, followed by "property=value" entry. If wanting to add more entries, add "&" after last entry Example: ohtp://1001.1002:1003.1004/index.html?username=admin&password=admin Client-Side: Once the socket is opened, the Client can ask data to Server The Client will send first a Request Header looking like it: OHML/MAJOR.MINOR REQUEST PAGE Example, if the REQUEST is GET, and the version 1.0, with a request page equals to /index.html (the PAGE entry CANNOT BE EMPTY, if wanting to access default file of server, use /): OHML/1.0 GET /index.html Currently the valid REQUEST values are: GET (just receive the file) There are also request bodies, which just include "Property: Value" entries. For now, request body is unused, however, there can be non-standard properties, but they must start with "X-" So a request is constructed like that: Request Header( + Request Body) The client, even after having received the Response from Server can still send new requests. All that until socket is closed. Server-Side: Once the Server receives a Request from a client. It must replies with a Response. A Response is contructed like this: Response Header + Response Content The Response Header is constructed like this: ERRORCODE Yep, i know it's really small, making it simple to implement. Currently there are thoses error codes: 200: OK 201: Moved permanently + new URL after ERRORCODE 300: Temporaly moved + new URL after ERRORCODE 301: Switch protocol + approved protocol name after ERRORCODE 404: Page not found 500: Server error 501: Internal error sending the the fetched page (e.g. file found but not accessible from server). 502: Server-side language is errored (Detailled version of 500, optional) 503: Service temporaly down The Response Content is just the content of the fetched file (if found).
  3. For the signature, is the current version of this document is 1.0 (1 as major and 0 as minor) or is it something else? Because it's not written inside the document.. Also, the document says all string are encoded in UTF-8, ok, but must have their length at first, does it applies for the "URF" string part of the signature? There is also a lot of oddities in the entries, you say that if the entry is a file, the specifier byte must be "F", well it's ok because ASCII F byte have 6th and 7th bits equals to 1. However if the entry is a directory you say the specifier byte must be "D", but in ASCII, D equals 68 in decimal, in binary the 7th bit is 0. Also you say a entry should contains Object ID and Parent ID, but where, is parent id first or last? And is it written with 32-bit unsigned integer? Is it an ALI? You're not saying it which makes hard to make a standard implementation! P.S.: Even if document is unprecise, i managed to make an implementation of it, the first URF file is born
  4. I finished the 2nd stage installer, i'll do the 1st stage (installing from OpenOS/MineOS) when i will have more time
  5. Is there any video games for OpenComputers? As this would be cool, and no, i'm not speaking about a chip8 emulator or lunatic86. By that i mean games targetting OpenComputers Lua architecture. If no, that would be interesting to create some. After all almost all the programs i saw on the Showcase are OSes, #### control programs, drone managers, etc.
  6. Fuchas One of the best multitask OS How Fuchas Works Fuchas is a true multitask OS for OpenComputers. By true multitask, i mean it is based on a task manager. To do it simple, the task manager cycle through all the active processes. It also pulls signal with a timeout of 0.05 seconds! (Speed is best). Fuchas is also modular and based on a driver system, the driver library will try automatically choosing the best driver, but it can be configured by user. Meaning programs can easily adapt to addons hardware (e.g. Computronics cards), however for now this aspect of Fuchas isn't really well used, a re-overhaul of it is planned soon. If you don't understand all that just retain something: Unlike OpenOS, it can run tasks at same time. (Technically it's not correct, since there is like a ~0.05s delay between tasks, due to Lua nature) Interfaces Fuchas, being modular, is about not fair to have 1 interface. That's why there can be multiple interfaces. Currently only one is included: Fushell (basically like OpenOS shell). Soon to come will be "Concert", which is a GUI interface, better suited for multi-tasking. Currently, the only interface to show, Fushell: You might as well as spotted the "pl" and "kill" command. Yep! Thoses are multitask commands I'm not doing a whole documentation here, but basically "pl" lists tasks (called processes internally) and "kill", well, it kill tasks Installing Whatever from what OS you're installing it. OpenOS: Just type the following: pastebin run s2YZJ0T6 MineOS: Coming soon.
  7. 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
  8. 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
  9. 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
  10. 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
  11. Making liburf (omg it can't be a oc implementation of URF)

    1. Zen1th

      Zen1th

      liburf done :) !

  12. 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.
  13. 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 OHML v1.0.2 revision: - Added new tag: <br></br>, allows to break line in any ohml tags. 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.
  14. 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.