Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #4178

Re: directory recursion

Show all headers | View raw

Muta,

> I would need to know the layout as it was at a particular dos version.

Exactly.   And that is the info that Ralf Browns list tries to offer you.

> Not any new fields, like lfn, that had been subsequently added.

:-)   How would you know if the version of DOS you're programming under 
isn't one who actually has such extra fields ?

> Yes, because existing things wouldn't change.

I would not bet on that if I where you.

For the record, when you say "added" it normally means that extra fields can 
be *inserted* (and/or obsolete fields removed).  And that ofcourse means 
that the offsets to the fields after it change.

What I mostly do is to first create a test program, and simply try to match 
the data/record returned by the tested INT/procedure/etc. with the 
information (as in the RBIL) at hand.

>> Yes, the DTA /could/ change. But if it does its an *OS* related change.
>> Well documented..
>
> And as an os vendor taking over where  Microsoft left decades ago, I have
> documented an extension.

And that extention is only valid for your particular DOS version.    It 
could also easily clash with an extension written by someone else ...

> The application program can only code what was known
> at the time, not what Microsoft or some other os vendor
> added as an extension since then.

Quite so.  And that means that when you run a program using "what Microsoft 
or some other os vendor added as an extension since then" on a "what was 
known at the time" version it wil crash-and-burn.    Which is why you need 
to do version checking.

> I am an os vendor. I need to fill in that data.

*You* need to fill in that data ?    In that case its fully up to you to 
decide what your DTA is going to look like / what you're going to store in 
there.   If you want to store the number of the first cluster of the 
containing directory in there you can do that.  If you don't want to that 
you simply do not include that field in your DTA.

Its all upto you, as that part of it is, as I tried to make clear, an 
"dragons be here, stay out" area.

On the other hand, if you're just trying to supplement an already existing 
framework you should not be looking at the RBIL, but find yourself the specs 
for the version of the OS you are trying to, quite literally, add some stuff 
to.

On yet another hand, if you're just extending, isn't at least that "parent 
cluster" field all filled in yet ?

IOW, its not at all clear to me which level you are operating on.

> I at least need to chain through the clusters.

Yes you would.  But every time you want to grab a new entry from that 
directory ?   Why ?

I could easily imagine just storing the the sector/cluster the currently 
returned entry is in.  What good would it do me to know where the whole 
directory started ?   It just creates extra work.

Regards,
Rudy Wieser

Back to comp.os.msdos.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

directory recursion "muta...@gmail.com" <mutazilah@gmail.com> - 2022-08-16 03:01 -0700
  Re: directory recursion "R.Wieser" <address@not.available> - 2022-08-16 15:08 +0200
    Re: directory recursion "muta...@gmail.com" <mutazilah@gmail.com> - 2022-08-16 13:35 -0700
      Re: directory recursion "R.Wieser" <address@not.available> - 2022-08-17 08:35 +0200
        Re: directory recursion "muta...@gmail.com" <mutazilah@gmail.com> - 2022-08-18 01:24 -0700
          Re: directory recursion "R.Wieser" <address@not.available> - 2022-08-18 12:06 +0200
            Re: directory recursion "muta...@gmail.com" <mutazilah@gmail.com> - 2022-08-19 00:38 -0700
              Re: directory recursion "R.Wieser" <address@not.available> - 2022-08-19 13:08 +0200
                Re: directory recursion "muta...@gmail.com" <mutazilah@gmail.com> - 2022-08-20 03:55 -0700
  Re: directory recursion Steve Nickolas <usotsuki@buric.co> - 2022-08-16 13:59 -0400

csiph-web