From: dic5340@hertz.njit.edu (David Charlap)
Newsgroups: comp.os.ms-windows.advocacy,comp.os.os2.advocacy
Subject: Re: Some more misconceptions regarding OS/2 and NT
Date: 28 Jul 92 16:14:28 GMT
Distribution: na
Organization: New Jersey Institute of Technology, Newark, N.J.

In article <1992Jul27.173017.2806@vela.acs.oakland.edu> bcmatusz@vela.acs.oakland.edu (Brian Matusz) writes:
>In article <1992Jul27.164642.12035@njitgw.njit.edu> dic5340@hertz.njit.edu (David Charlap) writes:
>>
>>That you have directories which contain subdirectories and/or files.
>>Files are ordered sequences of bytes.  This isn't always the case -
>>the Mac for instance, has two file systems (MFS and HFS) which don't
>>fit this paradigm - MFS has no directories, and both use a forked file
>>structure.  If HFS was adopted as a PC file system, it'd cause
>>problems for many developers (if not users).
>
>I'm realitvely sure that OS/2 also uses the forked file paradigm ...
>can anyone verify this?  I have noticed on files in a DIR (from an OS/2
>command line) that there are two sizes listed for some files ...
>mainly I noticed that editing a file with E.EXE that has a 0 second
>size causes and "unknown file type" when saving ... then you select
>"Plain Text".  When editing this file again, no more questions.
>And the second size is now 35 bytes.

Ah yes, the second size.  This number is the size of extended
attributes in a file.  Yes, it is similar to the Mac's forked file
system, but it's nowheres near the complexity.  Briefly, an
application can store small pieces of data (icons, file type, etc) in
extended attributes, which are attached to the program.  On FAT
systems, all EA's for a volume are stored in the "EA DATA. SF" file.
On HPFS, they are stored contiguously with the file itself.

This is in contrast to the Mac's forked system.  On the Mac, there is
a resource and a data fork.  The data fork is a series of bytes, much
like a DOS binary file.  An application can do what it wants with
this.  The resource fork is almost like another directory tree.  The
resource fork of a file contains a list of resources, organized by
type and identifier - the type is a four letter code (like ICON, WDEF,
STR#, etc) and the identifier is a number (I think 16-bit signed int).
The Macintosh system has API's for quick reading and writing of
resources.  Everything about a program is stored in resources,
normally.  Your code segments are stored in CODE resources, icons are
stored in ICON, ICN#, or CICN resources, etc.  There are many dozen
standard resource types, and plenty of application-specific types.

This is not the same as EA's, which are limited in nature, and are
restricted in size (I think there can't be more than 64K worth of EAs
per file).  

It also isn't the same as program resources, which are physically
linked to program code using rc.

In most cases, the EAs for a file can be trashed and the program will
still function (though it might be missing an icon or something).  If
you corrupt the resource fork of a Mac app, you've lost everything -
because that's where the program is.
-- 
   |)  David Charlap           "I don't even represent myself
  /|_  dic5340@hertz.njit.edu   sometimes so NJIT is right out!.
 ((|,)
  ~|~  Hi! I am a .signature virus, copy me into your .signature file.
Newsgroups: comp.os.ms-windows.advocacy,comp.os.os2.advocacy