Qbix wrote:

are you sure that that one call doesn't result in more tests being done ?

I'm pretty sure that call is the entire issue, as I wrote a little TSR that modifies the return value of 21/4408 to always be 1 (fixed) as long as there was no error returned (invalid drive or such), and it cures the install program's problem.

Actually, there is sort of an additional test that's done: on any drive that is considered fixed, it tries to open the file \t7g\install\hdisk.gjd, and if the file is found then that drive is used as the source drive. But because a CD drive is being considered removable, it doesn't even look on it for that file.

BTW, it just occured to me that Graeme Devine, the developer, used his initials for the data files. 😀

as I wrote a little TSR that modifies the return value of 21/4408 to always be 1 (fixed)

That does not mean this call is the issue.

I have stepped through the code and observed what it is doing; the TSR was just a confirmation for what I learned. I don't seem to be succeeding at overcoming your skepticism; however, you can use the information I gave you to reproduce the problem for yourself.

well I don't have this game. So I can't confirm your findings.
But basicly this would mean that if you are right then this game wouldn't install on a real dos pc as well. As that returns removable for a cdrom.

I wonder if all versions of DOS handle it the same. I find it interesting that the WinXP NTVDM considers CD drives as fixed... not that it's the model for proper DOS operation, but it demonstrates some inconsistency.

The problematic installer is dated in the Summer of '93, and MS-DOS 6.0 came out in Spring of '93, so 5 and possibly that earliest version of 6 would be the ideal versions to test.

dos 5 and 6 most likely report the same. they aren't that different in the interrupt handler. think 6 just had a lot more utilities. no changed functionality.
(I suspect wd to have used 6.x for testing it with mscdex)

ntvdm is really totally useless when it comes to dos games.

I think your "fix" bypasses the real problem. So the fix is useful for someone who wants to play it (like the fall.exe z.cfg), but it doesn't fix the bug in dosbox. (for daggerfall a small bug in how the cdrom label was returned)

But maybe wd can test it with 5.0 as well

I wonder what sapucdex reports in XP for the drive?

I think that ioctl call should directly go to the cdrom driver, not through
mscdex/sapuxdex/whatever.

ripsaw8080 wrote:

BTW, it just occured to me that Graeme Devine, the developer, used his initials for the data files. 😀

Cool. I never noticed that.

cdroms don't have/provide the drive parameter block, thus this function
fails with invalid function returncode.

which call ?

4408, probably more

Ah, so I guess 21/4408 is the culprit, then, if for different reasons than the fixed/removable issue.

Perhaps there are other IOCTL functions that should generate an error for CD drives in DOSBox as well?

I assume that, but didn't check it yet, suppose a rather early call checks
for dpb or bpb presence and fails (that is not only for 4408).