I am trying to set up a new Virtual Machine (Windows XP Home guest on OS X host) that can support a legacy DOSapplication that I use to print to a USB printer attached to the host.
The DOS application requires some printer control codes to be sent to theprinter prior to running. It is kind of a kludge to print from DOS to a USB printer. In the previous real Windows environment, the way this was accomplished was by having the following three lines lines in a batch file:
net use lpt1: \\Powerspec4\Brother
dos_app_that_sends_HP_printer_code_for_88_lines_per_page
dos_app_that_does_the_printing
I was able to successfully duplicate this function in a virtual machine. However, I am having trouble duplicating it in a newly created instance of the virtual machine. Instead of sending the codes, the characters in the codes are getting printed. I think this is because of differences in the way the VMs are set up.
The differences in the VMs are as follows:
1. The older VM that works fine to send the control codes is using XP Pro; the new one that does not is XP Home.
2. In the XP Pro VM, the printer is set to print to the USB port. In the newer XP Home VM, no USB port appears available. I am not sure why it is not available. I have tried various configuration changes including trying to re-install the USB port (which device manager says is not working properly) in the thought that if I could get the USB port to be working properly, and set the printer to use it, then it would work. However, the USB device driver installation fails.
3.
For some strange reason, the "connect printer" icon at the bottom of the VMWare window acts in the reverse manner: in order to print, it must be in the "disabled" state.
There are several approaches to this problem:
1. Solve the problem by getting the "net use" method to work. Namely, print to lpt1 via the net use command, and use a program or command to send the
proper control codes. Perhaps this involves getting the USB port working, although since I cannot get that far, that may not even be the root cause of the issue. However, it is possibly a step in the right direction and worth points for solving this sub-issue.
2. Come up with a different way to send the control codes. So far everything I have tried results in the printer printing the codes.
3. More drastic measures involving modifications to the DOS program to send the codes directly. Since this program dates from around 1988, I really don't want to go there if I don't have to. The reason I used the external DOS utility back in 1988 was because I could not get those control codes to work properly then.
Here are the exact codes that need to be sent to the printer:
To set 88 lines per page: <27>&l88f<27>(s14H
To reset to 66 lines per page: <27>&l66f<27>(s10H
For clarification, the character to the right of the ampersand is a lower case "L". And the <27> indicates an escape, which can be produced in several different ways. The problem is not creating the codes; it is getting them though the middleware and drivers intact, so the printer treats them as its control codes.
The most frustrating part of this issue is that the XP Pro VM just continues to chug away and send the control codes to the printer. But this is an old VM which I don't what to keep around simply to run this one program.
The DOS application requires some printer control codes to be sent to theprinter prior to running. It is kind of a kludge to print from DOS to a USB printer. In the previous real Windows environment, the way this was accomplished was by having the following three lines lines in a batch file:
net use lpt1: \\Powerspec4\Brother
dos_app_that_sends_HP_printer_code_for_88_lines_per_page
dos_app_that_does_the_printing
I was able to successfully duplicate this function in a virtual machine. However, I am having trouble duplicating it in a newly created instance of the virtual machine. Instead of sending the codes, the characters in the codes are getting printed. I think this is because of differences in the way the VMs are set up.
The differences in the VMs are as follows:
1. The older VM that works fine to send the control codes is using XP Pro; the new one that does not is XP Home.
2. In the XP Pro VM, the printer is set to print to the USB port. In the newer XP Home VM, no USB port appears available. I am not sure why it is not available. I have tried various configuration changes including trying to re-install the USB port (which device manager says is not working properly) in the thought that if I could get the USB port to be working properly, and set the printer to use it, then it would work. However, the USB device driver installation fails.
3.
For some strange reason, the "connect printer" icon at the bottom of the VMWare window acts in the reverse manner: in order to print, it must be in the "disabled" state.
There are several approaches to this problem:
1. Solve the problem by getting the "net use" method to work. Namely, print to lpt1 via the net use command, and use a program or command to send the
proper control codes. Perhaps this involves getting the USB port working, although since I cannot get that far, that may not even be the root cause of the issue. However, it is possibly a step in the right direction and worth points for solving this sub-issue.
2. Come up with a different way to send the control codes. So far everything I have tried results in the printer printing the codes.
3. More drastic measures involving modifications to the DOS program to send the codes directly. Since this program dates from around 1988, I really don't want to go there if I don't have to. The reason I used the external DOS utility back in 1988 was because I could not get those control codes to work properly then.
Here are the exact codes that need to be sent to the printer:
To set 88 lines per page: <27>&l88f<27>(s14H
To reset to 66 lines per page: <27>&l66f<27>(s10H
For clarification, the character to the right of the ampersand is a lower case "L". And the <27> indicates an escape, which can be produced in several different ways. The problem is not creating the codes; it is getting them though the middleware and drivers intact, so the printer treats them as its control codes.
The most frustrating part of this issue is that the XP Pro VM just continues to chug away and send the control codes to the printer. But this is an old VM which I don't what to keep around simply to run this one program.
Tags:
fusion,
xp_home,
xp_pro,
usb,
thin_print,
printer_control_codes