I want to second Bret and point out that MS-DOS supports to write a block device driver that allows DOS to access a non-FAT disk. Let me cite a few explanations in books I have:
Ray Duncan writes in "Advanced DOS 2nd edition" page 261f: "Given adequate information about the hardware, any competent assembly-language programmer can expect to successfully interface even the most bizarre device to MS-DOS without altering the operating sys- tem in the slightest and without acquiring any special or proprietary knowledge about its innards." (Apparently he promotes DOS here) and further: "Block-device drivers usually control random-access mass-storage devices such as floppy-disk drives and fixed disks, although they can also be used to control non-random-access devices such as magnetic-tape drives. Block devices transfer data in chunks, rather than one byte at a time. The size of the blocks may he either fixed (disk drives) or variable (tape drives)." A tape is not FAT formatted and FAT does not support variable size blocks. The meaning of the bit 13 is described in Robert S. Lai's book "MS-DOS device drivers:" page 340: "The Evolving Bit 13" "Bit 13 has several meanings, depending on the device type. If the device is block-oriented, setting this bit will indicate to DOS that the device is a disk that contains a non—IBM-compatible format; leaving this bit off will tell DOS that the device contains an IBM-compatible format, If the device is character-oriented and the DOS version is 3.0 or greater, setting this bit indicates that the device driver can handle Output Til Busy commands. The issue of whether a disk uses an IBM-compatible format has evolved from a simple concept to a complex one. Recall from chapter 7 that the File Allocation Table follows the Boot Record (also known as the reserved area). On all IBM PC-DOS formatted diskettes, the FAT is always the second sector of the diskette. This was the initial definition for bit 13 set to 0. This also meant that DOS used the Media Descriptor to identify diskettes. Instead of using the Media Descriptor byte from the BIOS Parameter Block, however, DOS used the Media Descriptor byte from the first FAT entry. Thus, to identify the type of diskette in use, DOS would have to read the FAT into memory and pick off the first FAT entry DOS could not do this unless it could presume that the FAT was always in the same place on all diskettes. The inner workings of DOS to accomplish this task are even more complicated. As we shall show you later, in the section on the Get BPB command, the contents of the data-transfer area will depend on whether or not bit 13 is set. To make matters worse, the definition of bit 13 in later versions of DOS has changed subtly. You may recall that if bit 13 is set to 1, the format of the disk need not be IBM-compatible. This means that the FAT need not start at the second sector. What DOS will do at this point is to use the BPB to locate the FAT. the File Directory, and the user data area. This is the current definition of bit 13 as found in the manuals. If bit 13 is not set, the device driver uses the Media Descriptor from the FAT to determine the media type. If bit 13 is set, the device driver uses the BPB to determine the media type. To try to make some sense of all this, keep in mind that, as we showed in the chapter on disk fundamentals, the media descriptor is not a good mechanism to determine the media type. Disks come in all different sizes and have different physical characteristics, such as the number of tracks, cylinders, and heads. With different sizes for the FAT, the number of FATs, and File Directory, it is impos- sible to fit all these different combinations into a single media descriptor, par ticularly one that is limited to eight combinations (F8h to FFh). This is made worse by the fact that disks can have almost any media descriptor; there is nothing sacred about a given media descriptor value. In order to allow for all of these possibilities, you can set bit 13 on, allowing DOS to use the BPB to determine where things are." So this means you still have to use a BPB to tell DOS about the details of the disk even though it does not have to be a FAT disk. Bret writes: >it is at least theoretically possible to virtualize non-FAT systems through >a device driver, In the book Adams/Tondo "Writing DOS device drivers in C" they describe a WORM 3363 device driver that tells DOS that it accesses a 32 MB FAT disk. The driver then maps these 32 MB to the 200 MB WORM drive. If DOS tries to write to the emulated 32 MB FAT disk, once the 32 MB are used up, DOS writes to yet unused sectors on the WORM drive well beyond the 32 MB which DOS thinks would be available. So again, the block device driver interface is not limited to FAT disks. ----- Original Message ----- From: "Bret Johnson" <bretj...@juno.com> To: <freedos-devel@lists.sourceforge.net> Sent: Monday, October 05, 2015 6:15 PM Subject: Re: [Freedos-devel] XFTOOLS - exFAT access a la LTOOLS > you are a smart guy, but - as Eric already wrote - >> actually BLOCK drivers are only suitable for making >> FAT partitions on non-BIOS drives (e.g. USB) usable And I disagree with Eric (and probably lots of other people too) on this. They are not ONLY suitable for FAT partitions -- it is at least theoretically possible to virtualize non-FAT systems through a device driver, and would provide some advantages over an IFS if you did it that way. ____________________________________________________________ Fast, Secure, NetZero 4G Mobile Broadband. Try it. http://www.netzero.net/?refcd=NZINTISP0512T4GOUT2 ------------------------------------------------------------------------------ Full-scale, agent-less Infrastructure Monitoring from a single dashboard Integrate with 40+ ManageEngine ITSM Solutions for complete visibility Physical-Virtual-Cloud Infrastructure monitoring from one console Real user monitoring with APM Insights and performance trend reports Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911&iu=/4140 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
