Clipper: Maximum number of windows search handles exceeded

[epatrick]

Hello,

I have a Clipper program from those days... (compiled either with Clipper 5.2 or 5.2e) which runs well on vDos - but after running some time and having performed several operations i reach to windows error:

[Maximum number of windows search handles exceeded]

After this vDos [2020.03.01] crashes.

In another run instance I got:

[Windows search handle table corrupt.]

The clipper program of course opens and closes various db files during its operations... This error never appeared in pure DOS or some other emulators.

This has been also set:

SET CLIPPER=F200

Any ideas/clues where to look? 

Thank you

Patrick

[Jos]

Both error messages are generated by vDos itself, and it has to exit since these are unrecoverable conditions.

To clarify: The DOS API has a FindFirst function to look for some file, returning a result code. Accompanied by FindNext to look for further files matching the file specification given to the FindFirst call. Windows provides for a FindFirstFile function, returning a search handle. To be used in eventual subsequent FindNextFile calls and to be closed when the search handle is no longer needed.

You might conclude the DOS API is limited to one concurrent search operation since it doesn’t use search handles. But the FindNext function relies on the contents of the Disk Transfer Area block for subsequent search results. And a DOS program can either set/change the address of the DTA, or manipulate (copy/restore) its contents directly. Your Clipper programs would do that.

DOS FindFirst translates to Windows FindFirstFile with a search handle. First vDos has to figure out what Windows search handle matches a DOS FindNext, maintaining a translation table. Furthermore it has to decide when to close a Windows search handle. The translation table only holds 256 entries and when a Windows search handle is active for a directory, strange things can happen. You could delete a file in there, so can’t open it anymore, but neither create a new file with that name since Windows will return it already exists (a ghost file).

For instance DOSBox doesn’t have to deal with this complexity because it creates a directory list with the FindFirst call and uses that for subsequent FindNext calls. Somewhat like original DOS with FAT file entry numbers in the DTA. Disadvantage, this method relies on static directory listings.

I noticed a potential bug in maintaining the translation table after vDos 2020.03.01 was released. Could be the cause of your issue. Will send you a corrected version by wetransfer. You are the first to report this, so just check if the issue is fixed.

Jos

[epatrick]

Thanks for the quick response.

I have tried the new version - still getting this:

[Jos]

As I already told you by e-mail: I would need a copy of your program to replicate and investigate why this happens.
Else you have to wait until someone else encounters the same problem.
Clipper (and its libraries) compiled programs are notorious to do things in a non-standard (even sometimes buggy) way.

Jos

[Jos]

Solved: The program used FILE(Name + '*.DBF') to check for the presence of files (Name.DBF).
The extra accidental wildcard * resulted in an open Windows search handle to provide for a continued search operation.
That didn’t happen, while Clipper ad-hoc creation of a DTA memory block on its stack for a next file check/search prevented detection of reusing a DTA block due to the random data in it.
After 256 of such ‘file searches’, the limit of vDos open DTA-to-Windows search handle table was reached.
The solution was of course to remove that unwanted *.

Jos