Complex question: sending escape codes to printer from VMWare Virtual Machine

I am trying to set up a new Virtual Machine (Windows XP Home guest on OS X host) that can support a legacy DOS application 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 the printer 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 (where the names in the second and third lines are changed for simplicity):

    net use lpt1: \\network_printer_name /persistent:yes

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 two obvious differences in the VMs, which may or may not be related are as follows:

1. The older VM that work is using  XP Pro; the new one that does not is XP Home.

2. In the older 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 permutations of configuration in the though that if I could get the USB port to be present, and set the printer to use it, then it would work.

There are several approaches to this problem:

1. Solve the problem by getting the same 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.

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.

However, it would be an elegant solution to send the codes from within the DOS program. Just in case this avenue is fruitful, here is the current codes that the DOS program is supposed to be sending 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".
Who is Participating?
jasimon9Connect With a Mentor Author Commented:
To JT92677, post of 05/16/09, 07:28pm:

Rather than not understanding the responders suggestion, I believe it is my poor abilities with written English that have prevented the responder from understanding that I am doing exactly what he suggests.

I will try again with more detail to explain the successful procedure:

   1. Install the printer in the guest OS using the manufacturer's driver disk for the Brother MFC-8440.

   2. Enable sharing with the share name "BrotherU". Note that the port TPVM is assigned by default and that there is no USB port in the list of ports.
   3. Uninstall / reinstall USB ports. This seemed to fail numerous times, but repeat it a bunch of times anyway.

   4. Eventually the USB port appears in printer port list, so when it does, switch from the TPVM port to the USB port.

   5. In the VM Settings, observe that there is now a "USB Brother Printer" device. Enable the device by clicking in the box.

   6. Toggle the printer icon at bottom of VMWare screen to the "Connect Brother Printer" state.

   7. Test printing from typical Windows app (it works) and from "send-codes-plus-DOS-app" batch file (it also now works), where the contents of the batch file are as follows:

    net use lpt1: "\\XP-HOME\BrotherU"
    lj4 for 88 lpt1

where in the above "XP-HOME" is the machine name of the guest OS, "BrotherU" is the share name of the printer, "lj4" is a DOS app that sends printer control codes, and "ar" is the DOS app that does the printing.

The most critical aspect of this process with respect to the "control codes" handling is getting the USB port available so the printer can be assigned to use it instead of TPVM.

The above combination works in my environment.

What does not work is either of the following:

    1. Having the BrotherU shared printer assigned to the TPVM port.

    2. Instead of using the machine name of the guest OS, using the machine name of the host OS (for example: net use lpt1: "\\IMAC1\Brother").

It is also important to note, as many readers have missed this essential point: by "work" I do not mean "be able to print." Virtually every variation I tried "works" in the sense of being able to print. However, it is only the combination which includes using the USB port and the guest OS machine name that allows the sending of control codes that are interpreted as such, rather than printing on the page.
First, it doesn't matter if the VM supports USB or not.

Can you print to the printer from the HOST machine.
If yes, then SHARE the printer on the HOST machine, giving it a name like DOSPRT

On the HOST machine, find out the "full computer name" like on mine "DELL-M70"

On the VM, go to CMD prompt and try this

ping dell-m70
then try
net view dell-m70

do you see the shared printer?
if so

where you tried this:
net use lpt1: \\network_printer_name /persistent:yes

try this instead
net use lpt1: \\hostmachinename\sharedprintername

The persistent is optional if you put these commands in a batch file since clearly
you want to send the esc codes when you attach the printer, so persistent does nothing useful
if you shut down and restart the computer, you'll still want to resend the ESC codes.

After you do the net use lpt1: .... command check out the LPT connection with

net use

See if it shows that LPT1 is actually connected to the printer.

The advantage is that instead of trying to run the printer directly from the VM, you're going
through the HOST and letting it handle the spooling, and other printer driver issues, like
is the printer a USB printer, something a DOS program won't know about normally.

Hope this helps.

jasimon9Author Commented:
Jeff: thanks for your first attempt to understand this question.

I am already doing what you suggest, but that is not the problem. The problem is not "seeing the printer" or "sending output to the printer". The problem is sending codes to the printer which are properly interpreted.

In the "old" VM this is working fine, but in the new VM it is not. So what is the difference between the two VMs? That is what I tried to convey in my question. The differences are Pro vs. Home, USB port vs TPVN (ThinPrint port provided by VM) because there is no USB port present.

Unfortunately it appears my attempt to simplify and abstract the problem statement went too far. When I wrote

    net use lpt1: \\network_printer_name /persistent:yes

that was merely an abstraction to hide the detail. What is actually used is the machine name and printer name, as in the following two examples:

    net use lpt1: \\IMAC1\Brother /persistent:yes

- or -

    net use lpt1: \\XP-HOME\BrotherX /persistent:yes

In the first case IMAC1 is the host name and Brother is the shared name. In the second case, the XP-HOME is the VM machine name and BrotherX is the share name.

The first approach prints directly to the host OS, the second to the VM, which in turn goes to the host. Both of these approaches work to print, but neither of them sends the codes, as in the old VM.

For further insight, here is what prints in the new VM when the old DOS utility is used to send the command to put the printer into "88 lines per page" mode:

    %-12345@PJL DEFAULT FORMLINES = 88

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

jasimon9Author Commented:
The problem at the moment seems to be resolved.

I continued monkeying with things. I kept thinking if I could only get the USB device to appear in the Printer Ports list, I could try assigning to that, as that is what it is assigned to in the XP Pro VM that works.

Checking device manager, there was a yellow exclamation point on the USB driver. So I attempted to reinstall that. I tried a bunch of times using different sources for the drivers. Usually the installation failed, but eventually it succeeded. The USB port was still not there.

As I said, in the VMWare Settings > USB ports, sometimes a port labeled "Brother Printer" was there and sometimes not. I saw that it was there, so I turned it on.

When back to look at the available ports to assign the printer to, and unexpectedly, there was a USB port this time! So I changed from the THVM port (ThinPrint Print Port for VMWare) to the USB port.

I tried to print but "no printer was available" so I turned the VMWare icon at the bottom of the page back to "enabled" thinking that the "reversal" of this icon's function is now over because of being on the USB port.

Printing now works. I tested printing from Word, and from the DOS app that uses the special mechanism to send printer codes, and both work. Printing starts immediately too, instead of a long wait for each page.

So -- I am not sure of the exact sequence needed to solve this problem due to the seemingly non-deterministic results, but I think the path to the solution that worked goes something like this:

  1. Install printer using manufacturer's driver disk for Brother MFC-8440
  2. Uninstall / reinstall USB ports. This seemed to fail numerous times, but repeat it a bunch of times anyway.
  3. Eventually USB port appears in printer port list, so when it does, switch from TPVM port to USB port.
  4. Toggle printer icon at bottom of VMWare screen to "Connect Brother Printer"
  5. Test printing from typical Windows app and from "send-codes-plus-DOS-app" bacth file.
While I am sure there is a more direct route, at least this appears to work for now.
I would not attempt to connect directly to the printer, bypassing the host machine's support and drivers.

If you cannot print to the printer from Windows, all bets are off.

