Vorab, ich finde Eure Sparte "MTN erklärt..." sehr gut und ambitioniert.
Dennoch scheinen mir einzelne Themen u.U. nicht ausreichend recherchiert.
Da ich mich mit dem Prebinding auch schon eingehender beschäftigt habe fehlen mir eine Aspekte, die ich doch sehr wichtig finde während sich mir andere Aspekte doch anders darstellen:

1. Pre-Binding-Datenbank?
Mir ist eine solche Datenbank nicht begegnet. Die Daten für die Symbole (das ist der allgemeine Begriff für Funktionen und Variablen, die Programme von den dynamischen Bibliotheken beziehen) stehen in den dylibs (Frameworks unterscheiden sich da nur geringfügig von Libraries). Diese werden von Apple so erstellt, dass sich die Werte der Symbole nicht überschneiden, sonst würde das Prebinding nicht funktionieren. Beim Erzeugen eines Programmes, werden die Verbindungen (links) zu den importierten Symbolen erstmal mit Nullen aufgefüllt. Durch den lazy-symbol-stub (bei Funktionen) oder den non-lazy-symbol-stub (bei Variablen) Mechanismus wird beim Aufruf der Symbole der wirkliche Wert des Symbols dereferenziert und in den Symbolvalue eingetragen. Das passiert während der Laufzeit.
Um das Laufzeitverhalten zu verbessern, wurden diese Symbole schon beim Starten des Programmes (bind-at-load) dereferenziert, ein Verhalten, dass sich aber nach wie vor mittels Umgebungsvariablen unterbinden lässt.
Da dies immernoch nicht zufriedenstellend war (pre-Jaguar) wurde das Prebinding überarbeitet. Dazu werden bei einem Programm die importierten Symbole aus den angegebenen dylibs (die Liste der verwendeten dylibs steht im Vorspann jedes Programmes, oder dylibs) dereferenziert und die Symbolwerte eingetragen. Da sich aber auch dylibs auf andere dylibs beziehen können (im Allgemeinen immer auf die C-Library) haben auch diese importierte Symbole, die dereferenziert werden müssen. Beim Prebinding werden also die Symbole von unten nach oben neu aufgelöst und die Daten aktualisiert.
Das Ganze wird dann schnell unübersichtlich, daher werden beim Prebinding auch die Namen und Module der Prebound-Libraries in den Vorspann geschrieben. Zudem wird noch eine Prüfsumme berechnet, die sicherstellen soll, dass nicht versehentlich aktualisierte Symbole mit alten Werten verwendet werden.
Also nach meiner Einschätzung gibt es keine Prebinding Datenbank. Die Informationen werden in den Vorspann und in die Symboltabellen von Programmen und Bibliotheken geschrieben und auch von dort gelesen, verifiziert und aktualisiert.

2. Fix-Prebinding-Daemon:
Im Start-Up-Code eines Programmes (dieser Codeschnipsel muss nicht extra programmiert werden, sondern liegt als crt1.o den Entwicklertools bei) wird ziemlich am Anfang eine Verbindung zum Kernel aufgebaut. An dieser Stelle wird vom Kernel der fix-prebinding Daemon gestartet. Dieser greift auf die Symboltabellen des gestarteten Programmes zu und prüft, ob diese in Ordnung sind. Diese Prüfung findet im Hintergrund statt, während das Programm schon läuft. Fehler versucht der Damon zu korrigieren. Gelegentlich kann dieser aber Probleme nicht lösen und erstellt dann einen Eintrag im system.log, der leider nicht besonders aussagekräftig ist. Das Starten des fix-prebinding Daemons kann man per Flags im Vorspann des Programmes unterdrücken.
Desweiteren misfällt mir, dass ich sowas mit meinen Programmen zulassen muss. Wenn ich den fix_prebinding daemon (oder auch den crash-reporter daemon) nicht aus meinen Programmen aussperren kann, dann bin ich auch offen für andere Programme, die sich Zugriff auf interne Daten verschaffen können.

