Groups | Search | Server Info | Login | Register

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

Re: inoperative keyboard - analysis required

Show all headers | View raw

Paul Edwards wrote:
> On 02/03/24 10:54, Paul Edwards wrote:
>> On 02/03/24 10:48, Paul Edwards wrote:

snip

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

Ctrl-Esc is the keys to use. CAD will put you in a full screen session 
where you can (try) to kill the badly behaved program, run top, reset 
the WPS, reboot etc.
Isn't there a menu item to do CAD in vbox? I haven't run it in a while 
and might be thinking of vnc.
Pressing Ctrl-Esc sometimes will eventually bring up the window list 
after a bit so you can change focus or a popup saying the program that 
is not responding with a choice to cancel or close it. Cancel is usually 
the better choice as close it usually fails leaving you where you were.

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

I really wouldn't be surprised if Microsoft came up with the SIQ concept 
back in the 1.x days. They did a lot of the original development.
OS/2 2.0 had a lot more 16 bit code then currently, took a while to 
replace the 16 bit stuff with 32 bit and the 16 bit stuff is still there

>
> They recognized that there was an issue.
>
> Is there no solution to that issue? IBM couldn't
> think of anything?

They came up with the partial fix during Warp v3 days and perhaps fixed 
it on the PPC version
Otherwise it seems to be deep in the design of the Presentation Manager

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

Simply some type of watchdog that tries to recover if the queue is 
blocked. It often fails.

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

No, they don't have access to messages for all windows. I think they 
take turns and if a program hangs while reading it, no other program can 
get its own messages.

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

No. You do have to be careful using things like DosCtrlIOCtl, which most 
programs do not use.

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

Being a WPS program, it reads messages. You might press Ctrl-esc or 
chord the mouse while the VIO window has focus. Guess it is the VIO 
window reading messages, not the program running in it.

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

Well, there wasn't really any malware circulating and OS/2 didn't have 
networking at first. It was considered much more crash resistant then 
everything else on the PC at the time but had flaws.
Usually writing normal user programs, it wasn't a problem.

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

I think the programs just rotate who is reading the queue, while (no 
message) wait, kind of thing. Not an expert.

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

I don't know. IBM knew about the problem and other then the fix they 
came up with during V3, nothing was done. Too hard I assume and not long 
after they started winding things down.
One other problem is the Presentation Manager is none reentrant or such 
and can not be closed and restarted.

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

I don't know enough except I guess rogue programs are ones that play 
with things like DosDevIOCtl(). In normal use things seldom hang unless 
running out of shared memory, or it gets fragmented enough that it is 
that allocating doesn't work.
I usually get a couple of weeks of uptime before memory gets short 
enough that I need to reboot, others who aren't running browsers or 
other memory intensive programs get years of uptime
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