Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site ISM780.UUCP
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!hoxna!houxm!whuxl!whuxlm!harpo!decvax!cca!ISM780!patrick
From: patrick@ISM780.UUCP
Newsgroups: net.micro.pc
Subject: Re: Lotus 1-2-3 question
Message-ID: <31300006@ISM780.UUCP>
Date: Sat, 24-Aug-85 02:15:00 EDT
Article-I.D.: ISM780.31300006
Posted: Sat Aug 24 02:15:00 1985
Date-Received: Wed, 28-Aug-85 20:26:38 EDT
References: <31300003@ISM780.UUCP>
Lines: 52
Nf-ID: #R:ISM780:31300003:ISM780:31300006:000:2586
Nf-From: ISM780!patrick    Aug 24 02:15:00 1985


Thanks to those who posted patches for the 123 sign-on screen.  I tried
the one supplied by "Mr. Video" and it  worked just fine.

As to keyboard enhancers, I found George Snyder's note interesting.  If
Prokey does allow reassignment of the numeric 5 key, then they must be
taking over the hardware interrupt (I know of no other way to determine
that this key has been pressed).  We too take over this interrupt, and
interpret the keyboard scan codes directly.  (The fact that we can run
the PC software under the control of a UNIX system is irrelevant for the
purpose of this discussion.)   By the way, another reason we couldn't use
BIOS is that we make heavy use of ALT numeric-keypad combinations.
Because these can be used to enter ASCII values directly, their values
aren't returned by BIOS until the ALT key is released.  This makes it
very difficult to enter several of these key combinations in quick
succession.

I assume that keyboard enhancers function only with application software
which reads the keyboard via INT 16, and that they take over this
interrupt so that they can perform macro expansions on the raw key-stroke
data retrieved from the hardware.

This implies that if I could _guarantee_ that my users have Prokey, I
could direct them to define the appropriate values for the "hidden keys",
and use INT 16 myself to retrieve keystrokes.  Of course I can guarantee
no such thing, and even if I could this wouldn't be very user-friendly,
so I have to read the hardware.

It seems that there's no way I can provide compatibility with RAM-
resident software (such as ProKey or Sidekick) if that software takes
over the keyboard interupt vector; we can't both service those
interrupts.  (I could provide alternative mechanisms of reading the
keyboard, and allow the user to configure the system appropriately, but
this sounds like more trouble than it's worth.)

On the other hand I could probably make our stuff more compatible with
software which uses INT 16 to read the keyboard, if we coded our keyboard
routine in the form of a replacement for that interrupt, and ensured that
it returned all the "legal" values in addition to the "invisible" values
which the BIOS refuses to return.  Presumably the RAM-resident software
would then call my INT 16, and never know the difference.

Does this make any sense?  Am I missing anything?  Does anyone know
exactly how Prokey, Sidekick, etc. manage the keyboard?   How about the
Microsoft or Mouse-Systems mice?

Patrick Curran

INTERACTIVE Systems Corp.

decvax!cca!ima!patrick
{uscvax|ucla-vax|vortex}!ism780!patrick