FreeCom and 4DOS descript.ion files

Jeremy Davis writes:

I actually had a few free minutes today so I implemented the requested feature for bug#1889, have DIR command display descriptions from 4DOS's DESCRIPT.ION files if available.

Get from usual place, http://fdos.org/AutoIndex/index?dir=kernel/&file=cmdxms.HEAD.zip

I would be interested if people try this build to let me know if they see a noticable delay when doing a 'dir' command or not, and if DESCRIPT.ION files are in use or not. There should not be a noticable delay if you do not use them (one attempt to open per directory displayed), but may be for big directories as the file is sequentially searched for each filename displayed (as the file is unsorted and may or may not contain a description I'm not sure how to avoid this).

Because FreeCom will also display long filenames (when LFN API found and file appears to be short name), the description starts on the next line down; but otherwise displayed similar to how 4DOS displayed [given my minimal test of 4DOS displaying one].

No attempt is made to support creating/editing/copying/removing them, only displaying the descriptions if they exist during DIR.

Jeremy


David O'Shea responds:

I would be interested if people try this build to let me know if they see a noticable delay when doing a 'dir' command or not, and if DESCRIPT.ION files are in use or not. There should not be a noticable delay if you do not use them (one attempt to open per directory displayed), but may be for big directories as the file is sequentially searched for each filename displayed (as the file is unsorted and may or may not contain a description I'm not sure how to avoid this).

I'm not familiar with the exact constraints that apply to FreeCOM, but the following might be an optimization that performs better if there is enough RAM free and the same if you don't.

What I'd suggest is you use a binary search tree (with the key being the filename of course); the trick being that you just use up all the RAM available to build the tree, and if you run out before you finish reading the descript.ion file, you remember the file position of the first entry you couldn't add to your tree so that when you are looking up a description for a physical file you found on disk, if you don't find it in the binary search, you can then do a linear scan of the remainder of the file.

I think this would be a good design because it should perform well if you have enough memory/the descript.ion file isn't too big, but it will still work if there's not enough memory.

Of course I don't know if code size might be a concern for you guys and adding the above would be a problem! Apologies if these kinds of constraints are documented somewhere - I haven't gotten around to reading all the documentation yet but once I have I'm hoping I can contribute with regards to coding. Any suggestions of some small things that need to be done that are maybe the kind of thing that the main developers don't have time for or feel is below them - the kind of work that at my work we'd give to an intern? :)

Thanks in advance, David


Jeremy replies:

Definitely worth considering. What I would really like to hear is from people who actually use these files about the normal size (how many entries and usual line lengths) and just a rough impression if the implemented method is noticeably slow or even worthwhile?

we [at least me] appreciate any and all help, whether small patch, documentation suggestion, or just testing.