Groups | Search | Server Info | Login | Register

Groups > comp.os.os2.programmer.misc > #1874

Re: inoperative keyboard - analysis required

Show all headers | View raw

Paul Edwards wrote:
> Hi. I raised issue 3605 with Arca over this.
>
> https://mantis.arcanoae.com/view.php?id=3605
>
>
> I told them the below program rendered the keyboard
> inoperative, and they are of the opinion that it is
> ok for an unprivileged program to be able to do that.
>
> That's up to them I guess. So I was ready to close
> the issue.
>
> However, he claimed that I was using 16-bit functions,
> which I believe to be untrue.

DosDevIOCtl is 16 bit. I built your example like,
gcc -Zomf -Zhigh-mem -Zmap pdptest.c
as I couldn't remember how to do OPTION MAP=pdptest on the cmd line with 
OW. Map file contains,
Module: W:\usr\lib\libos2.lib(SafeDosOpen.obj)
0001:000003e0  SafeDosOpen
Module: W:\usr\lib\libos2.lib(SafeDosDevIOCtl.obj)
0001:00000610  SafeDosDevIOCtl

as DosDevIOCtl is not high memory safe, so libc does a wrapper.

>
> Furthermore he claimed that the "keyboard functions",
> presumably meaning Kbd* that I see in the referenced
> cp1.inf (same as what I have from the web) are 32-bit,
> which I believe to be untrue.
>
> Who is right?

When I looked at _getkey() a while back, it was a 16 bit function 
wrapped in a 32 bit function in libc to take care of the segments and 
such. David A. usually uses OW for development, mostly device drivers, 
so I wouldn't expect him to be wrong. Perhaps he is using one of his 32 
bit wrapper development libraries or spoke too quickly.

>
> However, regardless of any of that, he has an intriguing
> insight.
>
> "Your parameters have selected to turn off
> the input queue."
>
> What does this mean? What "input queue"? And how
> did I turn it off? And he suggests that I could
> have turned it back on.

You have found the Presentation Managers Achilles heel. All programs in 
the Presentation Managers session, eg started from the Presentation 
Manager or WPS excepting full screen sessions use one input queue, which 
if it gets blocked, the desktop hangs. It was partially fixed in Warp 
V3, FP#17 but it still possible for a program to block the queue and 
hang the desktop. It is usually called the SIQ
Seems you turned off the keyboard part of it. Note that CAD 
(Ctrl-Alt-DEL) still works to take you to the CAD handler along with I 
presume CTRL-ALT-F10 (twice to trigger a memory dump).
Full screen sessions don't usually have an input queue unless a 
programmer adds them.
NT fixed it by giving every window its own input queue.

>
> As far as I know, all I did was set binary mode on
> (even though it already seemed to be on), and then
> attempt to turn it off (which should be putting it
> back to normal).
>
> The program below works fine in fullscreen mode,
> but in VIO (window) mode it renders the keyboard
> inoperative (after the program completes). Note
> that when you run it, you just need to press a
> letter, e.g. "a" and it will complete.
>
> Can anyone shed any light?

I played around with it, didn't seem to matter what I assigned bb, same 
result, only tried a few numbers. My guess there's something else wrong 
with the parameters.
Perhaps you should post to the ticket asking for more info, like how you 
turned off the SIQ and how to turn it back on. David A. is pretty 
knowledgeable, Steven might answer too.
Shame so many are no longer here.
Dave

Back to comp.os.os2.programmer.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 03:06 +0800
  Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 15:57 -0800
    Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 09:17 +0800
      Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 22:37 -0800
        Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 15:08 +0800
          Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-02 19:04 -0800
            Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-03 12:34 +0800
              Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-03 13:42 +0800
                Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-04 18:47 +0800
    Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 10:48 +0800
      Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 10:54 +0800
        Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 11:43 +0800
          Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 23:22 -0800
            Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 16:05 +0800
              Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-02 19:07 -0800
      Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 22:42 -0800

csiph-web