In overall no; a DOS application will need a minimum amount of memory to run. Mostly, extra memory beyond this will be unused, can even have a negative performance effect. For instance FoxProX will first ‘format’ all XMS memory that has been made available by XMEM=. If it only needs 3 MB, while 63 MB is set by XMEM=, it will still initialize those extra 60 MB of memory. FoxProX won’t run any faster, but will take much longer to start.
Why support 63 MB of XMS/EMS memory, while for instance 4 MB was already considered a luxury when DOS programs were developed? Simply because 63 MB plus 1 MB conventional memory = 64 MB. In the past vDos made sure a program didn’t read/write beyond the set memory. An absolute maximum of 64 MB provided for some speed gain with these constant tests. For some time vDos is more optimistic with that, and leaves it to Windows to catch eventual memory violations. The next vDos version will probably only allow for more realistic XMEM settings; a far lower maximum than 63 MB.
One exception to this rule could be an editor, handling a multi megabyte file. It could run slower if that file doesn’t fit in the available memory.
If you want to use a Windows environment variable (for example, %systemroot% or %homedrive%) in vDos you must first explicitly declare it, either in autoexec.txt, in another batch file, or at the command line. The Windows variable must be surrounded by two percent signs on each side: set vdosvar=%%windowsvar%%
For example, before you can use %systemroot% in vDos, you must first declare it: set systemroot=%%systemroot%%
You can then use %systemroot% in vDos in place of the system drive.
At startup, two Windows variables are already set to DOS variables:
WIN_USERNAME: The Windows user name (%USERNAME%)
WIN_VDOS: The VDOS variable if set in Windows (%VDOS%), the command line parameters of vDos.exe, or “not_set” if both are missing.
The vDos specific CMD command is linked to Windows command processor (CMD). It can be used at the vDos command line, or from within a program by: CMD ["program"] [WAIT][HIDE] command line
"program": If supplied, the quotes are mandatory.
WAIT: Wait for the program or command processor to exit.
HIDE: Start the program or command processor minimized.
command line: Passed on to the program or command processor.
Eventual paths in command line (as in “program”) are those of Windows.
The optional WAIT and HIDE have to be in capitals. Mind, WAIT in combination with the Windows command processor has a major limitation: If that executes a command or program, it will exit immediately. While for instance the external program could still be running. An exit code will then merely indicate if the program could be started.
You can also call a Windows program from within a DOS program, without the use of the Windows command processor: program [WAIT][HIDE] command line
Here program is a DOS reference with its limitations like 8.3 file names. Essentially vDos will determine what it is supposed to be: A DOS or Windows program. And will start that inside the virtual PC (DOS program), or in a new window (Windows program). Program can for instance even be a document, to be opened by the associated Windows program.
Note: Some DOS programs don’t execute program directly, but call the DOS command processor (command.com) to do that.
In autoexec.txt you could have something like: USE F: \\server\DOS\
Great, you already used the direct UNC path, instead of mapping a Windows drive letter to it, and then refer to that drive letter. Can we even do without any (Windows) path at all?
Sure, when vDos is started, the Windows work directory for this vDos instance is set to the folder vDos.exe is started from. If vDos.exe would be located in \\server\DOS, that will become the Windows work directory. A relative path works equally well for the USE command. So we can also do: USE F: .\
Or if we would create a separate vDos folder (\\server\DOS\vDos): USE F: ..\
What will a portable DOS application eventually bring?
First, if you can get to (start) vDos.exe, your application will run. No matter from where it is started, or its location (local, network, RDP, VPN, in the cloud…).
Second, you can relocate the application without any modification needed. Or create a copy of it on another location, for testing, backup…
Here is a beginner's guide to building a copy of vDos from the sources. There is only one reason to do this: If you want to make your own copy of vDos that includes changes in the source code. This procedure was tested under Windows 8.1, but should work with any recent Windows version.
This assumes a basic understanding of Windows software (for example, you should know how to open .7z archives). You will be able to do very little with the source code unless you know something about C/C++, but you may be able to make some useful changes with very little knowledge.
If you have any questions about these instructions, you should be able to figure out the answers for yourself by experimenting or by searching the internet.
Request the vDos source code; start by visiting this page.
Use a standard archive manager (e.g. 7zFM.exe) to extract the vDos folder from the vDosSources.7z archive to any convenient place on your system (such as your desktop).
Download the free Visual Studio Community Edition from the Download link on this page.
Run the downloaded installation program, and proceed as follows.
Check the box where you agree to the license terms; click Next.
Remove the checkmarks from everything on the list of “Optional features to install”; click Install and proceed through the installation. At the end, do not click “Launch" but simply close the installation program.
In the vDos folder that you extracted to your disk in step 2, open the visualc_net folder and double-click on vDos.sln.
When Visual Studio opens, you can sign in with a Microsoft account if you want, or you can ignore the sign-in option.
Visual Studio will offer to upgrade the VC++ Compiler and Libraries. Click OK.
In the Solution Explorer on the left you will see vDos in bold. Right-click on it, and choose Build from the pop-up menu, and wait while the project builds.
When the Output window shows “Build: 1 succeeded…”, go back to the vDos folder and go to the vDos\bin folder. You will find the copy of vDos.exe that you built.
You may now experiment with the vDos source code and rebuild vDos to experiment with the results of your changes.
You may close Microsoft Visual Studio after building vDos.