Greg Ordy
The N2PK VNA connects to the computer via a printer port. When a printer port is used for purposes other than talking to a printer, it's a common convention to call the printer port a parallel port. It's a parallel I/O (input/output) port, where software running on the computer can change output port signals, and can read the data values present on input port signals. For many applications and devices, this is a simple, functional, and complete interface.
From the early days of DOS and then leading up through Windows ME, the home versions of Windows platforms allowed all programs to freely access the parallel ports. In fact, each program could freely run wild over other programs and the devices present on the computer.
Folks who work with operating system software usually do not like this wide open approach, since a single bug in a single program can crash the whole system, and there is no security (privacy) between applications. The traditional solution, employed for decades, is to use computer CPU hardware that supports two or more modes of operation, based upon a privilege model. The core operating system (kernel) is allowed full privileges, and individual application programs have a set of restrictions on what they are allowed to do. The typical minimum restrictions are that the program can only access memory which is part of the program itself, and that the program communicates to the outside world through a set of calls made to the operating system. The enforcement of privileges is not voluntary or on the honor system. As each instruction is executed by the computer, the hardware checks to make sure that the instruction is allowed for the current privilege level. Software cannot escape or ignore the mechanism.
When a program does something wrong, something it does not have permission to do, the operating system is handed control of the matter. At this point, there are many possible alternatives. The simplest is that the program is abruptly terminated. No doubt you have seen that behavior from time to time. In some cases, the program is informed that it has committed some sort of violation. The program may be able to work around the problem, probably expecting that this might happen (it planned ahead).
In order to have a higher degree of protection/security, and less chance of endless crash and reboot cycles, the Windows platforms targeted for business users, Windows NT, Windows 2000, and now Windows XP, have always used a hardware protection mechanism. The actual CPU chips, whether Intel, or AMD, or some other brand, have had support for privilege levels for many years. Some versions of Windows simply chose to not use them. Thankfully, the home and business product lines merged with Windows 2000, so the number of alternatives and approaches has gone down.
The good news is that our computers crash less. The bad news is that for the more recent operating systems, a normal application program can no longer directly access the hardware devices on the computer. This includes the printer port(s).
There are several possible solutions. The computer scientist in the crowd would probably suggest that a special N2PK VNA driver be created. This driver becomes part of the operating system, and therefore has full access rights to the hardware. A VNA application program would then open the hardware through the driver, much like a file, or floppy disk, or serial port is opened. At that point, the program would make calls into the driver, and the driver would handle all of the communication with the VNA. There is nothing wrong with this solution other than the fact that it is overkill on the versions of Windows that allow direct access to the hardware, and drivers tend to be far more operating system specific than application programs. In other words, you might need different drivers for different platforms. That complicates life a bit. The real problem with this solution is that it's not backward compatible - it won't help existing programs that want to access the parallel port directly. It will also be a little slower than direct access of the parallel port because the computer must change contexts between the application program and the driver for every operation. As computers get faster and faster, however, that is a relatively small concern.
There are solutions that possess backward compatibility. They will all use some form of driver or device driver, since that's the only way to get the privileges needed to access the parallel port.
The first solution is clever in that it is a driver which waits for a program to execute one of the privileged input or output instructions which are used to communicate with the parallel port. Since the application program is not allowed to execute those instructions, the CPU hardware will notify the operating system of this error. The driver will intercept the processing of that error, and recognize it as an attempt to access the hardware directly. The driver will perform the access, since it has permission, and it will arrange for the operating system to restore the application program as if the privileged instruction actually worked. This is usually called emulation. This technique was often used on computers that had an optional floating point computation unit. Programs would be built (compiled) with instruction streams as if the hardware was there. If the hardware was there, it would execute the instructions. If the hardware was not there, traps would be generated that ended up in the operating system, where the floating point operation was painfully computed in software, and the program eventually resumed execution, not knowing if the hardware was there or not. The only way that you knew that the hardware was not present was that the program ran very slowly, depending upon the number of floating point instructions executed.
While this approach would allow existing programs to run without modification, the overhead is very high. This would certainly be the slowest approach.
The second solution, the one that we are using here, uses a driver which simply turns off the protection mechanism for I/O instructions. This approach will not reduce performance, but opens up a security and protection hole, for those interested in that sort of thing. This mechanism was apparently added so that certain video cards which required additional access through a parallel port interface would continue to function on operating systems that used hardware privilege levels.
The N2PK software, which assumes the ability to directly access the VNA parallel port, will not work on Windows NT, 2000, or XP due to this issue. One of the solutions that provides backward compatibility must be used. One suggested solution is a product called Direct I/O. This package allows application program to access to the I/O ports. The package appears to solve the problem, and it's only downside appears to be that you have to pay $29 to get rid of the nag screens.
There are several completely free packages which basically do the same thing. One that we found and have been using is called UserPort 1.0. The rest of this page describes UserPort 1.0, and includes a download link. We have used UserPort 1.0 on Windows 2000 and Windows XP.
There are two main parts to UserPort 1.0. The first is a kernel (operating system) mode driver. This file is named UserPort.sys. Although it is possible to locate this file in any folder, it is usually placed in the %WINDIR%\SYSTEM32\DRIVERS folder. %WINDIR% refers to the folder that contains the Windows operating system. The name of the folder is a function of the version of Windows you are using. As the name suggests, this folder is the standard location of all related drivers.
The second major part of UserPort 1.0 is the program UserPort.exe. This program is the client control program, which configures the behavior of the driver.
Two issues come up when defeating the protection mechanism. The first is the specification of the address ranges which will be allowed to be directly referenced by application programs. Ideally, the ranges should be no larger than absolutely necessary for the situation. The second issue is deciding which programs are allowed to defeat the protection mechanism. If you have an existing program which you cannot change (such as the N2PK software), you need to open up port access to all programs. UserPort 1.0 includes a second access mechanism which limits the protection removal to programs which open a special device named \\.\UserPort. Opening this pseudo device tells the UserPort driver that the program in question is asking for permission to access I/O port addresses. The VNAccess library, which is used in all Seed Solutions VNA software opens this pseudo device name.
UserPort 1.0 lets you specify ranges of I/O addresses which will be opened up for either all programs, or the programs that use the \\.\UserPort pseudo device mechanism. You can also start and stop the driver from the control program. Normally, you would install the package, select the ranges and program classes that you want, start the driver, then exit the control program. UserPort 1.0 should then start automatically each time that the computer boots.
By the way, if your computer has a single printer or parallel port, and it is installed in the default manner, the required address range will be 0x378 to 0x37B This is the default address range used by the first printer, normally named LPT1.
If there is a downside to UserPort 1.0, it is that it requires a manual installation. A ZIP file needs to be unpacked, and files put in the right folders.
In addition to these two main parts, the UserPort 1.0 ZIP file includes the source code for the parts, and a limited amount of documentation.
UserPort 1.0 installation and configuration is described on a page which is part of Writelog for Windows.
The UserPort 1.0 download file appears to come from this link.
The UserPort 1.0 ZIP file can be downloaded from this link.
DOS, Windows, Windows 98, Windows NT, Windows 2000, and Windows XP are trademarks of Microsoft Corporation.
Back to my Software Contributions Page
Back to my Experimentation Page