Windowing Systems by Example: 3 - I Like to Move It

[jojo]

For your sbrk, without any context to go on, I couldn't rightly say.

Just tried upping to 1920x1080 myself and everything still works a treat (though it does start to emphasize how sluggish redrawing everything is, which is nice), so it looks like that's still probably somewhere on your end.

You're going to have to do some debugging, here. Did you copy the sources directly from the git repo and include them or did you write them out manually from the tutorial? Either way, I would start by throwing some debug printing via the serial port in there to see if you can't figure out at what point in the code your width and height are getting modified on a in-drag mousemove event. Though you should check both there and also in your rect drawing code, because it's possible that things are getting screwy during drawing and it's not actually the window props getting mangled.

One random guess as to why you might be getting a blue screen and nothing else: More memory allocation issues. I don't know how your memory protection is set up, but it's entirely possible that with the bigger buffer the addresses you're trying to write to at the tail end of the desktop rect you're beginning to infringe on protected memory and causing a page or protection fault. Also possible that, if you're not making sure that your memory allocator is aware of the memory hole claimed by the framebuffer, you've got os critical data malloc'd near the end of the framebuffer memory region and it's getting overwritten when you draw to that area of the FB. As well, if not that then it could similarly be that your OS code is loaded and running from the memory area that the framebuffer occupies and you're not checking for that before setting up the framebuffer.

You have to be *very* careful about keeping track of memory in your OS. It's one of the most critical things it does and if it goes haywire it can screw up a LOT, and in very confusing ways.

Ultimately: Debug everything, especially your malloc code, even if that just means shoving some debug prints in. Because you really can't know for sure if things are getting allocated right unless you actually take a look at it.

[Octacone]

-reply-

Yeah, it is probably something that I screwed and aren't aware of. I did not copy it from the git repository, I was writing it line by line trying to understand the concept. I have all the serial ports set up so why not debug those sizes, great idea. I don't have any sort of memory protection really, my OS is not aware of the video memory buffer... (insert face-palm here) My frame buffer is just a variable that gets set based of a PCI address readout. Do you think I should allocate RAM to my frame buffer via malloc so it is protected? The other thing is that if I replace your draw rectangle function with mine I don't get size distortions. (maybe it is just a pure luck) Also, why does your random function always output the same result? I am definitely going to do some debugging.

Edit: sizing issue has been fixed, I accidentally replaced y with x.

[jojo]

It's really cheap pseudorandomness, and pseudorandomness is, by its nature, always deterministic. You may think to yourself 'but I use pseudorandom number generators from libraries all the time and they never give the same results twice!' The only reason this happens is that real pseudorandom library functions don't use a fixed seed value (as you can see, our seed always starts as zero) but instead pull it from a source of relative randomness -- in most cases the current millisecond value of the system clock. But even for these functions, if you fed them the same seed every time, they would still spit out the same sequence of numbers. I just didn't feel like adding the system clock as yet another thing one would need to have built in order to follow along would be especially prudent for such a trivial and tangental bit of the code, so I didn't bother with it.

There's a lot of ways that you could potentially handle setting aside memory ranges for things like I/O regions or memory holes -- yes, your memory may not be contiguous. It would be a good idea, while you're addressing this, to request a memory map from the BIOS or ACPI during your kernel startup and set things aside accordingly because you don't want to try and save data into an address where there is nothing to save to. Anyhow, the simplest way would be to set aside a global list in your kernel of non-allocatable memory ranges and make a kernel function that allows you to add entries to that list, then make your kernel memory allocator (or page allocator, if and when you decide to start using paging and virtual memory) check this list when it tries to allocate a new chunk of memory and skip to the next free area if it runs into one of those restricted ranges.

If you're curious, You can check out my very hacky memory map configuration code. The function I linked to is the function entered after I've used my v86 subsystem to store the memory regions reported by the BIOS in `m_map[]` after which, for each entry, I use my `mark_pages_status()` function to mark the affected physical pages as 'os-special' (eg: NOT TO BE USED) directly in the 'free for OS use' bits of the actual page table itself. And that works well because I use paging, so I can just skip any page that has those bits set when an application makes a request to the kernel for a new page and it has to go looking for the next available one. But I'm sure you can do something similar when allocating in a flat, all-kernel non-paged physical memory space.

Anyhow, glad to hear you got your rectangle function sorted!