address a port

[Tim Roberts]

Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:

>On Thu, 25 Mar 2004 23:34:08 -0800, Tim Roberts <timr at probo.com>
>declaimed the following in comp.lang.python:
>
>
>> For the 16-bit systems (Win98 and Win95), you can use the VERY handy
>> ctypes.py module to call the inp/inpw/inpd/outp/outpw/outpd APIs in
>> MSVCRT.DLL.
>>
>	Pardon? W9x /is/ 32-bit... The last 16-bit was WfW3.11

You have been seduced by Microsoft's marketing.

I put it the way I did partly to be a smart-aleck, but what I said is
largely true.  The core of Windows 98 is not substantially different from
Windows for Workgroups plus Win32s.  USER and GDI (and GDI drivers, like
displays and printers) are still 16-bit DLLs.  When a 32-bit process calls
a USER or GDI API, it thunks to the 16-bit side to execute.

> Oh, and ME is also a W9x variant.

Yes, a very slightly modified version of Win98SE, and not necessarily
improved: in my opinion, Win98SE was the best of that product line.

>	But yes, the NON-NT systems, to support old MS-DOS programs and
>games, did allow applications to do direct hardware port addressing.

There's more to it than that.  Display drivers in 95/98/ME are plain,
ordinary, user-mode, 16-bit DLLs.  In order to allow display drivers to
work, the system MUST allow user-mode processes to touch I/O ports.

>There are a number of library/driver utilities around that allow NT
>systems to access the ports -- with the overhead, usually, of DLL calls.

Yes, PLUS a transition to kernel-mode and back for each transfer.  It is
painful.  There are also a couple of slimy drivers that alter the I/O port
permissions mask, thereby eliminating the kernel-mode transition, but they
rely on undocumented structures.
-- 
- Tim Roberts, timr at probo.com
  Providenza & Boekelheide, Inc.