First post, by Kronuz
- Rank
- Member
I modified DOSBox so that it can unmount CD images. I also fixed some bugs on my way. Here's the patch.
Please let me know how it goes for you.
Kronuz
"Time is of the essence"
I modified DOSBox so that it can unmount CD images. I also fixed some bugs on my way. Here's the patch.
Please let me know how it goes for you.
Kronuz
"Time is of the essence"
Tested with your patch. It works here.
It still has a bug, as you know CD-ROM drives must be one after the other, right now you can't mount drives that break the order, however right now you can still unmount drives in the middle; in other words, you can always unmount images.
Other bug I missed in the first patch is, when you unmount cdrom drives that were mounted from a directory (not an iso file) the drive letter is not freed. I already fixed that, I'll attach a patch.
* Uploaded a small fix in this patch
Kronuz
"Time is of the essence"
Okay, this is an step closer to a full unmount.
I've added a couple things to fix the bug that let unmounting cdrom drives between two other cdroms (breaking the chain of cd drives) this should no longer be a problem.
CD Images Unmount has become CD Unmount (full support) and it's quickly morphing to * Unmount 😀
Here's the fixed patch.
* Sorry the patch had a bug it and was corrupt, I've fixed it now (I think)
** I have added a PhysFS friendly version of the patch 😀
For this friendly version, apply the PhysFS first (you can still use this same patch without the PhysFS installed (if you don't want to use PhysFS, just skip the 'drive_physfs.cpp' file patch, ignoring 3 of 3 hunks and also ignore the 2 of 8 hunks FAILED message on file 'drives.h'.)
Kronuz
"Time is of the essence"
does that make sense to mount a directory with -ioctl?
Ah, that's my mistake. 😀
attached a different screenshot...
Hmm.. true, and this is really weird as I don't recall touching anything that might have broken that... I'll have to check 😜
Kronuz
"Time is of the essence"
I now know where the problem is... I suppose it's a small design fault in MSCDEX_AddDrive() it returns an errorcode, the errorcode it's 0 if no error was found, and another number if something went wrong... or does it? well, almost.
0 = MSCDEX_SUCCESS
1 = MSCDEX_ERROR_MULTIPLE_CDROMS
2 = MSCDEX_ERROR_NOT_SUPPORTED
3 = MSCDEX_ERROR_PATH
4 = MSCDEX_TOO_MANY_DRIVES
5 = MSCDEX_LIMITED_SUPPORT
6 = MSCDEX_UNKNOWN_ERROR
Every single one of those non-zero codes is a "fatal error" making the mount to fail (and every one of them should destroy the half-created cdrom object) however, MSCDEX_LIMITED_SUPPORT isn't a fatal error, actually it's a success code (even when the "cdrom" has limited access, it succeeded to mount it.) This breaks the "0 means succeded" supposition I had. I think those error codes need to have a close look and better more consistent values; perhaps fatal errors could be negative integers, while success errors could be positive numbers and the 0... perhaps implementing a global common errorcode scheme with macros as SUCCEEDED() and FAILED() would be a good thing.
* Okay, I decided to post a temporary patch, this would make it easier for you 😀
Kronuz
"Time is of the essence"
Thanks, krounz. It's now possible to mount the cdrom drive.