OSDev.org

We used ffmpeg library, it's quite popular and very nice and configurable. It's possible to fit ffmpeg-based videoplayer with popular codecs in 300-500 kb.

As this theme is about screenshots, I'll post another one. Typical working environment in KolibriOS: Animage for graphics, Table for tables, Tinypad for texts and coding (with standard "open" dialog window) and Eolite for file management.

Nowhere near as fancy as anything you guys have done, but a quick, short checksum function (in real mode assembly):

My first attempt to run it on real hardware.

While it runs perfectly on Qemu, I guess the TSS is messed up somewhere since scheduler crash with ring3 process, so i disabled loading application here...

In the picture:
rEFIt -> boot USB stick -> MBR -> My Boot Record -> load boot.bin -> load kernel32.bin + initrd32.bin -> run kernel.

I've added mouse events to my windowing system and am working on a GUI toolkit for buttons and such.



I also have a demo video on YouTube.

Can't post a screen dump because Virtual Box did nothing but move the cursor down a few spots, and IRL, it just printed a bunch of spades and random characters. I'm blaming the linker script for now, because there's a few bugs I got in it.

I know this doesn't look too much different from my last screenshot, but my GUI toolkit now provides support for rendering labels in buttons and my graphics library has been majorly overhauled to allow for multiple rendering contexts (so an application can render into multiple windows using the library). The "Thick" and "Thin" buttons act as a toggle switch, changing each others fill colors when you click on them to indicate which one is active ("Thin" in the screenshot). I also added a quit button and threw it into the window decorations where it's supposed to be. Overall, flipping and alpha mapping speeds have been improved.

Yo, Don't feel bad about posting your screenshots I, along with many people here are very intrigued by your project, rest assured

--Peace out
gravaera

Yes please continue, it's extremely motivating to be honest. I'm only in the process of fixing my implementation of the IO-Apic and redirected interrupts!

LOL christ I cant even get a boot loader I am writing to work correctly. Half the time when I attempt to load it bochs just pukes a bunch of segment limit violation errors that I have yet to figure out exactly what the hell is going on there..... It makes no sense really since it doesn't even execute the very first instruction in the code which is just a simple jump past the bios parameter block. But anyway the other half the time it loads everything up but simply refuses to work unless the kernel is the very first thing on the fat12 drive.

Maybe I can post the code here and see if anyone knows what massive mistake I am making.

Hi, I have recently taken up development of BOS again after almost 6 years (time flies!) without anything new. But now I have finally managed to get my VFS and FAT12 driver to a point where I can load files. Seen on this screenshot is a simple dir command, a test case for parsing paths and reading out a txt file:



It's a great feeling, after spending like 2 days debugging it all.

I'm developing my operating system in a difference sense than most people, so I'm yet to have the ability to show screenshots.

My operating system is more like a high level virtual machine, where all executables are written in high level byte code, that can either be interpreted or JITed. My 'kernel' that I'm developing is just a standard desktop program that provides a virtual environment for my bytecode to run in. Once it's stable I'm going to port it to run on bare metal.

My reasoning for developing my OS this way is that the applications I want to develop for my OS I also want to use everyday and share with others people, even without them nor me being booted into my OS. Not only is it easier to develop and develop my applications easier this way, but I hope to have a full suite of applications (web server, Word processor, etc) developed and debugged, and the same with the interpreter/JITer, so when I port it to run on bare metal the only thing I have to focus on are the drivers and x86-specific parts.

My reasoning behind using a bytecode approach in the first place, is to ease the development of a microkernel. I envision a system where there is no memory protection, and IPC is nothing more than merely passing interfaces and references to data structures around.

I've done some benchmarks, and algorithms running under my interpreter are roughly 10x slower than running the same algorithm natively. However, I hope that when the VM can JIT bytecode into native code, combined with the lack of needing to use a MMU, having the do any copying to send messages between processors, and system calls being regular function calls, I will have an extremely fast OS where all applications are basically running at bare metal speeds.

Also, I'm trying to design a GUI that avoids the desktop-metaphor. (Inspired by tablets, smartphones, game consoles, etc).

Dongbin wrote:It's called "Mayax", a 32-bit OS with windows style GUI.

