5

I have a DOS application(running on Terminal Services, Win Server 2008 Standard 6.06002 SP2). I need to print to my shared printer on my computer. net use lpt2: \\mycomputer\myprn. When I "copy file.txt lpt2", it works flawlessly. When my application prints, it shows printer is not found. The DOS application points to lpt2 and using hppcl. I was able to print to my own printer when the DOS application resided on my machine(Win7x32). Any clues?

simon tan
  • 59
  • 4

4 Answers4

4

Dude, I'm sorry. Been there, done that.

Does the printer show up when you do a net use?

I was able to get the horrible 16 bit DOS program in the student lab to print with net use lpt2 \\servername\printer. I've also gotten a horrible program that didn't accept jetdirect/TCPIP printer ports but did accept network shares to print by sharing the printer as \\127.0.0.1\printername$ and printing to that. In other words: Make sure that the printer actually shows up with net use, make sure that the local printer is shared (to your local user only, unless you really want to share it beyond the scope of your horrible 16 bit program, and if you name it with a $ it will be hidden), and use \\127.0.0.1 as the server if you have to.

Good luck!

Katherine Villyard
  • 18,510
  • 4
  • 36
  • 59
  • Yes, printer shows up in "net use". My next step is to create a TCPIP printer pointing to a network printer, share, and test. Will see how that works. – simon tan Dec 24 '14 at 22:28
4

Too many people confuse a "character" or "console" mode application for "DOS". If you have a "DOS" application running on Server 2008R2, what you probably have is a 32 bit character application.

Had it been a 16 bit DOS application you would not be able to run it on Server2008R2 which is 64 bit and the only thing it knows what to do with 16 bit applications is throw an error.

Now if this application is attempting to use 16 bit printing routines, the bad news is that it won't work, at least not while the application is running on Server 2008R2.

dimitri.p
  • 653
  • 3
  • 8
  • I may have been wrong about the OS Version. It is 32bit Server 2008 Standard 6.06002 SP2 – simon tan Dec 26 '14 at 17:16
  • How about "copy file.txt \\mycomputer\myprn"? There is a good chance you'll get an error that will point you to the right direction towards a solution. – dimitri.p Dec 27 '14 at 08:50
3

I actually have a similar setup because of certain manufacturing software...

The usual culprit is that the applications expects the printer to be on the local computer's list. The other culprit is that the application expects the printer to be a very specific name or else it won't find it. Without knowing the software it's hard to say exactly what the problem is, but I would start by adding the shared printer to your TS server and naming it exactly how it is on your local machine - then try printing using the lpt port setup.

Nathan C
  • 14,901
  • 4
  • 42
  • 62
  • I know the problem is definitely the application because I can "copy file.txt lpt2" and it prints. I don't know enough about the application or how it knows there is no printer at that port. The application is smart enough to allow me to change hppcl to generic text or even to save the file to disk, so it is a good program; just the environment has changed. – simon tan Dec 24 '14 at 23:25
0

I can suggest an alternative that we use for printing from a widely-used 16-bit DOS program at my company: A.N.D. Technologies free DOSPrint application has worked perfectly for us over the last ten years. While closed source, it's only 63KB, runs as a system-wide service or per-user tray app, redirects the LPT stream from the DOS subsystem to any Windows print queue including shared printers, and has a liberal license ("free for general use without restriction"). Check their Downloads/Free Software link.

Another option — if you have any programming experience — is to write your own trivial LPT-to-whatever redirector. In .NET, you'll use P/Invoke calls to QueryDosDevice and DefineDosDevice to redirect an LPT from any DOS app to a file or named pipe:

<DllImport("kernel.dll", CharSet:=CharSet.Unicode, entrypoint:="DefineDosDeviceW")>
Public Shared Function DefineDosDevice(ByVal dwFlags As UInt32, ByVal lpDeviceName As String, ByVal lpTargetPath As String) As Boolean
End Function
STATComm
  • 1