DOS2USB literally means "From DOS to USB".
USB ports are widely used nowadays in modern computers to connect all kind of equipments, like webcams, mouses, memories and printers, but in the DOS age USB ports still weren't invented at all.
Today there are still a lot of old good DOS programs perfectly working on modern Windows computers, but they simply cannot directly access USB devices for the reason above.
In reality Windows allows DOS programs accessing USB drives and dongles because the OS "maps" them with a disk drive letter (like F:) so that DOS can read files on those devices without even knowing at all they're located on a USB device; the main problem is to access USB PRINTERS.
You can need to transform DOS to USB (DOS 2 USB) in a rapid and complete way.
We can see the problem as a dual one:
1) DOS cannot access USB ports directly: a DOS program most of the times prints to an LPT port (a parallel port: 99% of times it's LPT1:) and sometimes to a COM port (a serial port, like COM1:).
2) Printer's technology has changed over time to reduce costs, so most of the USB printers nowadays aren't DOS-compatible.
1) Redirecting data sent to a LPT port to an USB one
To solve this problem Windows provides a "NET USE" command that makes use of the Microsoft Networking Services to redirect data from an LPT port to a network-shared printer (that could even be an USB printer). Its syntax is:
NET USE LPTx: \\computer\printer
LPTx is the port to redirect (LPT1:, LPT2:, LPT3:)
\\computer\printer is the printer's shared name in the network (yes, you need to have the Windows Networking Services up and running to have this working, even though it does seem to be a different need)
This method does have some downsides however:
a) the need for having a network correctly setup and a printer shared on the network, that most often means giving full Administrator rights to the Windows user running the DOS program just for that purpose (a security lack)
b) it does not work reliably, especially of newest Windows systems (where security for Standard, 'non-Administrator', users has been enhanced a lot)
c) the printer addressed that way still needs to be DOS-compatible (even if it can be connected to an USB port)
For these reasons our Printfil software provides a better way to redirect a LPT port to a Windows printer, without using the Microsoft networking Services, but capturing the data directly at the NT-Kernel level.
This way you don't need neither to perform additional unnecessary network configurations, nor to grant Administrator rights to Standard Windows users and open security holes that way.
You just need to:
a) Install the free Printfil trial version you can find at http://www.printfil.com/download
b) During the "Guided Configuration" that starts as soon as you've installed it, select the LPT port to capture (usually LPT1:) and the destination printer you want to drive (your USB printer, that's already installed in the Windows Control Panel)
During this phase, if you'll instruct Printfil to drive that printer in RAW mode, data will be sent transparently from the LPT1: port to the printer itself, like you would be really in DOS, without being modified at all by the Windows printer driver and the Windows Printing System (so, for example, DOT matrix printers are very fast printing, like in DOS, and not so slow as they are when printing a Windows document, like a Ms-Word one for example)
The printer itself however in this case still needs to be DOS-compatible (the 'downside c)' above), but if you've a cheaper GDI (AKA Windows-Only) USB printer, Printfil still offers a solution for you; please see the next section.
Most of the USB printers nowadays aren't DOS-compatible
As we told you above, a DOS program simply sends a data flow to an LPT port, expecting a real printer is connected there.
ALL the printers at that time did have some embedded fonts and a "hardware logic" to render that data flow to something readable (characters, words, phrases, and "special effects" like Bold, Underline, Condensed, Enhanced and so on)
Windows does use a different printing technique named GDI (Graphics Device Interface - http://en.wikipedia.org/wiki/Graphics_Device_Interface)
Basically a Windows program creates something like an "image" of the page by using the Windows fonts and others graphic primitives; the page is then sent to the printer all-in-once through the Windows printer driver, so that the printer itself "prints the page/image" without having to render the data itself on paper (the expensive embedded fonts and hardware logic is substituted by the cheaper software printer driver)
So, most of the printers nowadays are GDI-only (especially the cheapest models) so, even though you can use a "trick" to send DOS data to their USB ports, they simply "print nothing" because they lack of the necessary hardware logic to "understand" the data flow they receive.
Printfil comes in help even to solve this problem. In addition to capture the data from the choosen LPT port as described in the section above, if you'll setup it to print in GDI mode (rather than RAW as described above), it can convert that data into the "image" the GDI printer wants, and then send the resulting GDI print job to the destination printer through the Windows printer driver.
So, in order to reliably print from DOS to a Windows printer you just have to setup Printfil to capture a LPT port (from LPT1: to LPT9:) and forward it to the choosen destination Windows printer:
1) In RAW mode if the printer itself is RAW compatible and you want it printing just like you were used to do it in DOS
2) In GDI mode if the printer is GDI only or if you want to enhance the DOS printing experience (for example by previewing the job first, or by adding graphical background images without having to modify the source DOS program: please refer to the Printfil manual for further info about these enhancements)