ericsa@microsoft.UUCP (Eric Sassaman) (10/04/90)
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