OSDev.org

muazzam wrote:I think porting software on a unix like os is easy. Is it true?

Yes, and also no.

In principle, all you need to do is implement the applicable standard and then cross-port the software. This isn't that easy, it's a significant amount of work to get this far. However, after you get this far, you get to deal with ports that pull all sorts of crap. The majority of the time I spend porting software isn't actually spent teaching the software what my OS is, but actually spent fixing stupid things that break on my OS. For instance, I aggressively deprecate and remove undesirable system interfaces (like gets(3), but also much more) and this causes ports to break. Other times, the ports just break on their own because they make non-portable assumptions. Sometimes they don't cross-compile properly and pull in stuff from the Linux environment. Sometimes they just do extremely stupid stuff. Sometimes the ports try to be portable but the portability layer causes even more trouble.

Implementing the Unix semantics merely make porting possible, it doesn't make it straightforward unless the software is well made, and unfortunately a lot of it isn't well made. I explicitly make design choices so stupid stuff breaks on my OS, this makes it likely that I discover any stupid stuff they do.

Porting is good if you want to port, not if you want maximum quality.

So yesterday I started a full recode of my os. To make it better, more understandable. This time around I have a real Linux machine to develop on. Here is a pictre of what the OS currently looks like.

makerimages wrote:So yesterday I started a full recode of my os. To make it better, more understandable.

I really want to fully rewrite my OS as well. I just don't want to get into the trap of constantly starting over again, because I'll never get anything done that way.
Your code does look really neat, so well done!

Lucky people who are working on their OSes now. I can't because I have school and, well, I need to improve my grades.

Meanwhile I can't do OS development, because I'm infected with flu. Today I've even had terrible convulsions once and temperature at 41°C.

muazzam wrote:

Roman wrote: And why do you think it's not famous? For example, it's (and PonyOS) well known on one of the most popular russian Linux forums - linux.org.ru.

Popularity at one website is not popularity. It is not even in wikipedia, osnews etc and it is even less popular than kolibri OS or menuet OS. I think, one reason of not being famous is that it is not available to download from its website and its "strange" name.

ACTUALLY, http://www.osnews.com/story/28038/ToAru ... userspace/

Restarted on OSDev a week ago, now I'm at this state. This is a Raspberry-Pi QEmu build modified to more closely match a R-Pi using a ramdisk for MMC as I don't have an MMC driver.

The logs mostly are debugging from the FAT driver and the memory management operations. The R-pi emulator puts the ramdisk at 0x8000000 - 0xC000000 so there are two chunks of RAM present in the memory manager, and it chooses the second to start with handing out.

Cedille has had a lot of under-the-hood changes. The name and license has been moved to kmain(), and it boots in 4ms on bochs.
It also has an internal list of tasks (called kernel processes); The first one manages the framebuffer, which refreshes every 100ms.
Not shown is all the documentation I've been writing. Trying to make a Kernel documented and professional looking is hard work! I plan to test the kernel on real hardware and show the results soon.

My hobby 64-bit kernel is loaded by my own 32-bit boot loader.
Today finally I got ACPI AML under VMware working (basically, with many opcodes ignored), but at least I can soft off the PC. The AML code is tested on Bochs, VMware and my own laptop.

nothing special

is that your own nano clone or a port of nano?

Peterbjornx wrote:is that your own nano clone or a port of nano?

It looks like a clone to me. I don't recall Nano looking like that.

Multitasking support!
The shot shows two tasks running. The first task prints "1" and the second task prints "2." The PIT IRQ handler does the task switching.

Well, It's been a while since I felt I have had something worthy of posting here. Since my last screenshot, I have moved to a 64-bit kernel written completely in assembly. With some inspiration from Turdus, I have finally started a built-in debugger, though it does not yet compare.

Here is a test of my kernel panic screen. :D It finally works the way I want it to and it is just three of them.