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.

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

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

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

>
> 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.
Shame so many are no longer here.
Dave

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.

On 02/03/24 07:57, Dave Yeo wrote:

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

I have done some searching. I do not currently have this:

SET PM_ASYNC_FOCUS_CHANGE=ON

in my config.sys

It's unclear to me that if I added it, something would
happen in this circumstance.

This seems to be used for too many unprocessed messages.

Is that something I am likely to have?

As per the Physical Device Driver Reference:

https://www.os2museum.com/files/docs/os220tl/os2-2.0-pdd-ref-1992.pdf

Function 51 H - Set Input Mode

on page 18-77 there are some "x" fields and I would
assume the proper thing to do is query current settings
before changing this.

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.

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

Do you know how to deliberately switch off the SIQ?

If so, that might give an idea on how to switch it
back on.

Thanks. Paul.

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.

BFN. Paul.

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.

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/" rel="nofollow" target="_blank">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

Paul Edwards wrote:
> On 02/03/24 07:57, Dave Yeo wrote:
>
>>> "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.
>
> I have done some searching. I do not currently have this:
>
> SET PM_ASYNC_FOCUS_CHANGE=ON
>
> in my config.sys
>
> It's unclear to me that if I added it, something would
> happen in this circumstance.
>
> This seems to be used for too many unprocessed messages.
>
> Is that something I am likely to have?

I forget the specifics. I notice that Arca does not include it. My old
Warp V4 has,
SET PM_ASYNC_FOCUS_CHANGE=9000
Probably don't need it but wouldn't hurt.

>
> As per the Physical Device Driver Reference:
>
> https://www.os2museum.com/files/docs/os220tl/os2-2.0-pdd-ref-1992.pdf
>
> Function 51 H - Set Input Mode
>
> on page 18-77 there are some "x" fields and I would
> assume the proper thing to do is query current settings
> before changing this.
>
> So the only other documented thing is "shift report".

I'd think whether the shift key is pressed.

>
> 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.
>
>> 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.
>
> Do you know how to deliberately switch off the SIQ?

No, never heard of the possibility until reading your ticket.
Usual problem is a program crashing while using it.

>
> If so, that might give an idea on how to switch it
> back on.
>
> Thanks. Paul.
>
Dave

On 02/03/24 14:37, Dave Yeo wrote:
> 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

53 is 16-bit, sure. I'm not using that version.
109 is internal according to this:

https://www.osfree.org/doku/en:docs:os2:modules:doscalls

And I'm using 284:

D:\devel\pdos\pdpclib>grep Ctl makefile.wat
makefile.wat: echo ++DosDevIOCtl.DOSCALLS.DosDevIOCtl.284 >>temp.wat

So unless David is using different terminology,
there are both 16-bit and 32-bit versions available,
and I am using the 32-bit version, and I think it
is wrong to call it 16-bit.

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

Oh - I don't care what happens beyond my
executable. And if the price is that I can't
use high memory - I don't particularly care
about that either.

So it may be a terminology issue.

So what is the correct terminology to say that
I am linking with pure 32-bit DLL exports, no
thunking involved, and I don't care what OS/2
does internally as it is none of my business,
nor do I care, and I don't have any direct insight
into OS/2 internals anyway.

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

No. "Edge" that comes with Windows 10.

Even using mainstream things, everything is broken.

That's why I am interested in supported software
(ArcaOS), and, if you want open source, then I have
a simple system instead (PDOS/386 is pretty simple),
that can actually be understood and maintained.

BFN. Paul.

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

On 02/03/24 15:22, Dave Yeo wrote:

> Ctrl-Esc is the keys to use.

After running my "rogue" program, that key
combination doesn't appear to work.

It does normally though.

> Isn't there a menu item to do CAD in vbox?

Yes, I see it now, and it does indeed work after my
program has been run.

I didn't see a way to get my keyboard restored
though, other than doing a reboot. The keyboard
does still work in that CAD screen etc though.
And I can open a fullscreen prompt too.

BFN. Paul.

