Network Printing Issue

[karpensteel]

Currently my company runs a DOS program off of a network shared drive. Our 64-bit Windows workstations run virtual XP machines to boot up the DOS program. Printing appears to be handled by .bat files which send text to pre-formatted document templates and then send those documents to a network printer via a c:\windows\system32\cmd /c copy invoice1.doc \\printserver\printer command included at the end of the last .bat file.

With the help of Jos, I have successfully gotten the DOS program to run in vDos. I can run to either from a shortcut to the shared network drive or directly by moving the shortcut .bat file to the vDos folder on my local C drive. Both work correctly.

The problem I have run into is getting the DOS application to print when run within vDos. Executing the print features from within the DOS application does nothing. No files are generated, no prompts appear, and no errors display. The DOS program simply appears to process for a second and then remain on whatever screen it was on prior to the print option being selected.

I have reviewed the Printing PDF as well as the forums.

I've tried mapping the network printer to LPT1 on my local workstation (This is confirmed as active by NET USE) and then added LPT1 = SEL: "\\printserver\printer" to the config.txt.

Currently there are no printers attached to the virtual XP machines so as best I can tell all printing functionality is coming from the DOS program itself and the .bat files it runs. Because of this I thought once I got the application itself running the printing would function as it does through the XP virtual machine since the DOS application would run the same .bat files on vDos as it did on the VMs. This doesn't seem to be the case. Any help would be greatly appreciated.

Please keep in mind the DOS application's printing logic has not been edited in over 10 years, and the developer of it has long since left the company.

 

[Jos]

Your program doesn’t print, instead creates text files, that are processed by batch files.
Perhaps even by calling external DOS or Windows programs. The end result is lastly copied to the network printer by c:\windows\system32\cmd /c …

That doesn’t work in vDos command processor because its (default) C: isn’t Windows C: drive.
You could perhaps do USE C: C:\. But the better alternative is to use the internal vDos CMD command, calling Windows CMD .

So it would become: cmd /c copy invoice.doc \\printserver\printer.
Or cmd HIDE /c copy invoice.doc \\printserver\printer to hide the Windows CMD window.

If you experience trouble with the batch file processing the text files:
Keep in mind vDos filesystem structure doesn’t (have to) match that of Windows. For instance the text files could be stored at some other location.

Jos

[karpensteel]

Thank you for your reply. If I understand correctly, the DOS application on the Virtual XP Machines is running instructions which push data to document templates, then send these populated templates to a printer by executing /c copy invoice1.doc \\printserver\printer via the local Windows CMD prompt. This final part is done by the bolded text in my original post on this thread.

You are saying vDos can execute the same /c copy invoice1.doc \\printserver\printer command via its internal CMD prompt.

To make the above happen I would need to remove c:\windows\system32\ from the .bat file. Correct? My only issue with this is that if the network only has a single instance of the .bat file then the moment I remove the c:\windows\system32\ portion from the file it will prevent the DOS application users on the Virtual XP Machines from printing.

[Jos]

I don’t know what “push data to document templates” involves. But have you tried what removing c:\windows\system32\ brings?
CMD(.EXE) should still be found by the command line processor of the virtual XP machines, not?

Jos

[karpensteel]

You were correct. The XP Virtual Machine continues to print even with the c:\windows\system32\ removed from the .bat file.

I can see that processing print commands through vDos is now updating the templates files because the date and time modified of the file description is changing each time I execute the print function in the DOS application within vDos. However, I'm still not getting anything to print.

At the moment all I have is LPT1 = SEL: "\\printserver\printer" RAW in the config.txt file for vDos.

I have also done a NET USE LPT1 \\printserver\printer on my local workstation.

Is it possible since these .bat files are executed on the server rather than my workstation I need to to a NET USE LPT1 \\printserver\printer on the server where the .bat file is hosted rather than my own workstation?

[Jos]

LPT1 = SEL: "\\printserver\printer" RAW won’t do anything since your programs write to files, instead of printing directly.

NET USE LPT1 \\printserver\printer won’t do anything either, at least not to vDos. LPT/COM ports in vDos don’t go to those of Windows.

Although the batch files reside on the server, they are executed locally.

I suggest you change cmd /c copy… to cmd /k copy… So the new CMD window will be kept open, and you will see what’s going wrong.
Copy can’t find invoice.doc because CMD has an incorrect current directory?

Jos

[karpensteel]

I've been running into a wall with this over the last couple days.

I created a test environment where I can change the batch files without worrying about breaking anything on the live system.

I did change cmd /c copy… to cmd /k copy… So the new CMD window will be kept open, and you will see what’s going wrong. As you instructed, but there is no CMD window appearing.

Currently I open vDos, it open the DOS application, I navigate within the application and "print". The command seems to process for a second and then nothing happens.

Perhaps you can clear something up for me.

My original situation as detailed is a DOS application running in a XP Virtual environment. As you pointed out, the "printing" in this DOS application is actually the creation of text files based on batch file instructions which then are sent to a network printer.

