Error starting clipper application when opening file

[ptorres]

Hi ... I'm testing and evaluating vDos for the first time ...

The problem that arises is that when I run a clipper application, when opening the first table (dbf file) it freezes and does nothing else. I know that it is at that moment, because when you open a file, the system displays a text on the screen of the file that is being opened. Then it stays there and I must open the task manager to kill the vDOS process. It is the only way out.

The first thing I did was put the

SET CLIPPER = // F: 200 or
SET CLIPPER = // F: 200 or
SET CLIPPER = F200

And nothing worked for me.

If I run vDOS / log I get the following:

vDos 2019.05.01
0.06 C: => (Local) c: \ vTwo \
D: => (Local) D: \ PRGS \ CLPDBF \
7.31 Execute: S02.EXE
Int 2F unhandled call 1686
Int 21 => 3158: 0968
Int 23 => 3158: 09ba
Int 0 => 299: 00c2
Int 24 => 63b: 03a7
CPU switched to strict memory mode
7.39 Int 23 => 817: 0025
7.42 Int 2F unhandled call 1216
Int 2F unhandled call 1216
Int 2F unhandled call 1216
Int 2F unhandled call 1216
Int 2F unhandled call 1216
. . .

The text "Int 2F unhandled call 1216" goes out indefinitely ... when it takes longer to kill the vDOS task, the larger the log file is ...

my autoexec.txt

@echo OFF
CLS
USE D: D:\PRGS\CLPDBF
D:
CLS
set PATH=C:\;C:\DOS;C:\TEMP
SET PIPEHANDLE=0
Set TEMP=C:\TEMP
Set TMP=C:\TEMP
SET CLIPPER = //F:200

Something I can do to make it work?

[Jos]

Hard to tell, the “CPU switched to strict memory mode” is already somewhat suspicious. vDos trapped your program setting its code or stack segment to the EMS page frame. So vDos switches to a less optimistic (and performing) CPU emulation mode that checks every given code or stack address if in EMS, requiring translation.
Also strange that Int 23 is set twice. Int 2F-1216 (Get address of system file table entry) is internal to DOS, and shouldn’t be called by a program. Certainly no indefinitely if reported the function isn’t supported.
You checked the paths C:\DOS and C:\TEMP exist in vDos?
The /F:200 or F200 option can be useless if the maximum number of file handles is determined at link time. If too low, would cause the Clipper to produce an error, not to stall.

Probably the only way (if at all) to find the problem is you create and submit some minimal vDos environment that replicates the error. So the autoexec.txt, config.txt and other files, the less the better.

Jos