Groups | Search | Server Info | Login | Register

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

Re: inoperative keyboard - analysis required

Show key headers only | View raw

On 02/03/24 10:54, Paul Edwards wrote:
> On 02/03/24 10:48, Paul Edwards wrote:
>
>> So the only other documented thing is "shift report".
>>
>> I don't know what that is, but I thought that by having
>> that switched off I might have disabled the keyboard.
>>
>> ie I used 0x80 instead of 0x81.
>
> This change:
>
> Z:\yyy2>diff ..\yyy\pdptest.c pdptest.c
> 50c50
> <     bb = 0x80;
> ---
>>     bb = 0x81;
> 65c65
> <     oldbb = 0;
> ---
>>     oldbb = 1;
>
> Z:\yyy2>
>
> still behaved the same - keyboard inoperative.

I had an idea that maybe one of those "x" bits says
whether the keyboard is active. So I tried 0xff but
got same result. Then I realized that that still left
binary mode on, so I changed it to 0x7f. Same result.

I tried adding this to my config.sys

SET PM_ASYNC_FOCUS_CHANGE=ON

so that after 2 seconds something is supposed to
happen if this is actually relevant.

Nothing happened. Same result.

Note that I can't press ctrl-alt-delete because I
am running under Virtualbox under Windows 10 so I
get the Windows screen.

But - is that what that "SET" command is supposed
to do? It's only if the SIQ is flooded AND the
user presses ctrl-alt-delete that you now have
options that you didn't used to have in OS/2 2.0?

Or is there supposed to be a popup or something
after 2 seconds?

Moving on to philosophy - so it is by design that
a rogue unprivileged program has the ability to
disable the keyboard system-wide?

Here's what David said:

Any program can affect the entire system, especially ones that call 
directly into drivers using IOCtl calls.

I can work within that philosophy.

Just don't write or run rogue programs.

However - I wasn't aware that I was writing a rogue
program.

But I'm still surprised that IBM would have such
a philosophy.

Ok, so IBM came up with a "SIQ" concept.

They recognized that there was an issue.

Is there no solution to that issue? IBM couldn't
think of anything?

They created that new environment variable because
they didn't want to "change the behavior of existing
programs".

Ok - so fine, I've gone to the effort of adding
the variable, and prepared to deal with any programs
that can't handle the new behavior.

But what IS the new behavior?

So the original problem was that all programs share
the same input queue and have access to all the
messages for all windows?

And the idea is that every program needs to "be nice"
and only read messages that belong to it?

If so, this is indeed a security flaw, and being
unprivileged doesn't really mean much.

That's fine. There is no security against deliberate
malware.

But - if I'm willing to accept a change in behavior
of existing software (by adding the above environment
variable, plus more if needed), how do I write a
program so that I can "be nice" and only read messages
that belong to me?

I'm not reading any messages at all in this test
program actually. You don't need to press "a" after all.
That was a previous test program.

Maybe this is a different aspect of the same fundamental
problem. You need to "be nice" if you want to avail OS/2
protection. It will protect against bugs, by only crashing
the one program in the case of a memory violation, but
isn't intended to protect against malware.

Previously the "not being nice" was not reading your
messages, and filling up the SIQ. So that environment
variable gets around that by flushing the queue or
whatever after 2 seconds.

But the current "not being nice" is a new one - asking
the physical device driver to do something that most
people don't ask for because they use 16-bit functions
instead.

So if IBM was interested in that (I know they're not -
this is a hypothetical), they would do what? Another
environment variable that does what? Or maybe they
would make it a default. You're not allowed to disable
the keyboard for more than 2 seconds?

ie my question is - can the OS/2 "achilles heel" be
worked around for this (presumably new) situation?

Any suggestions (if you were working for IBM and
it was the 90s)?

I would like to keep the possibility of an OS/2
revival open.


Moving on ...

I was told by David that the functions were behaving
correctly.

The system reports that it is in binary mode, even
though it is supposed to be in text mode by default.

And it is indeed in text mode, not binary mode.
Setting binary mode (the same value it already
reported), has an actual effect.

How can this be considered "behaving correctly"?

Here is the language used:

"Additionally, the IOCtl functions you are calling appear to be working 
correctly and as designed."


Am I missing something?

If that is "working correctly as designed", then
maybe the documentation needs to be clearer? Or am
I misreading the existing documentation?

I guess this problem 3605 can still be closed -
rogue programs are allowed to render OS/2 inoperative.
You need to "be nice".

And finding out why my program is "rogue" is a
separate problem.

Any thoughts?

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