ObjFW  Porting Obj-FW to a Hobby OS

Porting Obj-FW to a Hobby OS

(1) By Matt Parsons (h5n1xp) on 2021-07-10 07:57:33 [link] [source]

Hi all,

During COVID lockdown, I’ve been writing my own hobby operating system… It started out as nothing particularly serious, just some idle coding in the evening with a glass of wine or two. So I had no particular plan, goal or structure in place as to the design.

Anyway it’s now booting to a functional GUI, working multitasking, and FAT32 filesystem support. I’m currently adding file IO functions, and I have starting thinking about implementing an Application layer.

I have been wondering how easy/difficult it might be to do this in Objective-C using Obj-FW? Does my Kernel (such that it is), have enough feature to support Obj-FW?

My Hobby OS project (including some bootable hard disk images) can be found here: https://github.com/h5n1xp/CuriOS

(2) By Jonathan Schleifer (js) on 2021-07-10 09:49:45 in reply to 1 updated by 2.1 [source]

Interesting project! I like the themes 🙂. Side note, though: Why are there only ZIP files of the source checked into the Git repo?

On topic: ObjFW should be a perfect fit for this, given that it supports a large range of very different OSes already, some of them having what can barely qualify as an excuse for a libc 😉. As well as running on embedded.

To get started, I would recommend to run configure with something like this:
```
./configure --host=x86_64-pc-unknown-elf --disable-shared --disable-threads --disable-sockets --disable-files
```
(Replace `--host=x86_64-pc-unknown-elf` with whatever triple your cross-compiler uses)

This should give you an ObjFW that requires no functionality from the OS and only a somewhat working libc for memory allocation etc. If you run into any problems with basically all features disabled, please provide compilation logs / describe errors, and I can see to make ObjFW not use what you are currently missing. It's possible that it currently requires something that all platforms happened to have in common by pure chance, though I think that's quite unlikely.

The next step then is probably that you want files, as those also give you the standard input and outputs. ObjFW currently assumes that there is `open(), `read()`, `write()` and `close()` for this, though if it's helpful, I could also let it fall back to `fopen()`, `fread()`, `fwrite()` and `fclose()`. But so far, I have not found a system that only has the `f*` variant, despite the `f*` ones being C99 and the ones without `f` only being POSIX.

I suppose sockets aren't supported by your OS, so that probably should be kept disabled. Threads either use an OS-specific API or, if it does not know about an OS-specific API, checks if the OS supports pthreads. Shared library support just requires your OS to support, well, shared libraries (it assumes you are on ELF and use .so files if it does not know the OS).

(2.1) By Jonathan Schleifer (js) on 2021-07-10 09:52:11 edited from 2.0 in reply to 1 [link] [source]

Interesting project! I like the themes 🙂. Side note, though: Why are there only ZIP files of the source checked into the Git repo?

On topic: ObjFW should be a perfect fit for this, given that it supports a large range of very different OSes already, some of them having what can barely qualify as an excuse for a libc 😉. As well as running on embedded.

To get started, I would recommend to run configure with something like this:

./configure --host=x86_64-pc-unknown-elf --disable-shared --disable-threads --disable-sockets --disable-files
(Replace --host=x86_64-pc-unknown-elf with whatever triple your cross-compiler uses)

This should give you an ObjFW that requires no functionality from the OS and only a somewhat working libc for memory allocation etc. If you run into any problems with basically all features disabled, please provide compilation logs / describe errors, and I can see to make ObjFW not use what you are currently missing. It's possible that it currently requires something that all platforms happened to have in common by pure chance, though I think that's quite unlikely.

The next step then is probably that you want files, as those also give you the standard input and outputs. ObjFW currently assumes that there is open(), read(), write() and close() for this, though if it's helpful, I could also let it fall back to fopen(), fread(), fwrite() and fclose(). But so far, I have not found a system that only has the f* variant, despite the f* ones being C99 and the ones without f only being POSIX.

I suppose sockets aren't supported by your OS, so that probably should be kept disabled. Threads either use an OS-specific API or, if it does not know about an OS-specific API, checks if the OS supports pthreads. Shared library support just requires your OS to support, well, shared libraries (it assumes you are on ELF and use .so files if it does not know the OS).

(3) By Matt Parsons (h5n1xp) on 2021-07-13 13:04:56 in reply to 2.1 [link] [source]

Side note:

I only have zip snapshots because this project wasn't planned, I just wanted to have a play with some bare metal coding on a x86 machine (something I've not done before, my background is mostly with ARMs and as you can probably tell, the 68k in the distant past). The whole thing has been written with notepad/textEdit and i686-elf-gcc, all the source files are just compiled with a simple script and then linked into a single blob which GRUB can load. There is no proper build system or anything resembling a proper project structure.

I had never intended it to get this far, I just wanted to bring the machine up with a framebuffer and then just treat the PC like a massive microcontroller. But I just kept adding bits until I had rudimentary desktop OS, and I've never build a Desktop OS before (I've written kernels for microcontrollers, which is somewhat obvious from the architecture I have used), so I have just kept going.

I only added the project to GitHub because some friends wanted to play with the source. But, perhaps understandably given the state of the source, no one is particularly interested in contributing, so I've not really bothered to clean the sources up, use version control, and add a proper build system.

On topic:

This is great! Thanks for the information, it gives me a direction and lets me know what features I need to add next.

Currently (as of last night), I just managed to get the filesystem working (it can now read the boot disk) so I'll be adding POSIX compatible filesystem IO functions as required... Then I need to get my ELF loader working...