Re: encapsulating directory operations

On 2025-05-21 11:50, Paul Edwards wrote:

"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message
news:100jhh4$2lgt3$3@dont-email.me...

On Tue, 20 May 2025 22:26:57 -0400, James Kuyper wrote:
>

There is a practical barrier - while C was developed in the context of
Unix, which had a lot of influence on the design of C, that design has
also always been motivated by a desire to, among other things, be as
widely portable as possible.

>
Furthermore, back in that day, some OSes (like MS-DOS) were pretty limited
in their functionality, without even multi-tasking capability.

 And note that I sitll expect the proposed C90+ to support MSDOS.
 

That situation has improved somewhat. Nowadays the world divides into
POSIX-like versus non-POSIX-like. With the latter trying to become more
POSIX-like over time.

  I'm not interested in restricting myself to "nowadays".
 That doesn't mean I want to add a "far" keyword though.
Not that I would rule it out either.
 And MSDOS 4.0 - one of the systems I am interested in -
is not "trying to become POSIX-like".
 

 > [snip]
 >
MSDOS 2.0. tried to become more zzIX-like than MSDOS 1.x,
specifically it added directories separated by some kind of
slash.  It also had a hidden option to choose between '/'
for dirs '-' for options, or the MS-DOS 1.x style '/' for
options with some unused char ('\') for dirs.
Later versions phased out that option and got stuck with
the '\' notation ever since.
As for the directory API, MS-DOS went with an extended version
of the MS-DOS 1.x API where each returned entry contained both
the name and all other pertinent fields for a directory listing
So essentially the equivalent of a POSIX readdir+stat but
without the cost of a double directory lookup.  So essentially,
the readdir return structure was
// This is a paraphrase, actual structure has different layout
//   and different field names
struct _DIRENT {
   struct _stat st;
   char         fn[FILENAME_MAX];
};
This is more efficient to use, and the MS-DOS file system at the
time included the only copy of all the needed data in the place
read by the readdir() implementation anyway.  The later UNIX-like
file system NTFS did not, so the file system driver would actively
gather and cache the needed fields on the fly to preserve the API
structure .
   Enjoy
   Jakob
--
Jakob Bohm, MSc.Eng., I speak only for myself, not my company
This public discussion message is non-binding and may contain errors
All trademarks and other things belong to their owners, if any.