Groups | Search | Server Info | Login | Register

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

Re: another VIO attempt

Show all headers | View raw

On 16/02/24 09:38, Dave Yeo wrote:
> Paul Edwards wrote:

>>> the point why you decided using the more low-level
>>> access via the device driver rather than using the
>>> regularly supported means for accessing the keyboard
>>> inteded for VIO applications. Function KbdPeek,
>>> KbdCharIn and KbdGetStatus as provided in KbdCalls.dll
>>> provide (after proper initialization, setting the
>>> keyboard focus, etc.) full support for reading the
>>> keys and modifiers (i.e. shift, etc.) without any echo.
>>
>> I want to have a pure 32-bit executable.
>
> You can't, at least easily. Too much of the kernel(DOSCALL) and DOSCALL1
> are 16 bit at their heart. This includes DosOpen() and DosOpenL() and
> even DosDevIOCtl() or parts of it.

That is external to my executable. My executable
itself is 32-bit. I don't really care what OS/2
itself does internally. Note that PDOS/386 itself
transitions to RM16 in order to do I/O so that I
don't need to deal with drivers. That's fine too.
It's completely transparent to the applications.
The applications themselves are pure 32-bit. And
at any time PDOS/386 can be updated to use drivers
so that the 16-bit stuff is eliminated. That would
be transparent to the application.

> They do have 32 bit wrappers so they seem like 32 bit code

That's all I'm after. With the vendor providing
that, not a 3rd party.

> but will fail
> if you try to use them from high memory (above 1GB).
> Search for os2safe.h for the full list of functions that need special
> treatment if using high memory.

This is a deficiency in OS/2 itself that could
be corrected overnight by Arca. I will patiently
wait for Arca, or else replace ArcaOS with an
updated PDOS/386 that handles OS/2 2.0 calls.

>>> And, obviously, the KbdCalls functions work both in
>>> full-screen and in VIO windows (except for minor
>>> documented exceptions which shouldn't be necessary
>>> for your purposes as far as I understand them).
>>
>> And I believe IBM intended that the 32-bit functions
>> they provided would be sufficient to do the job
>> instead. And it just didn't happen much for other
>> reasons.
>
> Unluckily they never finished porting the functions to 32 bit on X86.
> There was a rumour that one of the devcon ISO's included 32 bit
> versions. All I found were official wrappers to emulate the pure 32 bit
> libraries when/if they got ported from the PowerPC OS/2. They never did
> get ported.

Yeah, that's fine. That's an internal thing that
can happen at any time (even if it never happens
at all).

It doesn't detract from the technical purity that
I am after.

>> And note that the functions they provided *do* do
>> the job in 32-bit. It's only when the program
>> terminates that I find I have an issue.
>>
>> So they come very very close to working.
>
> You are staying below the 1GB barrier? I think you mentioned OW1.6 which
> didn't have much support for high memory IIRC.

I am not familiar with any of that. I wasn't aware
of a barrier. But such a barrier can be lifted by
the OS/2 vendor whenever they have bandwidth.

My executable is "4 GiB-ready" (similar to 4k-ready
for sector sizes).

> User programs run in Ring 3 or Ring 2 in the case of DOS. Ring 2 so most
> DOS device drivers work. Drivers and Kernel often in Ring 0.

Ok, and that protectonly in config.sys would force
apps to be in the lowest ring 3?

But my 32-bit OS/2 executable would be ring 3 by
default and stay there unless I go to some effort
to elevate it, right?

That's all I'm after.

Thanks. Paul.

Back to comp.os.os2.programmer.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-15 13:13 +0800
  Re: another VIO attempt xhajt03 <xhajt03@gmail.com> - 2024-02-15 04:16 -0800
    Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-15 21:28 +0800
      Re: another VIO attempt xhajt03 <xhajt03@gmail.com> - 2024-02-15 06:47 -0800
        Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-15 23:23 +0800
          Re: another VIO attempt xhajt03 <xhajt03@gmail.com> - 2024-02-15 09:07 -0800
            Re: another VIO attempt Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-15 17:13 -0800
          Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-17 16:58 +0800
            Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-17 18:09 +0800
      Re: another VIO attempt Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-15 17:38 -0800
        Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-16 16:17 +0800
          Re: another VIO attempt Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-16 15:05 -0800
            Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-17 09:44 +0800
              Re: another VIO attempt Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-17 15:47 -0800
                Re: another VIO attempt Paul Edwards <mutazilah@gmail.com> - 2024-02-18 09:48 +0800

csiph-web