Paul Edwards wrote:
>
>>> 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.
>
> Oh - I don't care what happens beyond my
> executable. And if the price is that I can't
> use high memory - I don't particularly care
> about that either.
>
> So it may be a terminology issue.
>
> So what is the correct terminology to say that
> I am linking with pure 32-bit DLL exports, no
> thunking involved, and I don't care what OS/2
> does internally as it is none of my business,
> nor do I care, and I don't have any direct insight
> into OS/2 internals anyway.
>

Good question. I think of the 16 bit API where you have to thunk and
consider segment size etc, while you don't with the 32 bit API.
Strictly speaking some of the DLL's, including the kernel which presents
as a DLL, doscalls, are internally 16 bit while having a 32 bit API.

>>> 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?
>
> No. "Edge" that comes with Windows 10.
>
> Even using mainstream things, everything is broken.

Apparently so.

>
> That's why I am interested in supported software
> (ArcaOS), and, if you want open source, then I have
> a simple system instead (PDOS/386 is pretty simple),
> that can actually be understood and maintained.

Problem is software has gotten big. The browsers for example push the
limits on our 32 bit system. I've seen g++ use 2 GB's to compile one C++
file and then the linker (wlink) fail without the full address range
available
VIRTUALADDRESSLIMIT=3072 in config.sys. Only works on some systems as
PCI space may conflict. IBM didn't seem to finish the high memory support.
Dave

Paul Edwards wrote:
> On 02/03/24 15:22, Dave Yeo wrote:
>
>> Ctrl-Esc is the keys to use.
>
> After running my "rogue" program, that key
> combination doesn't appear to work.
>
> It does normally though.
>
>> Isn't there a menu item to do CAD in vbox?
>
> Yes, I see it now, and it does indeed work after my
> program has been run.
>
> I didn't see a way to get my keyboard restored
> though, other than doing a reboot. The keyboard
> does still work in that CAD screen etc though.
> And I can open a fullscreen prompt too.

Press ctrl-esc in that full screen session and go back to the desktop,
the window list will be open.
But yes, I was hoping resetting the WPS would do it, unluckily only a
reboot worked. At least could use the mouse to shutdown things first.
Dave

On 03/03/24 11:04, Dave Yeo wrote:

>> That's why I am interested in supported software
>> (ArcaOS), and, if you want open source, then I have
>> a simple system instead (PDOS/386 is pretty simple),
>> that can actually be understood and maintained.
>
> Problem is software has gotten big. The browsers for example push the
> limits on our 32 bit system. I've seen g++ use 2 GB's to compile one C++
> file and then the linker (wlink) fail without the full address range
> available
> VIRTUALADDRESSLIMIT=3072 in config.sys. Only works on some systems as
> PCI space may conflict. IBM didn't seem to finish the high memory support.

Yeah - and I wish to challenge that entire concept
that you "need" anywhere near 2 GB "today".

PDOS/386 can be put on a 360k floppy (or close).

And it has a 2.5 MB memory requirement just to start.
I can work on trimming that down, but it's fairly
pointless as I wish to run a fork of gcc 3.2.3 anyway,
and that requires something like 32 MB or 64 MB when
given a reasonable task (like getting it to recompile
itself with full optimization).

It has taken me 3 decades to get here. A lot of that
time was spent on the IBM mainframe where I was trying
to get things working too. I was chided by many people
for "my" program (gcc 3.2.3) needing more than the
16 MiB limit of the (older) S/370 IBM mainframe.

I think it is unreasonable to require programs to fit
into 16 MiB (minus overhead of maybe 6 MiB), but others
disagree.

However, I do agree that going a long way above 16 MiB,
even coming close to 2 GiB (a different mainframe limit),
is ridiculous.

And that if you need that much memory, it's more likely
that you are doing something wrong. And 64-bit is
unnecessary for the same reason. Which means that OS/2
should be perfectly fine for the job. Indeed - 512 MiB
should be perfectly fine.

wlink will similarly be replaced, in this case by the
public domain and supported pdld.

