Climbing Trees
                                By Bill Ross

    The only advantage to the study of history is that it might  allow  us
    to  learn  from past mistakes.  In this regard, MS-DOS is the child of
    CP/M.  Like most children though, it does things a little  differently
    than its parent.  And in many cases, a little better.

    For  some  of  us,  one  of  the  greatest  irritants  to  CP/M is the
    limitation of 64 floppy disk directory entries, even on a double sided
    disk.   If we keep copies of short correspondence-such as letters-on a
    disk, we usually run out of directory space long befo  re  we  exhaust
    disk  file  storage  capacity.   MS-DOS  is a little better;  a single
    sided disk provides 64 directory  entries  and  a  double  sided  disk
    allows  112.   The  availability  of  hard  disks  muddied  the water.
    Although there was no longer a realistic problem on  directory  space,
    they  presented  another  problem:   how  to  keep  track  of  so many
    directory entries.

    For CP/M somebody-I'm not sure who-finally wrote  LIBRARY,  a  program
    that  allows  you  to keep track of numerous files under one directory
    space.  And for hard disks, CP/M resorted to User  Areas.   These  are
    both  good  solutions,  with  only  minor flaws.  LIBRARY is a program
    external to the operating system and User Areas are awkward and  still
    limited.   MS-DOS  utilizes a combination of both ideas.  Technically,
    it's called pathing but most of us commonly refer to it as Trees.

    The term trees comes from the fact that the main directory of  a  disk
    under  MS-DOS  is,  in fact, only the root of a potential structure of
    inumerable subdirectories that spread out much like the branches of  a
    tree.   Each  directory  space  may  be utilized to build a completely
    isolated "user" area with as many  files  as  necessary  to  fill  its
    particular  needs.   The  advantages  of such a system are immediately
    apparent.  We now can have as many "user"  areas  as  we  are  allowed
    directory  entries on a disk-SS-64, DS-1 2 , or Hard Disks-512-and the
    size of the area is limited only by the total capacity of the disk  on
    which it resides.

    As  an  illustration,  let  us suppose that we might wish to place all
    MicroPro programs in one area utilizing a root directory name of STAR.
    Each program would then be listed under the root as follows:

    WORDSTAR DATASTAR CALCSTAR REPORTSTAR

    These  programs  would  not,  in actuality, lie one under the other of
    course;  each would be directly acccessible from the root  as  in  the
    following illustration -- STAR

    WORDSTAR/ DATASTAR/ \CALCSTAR \REPORTSTAR

    --and  the  subfiles  under  these  programs would reside in a similar
    manner.

    STAR

    / / \ \

    WORDSTAR DATASTAR CALCSTAR REPORTSTAR

    / \ / \ / \ / \

    WS.1 WS.2 DS.1 DS.2 CS.1 CS.2 RS.1 RS.2

    The subfiles above might include any of the program files required  to
    make  the  named  programs  functional (i.e.  WSMSG.OVR, WINSTALL.COM,
    etc.) and were limited to two here just to illustrate  the  tree  like
    structure  that  pathing  generates.  For those of you who fail to see
    any semblance of a tree, turn the page upside down.

    Pathing  is  accomplished  with  the  aid  of  three  internal  MS-DOS
    commands:  MKDIR (MAKE DIRECTORY), CHDIR (CHANGE DIRECTORY), and RMDIR
    (REMOVE DIRECTORY).  More commonly used  but  fully  functional  short
    forms  for  these  commands  are MD, CD, and RD.  They are re latively
    simple to use.

    Let's  generate  the  pathway  directory  structure  of  the  previous
    illustration.   Utilizing  MD  we first generate the STAR subdirectory
    listing in the disk root directory.

    A>MD STAR(Return)

    We can view the results by calling up the disk directory.

    A>DIR(Return)

    DOS shows the file STAR:

    Volume in drive X has no label

    Directory of X:\

    STAR <DIR> 07-23-85 8:15a 1 File(s) 360448 bytes free

    If we want to view the  contents  of  a  subdirectory  we  address  it
    specifically --

    A>DIR STAR(Return)

    --and will see the following:

    Volume in drive X has no label Directory of X:\star

    .   <DIR>  07-23-85  8:15a  ..   <DIR> 07-23-85 8:15A 2 File(s) 360448
    bytes free

    Even though we just created this subdirectory, it would seem that  two
    files  all  ready  exist in it.  These <DIR> subdirectory file entries
    are reference files  only  and  are  generated  for  the  use  of  the
    subdirectory  functions.   For  the  moment,  note their prescence but
    don't worry about them.

    We can, if we desire, now copy each of the programs we want  into  the
    subdirectory,  but  in  this  case  it  would not be a good idea.  The
    reason for this is that each program is  composed  of  multiple  files
    and,  after  we  transfered  them in, they would be listed amongst the
    files of the other programs, as well as any  working  files  we  might
    generate  as  we  use  them.  Gad!  how confusing.  No, the purpose of
    this system is to maintain order so  let's  go  one  step  further  by
    generating additional subdirectories for eac

    of  the programs to occupy.  In this way, we can actually provide each
    with its own private "user" area in which to reside and work.

    We do that in a similar manner in which we made the  first  one.   The
    primary difference is that these subdirectories will reside at a lower
    level and we must use specific instructions to  MS-DOS  so  they  will
    appear  where  we want them.  In this case we want t hem all to reside
    within the area commanded by STAR.  In order to lace  them  there,  we
    give the command--

    A>MD\STAR\WS(Return)

    This  command instructs MS-DOS to (MD) Make a Directory (\) below STAR
    (\) under the name WS.   Since  we  still  physically  reside  in  the
    RootDirectory,  we  utilize  these \ (reverse slash) marks to show the
    PATH to the place in which the new subdirectory is  to  be  generated.
    We generate subdirectories for each of the other programs by repeating
    this procedure with appropriate titles and, to save  space,  will  not
    repeat it here.  and, if we perform a DIR STAR, we will then see--

    Volume in drive X has no label Directory of X:\star

    .   <DIR>  07-23-85  8:15a  ..  <DIR> 07-23-85 8:15a WS <DIR> 07-23-85
    8:15a DS <DIR>  07-23-85  8:15a  CS  <DIR>  07-23-85  8:15a  RS  <DIR>
    07-23-85 8:15a

    6 File(s) 358304 bytes free

    Well  now  that we have this orderly layout of directories under which
    to organize our programs, how do we get the programs in them  so  that
    we  can  utilize  them.   We simply use the same commands that we have
    always used, except that we add Path directions.  For the purposes  of
    illustration,  we will assume that we have generated STAR on the Drive
    B.  In order to copy our WordStar program  and  its  supporting  files
    into  the  WS subdirectory, place the disk with these files in Drive A
    and issue the command --

    A>COPY *.* B:\STAR\WS/V(Return)

    --and MS-DOS will echo each file as it copies and then state how  many
    files were copied.

    We  can  check  our  work  by requesting a directory listing of the WS
    subdirectory.  Using path directions we enter --

    A>DIR B:\STAR\WS(Return)

    --and MS-DOS displays the following directory.

    Volume in drive B has no label Directory of B:\star\ws

    .  <DIR> 07-23-85 8:23a ..  <DIR> 07-23-85 8:23a WS COM 21375 01-01-80
    11:02a}  WSOVLY1  OVR  41216  03-16-84 8:02a WSMSGS OVR 29056 03-16-84
    8:02a 5 File(s) 7726496 bytes free

    And of course we repeat this procedure for each of the programs.

    All right, now that we have everything where we want them, how  do  we
    use them?

    Up  to  now, we have done everything from the root directory.  We have
    generated subdirectories, copied files  into  them  and  examined  the
    directory  listings without moving ourselves at any time.  This is all
    well and good for disk maintenance and the  like,  but  things  become
    very awkward if we try to use subpositioned programs from such a lofty
    position.  To begin with, program functions seldom recognize the  path
    instructions  that  would  be necessary under such conditions.  So, if
    the mountain  can't  come  to  Mohammad,  then  Mohammad  must  go  to
    mountain.   Our  magic  carpet  in this case is CHDIR or, more simply,
    just CD.

    Taken from the Alamo Kug Journal.