Forum unknown
· Programming
#Ver. 1.2 Ques.
5 messages in this thread
Thanks for the reply. The PD resident places copies of the
programs in ram. When they are executed, only the data allocation areas
are added to the space taken in ram by the program. Thus, the program
doesn't "load" twice — ram copy plus loaded copy. The DEC program
actually builds an index file of the track and sector at which a program is
located on disk. When the program is called, the index is searched, rather
than the disk. Thus speeding access to the program. In effect, it indexes
the disk. Much like an indexed file.
Ah, ok, I remember your earlier message about the DEC indexing
earlier…no, it doesn't work like that, it works like the PD program you
described. BTW, in re: indexing, the way AmigaDOS does a directory is
rather like that for all files. UnLike MS-DOS and lots of other DOS's, it
doesn't output a linear directory listing, but rather an indexed directory
listing based on a hash of the filename and lookup table.
It hashes the filename, looks at the hashed value offset in the root block,
then goes to the block pointed to at the offset. It reads the real
filename at that block and if they match..starts the read, if it doesn't,
it goes back to an extension block of the root block, and looks at that
hash offset in that block, etc. I've checked quite a few disks, and only
found a few disks that had 2 files that hashed to the same number and thus
required the extension block lookup.
Don, the extension it looks at is not in the root block. It resides in each
"header" of a chain off one hash table entry. Even faster.
Don, the extension it looks at is not in the root block. It resides in each
"header" of a chain off one hash table entry. Even faster.
Ah, ok, I remember your earlier message about the DEC indexing
earlier…no, it doesn't work like that, it works like the PD program you
described. BTW, in re: indexing, the way AmigaDOS does a directory is
rather like that for all files. UnLike MS-DOS and lots of other DOS's, it
doesn't output a linear directory listing, but rather an indexed directory
listing based on a hash of the filename and lookup table.
It hashes the filename, looks at the hashed value offset in the root block,
then goes to the block pointed to at the offset. It reads the real
filename at that block and if they match..starts the read, if it doesn't,
it goes back to an extension block of the root block, and looks at that
hash offset in that block, etc. I've checked quite a few disks, and only
found a few disks that had 2 files that hashed to the same number and thus
required the extension block lookup.