don't expect that to always go right. especially on networked drives with caching and such.
(2 instances using the same files)

Although it could be that your clipper application has no sense of file locking at all. I've debugged 3 different database programs in depth in the past.
2 relied on filelocking (and worked perfectly when implemented) and 1 didn't. That one did some locking itself by keeping some sort of counter inside the database.
I didn't analyse your application on how and if it handles file locks. So it might work, but if I were you I'd do a lot of testing with multiple people changing data at the same time. Running 2 instances on the same computer is not a good test of networked file sharing.

You're right. I should take into consideration your advice about serious testing before apply this solution into production environment.
I have another thought about recompiling this app into native linux executable... I've got Valkyrie. I'm only not sure about a correctness of decompiling process. But I can make a try.

P.S. I think I would note that our girls run the same executable from different PCs from shared Netware volume. If that works with Netware and dos network clients for netware I guess that should work the same with linux NFS-share. At least I hope that is that. Surely, everything will be tested before use in a production.

Surely, everything will be tested before use in a production.

You can't test "everything". dosbox is not intended to run anything besides games so it's fully your responsibility if you use it in a different scenario.

I didn't threw away my responsibility. Saying "everything" mean "the everything in the app I plan to use under dosbox emulation". I didn't meant "the everything in dosbox itself". Sorry for the ambiguity.
Maybe I'll be lucky enough to rebuild it as native linux executable. But, yet only my dreams.

"the everything in the app I plan to use under dosbox emulation"

Good luck with that. Still can't even "test" a fraction of that.

I was mistaken, the app does not run out of handles in MS-DOS 5/6. The default file handle table in the PSP is 20 entries, and trying to specify fewer than 20 in a call INT 21/67 is treated as if 20 was specified. It makes sense because there is no benefit to setting less than 20; the table space in the PSP is reserved.

Easy enough to have DOSBox work more like DOS here, and the app is working with this change:

1 bool DOS_PSP::SetNumFiles(Bit16u fileNum) {
2     if (fileNum>20) {
3         // Allocate needed paragraphs
4         fileNum+=2;    // Add a few more files for safety
5         Bit16u para = (fileNum/16)+((fileNum%16)>0);
6         RealPt data    = RealMake(DOS_GetMemory(para),0);
7         sSave(sPSP,file_table,data);
8         sSave(sPSP,max_files,fileNum);
9         Bit16u i;
10         for (i=0; i<20; i++)        SetFileHandle(i,(Bit8u)sGet(sPSP,files[i]));
11         for (i=20; i<fileNum; i++)    SetFileHandle(i,0xFF);
12-    } else {
13-        sSave(sPSP,max_files,fileNum);
14     };
15     return true;
16 }

Not sure if the devs will care about the issue, as there is no game known to be affected by it, but I have verified the behavior in real DOS:

can an application set it back to 20 as well ?

Yes, and I guess going back to 20 exactly is not allowed for in the change.

Furthermore, DOSBox does not currently try to do everything DOS does with INT 21/67. From the RBIL:

If BX <= 20, no action is taken if the handle limit has not yet been increased, and the table is copied back into the PSP if the limit is currently > 20 handles.

AFAICT, DOSBox always allocates more memory, so there is no behavior of copying back into the PSP when reducing to <= 20. There is also no freeing of previous blocks, so you could run out of memory eventually if the handle count is changed multiple times; but most apps are only going to set it once.

I wasn't going to suggest overhauling the function to behave exactly like DOS in all respects when it's probably good enough for most cases, but the 20 minimum is very simple to implement.

maybe a

1else if(current_max_files >20) {
2sSave..

Would solve this specific case and behave identical for the other case (although the behaviour there is indeed pretty wrong)

Or just a:

1if (fileNum<20) fileNum=20;

at the top of the function. Whoa, just like DOS. 😉

that stays the closest to our current approach, so I'll commit that.

Hi
I keep getting the "too many files open" error when I try to run my program in DOSBOX. I cannot find where in the DOSBOX config to change the to files=200 instead of the default 127 (this is what I read that Dosbox uses). I see in this post that someone was able to change it to 250 and I was wondering if someone could tell me where to put that in the config.
Please help, with having to take all of my xp machines off of my network, I am at a loss for getting this program to work.

You are replying to a thread from almost two years ago.

I believe the change you are looking for is available in the SVN Daum build of DOSBox.