OSDev.org

Hello

I'm working on my GUI of my OS, and I really don't know anything about GUIs and how they work. So, I've been thinking about it and researching a bit and I think I've come up with a way to do it. The user space will access the gui through system calls.

So far, i have a system call that opens a new window and associates it with that process, and a system call to blit a bitmap onto that window. I am thinking that's probably all I need for out put.

For input, I am thinking each program will poll for input in it's main loop, basically a system call says any clicks / keystrokes for me that gets called every loop.

Is there a better way to do this? I can't think of a way to have the kernel interrupt the application and say I have data for you.

Andrew

Typically there's no "interrupt". The normal approach is not one to ask to "give me input if you have it, I don't want to wait", but rather "give me input when you have it, I can wait". In the latter case you can remove the task from the scheduler, and you'll know under what condition to put it back.

As Combuster said, these days it is common to "sleep" (i.e. remove a task from the scheduler) unless there is an event waiting for it. In your case, the only "events" are input events (mouse click or key press), but in more advanced systems there are also timeout events which an application can request if it wants to be executed every x length of time even if there is no input, and eventually you'll probably want to implement that.

What you're describing though is called "polling". In that method, the application still executes in at its designated time, and asks the kernel if there are any events. If there are any events, it processes them then goes round and polls again. If there are no events, it polls again immediately. It keeps doing this until its timeslice is up. This is an older approach which is not used that much anymore.

The disadvantage to your applications polling for input events is that it will use 100% of the CPU at all times. This would be bad for laptops running on battery power.

Having your applications sleep until they receive an input requires no CPU time, and allows the system to increase battery life.

SpyderTL wrote:This would be bad for laptops running on battery power.

This would be bad for desktops too, because other programs would lack CPU time, the system would become slow.

Roman wrote:

SpyderTL wrote:This would be bad for laptops running on battery power.

This would be bad for desktops too, because other programs would lack CPU time, the system would become slow.

And it also consumes more power, which is a bad thing if you're interested in not causing the user an excessive electricity bill. So while on laptops it's important to not use too much power for the sake of battery life, the same thing applies to desktops for the sake of power consumption.

Thanks guys,

so from what I understand, I should do polling in my applications, but also sleep.

i have just written an analog clock for my OS, it loops all the time and polls for a close request everytime, but it only needs to update every minute (it has no second hand) so I should sleep for a minute in the application and have a mechanism in my kernel to wake it up if a close request happens before the minute is up?

it seems to me, that from a kernel standpoint, polling is the way to go, but have some sort of sleeping mechanism available, but it is up to the application to sleep (or my gui library which would be part of the application).

apamment wrote:i have just written an analog clock for my OS, it loops all the time and polls for a close request everytime, but it only needs to update every minute (it has no second hand) so I should sleep for a minute in the application and have a mechanism in my kernel to wake it up if a close request happens before the minute is up?

Not really. It's more that the application tells the OS "Send me this event message if I get a close request. Also, send me this other event message every minute." Then it enters its main loop. At that point it makes a sleep system call, which returns immediately if the application has any messages waiting. If there are no messages waiting, the OS removes the application from the list of schedulable processes and calls the scheduler to find the next application to run. Whenever the OS sends an application a message. It checks to see if it is on the list of schedulable processes and adds it if it isn't. The next time the scheduler selects the application as the next process to run, it knows from the very fact that it is running that it has received one or more messages and starts processing its message queue. Once it has emptied its message queue it does any housekeeping work it needs to do, then calls the sleep system call again.

I have no experience with writing any GUI, but I think you need an event mechanism (event queue or something like that), and a system function you can call which puts the task to sleep until there's an event available. And of course, if one or more events already available, just return without putting the task to sleep (only sleep if the event queue is empty when calling it). This is not only for a GUI, but a system function which can be used for everything. In the case of the clock, you would enable the events of close, date/time change, and possibly window move/resize. Then you call that function and you know it will only return when there's an event available. Then you call another function to remove the event from the queue and get its information (event type, when it occured, more event parameters, etc), and then either redraw the clock if the hour/minute has changed or exit if it is a close event.

apamment wrote:so from what I understand, I should do polling in my applications, but also sleep.

No. Just sleep the way i explained.

apamment wrote:it seems to me, that from a kernel standpoint, polling is the way to go, but have some sort of sleeping mechanism available

A good kernel also sleeps (no need to poll) if, when the current "to do" list is empty, the kernel waits until something has to be done. Just use a HLT instruction when there's no need to do anything (all the tasks are in sleep mode and without any event in their event queues), it's very similar to the system sleep function i talked about, but it returns when an interrupt occurs. The interrupt is like an event notification for the kernel, but the difference is that it's not something you can get from a queue, but an event which actually interrupts the currently executing code.