Hobby OSs

[colinh]

I often see people mentioning their own hobby OS (and may have done so myself, on occasion). I'm curious about other people's OSs (but not to the extent that I want to wade through their code--unless it's really interesting, of course )

a) what would you say yours most resembles in the Real World(TM)?
A LISP Machine
POSIX
Plan 9 (a hobby-OS name, if ever there was one)
RISCOS
Oberon
System/360
DOS
Not remotely like anything else on the planet

b) Why are you putting (or have put) effort into this?
Because I can
Because everything else is rubbish. My OS is better than any and everything out there.
Best way to learn about OSs is to design one onself.

c) Are you most interested in
Speed
Size
Functionality
Elegance
"Correctness"

d) What sort of things does it have?
file system
multiprocessing
memory management
IO
integral assembler/debugger
C/Java/Lisp runtime environment

e) Does it have a cool name?

For example, my OS, provisionally called Naive OS (so that one can say, "The naive user might expect..."), is inspired by a dislike of the prevalent lack of respect for resources (CPU cycles and memory) together with a disdain for the exigencies of commercialism. It's a hobby. I'd like my code to be elegant. It doesn't matter how much time (within reason) it takes me to get a routine right.

I suspect that some programming stock phrases such as "an optimising compiler will always beat a human...", "using X facilitates code reuse", "maintainability" etc. may not be 100% correct. I dislike management buzzwords.

I've often noticed that one can rewrite plodding, ugly (aka "stupid") code to make it shorter, faster and clearer (aka "better"). It's odd: you start off with some code. Then you add a feature and it ends up using less space (while doing more, faster). And one can repeat this. In the limit, the code would take up no space at all and do everything(*) infinitely quickly. Strange. One of my (long term) goals is to write less stupid code...

(*) The mu-byte takes up no space and represents the integer 42.

The entire thing is written in assembler, because I like knowing what the machine is actually doing, and reading gcc-produced stuff is depressing. Portability is not an issue.

What I have so far is:
16-bit framebuffer graphics:
character drawing
dots, lines, rectangles, rectangle fills & blits
windows, text/graphics scrolling
PS/2 keyboard/mouse driver / UART serial IO
terminal, (command)line-editor and "visual" editor
alloc/free, hash, a digital storage oscilloscope app (every OS should have one).

Conspicuously absent are a filesystem or processes. They just don't seem to be pressing concerns yet At the moment I'm playing with the editor. Then I'll do a (dis)assembler/debugger (not that my code ever needs debugging). Then a database, regexs, (de)compression, images.

C++, Java and USB support will come after the end of the universe.

[kriss]

go disasm the bare-metal usb and that's the end of universe

[DexOS]

My OS called DexOS, is like a 32bit dos, there's no virtual memory paging,
and only a single process is allowed (though that process can spawn multiple threads). The program runs in ring0, so you have direct access to all hardware (including CPU and graphics). Memory allocation is the responsibility of the app - there's no front-end memory allocation.

The entire operating system will fit into less than 64KB of memory. dexos can boot from a floppy disk, cd, usb flash drive or directly from hard drive. It has lots of built-in functions and libraries to help programmers. You can boot without touching the underlining OS.

There's an IDE, a Fasm port, and a full TCP/IP stack
implemented, plus a console like GUI.
There's also a arm port.
http://en.wikipedia.org/wiki/DexOS
https://www.youtube.com/watch?v=mYJx2zZK7c8

[kriss]

Dex i missed that your os have a arm port
do it have support for all of the RPI2 ?
i will try it anyway

[DavidS]

Mine does not have a name as yet, it is a TOS/DOS like core with many *nix extensions (simple memory protection, page mapping, multitasking, multithreading, with TOS/DOS + *nix style API), with a GUI similar to GS/OS in function (not apearence).

The goals are eloquent design (in the mathmatical sence), simple API, speed and ANTI BLOAT, while preserving the simple design that OSes have lost.

My reasoning is simply because I can and it is fun, and I can do it in such a way as to support much modern software with out the unneeded bloat.

[kriss]

DavidS sources of your os ?

[DavidS]

DavidS sources of your os ?

Soon enough I hope, as soon as simi-complete (hence why I do not usualy talk about it much).

[hldswrth]

I have a hobby O/S, main goal originally was to produce something that was very quick to boot and provided full control over the RPi peripherals and was simple to use. Something like the ZX Spectrum experience Along the way I got a bit side-tracked with virtual memory usage and may have diverted somewhat from the original intention.

a) what would you say yours most resembles in the Real World(TM)? POSIX/DOS
b) Why are you putting (or have put) effort into this?
I wanted to create something much simpler you could turn on and use.
Best way to learn about OSs is to design one oneself.
c) Are you most interested in: Speed Size Functionality Elegance "Correctness" All the above plus simplicity
d) What sort of things does it have? file system, memory management, IO, C runtime environment
e) Does it have a cool name? TBD. No, that's not its name

My O/S includes:

Modular kernel allowing dynamic addition of modules
Virtual memory with 2:2 user:kernel split
I/O system with modules for FAT file system (r/w), SD card (r/w), serial port and console
Support for executables in ELF format, each running in their own address space.
C runtime library (partial implementation - enough to run a port of nethack
Command shell
A set of commands modelled on DOS - dir, copy, rename, attrib, etc.

Some things I'd like to do.

Finish working on demand-based loading for executables based on page faults
Add support for dynamically loaded libraries
Port to the new USB library (still using CSUD)
Add c runtime libraries for Pi peripherals
Add a BASIC interpreter (or some other interpreted language, python maybe)
Update to run on Pi v2.
Look into multi-processing.

Unfortunately I've just not had time to devote to this for the last few months. I tend to focus on it for a month or so then stop for six.