DOS ain't dead - Volumes vs physical storage media

Volumes vs physical storage media | WAS "Protectmod handl" (Developers)

posted by bretjohn , Rio Rancho, NM, 26.08.2010, 19:03

> > Purpose: to find out to which physical device and LBA address points the
> DOS drives

At least in theory, this is not something you're supposed to care about (though I must admit this is something that would occasionally be "nice to know"). A DOS-accessible volume doesn't have to be associated with an INT 13h physical device or CHS/LBA addressing at all (common examples include RAM drives, network drives, CD/DVD, SCSI/ASPI, USB, FireWire, etc.). That's why things are designed the way they are, and why you're supposed to only use OS calls to access data inside volumes. "Going behind the OS's back" and directly accessing data inside a volume is not a good idea, and why DOS (and Windows) don't provide a way to go back and forth between the two.

> Indeed badly missing:
>
> - a call revealing what device hosts a volume

I _might_ add something like this to a future release of USBDRIVE, though it is unlikely. If I did, however, the call would only be valid for the USB drives controlled by USBDRIVE -- it would not work for any other disks (including the MFM/RLL/ESDI/ATA/SATA/PATA/... disks that the BIOS & DOS kernel provide drivers for). In addition, there would be at least two different calls needed: one to obtain the physical information given a volume, and another to obtain the volume(s) given a physical disk.

Laaca is working on a protocol-independent way of accomplishing this: http://www.bttr-software.de/forum/forum_entry.php?id=8578

> - a call taking 2 volumes as input and revealing whether to use low memory
> (2 different disks, at least 1 is RAMDISK or SSD or so) or high memory
> (both on 1 hard disk) copy strategy

First of all, what do you mean by "high memory": UMB, HMA, EMS, XMS, or something else?

Secondly, when dealing with volumes, you should always use DOS calls, which require the memory address to be in segment:offset format, which in turn requires conventional, UMB, EMS, or in some cases, HMA. The memory must generally be compatible with all types of hardware DMA (including PCI bus mastering). It doesn't really matter whether the volumes are on the same physial disk or not, or even if they are on a physical disk at all.

> Windaube AFAIK doesn't have such calls either, some people (or companies)
> simply never learn :clap:

And they probably never will have such calls, for security and data safety reasons.

> It has this BUG (reported cca 1 year ago) that after driver uninstall the
> occupied "physical disks" are not freed :-(

That will be fixed in the next release of USBDRIVE. I've discovered that this is actually a "bug" in the way some BIOS's work, not a "bug" in USBDRIVE as such.

Post reply

Complete thread:

Protectmode handler called from realmode - Laaca, 12.08.2010, 21:12 (Developers)
- Protectmode handler called from realmode - ecm, 12.08.2010, 21:24
  - Protectmode handler called from realmode - Laaca, 13.08.2010, 01:46
    - Protectmode handler called from realmode - Japheth, 13.08.2010, 07:31
      - Protectmode handler called from realmode - bretjohn, 13.08.2010, 18:43
        EDIT: Protectmode handler called from realmode - bretjohn, 13.08.2010, 19:25
        Volumes vs physical storage media | WAS "Protectmod handl" - DOS386, 26.08.2010, 09:33
        Volumes vs physical storage media | WAS "Protectmod handl" - bretjohn, 26.08.2010, 19:03
        Volumes vs physical storage media | WAS "Protectmod handl" - DOS386, 27.08.2010, 03:25
        Volumes vs physical storage media | WAS "Protectmod handl" - bretjohn, 27.08.2010, 16:47
        Volumes vs physical storage media | WAS "Protectmod handl" - DOS386, 28.08.2010, 01:26
        Volumes vs physical storage media | WAS "Protectmod handl" - bretjohn, 28.08.2010, 16:35
        Volumes vs physical storage media | WAS "Protectmod handl" - DOS386, 06.09.2010, 20:10