Printing by a DOS application differs completely from Windows printing. vDos should however by default mostly determine correctly how to handle that. So just start with what that will bring.
One major exception will be if you print to an old-style DOS printer. vDos supports that also, but you might consider to switch to Windows printing. So you can use any printer supported by Windows (for instance also PDF).
Keep in mind, the DOS LPT/COM in vDos isn’t that of Windows. With that you were only able to print to actual DOS printers. Even if you convinced Windows to print to an USB or network printer instead.
The printing capabilities/options of vDos are covered by the Printing.pdf document in the vDos folder. Read that when you get to printing from your DOS application.
If printing doesn’t work (as expected): First read the Printing.pdf document. Most questions in the past just came from not reading (anything).
vDos creates two files before the actual printing process starts: #LPTx/#COMx.asc (x being the port number), and a .txt version of that. Those however have no value for vDos itself whatsoever. The .txt version is mostly a means to export (large amounts of) data, to be imported by a Windows program (the DOS ASCII text is translated to Windows Unicode). The .asc version contains the data stream as send by your program to the printer. It is generated to facilitate an eventual third-party DOS-to-Windows print processor, and for debugging purposes.
If you have an issue with printing: Submit a copy of the generated .asc file, so the problem can be investigated (that’s the debugging part).
By default, writing to LPTx/COMx ports (DOS, BIOS or direct hardware) is considered to be a printing task.
If COMx however is supposed to access some serial device; use the COMx = "COMy": directive in config.txt. Mind the trailing colon, it is mandatory. You also have to initialize the COMx port before starting vDos. By the MODE COMx command, or the device manager.
Support of serial devices is basic. To add further support, I would need to have such a port, hardware device, and DOS software using those. I don’t, and gave up communicating with someone who had, and (initially) willing to do some testing. Though that basic support could work, as reported so far.
Documents are more and more stored and sent digitally, instead of printed out on paper. Sending documents to clients by mail, you want those to resemble closely the former printouts on your stationary. vDos’ internal print processor doesn’t support (bitmap) graphics, but that actually is of no concern to produce high quality digital documents.
A digital copy of your stationary, ask your print supplier for the PDF files(s), vector based! Eventually modify those, or even create your own. As I did with PagePlus X8 of Serif; I created InvoiceBack.pdf from scratch as an example.
A virtual PDF printer that creates a PDF file, instead of printing to paper. A freeware PDF printer, capable of merging two PDF files, could do. But for instance novaPDF Professional is more versatile with his profiles, options and different handlings of documents: What stationary to use, how to name, where to store…
I created two files by hand:
InvoiceBack.pdf: The stationary used for invoices.
Invoice.txt: Output of an imaginary DOS invoicing program, just plain ASCII (DOS) text.
The setup in config.txt: LPT1 = sel:"novaPDF 8".
Since there’s no actual invoicing program to print, this was mimicked by COPY INVOICE.TXT LPT1 at the vDos command prompt. The Select Profile dialog of novaPDF pops up (I have several profiles), I chose the temporary test profile “Invoice”. That is setup to merge the printers output with InvoiceBack.pdf to a PDF file with an incrementing number as its name (matching the invoice number), save it to the designated folder for invoices, and open it in the default PDF viewer. The resulting 6067.PDF (you find the link at the Home page) isn’t that bad for a simple test.
Generating PDF’s this way, keep in mind:
Make sure (test one PDF file) the PDF document can actually be printed as expected; PDF version 1.4 gives consistent good results for me. Effective general testing: Print to Microsoft XPS document Writer :).
Consider what actions to allow with the PDF's; you won’t want for instance invoices to be modified. I just set them to print-only.
Spent some initial time on fine-tuning the PDF's, and optimizing the automated document handling.