First, you are not talking about it affecting the global directory listing capability (of DOSBox itself). You are talking about it affecting some feature of some specific application that uses who knows what algorithm to do what it does. This is a big difference.

For this and other purposes, DOSBox's developers always refer you to a disclaimer that DOSBox is officially designed to support games only, not any other kind of application. That applications may work without issues or with just minor glitches (and most of them do) is a reasonable side effect, but it's not guaranteed.

Generally, a lot of weird things happen when cycles=max is used. Some games have random glitches which disappear when a fixed number of cycles is used (even a high one). Others have issues if the number of cycles is too high, requiring you to set it lower. The glitches can be in any aspect - graphics, audio, controls, and from your example - file I/O as well. 😀

It is a weird problem. Not sure why that would happen.

dr_st wrote:

First, you are not talking about it affecting the global directory listing capability (of DOSBox itself). You are talking about it affecting some feature of some specific application that uses who knows what algorithm to do what it does. This is a big difference.

For this and other purposes, DOSBox's developers always refer you to a disclaimer that DOSBox is officially designed to support games only, not any other kind of application. That applications may work without issues or with just minor glitches (and most of them do) is a reasonable side effect, but it's not guaranteed.)

As you saw, my initial message made extremely clear (or at least I thought it made it clear) that my question (1) referred only to the directory listing created inside an application, not the listing at the DOSBox command prompt, and (2) had nothing to do with games. I'm always grateful for a reply in this forum, so thank you for those two paragraphs; they say exactly what I said in my original post, but it's always good to emphasize these things, in case someone didn't notice the identical points in that first post.

I'm also grateful for the warning about cycles=max. It's possible that I read a warning on the forum about cycles=max a long time ago, but, if so, obviously I had forgotten it. I only narrowed the problem down to this line by commenting out one line at a time from my conf file until I found the one that caused the problem.

and does it happen with all cores and machine types?

Dominus wrote:

and does it happen with all cores and machine types?

I tried all the core= settings and the results didn't change.

I didn't try all the machine types, but I tried four or five, and again the results didn't change.

I also tried a few cputype= settings, again with no effect on the results.

One odd thing: I sometimes - only sometimes - get randomly inconsistent results with the same settings, so that instead of 32 files being displayed in the WordPerfect List Files screen, sometimes 44 or 54 files will be listed. This happens perhaps once in every ten tries. But I never get the full list of 136 files when I have cycles=max in the conf file.

And the DOSBox command prompt always shows the correct number, which is 136.

And commenting out "cycles=" fixes the problem entirely.

EDIT: Also, the problem goes away when I set cycles=max 40% (but it's still there at max 45%).

try figuring out the limit amount of cycles before the bug happens

(max 100% limit 100000)
or something similar. Exact syntax in the options/preferences file.

Qbix wrote:

try figuring out the limit amount of cycles before the bug happens

(max 100% limit 100000)
or something similar. Exact syntax in the options/preferences file.

This is a MacBook Air with a 2.2 GHz i7 processor.

With this line, the problem does NOT occur:

cycles=max limit 8100

With this line the problem occurs but only truncates one file from the list:

cycles=max limit 8200

With 8300 the list is more truncated. Anything above 9000 causes at most 32 files to be displayed in the list.

EDIT: 8176 seems to be upper limit before the bug appears. It's not absolutely consistent; WPDOS seems to cache a directory file, so I have to run it twice before getting consistent results, but 8176 seems right.

and what about cycles= fixed 9000 (so no max limit), but a fixed cycles count that is higher than were the bug happens.

Basically the same result

cycles=fixed 8177 is OK

cycles=fixed 8178 produces the bug

Though again, as I move up or down, I often have to run the test twice before the results are consistent.

Is it significant that this number is very close to 1024*8 ??

EDIT: At 9000, around 45 files out of the full 136 are listed; at 10000, 27 files, and it doesn't go below that.

The main significance is that max cycles on itself doesn't matter. It is the cyclecount being high that gives the problem, although 8000 isn't really that high.
It is hard to tell what is going on. Especially as you claim that happens only on the Mac. You'd have to use the debugger and see if the findfirst results are different are if something else is going on. The things that can be done at this stage without debugging (and having access to the problem files) is limited.

And since you are building yourself sometimes, is it with lock stock Dosbox 0.74-1, or my SVN built or any other built by you?

Dominus wrote:

And since you are building yourself sometimes, is it with lock stock Dosbox 0.74-1, or my SVN built or any other built by you?

Apologies for wasting everybody's time: The problem occurs with my own customized build, not with the build that I make with pure SVN using the OneStopDOSBox script that I put together with the help of Dominus. I really do apologize for not doing this elementary test from the very start.

I suspect that the problem is that I haven't incorporated all the latest SVN fixes. I'll put together a diff of my code and SVN and try to narrow down where my code goes wrong. I'm really puzzled by this, because my changes only involve things like video modes, text display, and a few fixes that experts on this board suggested to me in order to get around various WordPerfect problems in the past.

Again, my apologies for time-wasting. I'm slapping my forehead in embarrassment at this.

EDIT: And it's a problem that I introduced sometime between August 2016 (when I built code that works) and February 2017... Strange!

happens 😀
I should have thought of asking you right away...
Just another proof that anything but lock stock Dosbox can introduce problems that are so low level that you cannot find them right away 😀

Dominus wrote:

happens 😀
I should have thought of asking you right away...
Just another proof that anything but lock stock Dosbox can introduce problems that are so low level that you cannot find them right away 😀

A lesson learned! The background of this is that I decided a few months ago to use the code in my Windows-based project for my OS X builds. The trouble was that my Windows code is filled with all kinds of extra stuff that got added over the years, and it works on Windows, but caused this problem in OS X. So I've gone back to my earlier OS X code, which was very close to SVN, and everything works correctly.

Apologies again for wasting everyone's time with something I should have sorted out for myself. (And thanks again to Dominus who taught me how to build standalone DOSBox under OS X in the first place...)