Maybe look at something like DOS_ReadFile() in dos_files.cpp for an example of making sure the handle is valid and so forth. DOSBox uses methods on the file[handle] object for things like reading, writing, and seeking, because there are different drive types (local files, image, etc.) but you might get away with a hack that assumes local file access if you don't want to go so far as making a lock/unlock method for all drive types.

you might be able to get a C FILE* pointer, but no C++ file stuff.

I wrote file locking a while ago. but it only worked with programs written in BASIC. not sure which version.
It even worked with sharing files between multiple computers with partial and full locks.
Nice stuff to play around with, but not needed for games. 😀

I implemented a very simple locking patch.
Please note that it's not thouroughly tested and I just made it to get my DOS-Application to run, but it should basically work.
It's available at http://dose.0wnz.at/dosbox/
The locking.patch contains the patch (patch -p1 <locking.patch in your source directory).
I also made a precompiled dosbox.exe available which includes the patch, however this is a compiled version of dosbox-MB5 (http://home.arcor.de/h-a-l-9000/mb4.html).

Regards,
l.

I just updated the patch a bit. It now only works for WIN32, but I saw that it had some problems with locking requests for Offsets >2GB. This seems to be the case with Microsoft Excel 5.0 for Windows 3.11 for example.
Now it works correctly. I also added that the SHARE.EXE installation check returns "installed" for applications that are checking for the presence of SHARE.EXE.
If you already downloaded the patch, please download it again.

Now it works correctly. I also added that the SHARE.EXE installation check returns "installed" for applications that are checking for the presence of SHARE.EXE.

IMO this is highly critical. Since it will now only report that Share.exe is installed but the functionality of share (be it share.exe for Dos or vshare.386 for Windows 3.x) is not working correctly. If you make use of OLE (or whatever it is called) in Windows Word, Excel, other Office software this can result in data loss. Disregard this if you have the functionality of share working in your patch...

I wouldn't call this highly critical, because the file locking functions (0x5C/Int 21h) actually work like they are supposed to.

Altough it's true, that I haven't implemented the 0x5D-class of DOS 3.1+ internal functions yet, they are still to be considered as "internal", therefore I guess they shouldn't be used by real applications (they aren't even mentioned in PC Intern 4). They aren't supported under DR-DOS either, for example, so I don't think that many apps will use them.

Another reason why I don't consider this critical, is, that many apps don't even do a SHARE.EXE installation check and instead just try if the function calls succeeds. But for apps refusing to run without share.exe, pretending that it is installed is required for them to run and as file locking is implemented, the most important function of SHARE.EXE is working.

Maybe I should let the user decide what to reply on installation check via a configuration variable in dosbox.conf?

yeah, as I wrote if your patch fixes some of the share.exe woes on Dosbox (I presume file locking is one of them) then disregard my opinion 😀

I wouldn't make it a dosbox.conf option, imo dosbox.conf settings aren't supposed to be that much specific for issues. OTOH since the patch hasn't got much chance to get accepted into mainstream SVN (judging by the no-games-need-it policy) you can do that...

they are still to be considered as "internal"

Yes even list of lists is internal, and you wouldn't want to know how much direct dos internal interfacing win3x does.