What's your OSDev AWWWW YEAH! moment?

[Peterbjornx]

Finally finding the memory thrashing bug that has been eluding me for over a year:
https://github.com/posnk/posnk/commit/0 ... e14f8fca14

To do this I built my VFS + File stream + FS driver + block device + drivermgr code as userland binary for linux and wrapped the file syscalls in a FUSE driver

[DeezRamChips]

1) When I had grub running for the first time
2) When I ploted a pixel in vesa for the first time (1024x768x32)
3) When I drew a 64x64x24 bitmap of doge on real hardware
4) When I drew text in Graphics mode

[Octacone]

When I started understanding interrupts.
When I figured out how to deal with the mouse.

[BrightLight]

Haven't posted in this thread since I was a newbie, so there's definitely some new interesting stuff:
1. When I set VESA mode 1366x768 on real HW for the first time.
2. When I performed my first ACPI shutdown.
3. When I studied the disassembly of my physical DSDT and read the percentage and status of my laptop's battery without an AML interpreter.
4. When I read from my SATA hard disk (in IDE mode) on real HW and a real ATA drive with my PCI IDE driver.

[max]

Finally got my canvas implementation to run.

It's now possible for an application to create a canvas component, which creates a shared memory region between the program and the window server. Canvas buffers are automatically resized when the component changes it's size.

I had a terrible bug where the client would free the same buffer that it was currently using, that was because the window server may send multiple "wait-for-acknowledge" events for the same buffer - what the client did not consider.

With this easy sample code it's possible to create a user interface application as seen below:
http://pastebin.com/PVAcjWdJ

[Octacone]

Finally got my canvas implementation to run.

It's now possible for an application to create a canvas component, which creates a shared memory region between the program and the window server. Canvas buffers are automatically resized when the component changes it's size.

I had a terrible bug where the client would free the same buffer that it was currently using, that was because the window server may send multiple "wait-for-acknowledge" events for the same buffer - what the client did not consider.

With this easy sample code it's possible to create a user interface application as seen below:
http://pastebin.com/PVAcjWdJ

That is just awesome. Really like the look of your GUI.

[tsdnz]

Finally got my canvas implementation to run.

It's now possible for an application to create a canvas component, which creates a shared memory region between the program and the window server. Canvas buffers are automatically resized when the component changes it's size.

I had a terrible bug where the client would free the same buffer that it was currently using, that was because the window server may send multiple "wait-for-acknowledge" events for the same buffer - what the client did not consider.

With this easy sample code it's possible to create a user interface application as seen below:
http://pastebin.com/PVAcjWdJ

That is just awesome. Really like the look of your GUI.

Agree, looks great.

[BrightLight]

Just now, when I "identified" a SATA device using AHCI, after a long 12 hours of frustration. The screenshot is my kernel's log via QEMU's serial port.
Still need to implement reading a SATA device, and then I can natively boot from SATA.

[Ycep]

We should parody this thread with "What's your OSDev AW HELL NAW! moment?"

+1 Haha.

[matt11235]

We should parody this thread with "What's your OSDev AW HELL NAW! moment?"

+1 Haha.

That could be the When your OS goes crazy thread.

[Sik]

That only works when you can take a screenshot of it, which usually means it's not that broken.

For a serious mix of "awww yeah" and "awww naw": once I was working on some dumb project and I had put it on a floppy drive (running it on real hardware, yo). Then at some point for some unrelated reason (used PKZIP at the wrong place x_x) the whole Windows install broke up and I was pretty much forced to use that floppy to boot the system. Even had to complete a school assignment using the software in it (・×・)

No, I don't have that floppy around anymore.

[onlyonemac]

That only works when you can take a screenshot of it, which usually means it's not that broken.

I think they're usually running the OS in a virtual machine/emulator, or take a picture of the monitor with their phone/camera.

[Sik]

Well yeah, but when the OS is so utterly broken that you start yelling like that it won't even show anything on screen usually. Although I suppose an alternative case may be something like wiping your main hard disk and the back-up drives or accidentally bricking the firmware...

[deleted]

Hi,

My "AWW YEAH!" was when I booted my "Hello world" kernel on real hardware. That was really quite impressive to me hahaha

Now back to my VMM...

Cheers,
Walt

[Candy]

We should parody this thread with "What's your OSDev AW HELL NAW! moment?"

+1 Haha.

That could be the When your OS goes crazy thread.

I had a nice one for that. I started up my brand new task switching, with a lot of new things and two bugs. It looked fine. I suspected it was too slow though, because it took a couple million instructions in Bochs to get to the idle thread, and I had no idea it would do that - a couple thousand was what I expected.

So I turned on tracing and traced *every* instruction. For a few million. And then figured out what happened.

It finishes the boot procedure and enters the task switch logic. It switches to task 1. Task 1 executes, says "hello world" and suspends execution, marking itself as blocked (temp fix). Task switcher finds next task in list and oops - bug 1 - it's uninitialized. So it goes to task X (where X is a random 32-bit number). Luckily it happens to match the range for tasks (which I preallocated to 256MB of address space). No memory mapped there, so it demand-pages in an empty page. That's bug 2 though, it forgets to zero the new page before releasing it. So then it reads another uninitialized block of data for the next task, which is not runnable, and it goes to the next task (uninitialized), to find a not-runnable task demand-paged in, to go to the next ..... and eventually it hit a 0 pointer. Which was the ID of the idle task, so it switches to the idle task and stops.

So two bugs in perfect harmony creating the desired behavior.