🚀 go-pugleaf

Oops, somehow I lost the name of the person who responded to this...
my apologies.

> ericsa@microsoft.UUCP (Eric Sassaman) writes:
> >The problem is that port I/O from an OS/2 2.0 32-bit application is
> >only allowed in a ring zero code segment. An IOPL segment runs at ring
> >2; at this level port I/O is not allowed in a 32-bit application. In
> >order for you to do direct port I/O under OS/2 2.0, you will need to
> >either write your application as 16-bit or write a device driver that
> >runs at ring 0. This device driver can be either 16 bit or 32 bit.
>
> I won't deny that any of this is true, but I *think* it omits an
> important point. About 6(?) monthes ago in either Computer Language or
> DR Dobbs there was an article on using IOPL segments to read/write the
> I/O ports. It mentioned that there was a function that
> enabled/disabled port access (even to IOPL segments). In OS/2 1.x this
> function didn't do anything, since the 286 is not able to offer
> individual I/O ports (and disallow others). But according to the
> article there were supposed to be required in OS/2 2.0.
>
> I think the name of the function was DosEnablePortAccess (or something
> similar). If this isn't enough information let me know and I can look
> up the article.

DosPortAccess under OS/2 1.x was essentially a no-op call that ALWAYS
returned 0 for success, without doing anything. DosPortAccess was
initially included in 1.x for compatibility with a future
implementation specifically for the 80386, but after it was decided to
make the 32-bit APIs more portable to other 32-bit processors, a
different access scheme was chosen and DosPortAccess removed. As it
stands today, IOPL from 32-bit applications will require the aid of a
device driver or must call 16-bit code. IOPL from 16-bit applications
will not change.

Eric Sassaman
ericsa@microsoft
  I don't speak for Microsoft. I just try to figure out how OS/2 works.

f f p  n
 i o o  e
  l r s  w
   l   t  s
    e
     r