Advocacy
Dojo (HowTo)
Reference
Markets
Museum
News
Other
Myths
Press
General
Hack
Hardware
Interface
Software
Standards
People
Forensics
Web
CodeNames
Easter Eggs
History
Innovation
Sightings
Opinion
Martial Arts
ITIL
Thought
|
The Mac innovated many things in filing systems, and took paradigms much further. One area that gets no credit, because only geeks truly appreciate it -- and only the geeks who know Macs -- is the MultiForked Filing System.
Forks
Files contain data. But not all data is equal. Sometimes you have user data, and programmer data. Sometimes you have data that is standard type (like a Picture, Sound, String, etc.), and sometimes the data is actual code, or sometimes it is custom structures used only by the programmer.
Apple created the concept of multiple "forks" for files, with different "indexes" (entry points). One is used for the data (like normal), another is the resource fork. The resource fork is a way to have all of the common elements (strings, icons, sounds, pictures, and so on) in a separate database/fork separate from the programs data. This allows people to edit these common elements without having to alter the data fork (and without having to know anything at all about the data fork).
Without a separate database/fork for resources, once an application or file is created, everything about it is "opaque" and unknown to the outside world -- there is no changing or browsing of common elements. You can't fix things or change things! It is because of the resource fork that it is much easier to "localize" programs for different countries, and it is easier to fix and edit the interface (or many interface elements) separate from the rest of the code. This is a big gain to programmer, support people, and even users because of the features that it empowers (many power users alter/hack Mac Applications).
Apple created Forks in 1983, Microsoft finally added a forked filing system to Windows NT (NTFS) in '93, only about 10 years after Apple had it. Microsoft hasn't actually used it for Windows or the API's yet -- they just have the theoretical capability to use it. To actually use it (and for it to have value) they'd have to do things like add a resource database and management system (like the Mac has) and re-architect the OS to be GUI (Graphical User Interface) from the ground up -- and that would have taken time. But Microsoft does use the forks under NT to keep security information, and of course when they are serving Mac files. Remember NTFS filing system isn't the only Filing System used by NT, they also use FAT (File Allocation Table) filing system (which used to be called BAM, for Block Allocation Map, before Microsoft borrowed it). It will probably be until Windows00 (Win2000), expected before the end of 2000, before NTFS will be completely mainstreamed (another 7 years after introduction, and roughly 18 years after the Mac).
NTFS's forks are nicer in that they actually allow many forks -- Macs original MFS and HFS only allowed for a resource and a data fork, though Apple had been talking about adding multiple named forks for years before NT. Copland's Filing System had any number of forks, and HFS+ does as well (which looks suspiciously identical to the one that was talking about for Copland).
There was a not too dissimilar concept to a "fork" in a minicomputer (Digital Equipment's VMS). It allowed a file to have multiple "parts", each part was a different "revision" of the file. This was built-in versioning. It was more implemented as files that were "stuck" together or related -- which is similar, but not quite as tailored for the job. The Mac was a personal computer, not a $100,000+ minicomputer.Someone said something about later UNIX (Mach) that uses segments -- they being similar to multiple forks, but I don't know enough about them. Also I assume some other mainframes and minicomputers used some not completely dissimilar concepts. I'll read up (eventually) and add more to this article.
There are some problems with forks. Since no one else utilized them, despite them being a serious advantage, this makes the Mac a little unique -- and requires some translation getting some files in and out of Macs, or sent across the Internet, and so on. So innovation sometimes hurts you if others don't follow. Apple outsmarted the industry -- but it made them unique. I'd still gladly pay for the "uniqueness" with the versatility of file-forks -- or for some way to bind dependencies.
NeXTSTEP (UNIX hybrid)
NeXT solved Resources in a very neat way. They would simulate a multi-forked file system in the UNIX File System (UFS), by having files/applications that were really folders with a special extension (tag). Every folder with that extension (.app) would be treated like a single file, but it would really contain many files, each of which was a separate fork. (You accessed the sub files by wrapping them with "#"). So you could have a data file, a bunch of sound files, a few files that were pictures, and so on -- all behaving like resources. It was a really neat compromise, or way to make a multi-forked filing system, out of a system that didn't have that capability. It was an interesting innovation. Apple uses this in OS X Server -- but I think OS X client will use HFS+ (which has multiple forks built in).
Also the British Acorn RISC Computer used a nearly identical scheme to NeXT. Remember the ARM chip used in the Newtons? ARM stood for Acorn RISC Machine.
Conclusion
Separating a file into multiple forks was a really neat innovation. Some of the concepts came before -- like binding multiple files together -- but not how Apple had done it. The truly sad part is that sloth ruled, and others didn't copy Apple in this innovation. It was just too much work to redo everything, so people just left things in their ugly state. There are lots of reasons why the Mac way is better -- but many people just don't understand it, so they make fun of it.
Apple could have done more with Forks as well. Apple's implementation in 1984 was good for 1984 -- but by the 90's it was getting long in the tooth. I like the hybrid solution used by NeXT and Acorn -- in many ways they are a better implementation (but they were done years later). Some of the disadvantages of Mac resources were that you could only handle 65,000 of any type of resource, and realistically you could bog down the system with less than maximum case. So we need continued improvement.
Apple is adding a far more complex multiforked file system working (HFS+) -- which is a step in the right direction. There have been other projects like their Bento (Japanese Lunch-Box) Object-File-Format used in OpenDoc -- which could handle many objects inside of a file, and could handle versioning as well. This was a sort of a fork for every object, or a way to make a standard format for the data-fork as well as the resource fork. It died as an open format for political reasons (like many big companies don't want other companies to be able to read and write their file formats -- even if that would be great for users). There was also some research done in the Copland time frame about file binding and dependencies -- so that many files are bound to each other and if you copy one file, all the dependent files can be copied as well. All of the things Apple has done in these areas were innovative -- and this is only one aspect of Filing System innovations by Apple. Of course Digital Equipment did some innovation as well with VMS, as has NeXT, Acorn, and others. I'm waiting for Microsoft to do something innovative with a filing system -- but it's been 20 years with nothing. I hear they are going to try to copy the Bento (Object/Component File Format) idea in the future.
|
