Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Re: inoperative keyboard - analysis required

Show all headers | View raw

On 02/03/24 07:57, Dave Yeo wrote:
> 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.

Here are Watcom's header files:

16-bit takes 5 parameters:

D:\watcom\h\os21x>grep DosDevIOCtl *
bsedev.h:  *  bsedev.h    OS/2 DosDevIOCtl structures and constants for 
16-bit
bsedos.h: USHORT APIENTRY DosDevIOCtl(PVOID,PVOID,USHORT,USHORT,HFILE);
bsedos.h: USHORT APIENTRY 
DosDevIOCtl2(PVOID,USHORT,PVOID,USHORT,USHORT,USHORT,HFILE);

32-bit takes 9 parameters:

D:\watcom\h\os2>grep DosDevIOCtl *
bsedos.h: APIRET APIENTRY 
DosDevIOCtl(HFILE,ULONG,ULONG,PVOID,ULONG,PULONG,PVOID,ULONG,PULONG);

I am using the 9 parameter version, which is
significantly different. ie I am using the 32-bit
version, not the 16-bit version.

> 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.

Here is how to get a map file:

wcl386 -bt=os2 -l=os2v2 pdptest.c os2386.lib -"option map"

  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.

Not being high memory safe doesn't make it a 16-bit
function. That would make DosOpen 16-bit by the same
logic. After all that effort IBM made to provide a
32-bit version of DosOpen (noting that the 16-bit
version still exists too).

Am I using the wrong terminology?

>> 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.

Ok, I'll leave that for now.

>> 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.

Ok, thanks for that insight.

>> 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.

Ok, I'll do that after I have exhausted all effort
outside of the support.

> Shame so many are no longer here.

"here" being this newsgroup? As opposed to they are
still in os2world.com?

If I have exhausted what can be done here I will
try os2world.com, which I can now log on to.
I finally figured out the trick. I need to log
on to here:

https://www.os2world.com/forum/

which works, rather than here:

https://www.os2world.com

which appears to reject my userid, and when I ask
for my userid to be sent to my email, it hangs on
the captcha verification (possibly because I am
in the Philippines), after I click to say I am
not a robot.

BFN. Paul.

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