> >> Someone told me that NT does not allow direct writes to
 > >> anything, without it's permission is that true ?

 > RJ> _inp() and _outp() in NT will give you a
 > RJ> priveleged-instruction exception message.

 > Not from an IOPL segment, and even a user application can
 > have one of those (unless the kernel refuses to link it, but
 > afaik, NT does).

Haven't tried it, I'm running OS/2, NWDOS/3.1 and Linux. (But read on)

 > BTW, as you no doubt already know, this isn't so much an "NT"
 > feature, as it is a feature of the 386 in protected mode. It
 > wouldn't be the first time an OS vendor claimed amazing
 > "features" stolen from Intel. :-)

BOC. NT implements processor privelege levels 0 and 3. Any process with a
Current Privelege Level numerically greater than the IOPL must go through
the protection mechanism when attempting port I/O. Kernel device drivers
have level 0 access, but user programs run at CPL level 3. 

The I/O Permission Map bitmask array is stored in the Task State Segment
structure in main memory, which is contained in a special segment referred
to by the selector in the processor's Task Register. The location of the
IOPM within the TSS is found by referencing a 2-byte integer offset at
location 0x66 in the TSS. So far, this is all 386 stuff.

In NT the TSS is not fully used. The TR, which points to the TSS segment
descriptor, is never modified. Each process uses the same copy of the IOPM,
and the default IOPM offset points beyond the end of the TSS, effectively
denying user-mode programs access to level 0 and thus I/O ports.

There are ways around everything of course. You can either modify the IOPM
offset so that it falls within the TSS, or extend the TSS so that the
original default offset falls within it.

There are video driver support routines VideoPortMapMemory() and
VideoPortSetTrappedEmulatorPorts() for use with video drivers, but they're
a bit messy for any other use, since the application has to pretend it's a
video driver with associated headers, library overhead and video
initialisation.

 > RJ> If you attempt
 > RJ> port I/O from a 16-bit DOS app in an NT console window,
 > RJ> the I/O is either ignored or emulated by NT's virtual
 > RJ> device drivers.

 > Emulated? It might actually /do/ it, and probably does. :-)

Ummm, "I'm sorry Dave, I'm afraid I can't do that".

Rob
--- FMail 0.94