Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Excuse me, but do you have an English or French version of tyndur's doc ?
(As an aside, I always find amazing how fast projects are labelled "mature" or "amazing" as soon as they have something that looks like an UNIX shell or have some SDL port equivalent and disk handling implemented. I'm sure that even if my kernel implemented über-advanced IPC and object-oriented API for everything including the kernel, it would'nt get so much love unless I get some hacky VBE support running .kkrieger )
Neolander wrote:Excuse me, but do you have an English or French version of tyndur's doc ?
Not really. Even in German there's not much documentation, in English the 0.2.2 release thread is probably the best description and for French... je ne parle pas français.
(As an aside, I always find amazing how fast projects are labelled "mature" or "amazing" as soon as they have something that looks like an UNIX shell or have some SDL port equivalent and disk handling implemented. I'm sure that even if my kernel implemented über-advanced IPC and object-oriented API for everything including the kernel, it would'nt get so much love unless I get some hacky VBE support running .kkrieger )
That's true - because you can't see IPC on screenshots. A screenshot doesn't tell you much more than that the OS is able to get some pixels to the screen. The same screenshot could be produced by a very simplistic OS or a very advanced one. It's why I've never bothered posting here before. You need at least some crappy graphics mode stuff to get some interest.
I finally got a proper shell working! It requires seven concurrent processes (vfs, device manager, terminal driver, keyboard driver, initrd driver, init, and the shell itself), not to mention a multithreading microkernel with message passing and events, to do it, but it can execute arbitrary programs from a tar-based initrd with arguments. Elapsed time: 14 months.
test.png (7.32 KiB) Viewed 7237 times
Btw, the command is "acho" not "echo" because of a bug I'm still working out in the initrd driver - I've got it tracked down to the file offsets...
1. On the kernel level, asynchronous, with optional events on reception; however, most I/O waits for changes in message queues, which makes them synchronous. There's already support for "fragmented messages" (sorta like fragmented IP packets) which could take advantage of certain multithreaded drivers if I added more precise queue control, but it's too soon for that kind of optimization.
2. Yes, they're separate, and "term" is the text mode video driver. I don't know if that will stay that way forever though. I'm thinking of combining keyboard, mouse, and video drivers into one process, sort of like X11 does, except with a flatter (i.e. non-windowed) design, once I start on a GUI.
Also, I just realized that my architecture comes with a loopback device equivalent for free - I can mount any tar file in the initrd as its own filesystem by invoking the "tarfs" driver (used for the initrd) on that file. I tested it, and it works fine. Of course, once I add a real permission system it will get a bit hairier, but it's still awesome.
The top line is reserved for system status info. Currently it shows which CPU cores are active. A core is idle if it is black and active if it is flashing between gray and white.
While the smptest program was running all cores were lit up.
BareMetal OS - http://www.returninfinity.com/
Mono-tasking 64-bit OS for x86-64 based computers, written entirely in Assembly
Each rectangle (frame) is drag-able. The mouse pointer there I made myself, by hand, pixel-by-pixel (I was bored). There is transparency (alpha-channel) as well. There are still a couple bugs, like if you move a box to the very left of the screen its color goes a bit off, and after dragging the mouse pointer momentarily disappears, but besides that it works great
NickJohnson wrote:Also, I just realized that my architecture comes with a loopback device equivalent for free - I can mount any tar file in the initrd as its own filesystem by invoking the "tarfs" driver (used for the initrd) on that file. I tested it, and it works fine. Of course, once I add a real permission system it will get a bit hairier, but it's still awesome.
This was one of the two ideas I had for my (yet-to-be-written) vfs system - to allow reading/writing archives (frex, 'cp foo bar.zip/x/foo' would be a valid command). I won't elaborate any further here, though, because then I'd be at risk of derailing the thread