We have an old DOS-based print queuing program that we need to port to Windows. The conversion is necessary because we have a very large DOS based business application that must work under Windows 2000 or XP. The business application prints directly to LPT1, LPT2, or LPT3, and unfortunately we cannot convert it to use windows printing because it is too large to rewrite and incorporates too many 16 bit libraries to convert. By itself, the business application works except it prints directly to printers mapped to LPT1/2/3 since the queuing program we use is not W2K compliant. The queuing program would normally capture the data bound for these printer ports so that we can print them from other locations, write them to files, put online, etc. The problem is that we don’t know how to intercept files bound for the standard printer ports. For example, if we were to type: echo Hello > lpt1 at a command prompt in Windows 2000, we’d want the new queuing application to intercept this stream so that we print the statement on any HP printer we want later (our business application only uses HP PCL when printing to a printer port). Same thing if we do an fprintf to the printer port from the business application. Is there an easy way to do this?

I'm trying to follow what your saying and hope I'm on the same track... Would something like this work for you? I know when you install Adobe Acrobat you can get a "software printer". That when you send it to print, you can pick acrobat format, it converts your text to PDF as if it's printing on a real printer. You then end up with a PDF document. I wonder if it would be possible to setup this software printer under lpt1 so that the program you're using would think it's printing to a real printer, but WinXP and Acrobat would be making a PDF instead, then you could do whatever you want with the text in PDF, use it for internet, print to other printers in XP. If Acrobat is not an option I would assume some other software close to this would do the same thing. As I said, I hope I followed your post. If this isn't what you want please let me know and I'll try again. lol. TK.

I don't believe ntldr based systems will allow you to make the hardware calls you are trying to do with the 16bit system. You have to print to the windows minidriver system. I can tell you right now as a CIO and the guy that does the software/hardware purchases that your product wouldn't even be considered if printing isn't done via the Windows print system. It simply isn't worth the problems associated with what you are considering. You are also way behind the market which is already moving onto the 64bit system. My advice is consider a complete rewrite/port to a 32bit/64bit system. After all what is the point of going from 16bit to almost 32bit if no one will buy your product because they can't even buy a 32bit server system anymore. Give a person a fish, they eat for a day. Suggest they internet search and they learn a skill for a lifetime.

NT based O/Ses do not allow direct port access from the software period. Also most DOS Based software will not run under NTVDM. If you run the software under W98SE you may have more joy as it is MS-DOS with a GUI. Here is an article on why NTVDM is not MS-DOS: http://www.windowsitlibrary.com/Content/226/03/toc.html Her is an article regards printing to Windows printers from Word Perfect for DOS and if you have the time I am sure you can adapt: http://www.columbia.edu/~em36/wpdos/index.html#anyprinter

Lastly if you do adapt your software will it also run under NT6 (aka Vista) ?

If I understand you correctly, the problem can be solved quite simply. I am a LAN Admin and we, too, use an old DOS-based app that prints to LPT1 only. Here's what we do. Right click your printer and select Sharing. Enter a shared name, and remember it. At a command prompt, type: net use lpt1: \\computername\sharedprinter /persistent:yes That will capture the output to lpt1 and send it to the shared printer. To "undo" the command, at a command prompt, type: net use lpt1: /delete Kevin