It Still Pays To Be “DOS Old School” in a Windows World

Recently, at work, I was recently made aware of a problem that also brought back an old pet-peeve of mine. In 2010, I still cannot believe people actually SELL products that were primarily designed for DOS. Very irritating! It’s even more frustrating to talk to some of these people when you have support issues.

Thankfully, there are some issues that can be “bridged” by eliminating the need call to support. One of those is when that pre-historic application needs to exist in a networked environment and has to print.

You’ll typically find that many in the IT world, who are relatively new, don’t realize you can sort of “fool” these old applications. Many old DOS applications print to LPT ports. A simple trick combines this knowledge with some good ol’ command line knowledge. You can accomplish the following steps through any means necessary (batch file, vbscript, and even PowerShell). But, I’ll illustrate it “the old school way” using a batch file.

REM batch file calling application
DOSAPP.EXE

If we’re on a network and local printers aren’t used, the trick is to “capture” an LPT port to a network printer. This can be done within the batch file that calls the app. The LPT port should be captured prior to calling the exe.

REM batch file calling application
REM First, capture LPT1 to a network printer, then call the application
NET USE LPT1: \\SERVER\PRINTER1 /PERSISTENT:NO
DOSAPP.EXE

NET USEwith /PERSISTENT:NO tells Windows NOT to capture the port in a persistent manner. This ensures that we are only capturing the port “as needed” (when the application is run via the batch script. Don’t run your batch file just yet…

We’re only half done! We’ve captured the printer port, but nothing is connected to that port. We’ll need to install a printer and connect it to the captured LPT port in order to print.

Many old DOS apps heavily rely on simple printer drivers. The rule of thumb is to select a “neutral” driver such as the Microsoft Windows provided “HP LaserJet III” driver. If you are printing postscript, then select a similar “neutral” driver. I have always used the “HP LaserJet III” driver because it won’t require me to provide vendor media or Windows installation media. It also supports the standard PCL language and rarely presents any conflicts for older DOS applications.

So, from “Add Printer” in Windows, the procedure is to 1) a printer, 2) select local port and choose LPT1. When asked for a driver, select “HP LaserJet III.” Don’t do a test print at this point. After the print driver is installed and is associated to LPT1 in windows, then run your batch file.

Voila. You’ve successfully made someone in your company happy and are helping to support a dinosaur application that needed to print on your network.

Now, is it absolutely necessary to install a print driver? Not in every situation. If the application is simply printing ASCII text, probably not. If the application needs the driver layer (for whatever reason) then yes. You can test either way. There will be some old applications which require either PCL or PS drivers installed. You’ll just have to test your app both ways. Simplicity is the way to go. If your tests determine you don’t need the drivers, don’t install them.

Advertisements