Groups | Search | Server Info | Login | Register
Groups > comp.os.os2.programmer.misc > #1872
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Newsgroups | comp.os.os2.programmer.misc |
| Subject | inoperative keyboard - analysis required |
| Date | 2024-03-02 03:06 +0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <urt90a$1cvoe$1@dont-email.me> (permalink) |
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.
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?
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.
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?
Thanks. Paul.
wcl386 -bt=os2 -l=os2v2 pdptest.c os2386.lib
#include <stdio.h>
#define INCL_DOS
#include <os2.h>
int main(void)
{
ULONG kbdfile;
static USHORT fileAttr = 0;
static ULONG newsize = 0;
ULONG action;
static ULONG openMode = OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE;
static ULONG openAction = OPEN_ACTION_OPEN_IF_EXISTS;
ULONG datalen;
ULONG parmlen;
USHORT rc;
BYTE bb;
static BYTE oldbb;
rc = DosOpen((PSZ)"KBD$",
&kbdfile,
&action,
newsize,
fileAttr,
openAction,
openMode,
0);
if (rc != 0)
{
return (-1);
}
parmlen = 0;
datalen = sizeof oldbb;
/* get old input mode */
DosDevIOCtl(kbdfile,
4,
0x71,
NULL,
0,
&parmlen,
&oldbb,
sizeof oldbb,
&datalen);
printf("surprisingly, oldmode is already binary %x\n", (int)oldbb);
printf("surprisingly, we need to set binary mode, even though it is
already set\n");
/* set binary mode */
bb = 0x80;
parmlen = sizeof bb;
datalen = 0;
DosDevIOCtl(kbdfile,
4,
0x51,
&bb,
sizeof bb,
&parmlen,
NULL,
0,
&datalen);
printf("restoring old (binary) mode is identical and useless and
behavior is same\n");
printf("so setting text mode instead\n");
oldbb = 0;
parmlen = sizeof oldbb;
datalen = 0;
rc = DosDevIOCtl(kbdfile,
4,
0x51,
&oldbb,
sizeof oldbb,
&parmlen,
NULL,
0,
&datalen);
DosClose(kbdfile);
printf("surprisingly, keyboard is now inoperative and you need to
use mouse to reboot\n");
return (0);
}
Any program can affect the entire system, especially ones that call directly
into drivers using IOCtl calls. Additionally, the IOCtl functions you are
calling appear to be working correctly and as designed.
Regardless of what you are trying to do, these IOCtl functions are
likely not
the way to do it. You should look at the keyboard functions in the Control
Program Guide and Reference (cp1.inf) in the toolkit.
There is also a lot of development information available from the EDM/2 site
which you can get to from the link on the Information for developers page:
https://www.arcanoae.com/wiki/information-for-developers/
The IOCtls you are using are 16 bit functions. The regular Control
Program stuff
I pointed you to are the 32 bit functions.
The functions you are calling are working correctly as IBM designed, not
me, and
are doing exactly what you requested. Your parameters have selected to
turn off
the input queue. The system is still fully running and functional, but
with the
input queue disabled as you requested. You could turn the input queue
back on
with another call, or you could not turn it off at all. No reboot is
required.
The system is simply doing what you asked.
Back to comp.os.os2.programmer.misc | Previous | Next — Next in thread | Find similar
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