Image Map Image Map
Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: Finding all valid DOS drive letters (unobtrusively)

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1

    Default Finding all valid DOS drive letters (unobtrusively)

    I'm looking for a way to query DOS and enumerate all available drives in the system. My target is MS/PC-DOS 3.0 and above.

    For floppy drives, the sample code at http://www.fysnet.net/getdrvs.htm uses an acceptable method (already discussed here in the past).

    For non-floppy drives however, that same program simply tries to change the current drive (INT 21h function 0Eh) and then access it (function 19h). Another suggestion I've seen is to use function 29h (parse filename into FCB), which returns AL=FFh if the drive letter is invalid.

    What I'd like to know is, what happens if the drive is removable (CD-ROM/Zip/etc.)? Will these methods cause DOS to check for available media (possibly waiting quite a long time) before telling me if the drive letter is valid?

    The idea is to do this as unobtrusively as possible - at this point I only need to know if the drive *letter* is recognized, so I'd like to avoid annoying delays like that.
    int10h.org :: :: :: blog

  2. #2

    Default

    How about INT 21h function 44h (IOCTL) with AL=8 (Device Removable Query)? I think this will return CF=1 if the drive letter doesn't exist. Ultima VI (when run on DOS 3.0+) will enumerate over all 26 drive letters and call this on each one to determine which drives to look at for its disks. I used to play it on a machine with a CD-ROM drive and I don't remember it pausing on start to see if optical media was present. There is a note in HELPPC that "device drivers compatible with DOS 2.0 do not always respond correctly to this query" but that may not matter if it's just the availability of the drive letter that you care about and not the removable status.

  3. #3

    Default

    Thanks, I'll have to give that a test with DOS - I wonder if it's equivalent to the function 29th (FCB) method for my purposes. But yes, I don't need to know if the drive is removable; I just need a list of valid drives handy for a file-system navigation widget. So as long as it doesn't cause DOS to make spurious accesses to the drive, it should work well enough.
    int10h.org :: :: :: blog

  4. #4

    Default

    Just be sure to test on real hardware I made that mistake once, I did a 'stat' on 'con' on all drives, a:\con etc. worked great in dosbox, I got a list of drives that were present or not from a-z... total fail on real hardware!

  5. Default

    Quote Originally Posted by BloodyCactus View Post
    Just be sure to test on real hardware :) I made that mistake once, I did a 'stat' on 'con' on all drives, a:\con etc. worked great in dosbox, I got a list of drives that were present or not from a-z... total fail on real hardware!
    Device names seem to be handled differently depending on whether there is a path (including "\") after the drive letter. You can try this on the command line:

    type a:nul
    will not access drive, but print an error message if it doesn't exist

    type a:\nul
    accesses drive, "abort/retry/fail" prompt if no media

    truename a:nul
    truename a:\dev\nul
    both print "A:/NUL" (with forward slash), error if no such drive. The path "\dev\" is still treated as a special case on MS-DOS 6.22!

    truename a:\nul
    accesses drive, prints "A:\NUL" if successful

    Since function 29h doesn't deal with paths, and only parses the filename instead of trying to do anything with it, it should be a safe way to detect if a drive exists.

  6. #6

    Default

    back in the day of heavy(!) Borland Pascal programming I used this code

    Function DriveValid(Drive:Char):Boolean;Assembler;
    ASM
    MOV DL,Drive
    MOV AH,$36
    SUB DL,'A'-1
    INT $21
    INC AX
    JE @Fine
    MOV AL,1
    @Fine:
    END;

    Don't know if it helps...

  7. #7

    Default

    Quote Originally Posted by reenigne View Post
    How about INT 21h function 44h (IOCTL) with AL=8 (Device Removable Query)? I think this will return CF=1 if the drive letter doesn't exist.
    Yeah, that should work fine especially since it is supported from DOS 3.0. In XTIDECFG.COM I used INT 21h AX=4409h (CHECK_IF_BLOCK_DEVICE_REMOTE) which will also return CF set if the drive doesn't exist and it won't access the drive so there are no delays. It does require DOS 3.1 though so might not be suitable in this case.

    See this file if you want to see how it's done in XTIDECFG.COM (I'm not saying this is the best way to do it - In fact, I would very much like to hear any suggestions for improvement).
    Looking for a cache card for the "ICL ErgoPRO C4/66d V"

  8. #8
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,794
    Blog Entries
    20

    Default

    Does this work on drive letters that are the object of subst?

  9. #9

    Default

    Quote Originally Posted by Chuck(G) View Post
    Does this work on drive letters that are the object of subst?
    Do you mean function 4408h or 4409h? In the case of 4409h then yes, at least according to RBIL. I haven't tried it myself as I don't think it really matters in this use case.
    Looking for a cache card for the "ICL ErgoPRO C4/66d V"

  10. #10

    Default

    Quote Originally Posted by BloodyCactus View Post
    Just be sure to test on real hardware I made that mistake once, I did a 'stat' on 'con' on all drives, a:\con etc. worked great in dosbox, I got a list of drives that were present or not from a-z... total fail on real hardware!
    I don't have any such removable drives to test on the real hardware (to rule out the delays), hence my asking here. I guess PCem, 86box or DOSBox-X might emulate them a little more accurately than DOSBox, but I still don't want to put all my trust in that.

    Quote Originally Posted by Krille View Post
    Yeah, that should work fine especially since it is supported from DOS 3.0. In XTIDECFG.COM I used INT 21h AX=4409h (CHECK_IF_BLOCK_DEVICE_REMOTE) which will also return CF set if the drive doesn't exist and it won't access the drive so there are no delays. It does require DOS 3.1 though so might not be suitable in this case.
    Ah, nice- that makes me somewhat confident that AL=08h would work similarly. A minimum requirement of 3.1 wouldn't be a huge deal actually, but I guess I'll go with the 3.0-supporting alternative.

    Quote Originally Posted by Krille View Post
    See this file if you want to see how it's done in XTIDECFG.COM (I'm not saying this is the best way to do it - In fact, I would very much like to hear any suggestions for improvement).
    Well, I've also been considering the issue with single-floppy systems and those "insert disk for drive A:/B:" DOS prompts. Your chosen solution is good enough for me (reading 0:504h to determine the current logical drive, and "hiding" the other one), but I still wonder if there's a way to go one better.

    What if you intercepted the requested drive number, modified the flag in 0:504h to match it, and only then executed the DOS call? That way DOS *should* play nice with whatever letter the user selects; the advantage is that you don't have to hide a potentially-valid drive letter, or have a weird-looking list starting with B:... assuming there are no other gotchas, of course.
    int10h.org :: :: :: blog

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •