Existing exe files that make calls to ms-dos (COM) programs

[ba]

Is it possible to set vDOS in a way where any MS-DOS (COM) programs that are called automatically run through vDOS emulation?

My company has several nested exe and bat files that run several different MS-DOS programs at various points in a batch process.  Is there a way to force these COM files to be run through vDOS without individual, implicit-calls being setup in the autoexec.txt?

[Jos]

If programs or batch files run in vDos, further called programs or batch files will also be executed by vDos. Only exception would be calling a Windows executable.

If you however mean Windows programs or batch files calling a DOS program, then Windows 64-bit will throw the error it can’t run that. Just like starting a DOS program directly.

Parameters to vDos.exe are stored in the WIN_VDOS DOS environment variable. But you don’t mean that?

Jos

[ba]

Thank you for the response, Jos. It sounds like I'd need to modify the code and recompile each exe (see below).

I was thinking more about this last night. Tell me if this is possible, if I'm overthinking this, or if this is even possible. I'll create new BAT files with the same name as the COM files (ie, a.COM = a.BAT). I'll then change all of the DOS (COM) calls in the code to call the new BAT files. In the newly created BAT files, I'll create a call to vDOS with a parameter to call the appropriate COM file. vDOS then runs the appropriate COM file, based on the parameter passed-in from the BAT file.

So, in my mind it would look like this:
programA.EXE calls a.BAT -> a.BAT calls vDOS with parameter pointing to a.COM -> vDOS runs a.COM (16-bit)
programB.EXE calls b.BAT -> b.BAT calls vDOS with parameter pointing to b.COM -> vDOS runs b.COM (16-bit)
etc...

If this is possible, can autoexec.txt handle a parameter (similar to autoexec.bat)?

[Jos]

If I understand correctly, programA etc. are Windows executables calling DOS programs.
That works in Windows 32-bit since NTVDM is integrated. And you cannot compile programA etc. as DOS programs.

Creating corresponding BAT (or CMD since it’s Windows) files seems then a logical solution.
When you start vDos with some parameter, let’s say A (vDos.exe A), then the DOS environment variable WIN_VDOS is set to A.
So the command %WIN_VDOS%.com in autoexec.txt is replaced by A.com.

Or you could do with one generic BAT/CMD file. Called as for instance to_vDos A, that contains vDos.exe %1. Or perhaps precede all ?.COM calls by to_vDos<space>?

An alternative method to pass on parameters is to use/set Windows environment variables. For instance Windows progname=A would be available at the vDos command line as %%progname%%.

Jos

[ba]

Thanks again for the response. NTVDM is not available, and my apologies for not giving you all of the details. Basically, we're having to move from 2003 32-bit to 2019 64-bit.

As it turns out, the programs that are calling these 16-bit programs are batch files, so I am able to modify the program call and pass in the DOS program as a variable to vDos, which so far has seemed to work very well.

We have several batch files that call these DOS programs and the DOS programs all over the place. For simplicity and to avoid confusion for other Engineers at my company, I'd like to keep vDos (along with one set of config.txt and autoexec.txt) in the c:\vDos file. I've already set a 'Path' environment variable for vDos.exe, but is there a way to tell vDos to always look for autoexec.txt in the c:\vDos folder (only) and not in the location where from where it is called? Would that be a setting in config.txt? I'm trying to avoid leaving autoexec.txt files all over, as many of these batch files are calling DOS programs in mapped and local drives/folders on the server.

Thank you!

[Jos]

vDos will at startup parse the config.txt and autoexec.txt files in the Windows current work directory (CWD).

Double click vDos.exe in some directory, Windows will set that as CWD.
Start a program in a batch file, no change of CWD unless a previous CD is given.
Start a shortcut, its Start in directory (default that of the program) will become CWD.

To work with a PATH, C:\vDos, the config.txt and autoexec.txt file there, your would have to create a shortcut to vDos.exe in that directory. And call vDos.lnk instead of vDos.exe.

But isn’t more simple and less confusing to create (a second?) vDos directory on the server, and set PATH to that? Instead of having numerous copies of vDos around.
Eventually setting vDos C: to Windows local C:.

Jos

[ba]

"Start a program in a batch file, no change of CWD unless a previous CD is given". This is the problem I'm running into... The CWD could be in several places throughout these batch files, as it constantly changes drives and directories.

I can get around this by:

--A)-- Changing the CWD
c: (may or may not be needed)
cd \vDos
vDos [programToRun]

I'm ok with this, and I could even CD back to where we were, in the case where the previous path is required for existing, subsequent code.

--OR--

--B)-- As you said, since I've already setup PATH, I could just drop the vDos shortcut in the CWD.

Really, I was just try to "perfect" this solution to our needs. Overall, it seems to be working well so far in our testing.

Thanks again for your assistance!

[Jos]

Although you should get it working in vDos, the main pickle will be the heritage of a rather complex system.
Once DOS based, then came a probably Q&D conversion to Windows 32-bit/NTVDM, making it even more complex.
If your starting point would be the original DOS based one, it would be more simple.
Now you probably end up with a second Q&D conversion…

Jos

[ba]

Agreed. We're in the process of modernizing this system, so we just need it to work (as it did on the 2003 Server). We hope to be fully migrated sometime in the next few months. I did opt for option 'B' (from my last post), as it will be more seamless and will not affect the subsequent code. Now it's just a matter of finding all of the DOS program calls, modifying the calls to vDos [programName], find and drop a vDos shortcut into the CWD, and test.

Have a great weekend!