That basically already exists when you use a debug-enabled build. The debug window log then shows all attempts to open files (and quite a bit more beside that).

Thanks for the quick reply. There are no binary debug builds available for windows right? 😕

I don't think there is an "official" 0.73 debug-enabled build, but the 0.72 one is available right here and will do what you want.

I got it and it does tell me the file in question is being opened! Thank you!

This happend to me in several games, so far, booting MS-DOS in DOSBox was a good workaround that always worked.

This happend to me in several games

*This* being what exactly?

Probably this one

> It seems the file FILES.DAT which contains the player/save data is never being updated.

As h-a-l-9000 said, "This" refers to DOSBox' shell not being able to write to certain files.

I don't know of any such problem, if a file is read-only you'll get an error
message in the console log and for everything else please post on the forum
(game details etc.)

Well, I don't really have a problem with anything... I was just trying to help the OP.

But if you are referring to his problem then you can find a shareware version of the game if you google "Champions of Zulula - Elite Edition". You can see that the file he's talking about, FILES.DAT, is not set as read-only/hidden/system (or any other attributes besides Archive) and still DOSBox doesn't write to it and gives no error, not ingame or by the console (or at least I think so... I don't know this game).

Indeed he should be using msdos then.

The OP is actually the author of these games. He's being told by users that they don't function properly under DOSBox. Cause to investigate, I suppose. (/me fires up his debugger).

Og wrote:

This happend to me in several games, so far, booting MS-DOS in DOSBox was a good workaround that always worked.

Og i think you should tell us names of all these games if you still remember them just for us to know. If someone will encounter problems with these games he/we will already know the problem by searching the forum.

Cause to investigate, I suppose.

reading from a file opened in write-only mode.

do we or did ms dos forgive that ?

In localDrive::FileOpen, there is a line:

1case OPEN_WRITE:type="rb+"; break;

so read operations succeed.

1case OPEN_WRITE:type="wb"; break;

makes the game work. No idea if that is proper DOS behaviour, but it would match the behaviour of the flags, of course.

do we or did ms dos forgive that ?

dos doesn't allow it (we can check against flags in localFiles).

makes the game work. No idea if that is proper DOS behaviour, but it would match the behaviour of the flags, of course.

Doesn't really work because our read() doesn't check for error codes.
It just "fixes" overwriting the memory. Still that may be useful in addition.

think we should do both. so we can return an errorcode as well if the flags don't include reading