you want to check for a DOS drive and check at BIOS level...
Are you sure that that is best way ? (hint no games uses this)
There are things like partitions and such in DOS as well.

try something like int 0x21 ah=0x36
for various drives. be wary of floppies though. Those are always special.

Qbix wrote:

you want to check for a DOS drive and check at BIOS level...
Are you sure that that is best way ? (hint no games uses this)

I want to check for a DOS drive being ready, not just that the drive exists.

Something I neglected to mention in my original post is that I would prefer not triggering an Int 24h in the process of the check.

Am I sure if it is the best way? No, not really, but it works well on real hardware. During runtime, my app may change drives numerous times, so this method prevents drives that are not ready from being added to the ready list.

My app isn't a game, btw. The DOSBox project has inspired me to continue development of a communications program I started over 15 years ago. I am very excited about DOSBox and I bet we can both agree that its potential exceeds DOS gaming.

Qbix wrote:

There are things like partitions and such in DOS as well.

Yes, which is why I like Int 13h/AH=2h. It does not trigger Int 24h on a fail for the case of the existing drive letter that lacks a filesystem.

Unfortunately, for non-floppy disks 13h/AH=2h seems to require a drive number that is mapped to 0x80+ (DL = drive number (bit 7 set for hard disk)), which is why I am asking how DOSBox handles its drive numbering with regards to the BIOS.

Qbix wrote:

try something like int 0x21 ah=0x36
for various drives. be wary of floppies though. Those are always special.

This works for the ready disk, but for the case of the non-ready disk it triggers Int 24h which I would like to avoid.

After some further digging, here is what I see regarding DOSBox mounts.

For the cases of "imgmount"ed floppy or disk images ...

imgmount a C:\DOSBOX\imgmount\blank144.img -t floppy
Drive 0x0 (AH) Status = 0x0

imgmount c C:\DOSBOX\imgmount\doswin512.img -size 512,63,16,1021 -fs fat
Drive 0x80 (AH) Status = 0x0

For the cases of "mount"ed disk images ...

mount d C:\DOSBOX\mount1
Drive 0x81 (AH) Status = 0xFF

mount e C:\DOSBOX\mount2
Drive 0x82 (AH) Status = 0xFF

and the default Z drive mount ...
Drive 0x97 (AH) Status = 0xFF

For the case of a partition without a file system ... (tested on hardware)
Drive 0x81 (AH) Status = 0x1

01h invalid function in AH or invalid parameter
FFh sense operation failed (hard disk)

FFh seems to be the correct and expected value given that the disk is emulated.

What I would like to do is handle the case for FFh in some way that does not trigger Int 24h but verifies that data is ready on the drive.

I am open to suggestions.

with disk images it is supported.
with mounted drives it is not. (as games don't use it).

Then again dosbox will never trigger an int 0x24

So to make it clear. with normal mounted drives int 0x13 ah=2 is not supported, as no games uses it.
However there is one exception

1                if (!any_images) {
2                        // Inherit the Earth cdrom (uses it as disk test)
3                        if (((reg_dl&0x80)==0x80) && (reg_dh==0) && ((reg_cl&0x3f)==1)) {
4                                reg_ah = 0;
5                                CALLBACK_SCF(false);
6                                return CBRET_NONE;
7                        }
8                }

but that has nothing to do with your request. Just for completeness sake.

In dosbox there is no concept of a DOS drive not being ready. If it is mounted then it is ready. So if it exists , it is ready.

Another point is that dosbox doesn't raise int 0x24 on non-existing drives. In fact it never raises it.
(at least not in the build available to the public)

Qbix wrote:

...Then again dosbox will never trigger an int 0x24...

This is good to know.

I should point out, though, that I am building my app to be MS-DOS compatible as well as DOSBox compatible, but not exclusively DOSBox.

So, of course I have to adhere to the world of the machine as well as the emulator which has me seeking solutions that are the best common denominator.

What is the recommended way for an application to know that it is running under DOSBox?

Rather than rely on unsupported services for disk ready, I will make the assumption that the disk is ready, if the drive exists, for the case where the app is aware of DOSBox.

Thank you for your replies.

well you can boot msdos inside DOSBox. then 0x24 will be triggered ofcourse.

I don't think there is a 100% foolproof way of detecting that you run under DOSBox. (anybody can change the source afterall)
However you can check the bios copyright string for the name DOSBox
or check the vesa vendor
Or check some of the default interrupt handlers to see if the callback instruction is there.
or check if comspec is set to z:\command.com