Groups | Search | Server Info | Login | Register

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

Re: inoperative keyboard - analysis required

Show all headers | View raw

Paul Edwards wrote:
> 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.

OK, I'm not really knowledgeable enough on this. The toolkit headers 
seem to define the 32 bit one as DosDevIOCtl2, ordinal 109 whereas 
DosDevIOCtl is ordinal 53

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

OK, thanks.

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

I thought the 32 bit version was basically a wrapper around the 16 bit 
version.

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

The newsgroups. Though there are those who also don't use OS2World. I 
can think of a couple of people such as Lars who could give much better 
insights then me who do hang out on OS2World.

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

Using Firefox 45? Yes the captcha's are broken on the old browser. 
Registration might still be broken on the main page as well. Usual work 
around is to communicate with Martin. Though as you found, the forum log 
in is all you need.
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