3. Geschwindigkeitssteigerung durch Prebinding:
Da ich im Rahmen meines Projektes viel mit non-prebound Programmen zu tun habe, kann ich Euch versichern, dass der Unterschied kaum spürbar ist. Falls aber verknüpfte Bibliotheken große Fehler im prebinding aufweisen, wird das unter Umständen doch spürbar, da sich dylibs ja wie ein Netz untereinander verbinden. Macht Euch also keine Sorgen, wenn Ihr ein Programm von einem Rechner auf einen anderen kopiert, eher wenn Ihr das mit Bibliotheken macht.

4. Nachteile des Prebinding:
a. Änderungen der Dateien:
Durch das Prebinding wird die Programmdatei an vielen Stellen geändert, sodass ein und dasselbe Programm auf jedem Rechner anders aussehen kann. Dass kann durchaus ein Sicherheitsrisiko sein, da man nicht einfach einen Hash Bilden kann um festzustellen, ob das Programm z.B. durch einen Virus verändert wurde. Dazu gibt es allerdings Lösungsmöglichkeiten, die aber tief in die Struktur von Mach-O Programmen eingreifen.
b. Symbol-hooking:
Auch wenn dies weniger ein Problem des Prebinding als der dynamischen Laufzeitumgebung von OS X ist, genaugenommen könnte das Prebinding sogar davor schützen, möchte ich darauf eingehen. Als Angriffsvariante wäre es vorstellbar, dass man gefakte Bibliotheken erstellt und einspeist und dann Aufrufe in eine der Orginalen Bibliotheken auf die gefakte umlenkt. Damit hätte man dann vollen Zugriff auf alle Daten innerhalb des Programmes.
c. Fehlertoleranz:
Leider ist das Prebinding nicht besonders fehlertolerant. Sollte eine der angegebenen Bibliotheken nicht gefunden werden, dann wird das Prebinding für die ganze Anwendung verworfen. So geschehen bei iPhoto 2 unter Panther. Apple hatte nämlich eine der Bibliotheken von "Private Frameworks" in "Frameworks" verschoben, iPhoto aber nicht angepasst. Daher konnte iPhoto 2 nie prebound werden (ich konnte das Problem zwar manuell beheben, das macht iPhoto 2 aber auch nicht viel schneller).

Ups, das ist jetzt doch länger geworden, als ich gedacht hatte.

Also seid mir nicht böse, ich möchte Euer Engagement nicht bremsen, aber manche Sachen müssen nicht nur einfach sondern trotzdem richtig dargestellt werden - dass gehört aber sicher zu den schwersten Aufgaben eines Journalisten. Macht weiter so, aber vielleicht solltet Ihr bei Tipps und Tricks auch eine Kommentarfunktion einbauen.

Klasse, hab' zwar nicht alles verstanden - fühle mich aber schon schlauer

Kannst Du vielleicht noch einmal erklären, warum Programme, die nicht "successful prebound" werden konnten, trotzdem laufen (z.B. GarageBand)?

Entweder, die dynamisch zu ladende Library ist vorhanden bzw. wird gefunden (dann müßte doch auch das Prebinding funktionieren) oder nicht, dann dürfte doch aber auch das Programm nicht korrekt funktionieren?

Ist das Prebinding vergleichbar mit "ldconfig" unter Linux?

Das ist nicht Dein Ernst, oder?

Oder doch? Du meinst, MTN hätte diese ganzen Zusammenhänge für jedermann verständlich aufdröseln sollen (was Du ja nicht getan hast, und trotzdem war Dein Text recht lang)? Wer soll das lesen? Und wer soll es sich merken?

Ja, bitte. Wenn, dann richtig aufdröseln.

species8472:
In den Symboltabellen sind auch Referenzen auf die dylibs vorhanden, in denen die Symbole definiert sind.

