dBase 5 application and problems batchfiles and extern CMD.E

[herman]

Hello Jos,



Here are my comments about Version 2019.05.01



The external I / O traffic called from my dBase application (s) to the built-in CMD commands

no longer work in Version 2019.05.01.

These do work in Version 2018.05.01.

For that, I had to make minor adjustments at the time and do everything I expect there.



NTVDM assignments were previously not equally possible with assignments in vDos.

Because NTVDM is still among them.

The NTVDM commands (what you would expect for compatibility reasons with DOS applications) do not work either.



Error messages with a started CMD from dBase:

The system cannot find the specified path

Does C:\VDHTMXML\aw specify a file name

or directory name on the target

(F = file, D = directory)?



I conclude from this that the path cannot be reached.



Furthermore why should I not be able to use USE C: C: \ anymore?



This version is certainly not faster than the previous one for the things that do work for me.

This is in any case the I / O traffic to the hard disk.



Regards Herman

[Jos]

Paths given as parameters to Windows programs like CMD are of course Windows paths, not those of vDos.

One can still do USE C: C:\, but advised not to, since that exposes the whole Windows filesystem to the Dos program.

2019.05.01 is faster than 2018.05.01, but if you test with massive disk i/o, that will still be the bottleneck and so largely dictate the programs speed.

Jos

[herman]

It looks like, but I can no longer check that Windows (10) had to restart after the first new installation of vDos (?).
I received an error message with USE C: C:\ when I did that for the first time, as it was used for version 2018.
Unfortunately, I can no longer trace that message.
Now that is all going well. With the physical C-drive I can reach the CMD.EXE
I continue to observe that the interpetation after the CMD prompt is not yet complete as it is achieved in NTVDM i.v.m. the compatibility.
I do understand the differences, but it seems to me (if I could and should do that) this must also be compatible, as it always worked (in NTVDM).

With the speed (I am now sitting with 2 PCs next to each other and I see that vDos 2018 and 2019 continue to run virtually the same with records counting with read out - and replace in fields.
Honesty area not exact equal hardware configuration.
I think that is a great pity, especially since there is now much more process power in disk I/O.

For the time to come I will really have to keep working in Windows 10 32 bits and Hyper V for our non-commercial association all the more because we need reports and results quickly.
For us, vDos does not yet seem to be a solution for that.

Regards Herman

[herman]

Sorry for my bad English and I make the mistake not Windows 10 32 bits but Windows 10 x64 and Hyper V I use.

Regards Herman

[Jos]

vDos is a fully portable application. It could also come as a zip file instead of an installation package. But the first has some drawbacks, not at least that Windows won’t trust the unzipped vDos.exe because it’s not installed regularly.

Seems to me that CMD is CMD, called by NTVDM or vDos.

If the Windows/Hyper-V combo is real faster with disk i/o, I suspect it’s the same as with Windows/VMware: Extensive cashing of local virtual drives.

For the rest: An emulated CPU (core) will always be slower than the real thing. Only exception with DataPerfect programs, but then for a large part the emulated CPU isn’t used to run the program. Instead DP pseudo code is executed directly.

Jos

[herman]

I am still aware of the problem, but I will certainly find out.
Quite a lot of external CMD orders are sent from the dBase application.
CMD messages such as: The system cannot find the specified path
is sometimes a tricky one, but is always caused by a previous starting position and will come back to that later.

From C: it works as you would expect from vDos (with USE C: C: \).
But if the C is the vDos folder with the application placed there in a subfolder, then it goes wrong.

Regards Herman

[Jos]

If you modify a DOS application to the extend it won’t run anymore in DOS, depends on NTVDM, you have to do some rethinking about running it in vDos.
vDos is first for running ‘original’ DOS applications, somewhat out-of-the-box. That of course contradicts NTVDM-only applications.

Jos