Groups | Search | Server Info | Login | Register

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

Re: inoperative keyboard - analysis required

Show all headers | View raw

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.

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