OSDev.org

can anybody give me some resources about developing windowing systems ? something that describes event handling mechanisms, message queuing and so on..

How far along is your kernel? Writting a windowing system requires quite a fair bit of OS framework to already be in place.

MessageQueue's are fairly easy to write once you have mutex and/or semaphore's implemented, and they're a useful tool in actual kernel development (not just in a GUI).

You can get a quick look at one possible way to write a GUI by looking at the source code to my 'smoke' project (http://www.neuraldk.org/product-Smoke). Keep in mind I wrote this as a highschool programming project, so it's not without its faults. It contains only window management (no widget management) and does not use messageQueue's at all (one could argue this is a good thing, as well. Message queue's certainly aren't needed, and if you're using an OO language then all events can be mapped to methods of an abstract window class which all windowed applications must inherit).

Window management in smoke is, essentially, a heirarchy of windows. Each parent window can have 0 to many child windows. I employ a MDI-like setup where child windows cannot extend farther then their parent windows. I, personally, don't like this, but it was harder to code, so I implemented it. In the real world, the developer should probably be given a choice of how child windows operate.

In the somewhat near future I may start experimenting with GUIs again and try out some new ideas I've since gathered, but that'll also be on a linux platform, as my OS isn't ready for a GUI yet.

>How far along is your kernel?Writting a windowing system requires quite a fair bit of OS framework to already be in place.

Ans: multitasking,memory management,SVGA,FileSystem (FAT12 only),EXE loader.
is there any other thing needed in order to start

>Keep in mind I wrote this as a highschool programming project

high school !!! what is ur country? i can't imagine a school teacher working with something like that !!
and how long have you started programming ?!!

>Message queue's certainly aren't needed, and if you're using an OO language then all events can be mapped to methods of an abstract window class which all windowed applications must inherit).

unfortunatily i am working with C only.

AltCtrlDel wrote: Ans: multitasking,memory management,SVGA,FileSystem (FAT12 only),EXE loader. is there any other thing needed in order to start

Looks pretty good. You're going to need a lot of fundamentals, as well, some of which you've probably already written:
mutexes, semaphores, messageQueues, linked lists, binary trees, etc

I mention these simply because a lot of people have implement a lot of high level portions of an OS, but not these low-level portions which seems odd to me... how does one multitask without thread-safety?

Anyway, not to suggest you fall into that crowd, I merely mean to suggest that the more fundamentals you've got to chose from, the easier it will be to write a GUI.

AltCtrlDel wrote: >Keep in mind I wrote this as a highschool programming project

high school !!! what is ur country? i can't imagine a school teacher working with something like that !!
and how long have you started programming ?!!

I'm from Canada. My teacher was also our sys-admin, and had told me I could use C rather then QBasic (which everyone else was using at the time)... he was pretty good about it.

As per when I started programming... depends on what you consider programming I started using LOGO on an Atari 800 before I was 10. Then eventually led to AtariBasic, and then atari assembly language. Eventually I got a PC and started working in QBasic, then C, C++, Asm, Java, Eiffel, etc... it's been an interesting journey

AltCtrlDel wrote: unfortunatily i am working with C only.

Nothin' wrong with that. You can use smoke for some ideas... I hope the code is still somewhat readable. Like I said, it was written at a time where I'm sure I had some bad habits, and did things unnecessarily.

Essentially, all I did was to maintain a hierarchy of windows... I believe I used linked lists, but if I were to rewrite it today, I'd use a form of tree structure. Whenever the mouse moved, I'd check it's new position and then save off a pointer to the window it's currently in (and focused it, if it's not already focused, as I like the focus-follows-mouse policy).

The hard-part (which I assume most people want to know about) is how to overlap. My windowing system actually maintained a separate back-buffer for each window, which most don't. This makes things easier for repainting, but takes up more memory.

The portions of the windows that are visible are contained as a collection of rectangles. Initially, if the window is at the top of the stack, it has one rectangle which encompases the whole window. If another window overlaps it, then the overlapped window's rectangle is divided into other rectanges such that the overlapping portions are not included.

When a window then comes back on-top, portions of its backbuffer are copied using these rectangle coordinates. If your windowing system doesn't have backbuffers for each window (which most don't) then this is when you'd send a "window exposed" event, which would probably include the co-ordinates of the screen which need to be updated.

If I were to rewrite this, I might be inclined to use span buffers, rather then a list of retanges, to maintain exposed window pieces. This would allow me to have non-rectanglar shared windows (a span buffer simply being an array of alternating visible, and invisible spans per each horizontal line).

I was heavily influenced by the X11 window management APIs, so a lot of them mirror (or at least look similar to) X11 functions.

Also note that I can't even garauntee the executables in these archives will run perfectly on current computers. I think the DOS version works alright, but the Linux version (which will now be runtime linked to much newer versions of libc, libm, libdl, etc) may have issues.

If you have any questions, though, feel free to ask.

--Jeff

I just, annoyingly, noticed that the MySQL database that my website is based on, has become inconsistant.

In order to download the smoke binaries and/or source, you can use the following direct links:
http://www.neuraldk.org/downloads/smoke-1.0.DOS.zip
http://www.neuraldk.org/downloads/smoke ... nux.tar.gz
http://www.neuraldk.org/downloads/smoke-1.0.src.tar.gz

--Jeff