Advocacy

  Myths
  Press

Dojo (HowTo)

  General
  Hack
  Hardware
  Interface
  Software

Reference

  Standards
  People
  Forensics

Markets

  Web

Museum

  CodeNames
  Easter Eggs
  History
  Innovation
  Sightings

News

  Opinion

Other

  Martial Arts
  ITIL
  Thought


Packages (New Resources)

By:David K. Every
©Copyright 1999


Resource Management is changing in OS X and Carbon. These resource changes are coming soon -- actually, they will come to Sonata first, then OS X later.

If you don't know what resources are, then read Hack : What is a Resource or Innovation : File Forks to get what these things are and to understand a little about how (why) they work.

There will still be traditional resources, just like now -- but the way they are bundled in with Applications is changing (expanding). In fact, the way that you "package" an Application (with all the code and resources) is being radically improved.

The Old Way

In the early days, Mac Apps were very simple.

What the user sees = Application.

There was one Application that the user saw, and it did everything. People that wanted to move an Application would just move it, and everything to do with that Application would move as well (it was self-contained). Everything you would want to contain for an App was in that single file. Things were simple and pure.

Well times they have been a changin'. The problem was that a single file (Application) couldn't contain everything that a user might need. So things grew, and grew, and grew. Now days a single Application usually a folder, that contains many parts of the Application, some plug-ins, some parts, and so on. It is big, messy, and worst of all that isn't all of it -- some parts of an Application can be stuffed into the extensions folder (shared libraries) or put elsewhere on the system at install time. When you copy a folder, you may not get those parts, and so your Application is broken, some installers may remove those shared libraries, which can break another Application, and so on. The Mac is almost behaving as poorly as Windows. And we need even MORE complexity and power for building future Applications than the mess we already have.

So now it is time (or well over time) to make things easy again.

The New Way (called a Package)

So Apple is bringing back the single Application.

What the user sees = Application.

Now of course, Apple isn't going to be able to force users to cram everything into one file again -- that would be ugly and bad, and you can't turn back the clock. But Apple can make it look like that, even when there is really a whole hierarchy (directory tree) containing an Application.

Apple created a solution that was a very nice hybrid of the way that NeXT did things, combined with the way the Mac does things -- and we get something that is better than either.

Apple will use a special bit for a folder, which tells the folder that it is a special hierarchy of folders that will contain all the proper parts that the System wants for a single Application. What will truly be there, behind the facade of a single Application, is really the following:

Application Alias
Support folder
         info.plist - (xml tags to explain)
    Executables folder
        OS 8
        OS X
        Other
    Resources folder
    English.lproj
      English Resource Files
    Japanese.lproj
      Japanese Resource Files
    Non-localized.lproj
      Common Resource Files
    Shared Libraries folder
     Library

What this hierarchy gives users, and programmers, are many new features.

  • The user will just have to work with a single Application on the new version of the OS -- but even on the older versions of the OS, they will still see something that makes sense and is standardized.
      
  • A single Application can really contain many binaries (executables). Including versions of the code for multiple versions of the OS. So a single Application can run on OS 8, Mac OS 9, Mac OS 10 -- and they can even run on multiple platforms (that support this OS). So someday there could be an OS 8 for PowerPC version, and a OS X for Intel version of the Application, and so on. Basically this is planning ahead.
     
  • A single Application can support multiple languages. Currently this can be done on the Mac OS -- but it is tricky. Basically you would have to have separate files for each language, and you'd have to load the right resources for the language you are using (and often have duplicate resources in each version of the file). Under the new way, the same Application will automatically support the Language / System that the user is using, and the programmers have a little less work to do.
     
  • Shared Libraries are bundled with the Application. This is important. The Operating System will automatically figure out (and manage) multiple shared libraries (and versions) for programmers. There will be duplicate versions of shared libraries on the disk (assuming multiple Applications both use the same shared library). Of course the system will only let one instance of a version to be running (to save on memory). And under the new way, the user (or Application) can delete or relocate any Application (and it's shared library) -- and this will never hurt any other Application. That is a refreshing change over today, where deleting a library can break other Applications.
      
  • The Programmer gets far more metadata (extra information about the file) contained in a more versatile format (.xml). This will allow for more growth, and more custom information, and yet it is in a more standard format, and the whole way this system works is more compatible with other filing systems (than the current Mac way).

Conclusion

Basically what all this means is that Applications will just be magic for users and programmers. Programmers just bind in all the things that they need to work. New Resources (Application binding) use the best of the NeXT way -- but is still compatible with Macs, old resources, and you can do more than you could before. Things should be even more transparent for users, because of Mac advantages as well, and you can still encapsulate file fragments into a single file. It will be far harder to break programs by deleting a component (as a programmer or user). This system is far more versatile than the current Mac way. And this system is more standard, and is more likely to work across networks since any filing system can understand what is going on. This is truly the best of both worlds. It is very rare that you can get a Win-win (win-win-win-win...) type of improvement in any sort of engineering -- but this appears to be one of those rare cases.


Created: 05/11/99
Updated: 11/09/02


Top of page

Top of Section

Home