dBase or Clipper application fails under vDos but runs under

[michel]

Hello,

Due to the breakdown of an old PC running Windows XT, I had to migrate a DOS accounting application (CUBIC for dos, from Exact Software) to a PC running Windows 10 64 bits.

This application developed under DBase may have been migrated to Clipper 20-25 years ago, but I don't remember.
First, I found vDosPlus and the application runs without any problem (subject to more complete testing).
Since I don't need the vDosPlus additions and it is no longer supported, I test vDos and I encounter a problem.

The application starts but does not work and closes, returning the message "Bad command or file name" 5 times and finally the message "No users left", indicating that it was unable to read the users' file.

As this is a commercial application, I have no technical information.

So, to summarize:
- vDos 2023.05.01 (or vDosPlus, version 2015.11.01, build 2017.03.15)
- basic autoexec with REM in front of call dptest
- copy of the CUBIC directory to c:\vdos\ (or to c:\vDosPlus\)

- > cd cubic , then

- >CUBIC command, with or without command line parameters, to start the application.

Do you have any idea or suggestion why an exactly identical procedure (with the same directory) works under vDosPlus and fails under vDos ?

Thanks in advance

[Jos]

Start vDos with the logging option (….\vDos.exe /log) and have a look at the generated vDos.log file.
Cubic would try to execute a DOS command or program not provided by vDos.
Perhaps a command of 4DOS that was once incorporated in vDos/vDosPlus?

Jos

[michel]

Thanks for replying

Actions :
c:\>cd cubic
c:\cubic>cubic 1

The logfile does not give any useful information.
As follow :
vDos 2023.05.01
CodePage: 850
C: => (Local) C:\vDos\
44.17 vDos ended by EXIT (0)

As a check of my test, DPTEST give this, after cd dptest, dpstart and aborting (F7)
vDos 2023.05.01
CodePage: 850
C: => (Local) C:\vDos\

208.50 LOADEXEC: DP26YI.EXE /s
208.89 Delayed, directly set:
INT 1B => 2962:0004
209.49 FINDFIRST failed: DP{S2251.TMP(18)
OPENFILE failed: DPTEST\DP{S2251.TMP(2) => C:\vDos\DPTEST\DP{S2251.TMP(2)
FINDFIRST failed: DP{T2251.TMP(18)
OPENFILE failed: DPTEST\DP{T2251.TMP(2) => C:\vDos\DPTEST\DP{T2251.TMP(2)
FINDFIRST failed: DP{I2251.TMP(18)
OPENFILE failed: DPTEST\DP{I2251.TMP(2) => C:\vDos\DPTEST\DP{I2251.TMP(2)
215.78 Record locking verified for DOS C:
232.23 Delayed, directly set:
INT 1B => original
238.16 vDos ended by EXIT (0)


Any idea ?

Michel

[Jos]

If you start vDos with the logging option and then cubic, the vDos.log will at least have an entry “LOADEXEC: cubic.EXE 1”. Like that with DPTEST, and other entries.

Jos

[michel]

it was so unexpected and that's the reason why I checked with DPTEST.

So I did the test again and CUBIC does not leave any trace...!?

[Jos]

If there is no “LOADEXEC: cubic.EXE 1” entry in vDos.log cubic isn't LOADed nor EXECuted in that vDos session.
Logging is a function of vDos, not cubic.

Jos