Thanks ripsaw8080.

Woo, I was right. 😀

I'm betting a similar issue is what prevents Daggerfall from detecting the CD when launched from dagger.exe.

that is fixed in cvs (daggerfall)

Going further with the debugger, I learned that the installer is testing all of the drives from C thru Z and deciding if they're an installation "target" or an installation "source". So, sorry mg55, you weren't quite right. 😉

The reason the D: drive is rejected as an installation source is because INT 21 AX=4408 (IOCTL, Check if block device is removable) is indicating that the drive is removable. I don't know if this is bad programming on Trilobyte's part or what, because a CD-ROM drive is supposed to be removable, isn't it? Anyway, just to try it out, I mounted my install disc without the "-t cdrom" parameter, and it appears to work around the error. Only try mounting the disc this way for installation, not when playing.

Please try the work-around, and let us know if it is effective for you.

For which block device do they call the ioctl removable check?

ripsaw8080 wrote:

So, sorry mg55, you weren't quite right. 😉

Ah, well. It was only a hunch anyway, which is why I wanted to try and test it.

It sounds like having a debug build of Dosbox is the way to go though. As soon as I get some extra time to set things up I'll build myself one. I have a fairly large collection of DOS games and I am a programmer (C# mostly, although I've done a few things in C++ and Java).

Thanks

There is a (maybe outdated...) debugger-enabled build at the dev forum somewhere.

wd, it is calling both AX=4408 (removable check) and AX=4409 (remote check) for BL=03 through BL=1A (C-Z). Any drive that is indicated as fixed (not removable) is checked for the HDISK.GJD file. After this scanning of all the drives is complete, and IF a source is "located", a list of installation targets is given, usually this ends up as C: and Z: being listed... it also shows "local" or "remote" on each drive in the list, I guess to remind you if it's a network drive or not.

4409 should not really matter, network check as you said.
But i don't see the problem yet, they scan the fixed disks for that groovie.ini
file which indicates that the game is already installed (which it is not if the
file can't be found).
I'll see about 4408 for mscdex, but i think the response in dosbox is correct.

The groovie.ini and audio.dat are looked for in the current drive and directory only once, so that is its "already installed" check. The scanning with 4408 thing is the issue, 4409 is just something else it does. I'm not positive that indicating a CD is removable is correct, but it certainly sounds right to me. Not sure this is really DOSBox's fault.

msdos6.22+mscdex definitely report removable for the cdrom

Just to satisfy my curiosity I took my bin/cue files for 7th Guest disc #2 and extracted an ISO file for use in Virtual PC. I set up DOS 6.22 in Virtual PC and ran the install without any issues.

I don't know if that helps at all, but it at least confirms my image is capable of completing the install properly.

Helps, thanks.

What I found is based on a downloaded update package, and there's no certainty that it's identical to what's on the CDs with the problem, although there is some evidence for it. The INSTALL.EXE that I'm looking at is 43,704 bytes, date/time stamp of 7/23/93 6:55pm, CRC-32=4033D8EE If yours is not the same, it would be helpful to get a copy of it so it can be scrutinized in similar fashion. Also, did you have a chance to try the workaround I mentioned?

Your exe matches the one on my CD. The size, timestamp and CRC match.

Yes, if I mount the actual disc and leave off the "-t cdrom" then it works as expected.

I don't normally use my real discs though, I use image files to protect the originals.

Thanks for confirming that. And it's good that there's a relatively simple workaround to prescribe for others experiencing the problem.

I tried 21/4408 under the WinXP NTVDM, and my 3.5" floppy disk is reported as removable, but all of my HDs and optical drives are reported as fixed. It's interesting... maybe CD drives really should be considered as fixed by this DOS service, even though it doesn't make perfect sense.

Here's a link to Ralf Brown's info about the DOS service in question: http://www.ctyme.com/intr/rb-2890.htm

maybe CD drives really should be considered as fixed by this DOS service

Well my mscdex says otherwise, and i don't see a reason why a removable
device shouldn't be reported as such.

The only reason would be compatibility, of course. But I do agree that DOSBox is doing the most reasonable thing.

However, considering that the problematic version of the T7G installer thinks CD drives should be considered as fixed, and that the WinXP NTVDM is considering CD drives as fixed, I see the possibility that there has been some inconsistency in how it is handled.

The only reason would be compatibility, of course.

So what with games/installers that need the removability setting to
detect if the device is a cdrom? There goes your compatibility idea.

are you sure that that one call doesn't result in more tests being done ?
(when it detects removable => do some cdrom checks (label/search for mscdex or a cdrom device/ search memory for something.)

wd wrote:

There goes your compatibility idea.

You could always make it a conf file setting, fixedcd=false, does that put it back in play? 😁 Just kidding, the issue is hardly rampant among CD-based installation programs, and there is a simple workaround in the case of T7G.