Die Vernetzung der dylibs untereinander (Rekursionen sind dabei nicht möglich), führt dazu, dass viele Symbole mehrfach importiert werden. Insbesondere die StdCLib (bei OS X heißt die "/usr/lib/libSystem.B.dylib"), da alles ja irgendwo auf diese lib aufbaut. Wird ein Symbol gefunden, wird es als gefunden markiert und in allen images (das Programm und die dylibs) aktualisiert. So hangelt sich dyld im Speicher durch alle Symboltables aller geladenen dylibs, bundles und des Programmes. Die Vernetzung der dylibs untereinander kann also dazu führen, dass alle Symbole während der Laufzeit gefunden werden, obwohl eine dylib scheinbar fehlt - diese wird dann von einer der anderen dylib mit dem richtigen Pfad geladen.
Wenn ein Symbol tatsächlich nicht aufgelöst werden kann, dann wird auch das Programm nicht gestartet (sowas hatte ich schon) und man bekommt einen Eintrag in console.log "dyld: Undefined Symbols: ****".

Der Unterschied liegt also beim prebinding tool: beim prebinding wird nur die aktuell zu betrachtende Datei analysiert. Die Vernetzung der Bibliotheken wird über dependancy trees abgebildet und dieser wird dann von low-level bis zum Programm abgearbeitet. Aber immer nur eine Datei für sich. Somit soll sichergestellt sein, dass alle importierten dylibs schon prebound sind und somit auch keine Probleme zu erwarten sind. Fehlt aber eine gelinkte dylib, dann wird abgebrochen. Dass die Symbole, die innerhalb der vermissten dylib liegen, eventuell von anderen dylibs indirekt aus der gesuchten (und woanders gefundenen) dylib importiert worden sind, kann dabei nicht festgestellt werden.

Im Gegensatz dazu merkt dyld zwar, dass eine dylib nicht geladen werden konnte, kann aber dennoch alle Symbole auflösen, da dyld ja im Speicher mit allen gelinkten dylibs gleichzeitig arbeitet und somit Redundanz den Fehler kaschiert.

Jörn Dyck (Mac-TV.de)Eigentlich wollte ich ja nur auf die Sache mit der Datenbank eingehen, aber wie ich dann so am schreiben war... Zudem habe ich hier schon so niveauvolle Threads gesehen (ich denke an den über "virtual memory"), dass ich glaube, dass eine Richtigstellung und intensivere Betrachtung einige Leser interessieren wird.
Lesen soll's, wer sich dafür interessiert.
Wer sich das nicht (teilweise) merken kann, der hat sich dafür auch nicht wirklich interessiert.

ArekhonBitte die Quellenangabe in der KnowledgeBase nicht vergessen - und schick mir eine Kopie, wenn sie fertig ist.

ArekhonMacJournal - eben wie sieht das aus? Du kannst mir auch mailen (Du hast ja weder mail noch ichat angegeben).

ssb: Ich glaube ich gebe mir keine Blöße, wenn ich Dir sage, dass ich nichts, aber auch gar nichts verstanden habe!

Ich finde es überhaupt nicht schlimm, manchen Beitrag zu lesen und ein paar Lücken zu behalten; ich kann dann nachfragen, oder aber es erschließt sich mir eben im Laufe der Zeit. Auf jeden Fall erweitert es meinen Horizont so nach und nach.

Wenn ich Deine Beiträge hier lese, verstehe ich, das Frameworks und Libraries ähnliche Funktionen haben (aha!), und das Prebindings durchaus (sicherheitsrelevante) Nachteile mit sich bringen können (ggf. bedenklich und von daher in jedem Falle interessant!).

Ansonsten verstehe ich hier als Nichtinformatiker absolut null, nichts, was ich sehr schade finde.

