Re: Idea: Multitasking graphical OS for the GS

[Eric Rucker <bhtooefr@gmail.com>]

On Jan 4, 12:38 pm, "Jeff Blakeney"
<jeff.blake...@a2central.com.remove-109l-this> wrote:
>   To: Eric Rucker
>
> On Fri, 2 Jan 2009 11:58:27 -0800, Eric Rucker wrote:
> > Well, the Minix book suggests another way of doing things...
> > essentially, having the program sleep, which means the OS stops giving
> > it CPU time, until it receives a signal from the OS. This wouldn't be
> > a running loop, the program would halt execution until the OS sent the
> > signal, at which point the program would be sent into its signal-
> > handling routine.
>
> > At least, that's what my 2 AM reading through that section gave me.
>
> That's pretty much how Windows programs operate.  You create callback
> functions that the operating system calls only when it has a message for
> your program.  That call back then checks the message and acts on it.
> The problem is that Windows sends the callback function EVERY message
> that the operating system can generate for the windows and controls that
> the application is using.  Even if the program only acts on 5% of the
> messages, the callback routine is called and simply does nothing for the
> other 95% of the messages.  For example, a push button in a window can
> generate the following notification messages:
>
>     BN_CLICKED
>     BN_DBLCLK (also called BN_DOUBLECLICKED)
>     BN_DISABLE
>     BN_HILITE
>     BN_KILLFOCUS
>     BN_PAINT
>     BN_PUSHED
>     BN_SETFOCUS
>     BN_UNHILITE
>     BN_UNPUSHED
>
> Under normal circumstances, I only care about whether the button has
> been pushed so only act on the BN_CLICKED message.  However, my callback
> function is still passed in the other 9 when they occur so my program is
> given time to run simply to find out that the message passed in is not
> something I'm going to act on.
>
> What I propose is that the program should tell the operating system that
> when it gets a BN_CLICKED message for particular push button in my
> program, it should call my callback function.  That way, my callback
> would never be called for the other 9 messages that I ignore anyway so
> there would be less context switching.
>
> By the way, the TaskMaster call on the IIgs helps somewhat with this but
> its TaskMask is quite limited in what messages you can set it to not
> return.

Well, looking around the GNO archives, there was a folder that caught
my eye - "gui."

Alright, now my curiosity is piqued, native GNO GUI apps? So, I click
on the folder, and see... DRWM. Wait, a window manager? For GNO?

In other words, my "modern multitasking graphical OS for the GS"
already exists - and existed in 1994. Now I just need to get it
working, which... the menus in 2.0.0 don't work, and 2.0.1 crashes
KEGS on launch. (And I don't mean that it crashes within KEGS, I mean,
"KEGS32.exe has encountered a problem and needs to close.")

(And, I don't like its menu handling, but that's such a minor concern,
and could probably be easily fixed, without breaking compatibility
with existing DRWM applications - not that there's many, but an xlogin
app does exist that would be quite useful.)