Introduction:

History: By separating the data into individual pieces, and giving each piece a name, the information is
easily separated and identified. Taking its name from the way paper-based information systems are named,
each group of data is called a "file". The structure and logic rules used to manage the groups of information
and their names is called a "file system".

For example, the ISO 9660 file system is designed specifically for optical discs.

File systems can be used on many different kinds of storage devices. Each storage device uses a different
kind of media. The most common storage device in use today is ahard drive whose media is a disc that has
been coated with a magnetic film. The film has ones and zeros 'written' on it sending electrical pulses to a
magnetic "read-write" head. Other media that are used are magnetic tape, optical disc, and flash memory.
In some cases, the computer's main memory (RAM) is used to create a temporary file system for short term
use.

Some file systems are used on local data storage devices;[1] others provide file access via a network
protocol (for example, NFS,[2] SMB, or 9P clients). Some file systems are "virtual", in that the "files" supplied
are computed on request (e.g. procfs) or are merely a mapping into a different file system used as a
backing store. The file system manages access to both the content of files and the metadata about those
files. It is responsible for arranging storage space; reliability, efficiency, and tuning with regard to the
physical storage medium are important design considerations.

Memory management techniques used in Mac OS:

Historically, the Mac OS used a form of memory management that has fallen out of favour in modern
systems. Criticism of this approach was one of the key areas addressed by the change to OS X.

The original problem for the engineers of the Macintosh was how to make optimum use of the 128 KB
of RAM with which the machine was equipped. [1] Since at that time the machine could only run
one application program at a time, and there was nofixed secondary storage, the engineers implemented a
simple scheme which worked well with those particular constraints. However, that design choice did not
scale well with the development of the machine, creating various difficulties for both programmers and
users.

Contents
  [hide] 

 1 Fragmentation
 2 Memory leaks and stale references
 3 Switcher
 4 32-bit clean
 5 Object orientation
 6 References
 7 External links

Fragmentation[edit]
The primary concern of the original engineers appears to have been fragmentation - that is, the repeated
allocation and deallocation of memory through pointers leads to many small isolated areas of memory which
cannot be used because they are too small, even though the total free memory may be sufficient to satisfy a
particular request for memory. To solve this, Apple engineers used the concept of a relocatable handle, a
reference to memory which allowed the actual data referred to be moved without invalidating the handle.
Apple's scheme was simple - a handle was simply a pointer into a (non relocatable) table of further pointers,
which in turn pointed to the data.[2] If a memory request required compaction of memory, this was done and
the table, called the master pointer block, was updated. The machine itself implemented two areas in the
machine available for this scheme - the system heap (used for the OS), and the application heap. [3] As long
as only one application at a time was run, the system worked well. Since the entire application heap was
dissolved when the application quit, fragmentation was minimized.

However, in addressing the fragmentation problem, all other issues were overlooked. The system heap was
not protected from errant applications, and this was frequently the cause of major system problems and
crashes.[4] In addition, the handle-based approach also opened up a source of programming errors, where
pointers to data within such relocatable blocks could not be guaranteed to remain valid across calls that
might cause memory to move. In reality this was a problem in almost every system API that existed. Thus
the onus was on the programmer not to create such pointers, or at least manage them very carefully. Since
many programmers were not generally familiar with this approach, early Mac programs suffered frequently
from faults arising from this - faults that very often went undetected until long after shipment. [5]

Palm OS and 16-bit Windows use a similar scheme for memory management. However, the Palm and
Windows versions make programmer error more difficult. For instance, in Mac OS to convert a handle to a
pointer, a program just de-references the handle directly. However, if the handle is not locked, the pointer
can become invalid quickly. Calls to lock and unlock handles are not balanced; ten calls to HLock are
undone by a single call to HUnlock.[6] In Palm OS and Windows, handles are an opaque type and must be
de-referenced with MemHandleLock on Palm OS or Global/LocalLock on Windows. When a Palm or
Windows application is finished with a handle, it calls MemHandleUnlock or Global/LocalUnlock. Palm OS
and Windows keep a lock count for blocks; after three calls to MemHandleLock, a block will only become
unlocked after three calls to MemHandleUnlock.

Addressing the problem of nested locks and unlocks can be straightforward (although tedious) by employing
various methods, but these intrude upon the readability of the associated code block and require awareness
and discipline on the part of the coder

Licensing:
OS Architecture:
System Requirement:
Performance:
Application areas:
Discussion:
Conclusion: