Clipper and VB file integration exception

[Menen]

Hi,

I´m trying to run a network shared Clipper application with the latest vDos version (16 may 2021) on Windows 7 and 10, both x64.

In general, it goes well but there is a part not working of our Clipper app that comuniates some Visual Basic apps to get some data from MDB files. The Visual Basic apps generates .txt files with the requested info for Clipper app to read them, almost always getting an exception.

Shown exception is:
_



Generated log file: vDos.log (1.15 KB)

Thanks and best regards

[Jos]

Hard to tell what is causing this, essentially IRET got into an incorrect address.
The Visual Basic apps are DOS programs?
Do you have a SET CLIPPER=, if so, what is it?

Jos

[Menen]

The original Clipper app running on Windows XP had configured environment variable CLIPPER=F200;SWAPPATH:'C:\TMP';TEMPPATH:'C:\TMP';R50.
I have tried with "set CLIPPER=F200;SWAPPATH:'C:\TMP';TEMPPATH:'C:\TMP';R50" in autoexec.txt file just before launching the Clipper exe but not working. Also tried with diferent number of files (F param) and E0 but no way. Perhaps CLIPPER variable is hardcoded (I have no access to the Clipper app source code).

These Visual Basic apps are Windows programs.

Another strange event ocurrs when application crashes. Everytime the app crashes lets a 512KB file without extension on the same location the Clipper executable file is located.

Thanks

[Jos]

The Clipper settings could indeed be hardcoded into the program. But then why CLIPPER= in Windows XP.

You could try if adding ;NOIDLE;E2048 to SET CLIPPER=…. will help.

That 512KB file would imply some Clipper swap or temporary file, but that then shouldn’t in the program directory.

One more problem, though not related to the crash: Clipper starts external programs by delegating that to the command processor. A second COMMAND.COM instance in vDos only requires a copy of the environment variable table, a PSP and some 32 bytes, totaling less than 1KB. vDos then starts the Windows VB program, however it doesn’t wait for the VB program to finish. That would require the WAIT option, but you can’t change the command line used by the Clipper program. That would explain the “FindFirst failed: X:\bbb\eee\fff\TXTFILE1.TXT(18)” while that file would be created (by VBAPP1.EXE ?) at a later moment. And probably neither available to VBAPP2.EXE.

Strange the timestamp of the two lines:
11.65 FindFirst failed: X:\bbb\eee\fff\TXTFILE1.TXT(18)
11.00 Execute: C:\COMMAND.COM(/c X:\bbb\eee\fff\VBAPP2.EXE Param
Logging is strictly sequential, so that 11.00 doesn’t make sense.

Jos

[Menen]

I also thought Clipper app on vDos runs faster than on XP so asynchronous call to VB app make the generated file still not present when Clipper app try to get it.

Maybe CLIPPER variable in Windows XP for other Clipper app, there are at least 7 Clipper apps, no idea.

Probed with NOIDLE;E2048 added to set CLIPPER= getting same error.

New log file attached, perhaps in the previous log where two users accesing at same time?

vDos.log (1.15 KB)

Thanks

[Jos]

If two users start vDos with logging, the later one would override the first. Will remain a mystery.

Might seem strange, what if you add SET COMSPEC=12345.COM to autoexec.txt.
If the Clipper app doesn’t test if 12345.COM is present, no VB app is started, the same error or not?

Jos

[Menen]

Adding SET COMSPEC=12345.COM to autoexec.txt gets exception type 13 instead of 0.



As you said it seems VB apps are not executed but Clipper app keeps trying to access the .txt file.

vDos.log (1.11 KB)


Have done a test creating the two .txt files by me before launching the app and runs ok. Is there anyway for vDos to run slowler?

Thanks

[Jos]

That’s rather unexpected. 12345.COM isn’t executed, so the DOS API call returns a fail result immediately.
W/o setting up internal things like a copy of the environment variables table, PSP segment, interrupt vectors, a stack. That what might explain why Clipper encounters an exception.

Clipper now tests for TXTFILE1.TXT after VBAPP1.EXE failed to run. Still tries to run VBAPP2.EXE and doesn’t test for TXTFILE2.TXT anymore after that.
Some weird logic going on?
And no explanation for the exception, the presence or absence of the text files shouldn’t cause that.

Slowing down vDos won’t help. The VB apps take an unpredictable and relatively long (CPU) time to execute.
I could send you a vDos.exe that will wait until Windows (the VB) apps finish.
Though no real idea if that cures the exception, though it is at least needed for the text files to be created for Clipper to see them.

Jos

[Menen]

If it's not too much trouble for you to prepare this vDos.exe and send it to me, for me it's ok. I would test it and would tell you the result.

Thanks

[Menen]

Hi Jos,

Tested it and, as you said from the begining, same exception is shown (IRET: Illegal description type 0) although seems to be no problem reading the txt files (FindFirst failed: error doesn't appear anymore in the log file): vDos.log (1.09 KB) 

Thank you anyway

[Jos]

My guess would be it is caused by the Clipper program creating and later on reading back in the swap file. Assuming your test with existing TXT files let the program not execute the VB apps.
Perhaps creating the swap file the second time with VBAPP2 goes wrong. I’ll add logging of failed create and open file operations to the next vDos version.

Strange that “Record locking verified for DOS P:” line in the log file. There’s no DOS P: at that moment.

Jos

[Menen]

Ignore it, this is “Record locking verified for DOS X:”. Don't know how the P: is there. I will accidentally have changed it.