How to access parallel ports created by NET command in Windows XP?

Question

I am trying to get a USB-to-Parallel IEEE-1284 cable which is showed as USB Printing Support in Device manager to work as a LPT port and tried the answer here. Using this command:

NET USE LPT1: \\[Computer-Name]\Printer /PERSISTENT:YES

The command execute successfully but I can't see the LPT1 in Hardware Devices to get the address to write to it. I know the port I create exits because I made a Java application that lists Serial and Parallel ports using RXTX lib, here is the output:

I added all that LPT ports with the NET command because my PC doesn't have any. But I don't see them anywhere to get the address and RXTX lib doesn't allow me to get port address AFAIK. Any ideas how to access ports?

EDIT:

Ok, to clarify things a little, I have a USB-to-Parallel IEEE-1284, when you connect it to a Windows XP machine it is showed as an USB Printing Support device so It doesn't appear as a LPT port because it is designed to work with printers.

I created a Printer with Generic/Text driver and connected it to USB001 port because it is the port of the USB cable. Then I share the printer and create a LPT port using NET command. Now I want to write data to that LPT port as I would do with any other native LPT port using for example InpOut32.dll.

If it is not possible to access the port on that way, how can I get access to the port to write/read raw data to it? Not to print a document but to write/read raw data to it as you would do with any parallel port.

Answer 1

Ok. So you connected a parallel device/printer via a "USB-to-Parallel IEEE-1284"-cable to the USB-port of your computer. Now you need to directly communicate to it. I understand you can't change the software directly to communicate with modern ports like USB001 etc. like the drivers of scanners do. And the software you have needs to communicate by normal protocol for old-LPTx ports (i.e. 0x378 instead of LPT1 etc.)

That leaves you with one option and that is "emulation". This should be done by the driver which came with the "USB-to-Parallel IEEE-1284"-cable. This driver should make a LPTx port and capture port-communication etc. But most (if not all) of these adapters come with drivers who emulate an USB-printer. In most cases this is the easiest (and even in case of old DOS-programs this can be solved with a NET command) but when it comes to real port-communication it is useless.

So you need to find a program that can emulate a LPTx (and its ports) and bidirectionally communicate with (any) USB-driver on your computer. I have not found one (yet).

The only thing useful i found was this Converter From USB To Parallel. This one emulates the LPTx and ports and communicates directly with the adapter. I have not tested this myself but the info-page looks promising. From the help-file:

The USB2LPT device and its driver enables redirecting of port access by random application software to a USB-attached parallel port, i.e. emulating a parallel port via USB. This unique solution works on all USB supporting Windows operating systems.

It does label its own driver as "Driver unstable" but you'll get the idea for what you're looking for. It also needs a special USB2LPT-adapter though. From its faq-page:

Q3. Can I use the USB2LPT.SYS driver with a regular (cheap) USB to parallel printer adapter?
A. Of course not! It's never possible due to design limitations of such adapters. See below.

It also lists as a minus for itself its Reduced speed due to emulation (expect 10..100 times slower). But it will allow communication with Base address same as built-in (378h, 278h). If you like you can make your own adapter. The schematics are all on the site. Here you can find complete instructions (including videos) on how to build one. Or else you can mail him for details on how to get one.

Answer 2

I think that you may be going about this all wrong. You should not be using "NET USE" but rather using the adapter's software driver to associate a virtual printer port with the USB port. Rik has posted a screenshot of how this works. Only if the adapter's software allows it, should you then be able to write as if that physical port existed.

The NET USE LPT1 command that you showed is for when you connect to a printer on your own or another computer, and set that printer as your local (LPT1) printer. It is based on printing to the device name LPT1 and then redirecting that, which you have said your software won't do (requiring a hardware port).

Here is a driver from Startech, that makes some of these cables, but I don't know if it will work for you; it does work with some other models (including ones that I've owned): http://sgcdn.startech.com/005329/media/sets/ASIX_MosChip-MCS7715_Drivers/ASIX_MCS7715.zip

In the meanwhile, get rid of that NET USE command; it's really not helping you right now, and if you could get it to work at all with the local printer, would still require you to be writing to the LPT1 device (not to the hardware location where it would be, if only it existed.)

Answer 3

You will need the .NET-Framework and PowerShell, but with this script, you can get access to a list of any Parallel-Ports installed on your system.(+Additional informations)

$strComputer = "." 

$colItems = get-wmiobject -class "Win32_ParallelPort" -namespace "root\CIMV2" ` 
-computername $strComputer 

foreach ($objItem in $colItems) { 
      write-host "Availability: " $objItem.Availability 
      write-host "Capabilities: " $objItem.Capabilities 
      write-host "Capability Descriptions: " $objItem.CapabilityDescriptions 
      write-host "Caption: " $objItem.Caption 
      write-host "Configuration Manager Error Code: " $objItem.ConfigManagerErrorCode 
      write-host "Configuration Manager User Configuration: " $objItem.ConfigManagerUserConfig 
      write-host "Creation Class Name: " $objItem.CreationClassName 
      write-host "Description: " $objItem.Description 
      write-host "Device ID: " $objItem.DeviceID 
      write-host "DMA Support: " $objItem.DMASupport 
      write-host "Error Cleared: " $objItem.ErrorCleared 
      write-host "Error Description: " $objItem.ErrorDescription 
      write-host "Installation Date: " $objItem.InstallDate 
      write-host "Last Error Code: " $objItem.LastErrorCode 
      write-host "Maximum Number Controlled: " $objItem.MaxNumberControlled 
      write-host "Name: " $objItem.Name 
      write-host "Operating System Auto-Discovered: " $objItem.OSAutoDiscovered 
      write-host "PNP DeviceID: " $objItem.PNPDeviceID 
      write-host "Powe rManagement Capabilities: " $objItem.PowerManagementCapabilities 
      write-host "Power Management Supported: " $objItem.PowerManagementSupported 
      write-host "ProtocolS upported: " $objItem.ProtocolSupported 
      write-host "Status: " $objItem.Status 
      write-host "Status Information: " $objItem.StatusInfo 
      write-host "System Creation Class Name: " $objItem.SystemCreationClassName 
      write-host "System Name: " $objItem.SystemName 
      write-host "Time Of Last Reset: " $objItem.TimeOfLastReset 
      write-host 
} 

Source:Technet-Microsoft

Answer 4

_{(I have rewritten my previous answer which didn't fit your case.)}

The cable is apparently recognized by Windows, but the driver should have done some more extensive emulation for it to be directly available for writing.

This forces you to invent your own device, in this case a generic printer. It's entirely possible that this printer is unusable because it sends control-codes over the cable to which whatever device is connected on the other side doesn't know how to respond. A printer cable might in this case not be the best means of connecting devices.

The best I can find is in the article Getting a handle on usbprint.sys where a C program was developed for directly writing data to a printer by bypassing the print driver. You could possibly use this simple program as a template to develop your own program for writing the data to the cable.

For the program to work, one must find the GUID of the interface in Windows of the cable, assuming that the cable does have an accessible interface GUID. You will need to search the registry using regedit or the faster RegScanner.