Path: utzoo!utgpu!watserv1!ria!csd.uwo.ca!webber
From: webber@csd.uwo.ca (Robert E. Webber)
Newsgroups: comp.os.minix
Subject: Re: macminix
Message-ID: <1990@ria.ccs.uwo.ca>
Date: 5 Jan 91 09:09:45 GMT
References: <1990Dec22.1046.1132@canrem.uucp> <1991Jan5.031942.446@world.std.com>
Sender: news@ria.ccs.uwo.ca
Organization: see disclaimer
Lines: 64

[describes problem I had with the proposed console.c GetNextEvent fix and
alternative fix that SEEMS to work better.]

In article <1991Jan5.031942.446@world.std.com> mkahl@world.std.com (Michael Kahl) writes:
.In article <1990Dec22.1046.1132@canrem.uucp> "glen lalonde" <glen_lalonde@canrem.uucp> writes:
.>**** MacMinix upon boot overwrites the address error trap handler
.>address in low memory! This will cause a great number of problems,
.>since address errors will not drop you into macsbug but will cause
.>strange system behaviour. Most of the time the internal drive will
.>start to run, for no reason at all, after a little while of runnning
.>some bad code it will just crash the system. PLEASE post a fix if
.>you know what part of the system is trashing the vector. I think
.>it is at 0x0c in memory if I recall correctly.
.
.Here is the fix.  I have no idea what the original code might have been
.meant to accomplish, but it's clearly in error.
.
.*** /usr/src/kernel/console.c~	Thu Dec 20 23:00:34 1990
.--- /usr/src/kernel/console.c	Thu Dec 20 23:00:59 1990
.***************
.*** 115,121 ****
.    if (scrollrgn == 0)
.       scrollrgn = NewRgn();
.    vdusetparams(line, 1, monaco, 9, line == 0 ? 1 : 0, 1, 0L, 1, 0, 0);
.!   GetNextEvent(GetNextEvent(0, &e));
.  }
.  
.  
.--- 115,121 ----
.    if (scrollrgn == 0)
.       scrollrgn = NewRgn();
.    vdusetparams(line, 1, monaco, 9, line == 0 ? 1 : 0, 1, 0L, 1, 0, 0);
.!   GetNextEvent(0, &e);
.  }

When I installed this fix, elle continually responded wrong to control
keystrokes (such as control-l initiating a search, control-p deleting a line).
Currently I am running with a fix that replaces the original
   GetNextEvent(GetNextEvent(0, &e));
with
   GetNextEvent(0, &e);
   GetNextEvent(0, &e);

This seems a less drastic change since it also performs the
GetNextEvent twice, it just makes sure a meaningful location is passed
for the null event to be stored in.  If I am reading the Mac manuals
right, a event mask of 0 means no event is taken from the queue
although some side effects still occur.  GetNextEvent should return a
Boolean value of either 0 or 1 - in the original, this Boolean return
is being used as a mask for the second call (that is short a
parameter).  If the Boolean is 0, then the above second line is the
same thing.  If it is 1, the manual indicates that this is a mask on a
bit number that is NOT USED.  The manual says GetNextEvent returns
FALSE when returning a null event.  Nothing I have read indicates why
one might want to do GetNextEvent(0,&e) twice instead of once, but neither
has anything indicated that doing it twice might cause a problem.  The
effect of this operation seems to be to tell the Mac monitor to check
the queues for certain events like the key strokes that eject disks
and perform them if they are pending.  None of the events it catches
are things I am aware of occurring while I have run these patches.


--- BOB (webber@csd.uwo.ca)