About getting the useful drives

[untio]

Hi,

First, thanks for reading this post.

I am coding a program for the old msdos to not forget the old coding style. My aplication needs to get the list of useful drives. A, C, etc.

I have achieved the result in the code that I attach, but I do not know if there is a better method or even if my method is wrong.

Has someone got a correct or better way to do this?

Thanks.

[jj2007]

Does your code actually assemble, and if yes, which assembler & linker do you use, and which settings?

I ask because it throws several errors with my assemblers and linkers (and I usually can assemble & link 16-bit apps).

[MichaelW]

unito,

Since the drives are normally accessed through the OS, which may recognize drives that the BIOS cannot, the "useful" drives are the ones that are recognized by the OS. Also, drive letters are an OS concept, the BIOS uses numbers (0h,1h,... for diskette drives, 80h,81h,... for hard drives). If I were doing this I would use Interrupt 21h Function 4409h. You can simply rotate through the possible drive letters (specified as 1 to 26 in BX) and use the carry flag to determine whether or not the drive is valid.

[untio]

Hi,

First, thanks for your responses.

When I use function 4409h, I receive the same response from drive a than from drive b, but the system does not have any drive b.

When I use edit.exe to open a file, it lists the disk drives that are attached to the system. It does not list drive b, because there is not any drive b.

I attach the full code. It compiles with tasm v 3.2

Thanks for your attention.

REEDITED. Now I have attached the code.

[Gunther]

My active DOS times are a bit far away. If I remember it right, there was the following drive naming:

Drive A: the 3.5'' disk
Drive B: the old 5.25'' disk etc.

But I'm not 100% sure.

Gunther

[FORTRANS]

Hi,

   IIRC, DOS systems with two floppy drives named
them A: and B:.  If there was only one drive, it named
it A: and used B: too allow copying fron one diskette
to another.  It prompts you to swap diskettes when it
fills its buffers.  So a B: drive can show up even if it
does not really happen to be there in the real world.

Regards,

Steve N.

[untio]

Hi,

Thanks a lot for your answers. I thinked that it could be an standard way to handle this.

Doing it like I coded it seems to work.

Cheers.

[MichaelW]

As I stated, the OS may recognize drives that the BIOS cannot. From the Microsoft MS-DOS 5.0 Programmer's Reference:

MS-DOS usually reserves the first two logical drives for floppy disk drives. On Computers that have only one floppy drive, the second logical drive is often treated as an alias for the first. In this case Is Drive Remote (Interrupt 21h, Function 4409h) specifies the first and second drives as valid drives, even though they share the same physical drive. A program can determine whether two or more logical drives share physical drive by using Get Logical Drive Map (Interrupt 21h, Function 440Eh)...

Other examples of "useful" drives that the BIOS Interrupt 13h functions cannot recognize would be network drives, drives created with SUBST, and drives provided by special device drivers (CD-ROM drives for example).

For Windows 2000 and XP, running on a system with one floppy drive Is Drive Remote does not show drive B as valid.

[untio]

Hi,

Thanks once more.

In my code, first I test the kind of floppy drive of units a and b. In my system (a virtual box machine running msdos 5 and windows 3.1) this detects that unit b does not exist.

To manage the other possible drives, I change the default drive to each of them and I get the default drive, if both are the same then the unit exists. With this silly solution I detect that unit e does not exist, as it happens.

Cheers.

[untio]

Hi,

You were right. Using your method the code works greatly. And, in msdos, when I open edit.exe searching for a file there is a drive a: and a drive b: even if drive b: does not exist.

I attach my new code.

Thanks a lot and forgive my mistakes.