OSDev.org

BenLunt wrote: It has been an interesting project though. Also, another interesting thing is that I am using an emulator (QEMU) to emulate my OS which in turn is emulating another x86 machine.

Ooh, I can beat that.

At University, we had a new lab of PowerMac 6100 (it was a few years ago , and on there we ran:

- PowerPC emulating m68k to run MacOS
- MacOS emulating x86 to run Windows
- Windows emulating x86 DOS
- DOS running a m68k emulator to learn m68k assembler.

What's old is new again - a few years back, my userspace and GUI apps were written in Python, but I abandoned them / rewrote a lot of them in C on my quest for a fully DIY ecosystem. Now that I've spent countless hours building my own Python-like language, it's time to bring back the old apps!


More screenshots:

@klange: Nice! I have a question though: With one instance of Kuroko, can you receive events in the created window(s) and on the console too? The lack of that held be back from understanding toolkit programming in Linux in the 90s. (I was more confused back then.)

eekee wrote:@klange: Nice! I have a question though: With one instance of Kuroko, can you receive events in the created window(s) and on the console too? The lack of that held be back from understanding toolkit programming in Linux in the 90s. (I was more confused back then.)

Building UIs in the REPL like this isn't really the intended workflow, and there's currently no way to asynchronously handle events while the REPL prompt is waiting for input - but it would be possible to hack something together with poll() to support that.

klange wrote:

eekee wrote:@klange: Nice! I have a question though: With one instance of Kuroko, can you receive events in the created window(s) and on the console too? The lack of that held be back from understanding toolkit programming in Linux in the 90s. (I was more confused back then.)

Building UIs in the REPL like this isn't really the intended workflow, and there's currently no way to asynchronously handle events while the REPL prompt is waiting for input - but it would be possible to hack something together with poll() to support that.

Ah, so it's the same as most other systems. Thanks. I want to get away from this in my system, but I'm still not quite sure how. Perhaps I do want all input to be event-based, which is the opposite of what I once thought.

I have been working on my EFI loader (again), to remove the dependency on GNU-EFI and add a boot selection interface.
It's also now working on AArch64 (the screenshot was taken on my Raspberry Pi 3b), though I still haven't readded the kernel loading code.
(Using the url tag instead of the img tag as the screenshot will probably appear to big, as it is 1920x1080)

https://i.imgur.com/n6o9xxp.png

Well, that looks rather strange!

Greetings
Peter

That looks better because now in this higher resolution I can see and understand the windows. Can you already do advanced stuff with the windows, like moving? Can applications already take use of the GUI?

Greetings
Peter

Can you already do advanced stuff with the windows, like moving?

https://video.okelyon.com/forms3.mp4
https://video.okelyon.com/forms4.mp4

It moves! Nice one.

Looks interesting. And sure is a different path than other OSs!

Greetings
Peter

@Structure

Very interesting! What solar system are you from?