vDos is essentially replacing the XP Virtual environment for the purpose of running the DOS application. Shouldn't all the "printing" still be happening outside vDos? Or is the issue that vDos is initiating commands which can only be executed in a Windows environment?

I believe I'm working with .bat files which are grabbing data from the DOS application, plugging it into multiple document templates, combining these templates into a final document, then sending this document to a network printer. As I've stated, I can see that the final document is being accessed but not making it to the printer. This leads me to believe the core issue is that when it comes time for vDos to execute the command to send the final document to the physical printer it doesn't have an existing connection to it. Do you agree?

I so appreciate your help, and understand you are going above and beyond to help me. Thank you.

[Jos]

If I understand correctly, your program first creates a text file. Then it starts a batch file with commands to convert that text file to the final invoice1.doc. That then is copied to the printer by the last line in the batch file.

If no CMD is shown, that would mean the line cmd /k copy… isn’t reached/executed. Then the question is the batch file at all executed?
You could add a first line with PAUSE to check, you should get “Press any key to continue . . .”. If that appears, move the line downwards to find where the batch file stops.

If you don’t get “Press any key to continue . . .”, the batch file obviously isn’t started/executed.
Start vDos.exe with the log option (….vDos.exe /log), and look in the generated vDos.log file for an error regarding starting the batch file.

DOS applications basically (normally) print to LPT or COM ports/devices. Although you can redirect it by Windows NET USE, that often doesn’t do it.
The physical printer possibly doesn’t support DOS text input, or one wants to use a virtual (PDF) printer. So that’s where LPTx/COMx = in config.txt comes into place.

You could for instance change
cmd /c copy invoice1.doc \\printserver\printer
to:
copy invoice1.doc lpt1

At the XP machines the batch file is already processed by CMD, so cmd /c can be omitted. If LPT1 is redirected by NET USE to \\printserver\printer, the result is the same.

In vDos you would have a line LPT1 = SEL: \\printserver\printer RAW in config.txt (the RAW because vDos shouldn’t interpreter/translate the input). The copy is then vDos own copy (not of CMD).

Perhaps you can post an example of a batch file?

Jos

[karpensteel]

Jos,

I figured out the hang up, and why the printing is not executing within vDos.

There are three variables within the code for printing.

SET V tempri_os_cmd = "c:\windows\system32\cmd"

SET V TempOsCopy = "c:\windows\system32\cmd /c pjlcop.bat "

SET V TemPsPrint = "c:\windows\system32\cmd /c pwin.bat "

So as you thought, there was an error occurring before the print associated .bat files were executed.

The complete picture is then that when the DOS application runs on the XP Virtual Machines it executes these windows cmd prompt related variables without issue since it's in a Windows OS environment. However, when I attempt to print in vDos it process terminates when these variables come up in the code for printing.

I'm wondering if I can do the same thing you suggested previously, which is remove the "c:\windows\system32\ portion from code and let vDos use its internal CMD?

Here is the actual code which appears to be responsible for the printing process.

SET V tempri_os_cmd = "c:\windows\system32\cmd"
SET V TempOsCopy = "c:\windows\system32\cmd /c pjlcop.bat "
SET V TempOsPrint = "c:\windows\system32\cmd /c pwin.bat "

SWITCH .%1

CASE 14
SET V tempri_os = .TempOsCopy + " HEAD1A.doc invoice.doc invoice1.doc"
ZIP &tempri_os
SET V tempri_cmd = .TempOsPrint + " invoice1.doc " + .print_queue_front
zip &tempri_cmd
ERASE invoice1.doc
BREAK

DEFAULT
ENDSW
CLEAR VARIABLES tempri_cmd,tempri_os*, vos, vshell, TempOsCopy, TempOsPrint
RETURN

[Jos]

You can remove the "c:\windows\system32\ portion of all references to cmd (or cmd.exe) because it is in the PATH environment variable of Windows, so that will always be searched for.

But that isn’t really important. The batch file contains several commands not supported by vDos (like the V in SET). So it cannot be executed directly by vDos.

I reckon you cannot change the way the program calls the batch files. And want to still use XP machines alongside.

Instead you could:
1. Change the extension of the batch files to .CMD. For instance A.BAT would become A.CMD.
2. Create new batch files with the .BAT extension, and this single line (A.BAT):
CMD /C A.CMD %1

So that would call the original (now .CMD) batch file by both XP and vDos (but executed by CMD).

Experiment with one (you have a separate running copy). If still troubles, change the CMD /C A.CMD %1 to CMD /K A.CMD %1.

If you don't like the two batch files method, add these lines at the top of the batch files:
if not "%win_vdos%" == "in_vDos" goto XP
cmd /c a.bat
exit
:XP
rem The original lines...

Set win_vdos in autoexec.txt.

I didn’t see the (c:\windows\system32\cmd /c) copy invoice1.doc \\printserver\printer in the batch. That would be in pwin.bat?

Jos