If you can, then SHARE the printer (yes, sounds weird by it's the right way to do it)
Then be sure your computer name is reasonable, and the share name is reasonable (by reasonable I mean no spaces).

Then Net Use LPTx \\HostComputerName\SharedPrinterName

The way you're doing it seems prone to failure, although it seems right to go direct to the printer.

What you're doing is no different than other DOS programs that write to an Epson emulation, setting up the printer lines per inch (like 8 or 6) and characters per line (80, or 132) or print size.

Try what I suggested. I use the same approach here for Alpha4 DOS version printouts to a basic HP printer emulation, and to a basic Epson emulation.
The questioner does not understand the solution offered. USB printer support is provided by Windows, and the DOS box can get this support by NET USE, referencing the SHARED printer on the HOST machine.  By sharing a printer, the DOS box or any VIrtual machine can access the shared printer easily.

It may not seem obvious, but that is why the issue is (apparently) complex.

Further, the questioner indicates he solved the problem, yet the solution was not provided, nor was it clear that the solution he stumbled on is realiable, or even works right. Also, the solution provided by the questioner is exactly the source of the problem.

If people close questions by answering themselves, or give up and provide an incomplete explanation, there is no reason to respond to any further questions this person may post.

EE moderator wrote

"Question PAQ'ed with refund of points.
EE Moderator
I asked that the question be re-opened until the questioner actually verified that he tried the print SHARING approach, but instead, the question was closed, and "points refunded" whatever that means.

Have fun, whoever reads this  <<grin>>
jasimon9Author Commented:
To JT92677, post of 05/15/09:

It appears you did not notice in my detailed description that I am doing exactly what you are suggesting. That is, the net use lpt1: \\hostname\sharedprintername. Then sending the codes and output to lpt1.

But you don't make it clear what is the "HOST" in your example.

It should be the Virtual machine on which you are running the DOS box.

Since it's not at all clear what HOST you are using, it isn't clear that it will work.

You can reference the "HOST" of the virtual machine, or the "HOST" of the DOS Box,
or the "HOST" of a network printer. Which is it?

The problem is that the word "HOST" is overloaded with too many meanings..

I am using HOST to mean the machine that is hosting the CMD (DOS) box. The virtualization in VMware is so good, that it's often confusing when using DOS commands in a Virtual machine, but at the CMD prompt in a Virtual machine, the "HOST" in this case is the Virtual machine hosting the DOS BOX.

Oh well, if this doesn't make sense, I apologize.
jasimon9Author Commented:
Agreed, in my "detailed" explanation, I have taken greater pains to disambiguate the usage of the word "host", as the two contexts are the VM host, and the host in the sense of the share name \\hostname\sharename.

I trust that my final explanation avoids that ambiguity.
Well, you don't need USB printer support in the VM machine, since it can print to the underlying "host" of the VM machine. The USB hardware for the printer is best handled by the VM's host (the real computer running the host operating systm) , and not by the Virtual machine itself.

Then can ADD a network printer while in the VM looking for the shared printer on the VM's host machine.

If you can print to that printer (which is NOT printing directly to the USB, but indirectly through the shared printer of the host (there we go again with HOST <grin>)

If you can print to the mother ship's printer, on the mother ship's USB port, from the Virtual machine's network printer, NOW you can share the networked printer, which will share it with the DOS box.

I realize this appears to be redirection overkill, but so is printing from a DOS box to the VM which then prints to the VM's host, which then prints to the host's USB port.

That's why I started off noting that it doesn't matter if the printer is on a physical USB port, if you share that thing, the machines that use the shared printer could care less about the underlying hardware needed to transport the bits to the physical printer.

So your answer helped avoid some ambiguity, but I think it contains enough residual ambiguity to tell me you didn't understand my "shared" printer idea completely.

Too bad this question was deep-sixed before we have a real solution that works every time.

Sharing printers is the key to avoiding physical connection issues.
jasimon9Author Commented:
I believe you are still completely missing the point. I believe there is no part of what you are saying that I don't understand. But you don't seem to believe me when I say "control codes don't work in any of the configurations, except the one with the USB port."

You seem to be addressing the the issue of getting printing to work. That is not the problem.

You keep saying "you don't need USB ...."

You are addressing a different problem than I had.

I believe it is the TPVM driver that is filtering out the control codes, and a different port must be used to avoid that driver.

Please do not respond again to this thread, as this is going nowhere.
Here's what I don't understand

1. Why install drivers in the VM when they are automatically installed from the "host" (real) computer assuming it is setup to print to the USB printer and already has drivers for it.

When you install a network printer in a Virtual machine, the drivers are installed for the printer, you don't need to install drivers separately.

2. The Think client has a couple of settings that are changed AFTER you have the network printer installed in the VM. In the Thin Client properties, in "Advanced" you can set the "Driver" to use, and I assume you're using the driver that was loaded during the installation of the printer, which should have been installed as part of the search for network pritners and selecting the one you want from your real computer.

3. Using USB support directly from inside a VM is unreliable.  If your printer on the real computer is hooked to the USB port, and you then try to grab the USB port for your Virtual Machine, this seems to be a good way to screw up the spooling and job management.

USB support in a Virtual Machine connects to the USB says "Connect NEW USB devices to this virtual machine WHEN IT HAS THE FOCUS"

You can avoid the need for USB support in the VM by printing to the thin client ONLY if the thin client is using the right driver. Also, you can leave the thin client's name as "PRINTER" (when you do NET VIEW VM-machine-name it shows "Printer") or you can change the shared name to something more useful, like the model of the printer.

Did you setup the TPVM driver to use the right printer driver? (again, it's a Driver using a Driver, so we're back to multiple meanings for the word Driver).

As I said before, you don't NEED to use USB support in the VM, and in fact, you don't WANT to use USB support for a printer that is actually being used by the mothership machine.

The problem you are having is very likely related to the printer driver being used by the TPVM, and not the TPVM "driver"  itself, or (2) there is a problem in reliable access to the USB port directly, which shouldn't be a problem if you avoid it completely as I suggested. VM support for USB ports is not going to work unless you turn on the printer while the VM has the focus, and typically your printer will already be ON when you run up VMware.

Try solving the problem without going to the USB port from the VM machine, and remove the printer, and reinstall it using the "Add Network Printer" approach after you've shared the printer on your main (real)
"host" computer.

Until you do all these things, you may not be using the right printer driver, or have complete control over the USB port from the VM, or a combination of issues related to trying to force the VM to grab the USB port in a reliable way, which just isn't going to happen no matter how many times you try to make that work.

jasimon9Author Commented:
JT92677: thanks for your comment.

Everything you say is 100% correct and works 100% perfectly -- except for one thing: control codes do not work from DOS.

My solution also works 100% correctly, but has the added benefit that control codes work.

It sounds like you prefer to adopt the "theoretcially" better solution that prevents me from using my mission-critical application.

I am using the correct printer driver for the printer in either case. That is, both the USB port solution and the TPVM port. As I said, I believe the solution is simply avoiding the TPVM port. Any other port would probably work -- just that none of the other ports send anything to the printer attached to the host VM.

I answered your original question which seemed to be an issue using a USB printer from a Virtual machine. I suggested that it doesn't matter how the printer is attached if you share it.

USB support by a VM machine is not reliable since the USB port is no doubt "in use" when you run up the virtual machine, unless the virtual machine has the focus when you turn on  the HP printer. Otherwise, it won't be attached by the VM machine.

If it were me, I'd be inclined to print the HP output to a file, after going through the various drivers, the file can be at the HOST machine level, instead of printing to the USB port, print to a file.

If you then look at what's in file after you send the printer escape codes, you'd see what is actually being received by the printer driver.

It might be something as simple as a print job separator that puts the printer back to some default state so it can handle other print jobs from other sources, and does this before the DOS app prints, but after the ESC codes are sent. The ESC codes may be getting separated from the actual output by a timeout, which is how network printers often separate print jobs.

Whatever, you asked a question, it wasn't clear that I got the idea across that it doesn't matter about being USB or not, then things went downhill from there I guess. You've found another issue that may or may not be related to the VM thin printer driver, and to determine that would require more testing, but I understand that you have to get on with the task at hand.

I appreciate you answering and you can go ahead and close this out, points or no points.

jasimon9Author Commented:
Thanks for your comment.

You do bring to the table some interesting approaches for further troubleshooting.

Unfortunately, the DOS utility that sends the codes cannot be redirected as I have already tried that. I am not sure why it sends what it sends, as it does not seem to send the escape sequences that I would expect. However, those escape sequences that I know "are the right ones" do not work, but what it sends 'which seem wrong" do work. Go figure.

When I do print to a file in the VM I see the proper codes just as I would expect. But they don't work to achieve the desired result when copying to the printer from the DOS command line in the VM.

However, you point out a method I have not yet tried. Namely, print that file to the host and send it to the printer from there. However, I am not sure how to do that from a Mac terminal at this point, as my unix print skills are completely lacking. Maybe lpr or something like that would be the place to start.

I don't believe it is so much USB as much as it is avoiding the default connection, where that default is causing the printer codes not to be interpreted.

In any case, while this application is important, it is only run once a month and will not matter if the USB sharing is not perfect during that single print run.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.