|
Post by jace on Nov 7, 2019 16:54:42 GMT 1
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.
Any ideas as to why I get these errors?
Thanks,
-Jace
Attachments:
|
|
|
Post by Jos on Nov 7, 2019 19:11:51 GMT 1
"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…
Jos
|
|
|
Post by jace on Nov 12, 2019 14:43:03 GMT 1
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.
-Jace
|
|
|
Post by Jos on Nov 12, 2019 15:35:11 GMT 1
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.
Jos
|
|
|
Post by jace on Nov 12, 2019 17:01:02 GMT 1
Not sure what Clipper is, but using that setting in my autoexec file didn't help, so I'm assuming it's not Clipper-compiled.
Can you point me to some information about how to setup/use the Morehand utility?
-Jace
|
|
|
Post by Jos on Nov 12, 2019 17:29:43 GMT 1
Starting MOREHAND w/o parameters, you'll get:
This program is used by putting the command MOREHAND in front of the program you wish to run. MoreHand uses about 9k of ram and unloads. itself when the program terminates.
Example: MOREHAND <program> <tail>
Jos
|
|
|
Post by Jos on Nov 12, 2019 18:25:13 GMT 1
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.
Jos
|
|
|
Post by jace on Nov 12, 2019 18:50:45 GMT 1
Thanks. Still getting the same error.
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.
-Jace
|
|
|
Post by Jos on Nov 12, 2019 19:15:23 GMT 1
Then just print to a COM port?
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…
Jos
|
|
|
Post by jace on Nov 12, 2019 19:47:07 GMT 1
"Then just print to COM port?"
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!
-Jace
|
|
|
Post by Jos on Nov 12, 2019 19:54:56 GMT 1
You can setup COM1 through COM9 in config.txt, each with a different Windows printer. No idea how the Windows command prompt would get involved, you mean the Printer Selection Dialog?
Jos
|
|
|
Post by jace on Nov 12, 2019 22:37:44 GMT 1
My program only has COM1 and LPT1-3. Yeah, Printer Select Dialog is what I meant.
|
|
|
Post by Jos on Nov 12, 2019 22:52:05 GMT 1
Strange your program only offers COM1, while COM1-4 (apposed to LPT1-3) are common to DOS programs. Though mostly given by (incorrect) assumptions, using DOS, any x (1-9) in COMx or LPTx would do.
Can’t help you with that behavior of your DOS program since it only occurs with real data.
Jos
|
|