[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: using dmg files (fwd)

From: M. Uli Kusterer
Subject: Re: using dmg files (fwd)
Date: Sun, 26 Sep 2004 14:38:11 +0200
User-agent: MT-NewsWatcher/3.4 (PPC Mac OS X)

In article <address@hidden>,
 Markus Hitter <address@hidden> wrote:

> Am 25.09.2004 um 21:02 schrieb M. Uli Kusterer:
> > I personally don't like disk images too much. They're simply the only 
> > compression and packing method that shipped with MacOS X 10.0
> Huh? There's gnutar,

Yes, but as I said further on in my sentence, gnutar is a command-line 
tool, and  Apple wanted a GUI tool.

> Installer.app, zip, ...

 Installer.app's .pkg format is way more than just an archive, and you 
can't readily create one. .dmg allows you to pack up any folder, and it 
doesn't require you to specify an installation location.

> > and didn't swallow Mac resource forks
> Well coded Coca apps don't use resource forks.

 Yes, modern Cocoa apps don't use resource forks for any vital 
information. They *do* use them for some kinds of meta-data, though, 
like custom icon previews for documents.

 Also, Apple couldn't just cater to Cocoa apps. Apple needed a tool that 
would also handle Carbon applications. That's why they needed .dmg.

> If you really need them, 
> you can provide them as ._files (see /Developer/Tools/SplitForks) and 
> recreate them after installation using 
> /System/Library/CoreServices/FixupResourceForks. Installer.app will do 
> this automatically for you.

 Yeah, I can see typical Joe-Mac-user user doing that on a .tar.gz 

 I'm not saying that there weren't workarounds for a typically savvy 
user. I was just giving the rationale why Apple, in the interest of 
typical MacOS usability (which doesn't consider command-line tools as 
good usability if you could have a GUI) chose to add .dmg.

-- Uli

reply via email to

[Prev in Thread] Current Thread [Next in Thread]