That's pretty extensive, how long have you been working on this?

Looking great Dongbin!

Do those icons really launch working applications? (Firefox, a media player, etc?) Or are they just there to look good?

Anyway, nice work! Can we download a demo from somewhere?

MessiahAndrw, I am also interested in interpreted user space. And I'm not sure about the performance. It is true, that in your model, you avoid some of the performance penalties, but then interpretation / initial JIT'ing slow you down. Do you have any source, that tell's you, it would really be faster, or is it just your guesstimation? I mean you "hope" it will be fast in your implementation, but have you seen any evidence, that it can be faster then the usual kind of OS? I'm also thinking, what would be the value of no machine code running on the computer apart from the kernel. I mean, if the kernel is well implemented, you could not in any way run priviledged instructions, only the kernel would. So, again, would it be valuable, or is JIT the way to go?

Sandras wrote:It is true, that in your model, you avoid some of the performance penalties, but then interpretation / initial JIT'ing slow you down. Do you have any source, that tell's you, it would really be faster, or is it just your guesstimation? I mean you "hope" it will be fast in your implementation, but have you seen any evidence, that it can be faster then the usual kind of OS?

Interpreting would definitively be slower, but JIT (just in time compile) should theoretically run just as fast as a program already compiled.

The theory is that, a typical 'native code' build process generally goes:
[load .c file] -> source language -> abstract syntax tree -> language independent byte code -> machine code -> [save .exe file]

then in the kernel:
[load .exe file] -> machine code -> [jump to entry point]

The problem with this method is that you're trusting that the compiler didn't put any bad code (privileged instructions, accessing memory it shouldn't, etc). Many languages (like C) allow the programmer to create pointers to any arbitrary location in memory. That's why we need separate address spaces, ring protection, which in turn we invent IPC and system calls with large overheads to get around this.

The build process for my OS is:
[load .c file] -> source language -> abstract syntax tree -> language independent byte code -> [save .exe file]

then in the kernel:
[load .exe file] -> language independent byte code -> machine code -> [jump to entry point]

I'm just moving one of the steps into the kernel, so it's not possible to load an executable file that can call privileged instructions or access arbitrary areas of memory.

There are many studies online of the speed of native C++ vs Java/.Net. Sometimes C++ is faster, sometimes Java/.Net matches its performance (and rarely sometimes faster).

Certain things will be slower (array operations will always perform bound checking and deferencing objects will always check that you're not pointing to a null object) unless the JIT can safely optimise these out (if it knows that the index will always be valid or that the object will never be null). Java and .Net perform these tests, and there are many high performance programs that run under Java and .Net without too much drawback.

Certain things can be faster - a program can access low level hardware through a couple of function calls into the driver, rather than a system call. Memory will be flat - context switching will never require switching addressing spaces.

IPC will take the form of loading shared libraries (static variables will be shared between all instances of the library) - that library can choose to implemented a linked list of messages, or share interfaces so one program can directly call a function in another program.

Also, the JIT is able to perform certain optimisations that a compiler cannot when you're distributing an executable to a large number of people - for example it can generate SSE4 or AVX instructions if your CPU supports them.

Pointers and direct memory access will be allowed (drivers require it), but you have to explicitly mark that block of code as 'unsafe' and have permission to launch 'unsafe' applications on the OS.

Sandras wrote:I'm also thinking, what would be the value of no machine code running on the computer apart from the kernel. I mean, if the kernel is well implemented, you could not in any way run priviledged instructions, only the kernel would. So, again, would it be valuable, or is JIT the way to go?

In a JIT environment there will be machine code running - once the kernel JIT compiler compiles it from bytecode after loading but before executing it. An interpreter is much simpler to implement (my first release is likely to be an interpreter) but it's also much slower.

Intepreting bytecode isn't too bad though, before Android 2.2 their Dalvik VM interpreted bytecode, and Mono also includes an interpreter (though it JITs by default for most architectures) and all but the most high performance applications are still fast and responsive when interpreted. So I think, for starting off, you should focus on an interpreter to get your environment up and running as soon as possible, then slowly migrate towards a JIT solution a couple of versions down the track when your OS is mature enough to require the extra performance.