Fix issues 3535 (dosbox-x hang on zip-mounted drives) and 3347 (minor bug fix and related) #3678
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…of MEM_BlockWrite, and one path does not call the MEM_BlockWrite at all.
… zip-mounted drive
|
FYI: Unfortunately, functionality of #3347 is broken now. |
leecher1337
added a commit
to leecher1337/dosbox-x
that referenced
this pull request
Oct 9, 2022
…g breaking changes to get joncampbell123#3447 working again (MEM_BlockWrite MUSTN'T be called on ext device, otherwise it overwrites buffer which causes malfunction)
leecher1337
added a commit
to leecher1337/dosbox-x
that referenced
this pull request
Oct 9, 2022
…g breaking changes to get joncampbell123#3347 working again (MEM_BlockWrite MUSTN'T be called on ext device, otherwise it overwrites buffer which causes malfunction)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add a summary of the change(s) brought by this PR here.
What issue(s) does this PR address?
This PR proposes a fix for issue #3535 and some code fixes/cleanup for the merged #3347.
Longer explanation
I was trying to work with a ZIP file mounted as drive in read-only, with an overlay mount on top for changes. In order to collect the contents of the ZIP, I first used a regular folder mount as drive, testing all the programs inside of the drive, and making sure everything worked (which was the case). However, putting the same contents in a ZIP file (and mounting as described) makes dosbox-x crash with a "ERROR CPU:Illegal Unhandled Interrupt Called 6" when running the same content (DOS programs that worked fine under a regular folder mount).
Even a simple "edit bla.txt" produces the same hang of dosbox-x (when bla.txt is in a ZIP mounted drive).
I saw that #3535 described this problem, and the comments say that the temporary solution is to revert #3347 and rebuild. Digging deeper into this, I think I found two bugs:
In the code that was merged by Dosdev #3347, there seems to be a mistake in the 0x3f code (DOS File read). This code now calls MEM_BlockRead instead of MEM_BlockWrite in one of the possible paths (actually in the added path for DOS file I/O device drivers). And, in certain true conditions MEM_BlockWrite is not called at all. To me, it seems to be a minor mistake. So, this PR fixes this and cleans up the code a little bit.
The issue described in Mount zip file doesn't work since version 0.83.23 ? #3535 seems to be caused by the PhysFS code that sets the EXT_DEVICE_BIT (0x200) on the file handle objects for files in a ZIP (when doing open or create file). I believe this bit should NOT be set, as the files are just regular DOS files (not special device files). This bit causes the Dosdev #3347 code to think it needs the file I/O device driver path to be called when instead it's just reading or writing regular files.
Disclaimer
Now, I'm not (yet) familiar with the inner workings of dosbox and dosbox-x, so it's perfectly possible that this PR is completely wrong. If that is the case, then my apologies and just reject the PR (maybe let me know why). At least, for me it seems this PR solves the issue in #3535.
Does this PR introduce any breaking change(s)?
I hope not. Please review.