The Panther Installer, however, will let you run multiple packages at once and will install them in the order opened, waiting for the previous one to complete before running. That way, at least you can set up a series of installations and then go about other business or pleasure while you wait.

Doesn't quite work in practice. I've tried this on my AlBook after its HD died. Killed the login window. Had to reinstall from scratch.

Circa 10.0 or 10.1 I successfully stubbed out the command-line tool the installer calls to do prebinding with a C tool that just returned 0. This would enable me to do a bunch of installs without waiting for prebinding, and then prebinding just once.

Haven't tried it with 10.2 or later.

Pacifist will let you install without doing the pre-binding step. Or at least it could the last time I used it.

Take a look at 10.0 again and recall how life was like before prebinding.

Look, having to prebind after each install of 15 or so is a royal pain in the ass. However, you freely admit you were trying to get around the "correct" way of installing things (for an eminently reasonable purpose, but still). When users install one or two updates as they show up, it's not noticed and the speed benefits *are* noticed day-to-day.

Sorry you had such a rotten evening, and yes, Apple's Installer should have properly chained the installs, but don't fault *prebinding* for all of this mess. Place the blame with Apple's installer where it belongs.

No, it is OS X's fault. Do you remember Mac OS 9? Where was the pain in launching applications there?

These speed benefits don't exist! prebinding is a "solution" to a problem that shouldn't even exist and exists in no other major OS that I know of. Why is that?

>"Optimizing" is what Apple calls the prebinding phase in the installer.
>It isn't actually optimizing anything.

Prebinding *is* optimizing. It's optimizing the launch time of applications by binding applications to their libraries so they don't have to do it when you actually run them.

>Prebinding *is* optimizing. It's optimizing the launch time of
>applications by binding applications to their libraries so they
>don't have to do it when you actually run them.

No, it isn't Optimizing. It is addressing a major flaw in mach-o that shouldn't exist. When it is addressed it is faster than when it isn't addressed, yes.

>These speed benefits don't exist! prebinding is a "solution" to a
>problem that shouldn't even exist and exists in no other major OS that
>I know of. Why is that?

Okay, is this a serious question or just a rhetorical question? If you really don't know why prebinding exists in Mac OS X, and why it doesn't exist in other OSes, you should read bill bumgarner's explanation:

http://radio.weblogs.com/0100490/stories/2002/08/24/prebindingExplained.html

The question was why don't other OS's have prebinding? Why is OS X the only one (that I am aware of). XP doesn't have it. OS 9 didn't have it. I know exactly what prebinding is and this is another reason I hate it.

>When people are testing the speeds of OS X vs XP,
> then should also consider the time it takes to install.

You're joking, right? If not, here's your Jello...

I spent most of yesterday recovering from the ill effects of doing "other things" while the installer was still prebinding after that last security update. From now on, as soon as the installer starts, I'm stopping.

Sigh.

>The question was why don't other OS's have prebinding?

Presumably because they don't have weak binding. Normally, you link libraries into your executable file on compile time. Or maybe I'm not getting something.

Rosyna, I'm sometimes astonished that you're a developer, yet so utterly misinformed on issues that one would think are critical to your profession.

Again, prebinding is not at fault (or shall we start discussing why Windows registers DLL's and can take forever mucking with the registry?), but rather the problem is that the installer does not chain installs very well.

What's with all the anonymous hate? Of course other OSes have weak linking. CFM, for example, resolves all the weak links when the app is launched, and (surprise) manages to do so really quickly. The same holds for ELF binaries. The above-mentioned link describing prebinding doesn't really address the issue of why Mach-O needs this and other formats don't. I do know that Mach-O (until 10.2) didn't have a concept of weak-linking in the same sense that CFM did, so perhaps that is part of it.

People are actually bringing prebinding over to other platforms. Search for "ELF prebind" and you find things like:

http://mail-index.netbsd.org/current-users/2002/12/01/0005.html

> CFM, for example, resolves all the weak links when the app is
> launched

I think this is wrong. the code fragment manager resolves weak links when they're actually used, not when the app starts, and I think there's also the difference that with cfm, there's always only one version of a shared library on any Mac. prebinding, otoh, links to the current version of a given version (e.g. a version with the same interface as the version used on compile time) of a library. I think.

although I don't usually program Macs, so I wouldn't be surprised if I were horribly wrong.

http://developer.apple.com/technotes/tn/tn1083.html

Re: Security

http://www.periodic-kingdom.org/People/Miro/Papers/

Mountain, molehill...

quote:

"I think this is wrong. the code fragment manager resolves weak links when they're actually used, not when the app starts, and I think there's also the difference that with cfm, there's always only one version of a shared library on any Mac. prebinding, otoh, links to the current version of a given version (e.g. a version with the same interface as the version used on compile time) of a library. I think."

CFM resolves both weak and strong links when the fragment referencing them is loaded. In most cases, this is at application launch time. You can watch the process in the CodeWarrior debugger - the fragment info prints out to the log. The difference being that when a strong link fails to resolve, the application does not launch (or the shared library does not load).

You can have more than one CFM library in the search path. CFM has a well-defined set of rules for determining which shared library to link in. Those rules are published on Apple's web site:

http://developer.apple.com/documentation/mac/runtimehtml/RTArch-21.html

Interesting. This probably means that CFM executables could profit from prebinding, too :-)

I read the link about CFMs ability to differentiate between versions of a library. It doesn't seem to be as powerful as what the Mach-O Runtime Architecture (where the system itself manages several versions of a library or framework) can do, but I don't think the difference explains the difference in speed.

Prebinding is sort of trying to reimplement OS 9 behavior on OS X; ie having symbols resolved at start so the costly runtime resolve won't be invoked. (it will be invoked if the prebinding checksum of a particular symbol don't match anylonger however.)

As far as I'm concerned, prebinding has been totally broken ever since 10.2.8--that's when my console and system logs started filling up with 'application X could not be launched prebound, the file changed after the prebinding problem was noted'. Hasn't stopped ever since, and that was after a full reformat and reinstall to move up to Panthro. (No, the -force switch doesn't help.) Strangely, my system still works, and applications launch quickly. But I still have to sit through interminable periods of 'optimizing' after updates.

When using Mac updates burned from another computer. Remember the invisable files? After you have put the files on your computer you need to: 1. make files that are invisable visiable 2. unlock the D_store in that folder and trash it. That will force your system to create a new D_store file that matches the checksum. Then you'll have the correct hardware fingerprint present in that folder allowing you to execute updates. Believe it or not its a good thing that it won't install untill it gets the hardware id set correctly unless you want a hexdecimal nightmare going which prebinding is useless and would only create a hack missmatch at best.