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?
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 withnet 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!
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.
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.
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: