The structure of the special type of DOS files called directories (1998)

Re:The structure of the special type of DOS files called dir... by badsectoracula on Monday February 25, 2019 @01:52PM (#19248251)

Since the source code has been released [0], i decided to check it out and sadly it isn't that smart. Searching is implemented in DIR.ASM [1] by reading each entry one by one, matching is done only on the filename (encoded as 11 bytes for FILENAMEEXT) and it only handles "?".

Note that this is for MS-DOS 2.0 which didn't handle "*.FOO" searches on the kernel side (the star expansion was done on the COMMAND.COM side via the MakeFcb [2] procedure). MS-DOS 3.0 introduced the star wildcard on the kernel side, so it might have taken advantage of that... but there isn't source code for MS-DOS 3.0.

[0] https://github.com/Microsoft/MS-DOS/tree/master/v2.0/source

[1] https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/...

[2] https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/...

[ Parent | on HN ]

Re:The structure of the special type of DOS files called dir... by anyfoo on Monday February 25, 2019 @02:38PM (#19248664)

Wouldn’t you have to look how COMMAND.COM implemented * matching then, assuming that the filename buffer has a similar fixed length fields representation?

Also note that DOS 2.0 incurred quite significant changes to fs code, as it was the first version to support directories. Before that, the namespace was flat.

[ Parent | on HN ]

Re:The structure of the special type of DOS files called dir... by badsectoracula on Monday February 25, 2019 @06:26PM (#19250491)

All commands (implemented in the TCODE?.ASM files) call PARSE_FILE_DESCRIPTOR (defined in MISC.ASM) which just calls MakeFcb (defined in FCB.ASM) that does the star parsing. See lines 127-133, CX contains the remainder of characters not parsed, if it is star the rest of the characters are replaced with ?s, so a FOO<star>.E<star> (...HN eats the stars) would become FOO?????.E?? (the subroutine MUSTGETWORD "under" MakeFcb does the actual replacing for each part, once for the filename and once for the extension - see the calls to it and how the CX is set up for the lengths).

MS-DOS 1.25 does pattern matching mostly the same way [0]. The code is a bit simpler as it doesn't have the crazy macro stuff that MS-DOS 2.0 code has, but if you look a bit around the files, you'll see that it is mostly the same code just moved around and split in several files. The file scan works again in almost the same way, reading each directory entry one by one and doing the pattern matching after the fact.

[0] https://github.com/Microsoft/MS-DOS/blob/master/v1.25/source...

[ Parent | on HN ]

Re:The structure of the special type of DOS files called dir... by anyfoo on Monday February 25, 2019 @06:35PM (#19250553)

Thanks for the thorough analysis! Very insightful. So the 8+3 structure still simplifies matching: To my recollection at least, in DOS a * would always wildcard out the rest of the filename component (I did not look in the code), so things like FOOxBAR.TXT weren't possible. That way though, the common x.TXT still is.

Read "x" as *, because I could not for the life of me get the star work as a star within a word in this comment.

[ Parent | on HN ]

Re:The structure of the special type of DOS files called dir... by stevekemp on Monday February 25, 2019 @02:46PM (#19248725)

My memory is hazy, but the way that most DOS programs handled file iteration was to use FindFirst/FindNext, and that used data in the program-segment-prefix (PSP) - which was borrowed from CPM.

[ Parent | on HN ]

Re:The structure of the special type of DOS files called dir... by badsectoracula on Monday February 25, 2019 @06:27PM (#19250497)

Yes, the second link is essentially what "FindFirst" calls. A few lines below is the meat for "FindNext".

[ Parent | on HN ]