USB2LPT: Not recommended for new designs

It depends on why you need one. USB2LPT's .sys driver with its port access redirection “feature” is a dirty hack and never truly stable. Moreover, it is slow and will not work at all for 64-bit versions of Windows. (Except you disable the Patchguard somehow.) In conjunction with my InpOut32.dll, USB2LPT is capable to run on 64-bit Windows. I have no Linux solution for it. Here are some usage scenarios you should differentiate first:

• If you have source code for your problem, solve it by rewriting. You may use one USB2LPT device in this case, as it can be seen as a fully documented USB development kit with USB on the one side, a SubD25 female connector on the other side, and a nice case. Time-critical parts of your software should be managed by firmware. For PC communication, I recommend the HID USB class in general. Beside using my USB2LPT, I recommend using any other USB development system too, e.g. the widespread Arduino Leonardo or the compatible Pro Micro board.
• If your program is a DOS program, either use DOSBox and write your DOSBox driver (it is well documented how to do so), or use ntvdm (32-bit only) and write a VDD (this is poorly documented, but look at my InpOut32.dll source code for sufficient clues). Continue as stated above.
• If your program is a 16-bit Windows program, use 32-bit Windows and its ntvdm and continue as above.
• If it is for a dongle (= software copy protection device), forget USB2LPT. Dongled programs are “smart” enough to defeat usb2lpt.sys.
• If it is for a chip programmer or JTAG interface, forget USB2LPT, it is much too slow. Even the high-speed device. In rare cases, you can live with long programming times, but you should urgently use the high-speed version. I have none available: Buy any CY7C68013A development board (6-10 US$) and put my firmware (usb2lpt2.iic) onto it. Wire the pin headers to a SubD connector as given in my schematic, and you are done. Note that, while slow programming may be acceptable, slow debug reaction is inacceptable, as JTAG is often used for debugging.
• For data acquisition, like oscilloscopes or CCD image reception, USB2LPT is much too slow. Nobody can live with that slow speed. Use a true parallel port.
• For CNC machines with stepper motors, USB2LPT is too slow. It may work but not for sure over long periods of time. Nobody wants bad quality due to some missing steps in the middle of a milling process or so. Use a true parallel port.
• For slow automation control, like LEDs, ASCII LC-Displays, (synchronous clocked) temperature sensors, caliper readback, or relays, USB2LPT ist fully okay. But often there are cheap USB alternatives available. Delays may be noticeable but generally acceptable.
• If you urgently need your precious hardware on USB, you (not I) have to disassemble your software and rewrite it. At the end, you may have a perfect solution with source code.