OSDev.org

My new console scrolling did not work.

@Bloodman: That first screenshot looks like your shell is falling!


This odd little graphical glitch shows up in my login process most of the time:



Essentially, the login manager runs under the window compositor in a single full-screen window. It closes that window during the login process and, until the "wallpaper" app starts, the compositor has nothing to draw.

Another buggy piece of text screen scrolling code...
On my test machine (not in Bochs), this looks way cooler (couldn't get a photo sorry). At first I was just bamboozled. How could something so accidental look so cool?


Phillid

Somehow broken backbuffer-powered scrolling on real hardware - on emulators fails in less pretty way

Nothing really to look at, but the concept is a good laugh.

I've been chasing a bug or 15 lately, wherein I've not been able to push to the stack, nothing is writing to memory, and none of my comparisons working. When I pop back from the stack, I get meaningless rubbish. Or so I thought. Just now, a mistyped command into the QEMU monitor revealed this gem:

"06/23/99\0\xfcH"

Wait a minute. "06/23/99", that looks like a date. Frantic searching through the source code...

The realization hit me like a train. I've set my stack up in the EBDA! Maybe now, my kernel will actually be called from the new bootloader. -.-

In my page fault handler I called my panic function. In my panic function I forgot to actually pass the file, line and description to kprintf but had the format string using them still. On QEMU this looked really boring.

Just startet rewriting my OS (Unicorn OS)...
Going to protected mode = More stuff can go horribly wrong.

Can't wait to debug all the graphical errors

I was digging through my image archives and remembered that I had these from a while back when I was working on window resizing:





Windows are stored in shared memory regions, and resizing them to be larger (usually) requires that a new buffer be allocated. Shared memory handling wasn't thread-safe. If the main thread managed resizing (ie., through command callbacks from the client applications - a window asking the compositor "resize me"), resizing would work fine: new memory regions would be allocated by the same thread that did all the rest of the shared memory handling. When resizing was made into a window manager action it moved into a different thread. Shared memory regions would be allocated on top of existing memory regions due to the threading bug. Particularly, the memory used by the wallpaper application would be overwitten (in the compositor) by references to the memory for the newly resized window. So if you, say, made nyancat really big, it would overwrite the background and you'd get this (dynamic) effect. It would also overwrite important structures used for handshaking, ultimately breaking the compositor's ability to spawn new windows.

One-line fix in the kernel, and everything worked smoothly.

Was trying to use BGA, needless to say I gave up. I am now using GRUB 2 and VBE, seems to work alright, don't have to worry about PCI to get the address either.

EDIT: Think that issue was caused by assuming the wrong bitdepth, but that doesn't matter now since I no longer use BGA.

That feel when you try to add support for backspace in your console and it fails.
It's amazing what a single line of code can do.

A slightly buggy blit function assuming that if it's blitting a full destination scanline, it's blitting a full source scanline. Breaks when there's a window that's wider than the screen is.

This is my panic screen when called from a page fault:
void panicScreen(char *name, unsigned location, char *noteA, char *noteB, char *noteC);

While working on scrollback support in my terminal, I flipped a subtraction, resulting in this modern take on the classic garbage-text-framebuffer:



The beauty of chaos, now with Unicode support.

Primis wrote:[...]

I like that! Just remove the cursor.