Subj : Re: How to detect RAM disks To : Jasen.Betts@xspamp42.f531.n640.z3.f From : Matthias Paul Date : Tue Feb 26 2002 05:44 pm From: Matthias.Paul@f3.n342.z1.cereal.mv.com (Matthias Paul) Subject: Re: How to detect RAM disks From: "Matthias Paul" On 2002-02-24, Jasen Betts wrote: >> all (but one) have been block device drivers (and therefore used >> some form of FAT), which hook into the system at a much deeper >> level, and one particular driver hooked into the system down at >> INT 13h level > > I saw one like that in PCDOS 2.2 Unfortunately, I don't have PC DOS 2.2 here. How was the driver called, already VDISK.SYS? The one I know is a very special one, but DRI internal only. >> [...] but all RAM disk drivers I know of at least /use/ FAT. >> Using FAT you can significantly reduce the resident footprint of >> the driver, as you do not have to implement the file-system stuff. > > But you lose out on all the unused space, with a virtual filesystem you > could allocate ram from the xms pool as it is required and deallocate it > as files are deleted... (the Amiga ramdisk worked in this way, I haven't > seen one like it for dos) This is impossible to do in DOS. The only thing you could attempt to do is to allocate/deallocate small chunks of memory (say clusters) as you need them, but the volume's geometry must not change dynamically, as this would cause serious disk faults and problems in DOS internal buffering and there's simply no way to work around this in DOS. So, you would still have to specify the maximum size of the disk, and the FAT structure would remain static until the next "external" (and asychronous) resize operation. TDSK can resize at runtime, but this does not happen (and must not happen) without some form of user interaction, usually be running TDSK.EXE with parameters from the command prompt. TDSK, however, does allocate all the memory during the resize operation, because this keeps the resident code small (no extra code, no extra look-up table) and fast (no mem alloc/dealloc calls to the memory managers), and there would be no garantee that the memory can be allocated at random times later, anyway. The only way to solve this problem would be to emulate "media faults" then. ;-) Also, allocating the memory in one chunk will ensure that only one handle is needed and the memory does not get fragmented (this might be an issue for some memory managers, and no issue for others, it depends on how the memory managers works internally). Greetings, Matthias -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org -- |Fidonet: Matthias Paul 1:342/3 | | Origin: The Cereal Port BBS (603)899-3335 199.125.78.133 (1:132/152) --- # Origin: (1:132/152.4) * Origin: Baddog BBS (1:218/903) .