The problem was related to the difficultly in reading/writing to the parallel port in the newer OSs. In Win98 and older OSs, user programs could directly read/write to underlying hardware ports without restrictions. However the newer OSs had prevented this, and only kernel mode apps could write directly to the hardware ports.
The first option explored was to use UserPort, a kernel mode driver. The approach of UserPort is to manipulate the IOPM (I/O Permission Bitmap), so that user applications can be granted permission to directly write to the hardware. It uses a undocumented function (Ke386IoSetAccessProcess in NTOSKRNL.EXE) in order to achieve this.
However the UserPort driver didn't seem to behave correctly on windows 7. It would randomly freeze up the machine upon service start/stop operations. This could probably be a bug in the driver implementation, and not necessarily a problem of the approach, but the fact that a undocumented function has to be used, makes it that much unreliable.
The second option explored was to use inpout32.dll from here. This uses a more elegant approach where the user application calls the read/write of the dll, which in turn uses a embedded kernel driver (Hwinterface.sys) to do the actual hardware read/write (via DeviceIOControl API). The full details of its inner workings are explained here.
However my program in concern was written in java, and the inpout32.dll didn't have the necessary support to directly call it via JNI. One workaround would have been to write a bridge dll with JNI support, which in turn called inpout32.dll.
The other option was to directly modify the inpout32.dll (since the source was available) to support JNI calls, but luckily someone had already done it here - as jnpout32.dll. This worked right out of the box, solving my problem at hand.
References:
[1] UserPort
