I am trying to get printing to work in a specific program I am using in vDos. I have had some success with leaving the COM1 selection blank in the config file and using the Windows printer selection prompt, but I would also like to be able to map some of the LPT ports to specific printers. I have run into two issues:
When I try to use the config.txt setting to map an LPT port straight to the Windows LPT port I get an error saying (for example) "Can't Link DOS LPT3 to Windows LPT3 (error: 2)" My related config setting is: LPT3 = "LPT3":
I have also tried simply mapping the vDos LPT port to the correct printer with: LPT2 = SEL:"\\<servername>\<printername>" Which allows me to run vDos, but when I run my specific program I get an error from the program itself saying: "Too many files open when trying to print. ... Increase the number of files in the FILES = statement in your CONFIG.SYS file." Reading the vDos documentation, the FILES setting seems to be set to the maximum, and is unchangable.
"Can't Link DOS LPT3 to Windows LPT3 (error: 2)" simply means there’s no LPT3 device in Windows. But you also don’t want to use the LPTx="LPTy": construction for printing, vDos will claim the LPTy device exclusively.
If no LPT2= setting worked by presenting the Windows printer selection dialog, there’s no reason why your program would behave differently. It has no sense there will be a (Windows) selection dialog later on. Rem-out the LPT2= line, test your program again with printing to LPT2. Write down the printer you selected and specify that in SEL:. Though I’m afraid you changed something else in your program…
Yeah, I realized later why my first method wouldn't work.
No matter what I put in for LPT2= line (including rem-ing it out entirely), I always get the same error about "Too many files open when trying to print." You're right, the program shouldn't have any idea about what's going to happen to the print output, but for some reason, it never even gets that far. Why would it think there are "too many files open"?
If I try to print to COM1, it works, and I get the Windows printer setup. If I try any LPT port, I get the error.
The only cause I come up with is: When your program prints to a COM port, it uses BIOS calls to print (no file handle involved). For printing to a LPT port, it would however use DOS calls. The LPT port then has to be opened (or created), a file handle returned by DOS, but there are no unused file handle entries left in the PSP. Although vDos provides for the maximum of 255 DOS global file handles, a DOS program starts off with a maximum of 20 local file handles. If it needs more, it explicitly has to call DOS function 67h to increase that number by copying the PSP file table to another location.
If it is a Clipper compiled program, you could have to set the DOS environment variable Clipper. For instance: SET CLIPPER=F128. Else you could try the MOREHAND utility.
BTW, if you can use COMx instead of LPTx in your program, that is also an alternative. The left side of LPTx/COMx=<Windows printer> is of little importance. The only difference will be you can’t use the TIO:0 option to speed up the printer starting to print. Since your program doesn’t close the COMx device, vDos can only rely on timeouts to determine a print job ended.
I was able to set up a test environment that includs vDos and my program (with none of my actual data), and in that environment I do not get the error. So it appears something about my live environment is either *actually* using too many files (not sure that's possible?), or making my program *think* it's using too many files. My program does not complain when printing to LPT ports while running natively on a 32-bit OS.
A program can of course try to open more files (default 20, minus some reserved) than DOS accommodates for that program. But MOREHAND raises that number of available file handles to 99, so the "Too many files open when trying to print." seems just misleading. No idea why that would be related to data being present or not. A DOS program basically can’t inquire the number of available file handles. It would have to dive into the internal list-of-list structure of DOS. And why would it do that, DOS will return an error when a program tries to open or create a file and no file handles are available…
Yeah, that seems to be the only way to go. I was hoping to be able to set up individual printers to avoid the latency involved with selecting through the Windows prompt, but it appears unavoidable in my case.
Not sure what's actually happening in my program to cause that error, but thank you for your help and support!