Printing in Console application the DOS way

I am maintaining a very old DOS code. I have translated the code so that it now can also be compiled using VC using console mode. i.e. now it can be compiled to DOS and to WinXP both.

Initially it worked all right. But later when printing is needed (which is seldom used) the code found to be limited to LPT1 / LPT2 due to its DOS origin. LPTn was opened using "fopen" and written to using "fprintf".

Now parallel printers are nowhere to be seen, in fact we have a PC with no parallel port at all. Now I am at a loss to find a way to use non-LPT printers with minimal changes to code (it is a large code, despite the fact that printing is seldom used).

Ideally the new feature should not disturb the old DOS code. That is, old style fopen/fprintf should (as far as possible) remain intact.

Any help / pointer in this regard will be much appreciated.

Kamran
Islamabad, Pakistan

Windows is not DOS, and a Windows 32/64 bit console program is not DOS. Just because you compiled OK means nothing if the methods of communicating with external devices are radically different.

There is a standard way of printing in Windows -- open a device context to the printer and draw the text to it. Then you can print to any printer connected in any way to the system, whether it's LPT1, USB, network, etc.

Quote:

---

Ideally the new feature should not disturb the old DOS code. That is, old style fopen/fprintf should (as far as possible) remain intact.

---

So you or someone else took the responsibility of porting a program from one OS to another, and no changes are to be expected? That is the nature of the beast -- if you port a program, expect to make changes to the program, especially things such as communicating with printers.

Regards,

Paul McKenzie

Paul is right, yet I still use fprintf and write dos stuff . This is how I do it.

I use fprintf a usually pointing to Lpt1 , Lpt2, ... etc.

You have to share the printer and map LPT1, LPT2, etc to the shared printer. Let me know if you need more details.

I have a 16 bit dos app running on windows 7: that customer has an LPT1 installed, so I didn't have to rewrite code or map printer to LPT1. Customers w/o LPTx ports installed I just map port.

So there are two ways to get your existing code to work.


Regards, ADSOFT (please rate if helpfull)

Thanks ADSOFT I will definitely look in to this port-sharing stuff, it seems helpful.

And thanks Paul. You are absolutely right that no one should expect "no-changes" while porting to Windows.

But I left the details out of my original post. I "do" have many changes, but I tried to encapsulate all those changes in a seperate file which is compiled alongwith original files for WIN32 configuration.

These set of functions/variables try to mimic the original functions of DOS-origin using Windows' Console-Mode functions/handles/structures. So I have all usual screen/keyboard handling functions (e.g. clear-screen, move cursor, color different part of text-screen, peek a character in keyboard buffer and many more)

So basically what I need is not a simple solution, but a method which can encapsulate the nitty-gritty of Windows print-handling.

Off-course still my old-code contains "#ifdef WIN32" etc. to cater for things which cannot be encapsulated easily.

Thanking you again for your time.

Kamran
Islamabad, Pakistan.

It shouldn't be too hard to create a Winfprintf function that opens a spool if one is not open, prints a line of text and brings down the carriage for the next fprintf. I was going to, and still might write one.

I too like the simplicity of just using fprintf to send out a line of text.

I just might post some code that would do a lineprinter emulation in Win32 code. You have to have three (3) commands. 1) OpenPrinter(Port or Printer name);
2) Winfprintf();
3) PrintAndClosePrinter

I do a lot of dos printing stuff. And believe it or not, I still do DOS 16 apps as well as Win32 & MFC

if all else fails...
instead of opening "LPT1:" open a file, create the output as a file. then print the file to the default windows printer.
you can even do this automatically from the console application with ShellExecute, with the "print" verb.

Thanks OReubens, it seems a good last-resort option. More so because that code also prints to file.

And thanks to ADSOFT too. I will try to come-up with some implementation of Winfprintf, but if I get something from you without any hassle that would be nice :)

OReubens,

writing to a file is a Great suggestion, but printf will still not open up the default printer in a Win32 environment see. http://forums.anandtech.com/showthread.php?t=812272

However I believe that wordpad, edit, notepad has a command switch that will print automatically. In some of my win32 apps I write to a file and open the file with wordpad/notepad to grant me manual Edit/Print capabilities.


http://www.robvanderwoude.com/comman...es.php#Notepad

Quote:

---

Open a text file in Notepad:

notepad.exe TextFileNameForce Notepad to open a text file as ASCII text:

notepad.exe /A TextFileNamePrint a text file with Notepad (default printer):

notepad.exe /P TextFileNameTested in Microsoft Windows XP Professional SP2 (5.1.2600)

---

notepad.exe /P TextFileNameTested in Microsoft Windows XP Professional SP2 (5.1.2600)


so the above command via Shellexecute might do the trick

it's hard to answer posts with this new forum software. I like the other one better, anyhow.

If your doing printing alignment, it might be tough since you can't set the font size. However there might be a way with a different editing software.

Also, notepad/wordpad/msword will act a a preview before printing,something you don't get in DOS.

BTW notepad /A might be a better choice, sorry still getting used to the new forum software.

the notepad thing works, but I did actually mean it the way I said it.

ShellExecute the .txt file with the "print" verb instead of "open". This will make windows select the default program for .txt files (usually notepad, but it may have been set to somethign else), then print it with that program.