Dynamic LPT mapping

[jcat]

Scenario: We have several custom DOS applications (written in Clipper) that are programmed to print to LPT1 and LPT2 through the normal user workflows. A DOS-based menu application is used to present the different applications to the user and when an application is chosen it executes a batch script to dynamically map the LPT ports to printers in the Windows domain (using NET USE). This worked very smoothly under NTVDM though I don't know how this ever worked in the days before Windows but they were using Netware at that time so maybe it had some sort of server-side support for redirecting the print output.

My attempt to reproduce this setup with vDos has fallen short because config.txt statically maps the ports. I thought I could work around this with

LPT1 = "LPT1":
LPT2 = "LPT2":

and then I have vDos execute a batch script in the Windows environment (using CMD "program" HIDE) to execute the NET USE commands. In theory this should work. But the problem is that vDos keeps throwing "https://vdos.proboards.com/post/1442 (2)". In a prior post it was said that you shouldn't try to bind the ports this way, but it didn't explain the reason (vDos will claim the device exclusively, but why is that a problem if nothing else is using the port?).

It's also not obvious why this binding fails. On the assumption that the problem is that the port isn't bound to anything when starting vDos, I created a Dummy printer (in Windows) assigned to LPT1 and I get the same error. If I delete the printer and I run NET USE LPT1 /DELETE, I still get the error.

Assuming this approach of dynamic printer switching is not technically possible, do you have any recommendation for how to handle this gracefully? The only solution I can think of is to eliminate the menu application and replace it with multiple vDOS configs (one per program with statically mapped printers) and a shortcut icon to the correct vDos launcher. I'd rather not ask the users to pick the printer from the Windows pop-up because that will be error prone (printing the form to the wrong printer) and it's not something they've ever needed to worry about.

[Jos]

I was unaware of this issue assigning a DOS device to a non-physical Windows device. Tried NET USE LPT1 \\server\share beforehand, that gave the same error.
vDos uses the standard CreateFile API function for that. The (2) is the error code Windows returns: The system cannot find the file specified.
And MS does not document CreateFile is limited to physical devices. So it seems you cannot use this option at all for non-physical devices.

Besides the device being opened exclusively, it is limited to printers supporting DOS text input.
And every single byte sent generates a WriteFile API call, opposed to being cached internally by the standard printer assignments.

So it also seems you would need separate directories with config.txt and autoexec.txt files. And eventually also put the shortcut in there.

Jos

[martin]

Possible solution, if you really don't want to create multiple vdos configs: Print via a Windows-batch-File, defined in the CONFIG.TXT-printer settings, e.g. PRINTME.bat. Create different batch-files for your printers using the Windows PRINT command (@print /D:"WindowsPrinterName" #lpt1.asc) and copy the required batchfile to PRINTME.bat. Should only work, if you can send raw data to your printers and if only one of your programs run at the same time.

HTH

Martin

P.S. The other "solution" I posted before doesn't work, so I edited the post.