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

Zen1th

Members
  • Content Count

    54
  • Joined

  • Last visited

  • Days Won

    15

Posts posted by Zen1th

  1. Nevermind, everything (relating to installation) has been fixed. And here is a computer working with Fuchas :)

    spacer.png

    I'm glad now installing Fuchas is 100% easy (you have to press 3 keys during installation)

    P.S.: To have a easier dualboot, i will continue working on my (currently secret) OEFI implementation. It will allow booting other OSes instdead of just Fuchas and OpenOS (but it will be on EEPROM side, not HDD, which makes it a bit more limited). Of course we will be able to select something like "I arleady have an OEFI", "I don't have an OEFI", "I don't want an OEFI" during installation. So that people not wanting on OEFI or too lazy to install an OEFI can select their option

  2. Ok it turns out that i was dumb on the condition that checked GPU and screen. I forgotten to add a ~= nil. Anyways gotta publish changes, re-install in 15 minutes and it should be all good (this time it will be good!)

     

    Or you can manually edit init.lua, add "== nil" at line 19 after cp.list("screen")()

    And also thanks for still wanting to use the OS after all those little installation bugs i really appreciate this :)

  3. All bugs (i know of) related to installations are now FIXED!

    You can now freely install Fuchas without any problems. However only dual-boot work FOR NOW. Due to the lack of "edit" command, you will have to go to OpenOS to code Fuchas programs using "edit" command. I'm planning a editor for Fuchas, i'll do it when i can!

  4. I figured out the error, the main problem seems to be that, somehow, xpcall seems asynchronous only in OC machines and that so it will result in the computer finishing Fuchas/NT/boot.lua instdead of continuing Fuchas execution. Resulting in a computer halt. Second problem is that i forgot to add the "shell" library on first download. But the xpcall error is strange

  5. Thanks for reporting the installation bug and the error after installation. I will search what is causing this error to happen and i will fix it. However the error only seems to appear on OC computers but not on OC emulators :/, i guess i shouldn't rely that much on emulators for compatibility..

  6. The mod is not even yet updated for forge 1.13.X, so a version for 1.14 will maybe be in months or even year, since 1.12 and 1.13 have lot of technical changes. However i'm not a official developer of OpenComputers, so that's just guessings.

  7. 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)!

  8. 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.

    Line Break - Unix style line break: line feed (\n)

    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.ohml?username=admin&password=admin

    writeTable/readTable, Fuchas's liblon, etc.

     

    User Agents:

    User agents are standard strings defining what browser and what layout engine a user is using. It can be used for metrics and/or compatibility purposes (in case standards aren't fully respected).

    An user agent is presented in the following form:

    BrowserName/BrowserVersion, LayoutEngine/LayoutEngineVersion

    where LayoutEngine is the layout engine and LayoutEngineVersion is layout engine's version, etc.
    The format has been thinked to be simple making it easy to parse. Since it's just 2 fields separated with a "," (Browser name and version + Layout engine name and version), and in those fields, the name and version separated with a slash (/).
    Parsing user agent is in this case, just some splitting of strings.

    For example with Icecap browser (coming soon):

    Icecap/0.1, Geeko/1.0

    Peanuts:

    Peanuts are data stored as text files in a key=value scheme.
    They are handled on client-side and are only edited by server. He edits it by sending a response property (Set-Peanut) to client.

    A Peanut Group (peanuts) is separated by ";". Making ";" the only invalid character in peanut key and value.
    Server is aware of Client peanuts by the Peanut request property. Which sends peanuts as a Peanut Group. Of course this property is optional as a client doesn't always have peanuts.

    Now the most important note about peanuts: When a server send a Set-Peanut property. The peanut must be set for the whole website and not only the current page!

    Connection:

    OHTP DEFAULT Port SHOULD be 80

    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:

    OHTP/MAJOR.MINOR REQUEST PAGE

    Example, if the REQUEST is GET, and the version 1.0, with a request page equals to /foo.bar (the PAGE entry CANNOT BE EMPTY, if wanting to access default file of server, use /):

    OHTP/1.0 GET /foo.bar

    Currently the valid REQUEST values are:

    • GET (just receive the file)
    • UPLOAD (part of upcoming OHTP 1.1 document, will be used to upload files if the Client has permissions)

    There are also request bodies, which just include "Property: Value" entries.

    Non-standard properties, must start with "X-"

    Standard Properties:
    Standard properties are for now:

    • Peanut - Inform server of currently saved peanuts (see Peanuts)
    • User-Agent - User Agent of the current browser (see User Agents)
    • Referer - If redirected from a link, equals to the previous website URL.
    • Host - The hostname the browser used to connect to this website. This let the website know how it is identified. Useful for 300/301 error codes.

    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.

    Example Request (whole):

    OHTP/1.0 GET /index.ohml
    User-Agent: MineScape/1.0, Geeko/0.9
    Peanut: login=true;username=admin;password=admin
    X-Non-Standard-Header: non standard value

    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
    Response Body
    
    Response Content

    It's really small, making it simple to implement.

    Currently there are thoses error codes:

    • 200: OK
    • 300: Temporaly moved + new URI after ERRORCODE. The browser will redirect to the URI but is unable to cache.
    • 301: Moved permanently + new URI after ERRORCODE (ex: 301 ohtp2://thismachine). The browser will redirect to the URI and can cache it. Best used with Host property.
    • 302: Switch protocol (e.g.: 301 OHTP2) + approved protocol name after ERRORCODE
    • 303: Switch network protocol (e.g.: 302 minitel) + approved protocol name after ERRORCODE
    • 403: Invalid request
    • 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 Body is just a bunch of standard properties exactly like in the client-side request body. However the valid properties changes for Server.

    Standard Properties:

    • Set-Peanut: Sets a peanut on client.
    • Content-Size: The size of the content. Useful for long downloads!
    • Content-Type: The MMTI identifier for the corresponding resources. If not found, defaults to "text/txt"

    Like Request properties, unstandard ones start with "X-"

    The Response Content is just the content of the fetched file (if found).

    THE RESPONSE CONTENT MUST BE SEPARATED FROM RESPONSE BODY WITH TWO LINE BREAK (\n\n)

    Example Response (whole):

    200
    Set-Peanut: isadmin=true
    Content-Type: text/ohml
    
    <ohml>
      <text>Hello World!</text>
    </ohml>

     

  9. 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 :)

  10. 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.

  11. Fuchas
    One of the best OSes (as said by me)

    Fuchas in a Nutshell

    Fuchas is revolutionnary in that it uses drivers instead of component access and support UAC (with separate permissions!) ! It's the end of the era where the program needs to maintain integration with different components, the OS now does it! The driver library will try automatically choosing the best driver, but it can be configured by user. Meaning programs adapt to components with no effort (e.g. Computronics cards)

    A feature of Fuchas is security. If you do not trust a program, you can control permissions. Each account can have its own set of permissions. Allow one to have free access on a specific drive? You can do that!. Security is useful for computers on big servers with competivity. Although remember that without disk encryption, data can be accessed simply by using another operating system. Fuchas doesn’t hide files starting with ".", it uses attributes, filesystem’s one if supported on unmanaged drives, or with a .dir file at file’s parent directory.

    Fuchas is also fast at startup, around 2x faster than OpenOS down like memory usage. And graphical features are optional, so you can use command-line on your T1 computer, and a graphical interface on T3, all on the same OS! And since the UI is compatible with 40x16 and doesn't uses a lot of memory, you can use both on a T1 computer!

    Extra Features

    For example, the GUI interface of Fuchas (named "Concert") uses the newly added GPU buffers when available in a way that is transparent to programs and user.

    Interfaces

    Here are the interfaces included: Fushell (a command-line shell) and Concert.

    For example here is Fushell (warn: old version [4 major releases ago], but still a little representative):

    Fushell 0.2.0

    and Concert as of Fuchas 0.7:

    Screenshot_20210829_104335.thumb.png.ceacae7ff6a7d668115367e342596dd6.png

    Install It

    OpenOS:

    Just type the following:

    pastebin run EbHYvEE8

    MineOS:

    Search for the application 'Fuchas Installer'. Install it, launch it, and press Install.

    Fuchas:

    You’re on Fuchas :D

    (Note that all comments about broken installation below are outdated, and installers has been fixed!)

    Links: GitHub, Wiki, Progress to next version, And here is how to break the whole Fuchas security system

  12. Open Extensible Firmware Interface v2.1

    FOR LUA ARCHITECTURE, OEFI PRESENTS LITTLE TO NO ADVANTAGES!

    Lua BIOSes that implements OEFI must allow using conventional booting.
    Note that OEFI has been made to be more architecture-independent and will support ANY architecture able to read files and CPIO (basically any architecture with basic access to component and bitwise operations).

    Concepts

    • Application: Executable code booting using OEFI in the EFI1 or EFI2 format.
    • Conventional Booting: OpenComputers default booting method. Often called "BIOS"
    • Operating System (OS) : Complex Application with user interaction and/or providing an environment for programs. Concept only used in this document for Conventional Booting
    • OC: Shortcut for "Open Computers"

    Rationale

    Due to the limitation of current OC booting method which basically searches for an init.lua file, the most big problem is that this only work for Lua architecture, and what should other architectures use, init.asm? init.test? init.o? What happens if we want one drive to contains multiple inits for multiple architectures? Well that's where Open Extensible Firmware Interface comes handy. Using . The limitations OEFI fix in Conventional Booting in OC are:

    • In Conventional Booting, there is only one init script per filesystem, while in OEFI there can be multiple applications per filesystem.
    • Conventional 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, this is even worse for Applications booting on unmanaged drives
    • Conventional Booting isn't made for any other architecture than Lua. And with it, like addressed below, it's impossible to have multiple applications for multiple architectures, while OEFI allows in theory to have one same drive to boot on all architectures it support, without tweaks needed from the user!

    OEFI is basically a much more extensible version of OETF #1, « Standardized booting of nonstandard architectures » and Conventional booting.

    2.1 Changelog

    • Changed EFI2 format into a properties file for easier parsing
    • Using CPIO instdead of URF for same reason: easier parsing
    • Added OEFI Extensions, oefi.loadInternalFile(path) and oefi.setApplications(appTable)
    • Fixed having put AwesomeCatgirl instdead of AdorableCatgirl as username for CAP conntribution

    Application Table Format

    The application table must contains tables as entries.
    The tables must contains the drive address with as « drive » entry and the path (from drive) as « path » entry

    Example:

    {
      {
        drive = "af58dbe2-ff8c-433a-a871-c08723e01f25",
        path = ".efi/sampleos.efi"
      },
      {
        drive = "af58dbe2-ff8c-433a-a871-c08723e01f25",
        path = ".efi/osOnSameDrive.efi2"
      },
      {
        drive = "015f9d4c-cdfb-4686-91cb-bc8cf997f4ec",
        path = ".efi/another_os.efi"
      }
    }

    For architectures not supporting hash maps / dictionnaries, "drive" is index 0 and "path" is index 1

    For architectures not supporting arrays inside arrays (2D arrays), the arrays should be appended in such a way it look like that: drive, path, drive, path, drive, path, ... . This is the default standard used by C for multi-dimensional arrays. If the language supports multi-dimensional arrays then the arrays of the language must be used.

    Finding Applications

    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 files in ".efi" directory:

    If the file ends with .efi, then check if it contains CPIO signature, if no, boot in compatibility mode (OEFI1, which is not described anymore on this document).
    However if the same file contains that signature, then boot as normal.
    .efi2 will ALWAYS be in standard EFI2 format, unlike .efi which can be EFI or EFI2.
    .efi can be EFI1 or EFI2 to keep compatibility with old OEFI Applications, and to allow 8.3 filesystems to still support OEFI (would be problematic otherwise)

    API Methods

    Methods are same as in Version 1, of course API version is now 2 (logic), and some new methods are being added, so here is the new list of methods:

    • oefi.loadfile(path) - Loads file from boot drive
    • oefi.loadInternalFile(path) - Loads file from current archive - new in OEFI 2.1
    • oefi.getBootAddress() - replaces computer.getBootAddress()
    • oefi.getApplications() - Return an application table as described above
    • oefi.setApplications(appTable) - Set the application table (as described above) to appTable. - new in OEFI 2.1
    • oefi.getAPIVersion() - Return API version number. Returns float, double or any decimal 2.1 for this version
    • oefi.getImplementationName() - Returns implementation name
    • oefi.getImplementationVersion() - Returns implementation version number
    • oefi.returnToOEFI() - Recalls the OEFI program, the expected behavior is that the implementation will try to re-execute itself.
    • oefi.execOEFIApp(drive, path) - Boot another OEFI app by using the implementation's routine
    • oefi.getExtensions() - OEFI EXTensions is for non-standard features from implementation. This should always be used for implementation methods. The way this work is described below - new in OEFI 2.1

    For architectures supporting tables (and global), API must be available in Global
    Else, API must be available as a pointer/struct/class/anything like that available as argument to the code

    OEFI Extensions work in the following way: If the architecture supports entries with keys, then a entry should be created containing the function (or its pointer), and the key should be equals to ImplementationName_MethodName_MethodVersion, ImplementationName should be same as in oefi.getImplementationName(), MethodVersion should be the revision number of a method, starts at 1. And MethodName is the name of the method. Example: SuperOEFI_DrawHandSpinner_2, which could be called (in Lua) via oefi.getExtensions().SuperOEFI_DrawHandSpinner_2()

    If tables are not supported, then the array (returned by oefi.getExtensions()) should contain all the methods as other arrays. So oefi_ext will be a 2D array. Each array should contain the name (see above) at the first index (0 or 1, depends on architecture),  and a pointer to the function (or the function itself, if possible) at second index.

    If 2D array too aren't supported, then like Application Table, the array should act like if they are appended to each other.

    Please also note that if possible, computer.getBootAddress() and computer.setBootAddress(addr) should be REMOVED! This is due to that Applications supporting OEFI doesn't need any compatibility methods as thoses conventional booting methods are only kept when booting a OS that only support conventional booting.
    Implementation can create their own methods, however it should ALWAYS BE INSIDE oefi.getExtensions(). (see above)

    EFI2

    EFI2 is a new format for Applications, it replaces EFI(1) in , it is a CPIO archive. All files in that archive must be placed at root and are listed here:

    • app.cfg
    • app.exe

    app.exe is only the Application, it contains the code designed for target architecture, and will be launched by the OEFI .

    app.cfg is a configuration file using "key=value" scheme. The file should look like this:

    name=Application Name
    version=1.0
    oefiVersion=2.1
    arch=Lua
    archMinVer=5.2
    archMaxVer=5.3

    Space after key or before name is parsed as it and aren't ignored, be careful!

    "name" is equals to the name of the Application. Will always be a text
    "version" is equals to the version of the Application, if you don't want to fill it, just make it stay to 1.0. Will always be a decimal
    "arch" is a string with the name of supported architecture, "archMinVer" and "archMaxVer" are self-explanatory and will always be a decimal.
    Note that for archMinVer and archMaxVer, -1 can be used if a version doesn't make sense to the architecture to have a version. (example: a 6502 architecture)
    "oefiVersion" is equals to the OEFI version the Application has been designed to run with, if the "oefiVersion" field have a version incompatible with the current API version or if it's higher than the current one (ex. it's equals to 3 but we're on API v2.1, or it's equals to 1 but we're on API v2). This will also always be a decimal

    With all thoses fields in mind, the EFI2 was designed to be durable, with only changes being to app.lon and URF version.

    Configuration Data

    Everything is explained in that image:

    oefi_config.png.f5f5e3838e2587f5800608f639c72f2d.png

    Component Address Packing

    To shrink down components to 16 bytes, since components address (and UUIDv4 in general) are just hexadecimal numbers converted to string, we can re-convert the string to a byte array and vice-versa.
    To do it, the lines (-) must be ignored, and each group of 2 characters must be interpreted as a hexadecimal string, this should be easy with architecture supporting string to number with optional base (in our case base is equals to 16)
    For example it turns:

    68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b

    into:

    {0x68, 0xCA, 0x0F, 0x59, 0xAC, 0x2C, 0x49, 0xF8, 0xBA, 0x6A, 0x3C, 0x4C, 0x7E, 0x5F, 0x06, 0x9B}

    Here is a code sample submitted by AdorableCatgirl to encode and decode the addresses:

    function binToHex(id)
    	local f, r = string.format, string.rep
    	return f(f("%s-%s%s", r("%.2x", 4), r("%.2x%.2x-", 3), r("%.2x", 6)), id:byte(1, 16))
    end
    
    function hexToBin(addr)
    	addr = addr:gsub("%-", "")
    	local result = ""
    	for i=1, #addr, 2 do
    		baddr = result .. string.char(tonumber(addr:sub(i, i+1), 16))
    	end
    	return baddr
    end
    -- example: hexToBin("68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b") == {0x68, 0xCA, 0x0F, 0x59, 0xAC, 0x2C, 0x49, 0xF8, 0xBA, 0x6A, 0x3C, 0x4C, 0x7E, 0x5F, 0x06, 0x9B}
    -- "68ca0f59-ac2c-49f8-ba6a-3c4c7e5f069b" == binToHex(the array below)

    Back to EEPROM data, implementation name and custom configuration are very easy to understand what they're about.

  13. 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

×
×
  • Create New...

Important Information

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