Today I am going to be looking at gccwin (my fork of
gcc 3.2.3) to see if I can add the "_System" keyword
to support the OS/2 API calls. Otherwise we should be
able to work around the issue elsewhere.

I believe that will be a much more viable toolchain.

For me at least. Because that's another rationalization
I would like to do - sticking with fullscreen text.
Note that blind people can only "see" text, and that's
a "lowest common denominator" that I'd like to target.

But yeah - nearly everyone else has a different interest.
And that would nominally be fine. But it ends up with
code that is not understood and not maintainable, and
you end up with:

https://www.quora.com/Why-did-you-leave-software-engineering/answer/Jeff-Sturm-2

"The inmates are truly running the asylum, as the saying goes"

I wish to challenge that "leadership".

If I treat Linux as a glorified BIOS, a 53k executable
gives me a mini OS/2 clone, a mini Win32 clone, and it
also runs the flagship PDOS-generic apps.

It took 30 years to create something that is conceptually
simple and somewhat obvious in hindsight.

I say "somewhat" because it is not that obvious that you
can run different APIs with a single C library, and I
sometimes need to look into the code to answer "how on
earth does this work?".

And all sitting ready for anyone at all to commercially exploit.

BFN. Paul.

On 03/03/24 12:34, Paul Edwards wrote:

> It took 30 years to create something that is conceptually
> simple and somewhat obvious in hindsight.
>
> I say "somewhat" because it is not that obvious that you
> can run different APIs with a single C library, and I
> sometimes need to look into the code to answer "how on
> earth does this work?".

And just for the record, I'm still "before" getting
the keyboard working for fullscreen apps, and it is
not "obvious" how (or potentially "whether") it will
work as part of either PDOS/386 or the bios.exe in
UC386L.

Both of those things will be sending ANSI escapes
through for both cursor movement and pressing a
real ESC key (which microemacs uses). For the real
ESC, two escapes are sent through (Wikipedia says
that that is a valid ANSI escape sequence). But
DosDevIOCtl is expecting something quite different
when it reads keys. I can almost certainly do a
full translation of supported keys into what
PDPCLIB-based programs for OS/2 are expecting from
DosDevIOCtl. "almost certain" meaning I wouldn't
bet my life on it, as there have been numerous
instances where I have been wrong before.

However, what I'm wondering is whether I can finesse
things so that I don't need to do a full translation.
And just allow the OS/2 PDPCLIB to keep fetching
characters and pass them on to the app, without having
to do its own translation. Get the characters to go
"under the radar" as not being detected as special keys.

But I will need to recheck the OS/2 PDPCLIB code to see
how it is detecting special characters, whether ESC
is a special character.

Even in the semi-worse case, there should always be a
second character after ESC, so in my doscalls.c I should
be able to read a second character, and then just have
to translate two characters. The rest of the ANSI escape
sequence can then go "under the radar" (no need to
translate). It is very likely I just need to detect a
double ESC and translate that.

I will find out when I'm ready to code it up.

And none of this will be relevant if I am given alternate
Dos* functions to call.

Well - none MAY be relevant.

Nothing is "obvious" until 20/20 hindsight kicks in.

And then there's an infinite array of "experts" who
knew it all along. I'm not one of them and never
have been. I plod along, one concept at a time.

BFN. Paul.

On 03/03/24 13:42, Paul Edwards wrote:

> Even in the semi-worse case, there should always be a
> second character after ESC, so in my doscalls.c I should
> be able to read a second character, and then just have
> to translate two characters. The rest of the ANSI escape
> sequence can then go "under the radar" (no need to
> translate). It is very likely I just need to detect a
> double ESC and translate that.

It didn't work out like that. The escape was
still doubled up by PDPCLIB and I was about to
give up and do a full translation when I realized
I could provide a dummy (0) scancode and check
that in PDPCLIB and allow all the characters to
slide in "under the radar".

There's still an issue for people who may use x'e0'
for their national characters (issue may not exist
on PDOS), but for normal programming requirements
(ie pure ASCII), the new PDOS/386 at pdos.org handles
the raw reading now too.

BFN. Paul.