Klar gibt es Fachbegriffe, sie haben auch ihren Sinn. Guter Journalismus (oder allgemein gute (Schul-, Examens-, ... Arbeiten, gute Beiträge) werden so geschrieben, dass die Masse sie zu verstehen in der Lage ist. Daher halte ich Deine Beiträge, weil sie ausgrenzen, für schlechte Beiträge. Schade.

ssbAlso soviel an Arroganz und Ignoranz ist mir selten über den Weg gelaufen...

ssb
Danke, jetzt hab' ich es verstanden ...

Der Sinn einer Examensarbeit ist es, ein bestimmtes Thema einigermaßen komplett und kompetent vorzustellen, und nicht, Hinz und Kunz alles zu erklären ... in einer medizinischen Arbeit wirst du genausowenig verstehen wie in einer Abhandlung über Riemann'sche Knoten ... das ist nunmal so.

Wer alles kapieren will, muss halt auch alles lernen, und das meist von Grund auf, und weil das nicht geht, hat sich der Mensch spezialisiert.

Ich kann z.B. mit den meisten Grafik-Themen wenig anfangen, kenn mich da einfach nicht aus und bin künstlerisch mehr als unbegabt ... deswegen merk ich mir da auch nicht alles, schon allein, weil mir der Bezug dazu fehlt.

Was @@ssb damit meinte war, denke ich, dass es für diejenigen interessant und merkenswert ist, die mit den meisten Grundbegriffen vertraut sind.

Du kannst doch sicher auch irgendwas, was hier vermutlich keiner so gut oder überhaupt kann. Und wenn er den fortgeschritteneren etwas zu sagen hat, dann lass ihn doch. Außerdem waren die Kernpunkte doch gut ausgeführt.

Du fährst doch auch Auto, ohne zu wissen, wie es genau funktioniert ( ich übrigens auch ). Wenn es mich tatsächlich sehr interessieren würde, dann hätte ich mich auch eingearbeitet ... sei es als Hobby oder Beruf ... Ich denke, mehr wollte er damit nicht sagen, schongarnicht angeben, wieviel er dazu weiß im Vergleich zu dir ...

Ties-Malte:
Auf so eine Reaktion habe ich gewartet.
Wenn Du tatsächlich überhaupt nichts davon verstanden hast, dann sehe ich das nicht als Blöße. Wenn, dann war es eine Zeitverschwendung, das überhaupt zu lesen. Sorry, dass ich Deine Zeit darauf verschwendet habe, aber Du hattest auch jederzeit Gelegenheit mit dem Lesen aufzuhören. Ich mache das auch immer so, wenn ich etwas nicht verstehe und es mich nicht ausreichend interessiert.

Dass meine Beiträge kein guter Journalismus sind weiß ich selbst. Stört mich aber auch nicht, da ich kein Journalist bin. Mich stört es aber, wenn etwas falsch ist. Und eine Prebinding-Datenbank gibt es nicht. Und deswegen fing ich ja an den Beitrag zu schreiben.

Dass Du meine Beiträge (du scheinst ja dennoch alle gelesen zu haben, sonst könntest Du so eine generelle Aussagen nicht treffen) schlecht findest, sollte dazu führen, dass Du meine Beiträge nicht mehr liest.

Meine Absicht war es sicher nicht, andere mit meinem Beitrag auszugrenzen, sondern einige mit einzubeziehen.

Desweiteren frage ich mich, wieso Du denkst, dass ich ausgrenzen will. Abgesehen davon, solche unsachlichen Aussagen gehört hier wohl nicht her.

Ties-MalteDas hat nichts Arroganz oder Ignoranz zu tun. Wenn mich etwas nicht interessiert, dann merke ich mir auch nichts darüber. So kann ich mir ein ganzes Fussballspiel anschauen, und weiß nachher nicht mehr als das Ergebnis, da mich Fussball einfach nicht interessiert. Meist schaue ich es aber auch gar nicht erst an.
Und es gibt noch viele Themen, bei denen das ähnlich ist. Wenn ich mir also etwas nicht merken kann, dann wollte ich das auch nicht. Ein solches Verhalten ist vollkommen menschlich - das Gehirn selektiert eben. (Anderes Verhalten wäre auch krankhaft - Authismus).
Das wollte ich damit ausdrücken.
Eigentlich wollte ich mir einen Kommetar dazu verkneifen.
Kann ich daraus schließen, dass alle Beiträge, die Du nicht verstehst, Dir das Gefühl vermitteln, ausgegrenzt zu sein und Du sie damit automatisch als schlecht beurteilst?
Es gibt auch viel, was ich nicht verstehe, aber ich finde das deswegen nicht schlecht. Wie kann ich etwas beurteilen, was ich nicht verstehe?

Daher finde ich Deine Beiträgezu diesem Thema (besonders die zitierten Passagen) unsachlich und intolerant, da diese nichts mit dem Thema zu tun haben sondern mit meiner Person bzw. mit meinem Schreibstil.

ssb: sorry, Missverständnis: Ich meinte nicht alle Deine Beiträge, sondern die dieses threads! Insofern wollte ich dich nicht persönlich angreifen (auf welcher Grundlage auch), sondern Deine obigen Beiträge kritisieren.

Wenn Beiträge falsch sind, werden sie korriegiert, völlig o.k., das ist auch die Funktion eines Forums. Nur, warum tust Du es nicht gleich so, dass man´s versteht? mtn will genau das mit ihrer Reihe tun. Möglicherweise wurde der Begriff "Datenbank" falsch verwendet, beschreibt aber für Laien, um was es in etwa geht. Oder es stimmt auch nicht (was ich nicht beurteilen kann, weil ich Deinen Beitrag damit nicht vergleichen kann).

Klar hätte ich aufhören können zu lesen. Offensichtlich hatte ich also einerseits Interesse, andererseits die Hoffnung, doch die groben Zusammenhänge erfassen zu können

Gut, mache ich´s kurz: Schön, wenn Du es besser weißt, schön, wenn jetzt zwei bis drei Leute schlauer sind. Ich würde mich freuen, wenn es (von wem auch immer) so dargestellt werden könnte, dass auch ich es verstehe.

Oliver Kurlvink: Oooh, doch!!! !

Und umgekehrt scheint bei Hardcore-Linuxern kaum ein Verständnis dafür zu bestehen, was ein Mac-Anwender von einem zu installierendem Programm erwartet... und warum das Zusammenbasteln von zig Einzelkomponenten ohne Installer schlicht als Zumutung empfunden wird.

ssb: Einen Schüler da abzuholen, wo er sich befindet, ist allemal hilfreicher, als ihn für dumm oder uninteressiert zu erklären, weil er sich nicht schon auf dem Niveau des Lehrers befindet...

Nein, ich halte nicht alle Beiträge für schlecht, die ich nicht verstehe, aber solche, die ein Bemühen um Allgemeinverständlichkeit von Anfang an vermissen lassen.

Ties-Malte:
Dann frage doch einfach nach - da haben dann auch alle anderen was davon.

Ich schreibe solche Beiträge nicht, um mich über andere zu stellen. Und manchmal verliert man einfach den Blick dafür, was für Laien noch verständlich ist, wenn man sich sehr intensiv mit den Innereien von OS X und Application-Startup-Prozess beschäftigt. Vieles an diesem Gebiet habe ich mir durch monatelanges Studieren (Inside MacOS X: The Mach-O Runtime Architecture Experimentieren (mit einem Debugger Systemroutinen analysiert) und Analysieren (den Darwin Source) erarbeitet und wollte das Wissen mit anderen teilen.

Also wer etwas nicht verstanden hat, fragt mich einfach - dafür ist ein Forum da.

Ties-MalteEntschuldigung angenommen.
Nix für ungut!

Also ich fand es interessant. Dieses Posting wandert gleich in meine Knowledge-DB.
<br>Thx ssb!

ssb<br><br>
<br>Naja, ist mehr eine lose Sammlung in meinem MacJournal, aber Quellenangabe wird gleich nachgetragen.
<br>

Mann-O-Mann! Dass sich gleich immer alle an die Kehle gehen müssen!
<br>
<br>Ich fand den MTN Beitrag gut genug, dass er mir ausreichend Einsicht bezüglich Prebinding gebracht hat. Dennoch heisse ich die ausführlichen Ergänzungen von SSB sehr wilkommen. Also, warum immer gleich rumnörgeln?
<br>
<br>Ist doch alles Chico, oder??

ties-malte
<br>
<br>dann hast du noch nicht mit überzeugten linuxern zu tun gehabt und versucht denen zu erklären, warum einige gui-technische dinge ihrer applikation für endanwender nicht zu durchschauen sind