Groups | Search | Server Info | Login | Register

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

Re: another VIO attempt

Show all headers | View raw

On 15/02/24 22:47, xhajt03 wrote:
> On February 15, 2024 at 14:28:26 +0100 Paul Edwards wrote:

>> BTW, you wrote one very long line in this newsgroup
>> post instead of splitting it up. I have to manually
>> split it up instead.
>
> Well, sorry. I'm responding to these Usenet messages
 > via Google Groups (which will stop working in one
 > week from now :-( ).

I used to use that too. Just hit enter after a while.

 > I don't have any Usenet client installed.

Don't you use ArcaOS? It comes with Thunderbird.

You can get a free account here:

https://www.eternal-september.org/

>> I want to have a pure 32-bit executable.
>
> I see. You can have that if you use a 3rd party DLL
 > providing the translation from/to the 16-bit calls,
 > but you'd probably need to distribute those with
 > your application(s).

And I don't want to do that either.

Or if I was to do that, the 3rd party DLL would
be called PDPCRT.DLL and it would be comprised
of pure 32-bit pure public domain code from
PDPCLIB. I already produce my own msvcrt.dll too,
but it's normally not used.

>>> Yes, you cannot treat the keyboard as a file in that
>>> case (i.e. you cannot use DosRead for retrieving the
>>> keys, etc.), but that is comparable to BIOS functions
>>> needed under plain DOS.

>> You don't need to use the BIOS functions in plain DOS
>> to do the above.
>
> Well, yes, you can access the modifiers by accessing
 > the low part of the memory (modified by BIOS) there. ;-)

No. You don't need to do that either. You can
follow pure MSDOS rules and do INT 21H calls
(ioctl and read).

> Not really, because they clearly documented a
 > different solution (in particular using KbdCalls)
 > as intended for scenarios described by you.

Well they did that for OS/2 1.x, and so at that
point there was a 16-bit solution, and of course
it was documented.

For 32-bit they apparently updated what they
thought was enough and then stopped. And it
may well be enough. Or they came very very
close, anyway.

> Also, the fact that the (beta) PowerPC version
 > of OS/2 included a 32-bit version of KbdCalls
 > kind of suggests that they didn't consider other
 > solutions as directly replacing this DLL.

Well, they would have needed to do that for the
other documented solution to work.

They're not going to force everyone to migrate
to the alternate solution immediately.

And maybe not force it ever. Maybe in time they
would have updated the 16-bit x86 versions to
32-bit. But it was not a priority at all because
by then they were more interested in graphics.

>> So they come very very close to working.
>
> OK. Even if you get it fully working, it doesn't
 > mean that it's the most efficient solution.

I'm not after the most efficient solution, nor
the solution (graphics) that will attract the
most customers.

I'm after a technically pure 32-bit application.

And I may produce my own version of OS/2 2.0
(similar to PDOS/386 being a mini Win32 clone).

I'm actually planning on converting PDOS/86 to
be a mini OS/2 1.x clone and abandoning MSDOS.

Or I may do the opposite of win32os2 - and run
OS/2 2.0 programs under Win32. Certain OS/2
programs. Ones that are dependent on pdpcrt.dll.
Although that last one would still work if it
was implemented using the 16-bit calls internally.

>> BTW, I'm not familiar with privilege levels in OS/2,
>> but I haven't done anything to attempt to get into
>> any sort of privileged mode.
>
> Accessing the 16-bit calls requires the specific
 > binary (e.g. a DLL) to be marked for privilege
 > level 2 (IOPL), but you don't need to bother with
 > that when using a translation library like one
 > of those mentioned above (and it doesn't mean much
 > for you otherwise except for a necessity to have
 > the right flag in the respective executable header).

One of my experiments involved calling the Kbd calls.
I was using the Watcom compiler and libraries for
that, and it produced a standalone executable. Would
that executable have been marked as level 2?

And when I switched to pure dos calls, would the
executable have not had that marker?

>> It could be that the accessing of KBD$ is throwing
>> me into a privileged state regardless.
>
> The device driver works at a higher privilege level,
 > but the code accessing the logical device (e.g. KBD$) doesn't.

Ok, cool. I didn't want to have privileged code.

> If you refer to privilege levels specifically,
 > these are for sure enforced in OS/2.

Ok, thanks for the info.

> Talking about OS/2 security in other contexts
 > would go beyond the scope of this thread considerably.

Yeah, I'm not interested in security - just wanted
to make sure I was unprivileged.

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