PortTalk is a Windows NT I/O Port Device Driver.
A problem that plagues Windows NT/2000 and Windows XP, is it's strict control over I/O ports. Unlike Windows 95 & 98, Windows NT/2000/XP will cause an exception (Privileged Instruction) if an attempt is made to access a port that you are not privileged to talk to. Actually its not Windows NT that does this, but any 386 or higher processor running in protected mode.

Accessing I/O Ports in protected mode is governed by two events, The I/O privilege level (IOPL) in the EFLAGS register and the I/O permission bit map of a Task State Segment (TSS).

Under Windows NT, there are only two I/O privilege levels used, level 0 & level 3. Usermode programs will run in privilege level 3, while device drivers and the kernel will run in privilege level 0, commonly referred to as ring 0.

PortTalk will allow the trusted operating system and drivers running in kernel mode to access the ports, while preventing less trusted usermode processes from touching the I/O ports and causing conflicts. All usermode programs should talk to a device driver which arbitrates access.

The I/O permission bitmap can be used to allow programs not privileged enough (I.e. usermode programs) the ability to access the I/O ports. When an I/O instruction is executed, the processor will first check if the task is privileged enough to access the ports. Should this be the case, the I/O instruction will be executed. However if the task is not allowed to do I/O, the processor will then check the I/O permission bitmap.

The I/O permission bitmap, as the name suggests uses a single bit to represent each I/O address. If the bit corresponding to a port is set, then the instruction will generate an exception however if the bit is clear then the I/O operation will proceed. This gives a means to allow certain processes to access certain ports. There is one I/O permission bitmap per task.

Accessing I/O Ports under NT/2000/XP
There are two solutions to solving the problem of I/O access under Windows NT. The first solution is to write a device driver which runs in ring 0 (I/O privilege level 0) to access your I/O ports on your behalf. Data can be passed to and from your usermode program to the device driver via IOCTL calls. The driver can then execute your I/O instructions. The problem with this, is that it assumes you have the source code to make such a change.
Another possible alternative is to modify the I/O permission bitmap to allow a particular task, access to certain I/O ports. This grants your usermode program running in ring 3 to do unrestricted I/O operations on selected ports, per the I/O permission bitmap. This method is not really recommended, but provides a means of allowing existing applications to run under windows NT/2000. Writing a device driver to support your hardware is the preferred method. The device driver should check for any contentions before accessing the port.
However, using a driver such as PortTalk can become quite inefficient. Each time an IOCTL call is made to read or write a byte or word to a port, the processor must switch from ring 3 to ring 0 perform the operation, then switch back. If your intentions were to write, for example a microcontroller programmer which is programmed serially using a parallel port pin, it would make better sense to send a pointer to a buffer of x many bytes. The device driver would then serialise the data and generate the handshake necessary in the programming of a PIC device.

Such an example is the USBLPTPD11 driver at www.beyondlogic.org/usb/usblptpd11.htm. This driver accepts a buffer of bytes via the IOCTL_WRITE_I2C IoDeviceCall and then big bangs this out in I2C format on a parallel port pin. The source code for this driver is available and is well worth a look.
The porttalk device driver comes complete with source code. It provides the facility to modify the IO permission bitmap and/or write and read to I/O ports via IOCTL calls.
Compatibility - Using existing applications under Windows NT/2000/XP
PortTalk can be used in conjunction with allowio to make existing programs that access the I/O ports work under Windows NT/2000/XP. As you already know, any 32bit program will cause a Privileged Instruction Exception. Many hacks have been produced for I/O port access under Windows 95 and 98 such as .DLL libraries. Should you need to run such a program under Windows NT, an exception will occur. Try PortTalk.
16 Bit Windows and DOS programs will run on virtual machines. In many cases existing applications should be transparent on Windows NT/2000/XP. However others just refuse to run. The virtual machines has support for communication ports, video, mouse, and keyboard. Therefore any program using these common I/O ports should run, however there is often a problem with timing. Other MS-DOS programs accessing specific hardware requires VDDs (Virtual Device Drivers) written to enable them to be used with Windows NT.
The Virtual Machine will intercept I/O operations and send them to a I/O handler for processing. The way the Virtual Machine does this, is by giving insufficient rights to I/O operations and creating an exception handler to dig back into the stack, find the last instruction and decode it. By giving the VDM full rights to I/O ports, it has no means of intercepting I/O operations, thus creating less problems with timing or the need to provide VDDs for obscurer hardware.
In order to change a processes IOPM, we must first have the process ID for the process we want to grant access too. This is accomplished by creating the process ourselves, so we can pass the ProcessID to our device driver. An small application is used which accepts the program name as an argument. This application then creates the process (i.e. executes the program) which starts and continues as another process in the system.

Note : We can also register a callback with the operating system which notifies our driver of any processes started and what their ID is. We can then keep a directory of processes that we want to have access to certain ports. When this process is executed, the callback informs the driver it has started and what it's process ID is. We could then automatically change the IOPM of this process. See

The license of this software is Freeware, you can free download and free use this protocol analyzer software.