VOGONS


First post, by TBJ

User metadata
Rank Newbie
Rank
Newbie

Hi all,

I am new to C++ coding so please bear with me (lifelong BASIC/VB/.NET developer). I'm trying to modify the DOSBOX source to implement file locking - obviously the trapping of the function is already done in the Int21H handler (function 5c) , I am just trying to make it actually lock the file (I am trying to make an old accounting package run in DOSBOX which requires file locking). Once I've got it all together I will of course post the source, not that there will be much of it.

Basically I am just wondering if anyone can give me any pointers on how, inside the Int21H handler function, I can get the C++ internal file handle for a file so I can call C's Lock() function. I know that I can get the DOS_FILE object corresponding to the open file by doing something like:

Files[RealHandle(Reg_BX)]

I am doing all this from memory so it might not be 100% accurate.

All I need to do is get the C++ file handle to the file so I can lock it. Has anyone got any suggestions?

Cheers and thanks for writing a great piece of software 😁

Reply 1 of 8, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 2 of 8, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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. 😀

Water flows down the stream
How to ask questions the smart way!

Reply 3 of 8, by leecher

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 4 of 8, by leecher

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 5 of 8, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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...

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 6 of 8, by leecher

User metadata
Rank Newbie
Rank
Newbie

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?

Reply 7 of 8, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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...

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 8 of 8, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.