On Thu, 20-Aug-2009 11:27:47, Christian Masloch <c...@bttr-software.de> wrote:
>>>> I have never seen a RAMdisk that was not file-based >>> >>> Maybe we have a misunderstanding here ... The driver itself >>> is of course a file, but the disk is a DOS block device ... >> >> NO misunderstanding, and that is exactly what RDISK and other >> RAMdisk drivers do. After setting RAM memory to an "initial >> state", a RAMdisk does memory-moves, not file transfers, with >> a one-to-one correspondence -- every DOS "read" or "write" to >> a RAMdisk causes exactly one XMS move request. Thus, one is >> better-off viewing a RAMdisk as a FILE handler, rather than a >> "sector" handler. > > Looking from DOS, the RAM disk is a block device. It doesn't handle data > on a per-file basis; I don't understand why to call it a file handler > then. It "handles" or provides sectors to DOS and that's it, so one is > better off viewing a RAM disk as a sector handler. The "Phantom" RAM > disk > presented in the "Undocumented DOS" books was a file-based RAM disk: it > hooked the redirector interface and provided the appropriate functions > for each file. These files were stored in Phantom's own file system, in > RAM ... Unless you recently changed RDISK to use the inferior redirector > approach (that was a joke), it's still a block device as last time I > looked > at the source. I have made NO such changes, never WOULD, and never WILL, neither as any sort of insulting "joke", nor otherwise! > What do you define as "DOS read"? Calling the "Read from file" DOS > function? If that's the case then you're wrong, DOS usually calls block > devices multiple times to read the FAT and the necessary sectors of the > file's data to carry out such a request. If you meant "DOS read" as > reading a single or some sectors from a block device, this is correct. Fine, Christian, that is EXACTLY what I meant! Consider just what "drives" all I-O requests to RDISK or similar drivers. FILES do! Unless some "oddball" does his OWN requests for his OWN types of data blocks, RDISK will otherwise answers only to FILE requests by the DOS system, using the file DIRECTORY in its RAMdisk memory. To me, that makes RDISK a FILE handler, as distinguished from UIDE which in fact does reads or writes ONLY using LBA addresses and NOT any sort of "directory". Thus UIDE is a pure SECTOR handler and "Couldn't care LESS" about any DOS directory structure. DOS RAMdisk drivers MUST HAVE a directory and a file structure, or DOS is absolutely UNABLE to use them! WHO CARES if it is DOS which "knows" how to break down files into blocks/sectors/etc. -- DOS and RDISK are in fact handling FILES, NOT sectors addressed ONLY by their LBA addresses as done in UIDE! That dependency on a directory, and on FILES in its directory, are what make every DOS RAMdisk driver a FILE handler FIRST, and a sector handler only as a SECONDARY result, in my opinion! You are free to classify such drivers/handlers however you choose! And, to be honest, I wish you "Lots Of Luck" dealing with those who MAY NOT be as forgiving of your "jokes", then your too-RIGID "semantics", as I was!! Jack R. Ellis ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
