Midgard - Midgard Executables

[Hansinator]

Hi ho!

Ich weiss, midgard ist nochnicht so weit... aber bald gibt's ja floppy support wie es aussieht :D
Also greif ich mal wieder meine idee von einem XML Executable format auf ;)

MXE - Midgard XML Executable (oder so ..)

Dabei geht's darum, die besten eigenschaften von den besten executable formaten zu nehmen, und XML kompatibel in eine executable zu basteln.
Z.b. für's dynamische linken bis hin zu app-ressourcen.

Alles was ich mir bisher gedacht hab ist:
Mime types im header, und zwar für die ressourcen die in der MXE vorhanden sind.

Dabei ist der executable code selber auch eine ressource, aber speziell als der ausführbare bereich gekennzeichnet.

Damit es keine probleme gibt mit XML, wird der binary-teil base64 encodet (http://de.wikipedia.org/wiki/Base64).

Soeine anwendung könnte ihre dependencies oder sonstwelche informationen, die dem OS mal nützlich sein könnten in ihren xml-header-teil schreiben.
Vielleicht wird das format ja mal von anderen OSen adaptiert.
Durch die erweiterbarkeit kann man z.b. eine multi-os executable herstellen, wenn der compiler gut ist :D
Die realisierung ist ganz simpel, und zwar muss die anwendung lediglich mehrere executable ressourcen in sich haben, das os kann sich dann den teil aussuchen, den es ausführen kann ;)

Das ist vielleicht ein wenig weit her gegriffen, aber vielleicht haben ja mal ein paar leute lust, das ein wenig auszuarbeiten.

Ich fänd das mal ne coole sache ;)
Lizer, was sagst du dazu?

[lizer]

Klingt nach 'ner interessanten Idee. Ist leider mit einem (zumindest für unsereins) immensen Aufwand verbunden. Den Compiler kann man sich sparen, sonst müsste man ja für jede Sprache einen bauen. Am besten wäre es wohl, eine Art Linker zu schreiben, der Object-Files (die mit einem beliebigen Compiler erstellt werden können) zusammen mit eventuellen Ressourcen etc. verlinkt und daraus eine entsprechende MXE erstellt.
Nachteile, die mir jetzt grad einfallen: Da Ressourcen nicht mehr ge-outsourced werden können sondern alle in der Binary drin stecken, wird 'ne MXE ziemlich groß. Bei 'nem 'normalen' Programm könnte man z.B. ein Sound-File laden, abspiele und den Speicher wieder freiräumen. Hier wäre diese Datei die ganze Zeit im Speicher. (Eine Lösung wäre es, diese Dateien kurzfristig zu entpacken und nach Ende des Programms wieder zu löschen, das müsste man halt noch weiter ausarbeiten.)

Noch schlimmer wird es mit diesem Multi-OS Zeug. Wenn du z.B. ein Programm unter Midgard, Linux, BeOS und MacOS laufen lassen willst, wird die Datei doch recht groß. Musst auch bedenken, dass jedes OS andere Libraries hat und du daher auch 4 Header mit den Dependencies brauchst. Und wenn du z.B. in einem OS 'ne externe Library nutzt (z.B. um ogg-Files zu spielen), unter 'nem anderen OS aber keine vergleichbare Lib existiert, bist du vollkommen aufgeschmissen :)

Kurz gesagt: Wenn das jemand gescheit ausarbeitet und besagten Linker schreibt, bin ich gern bereit, einen Interpreter auf Kernel-Ebene zu implementieren. Kannst ja mal gucken, ob da jemand mitmachen will und gegebenenfalls ein Projekt aufmachen. Sobald ein Bisschen was steht, könnten wir dann zusammen arbeiten und das in Midgard implementieren. Z.Z. bin ich aber vollauf mit Treibern beschäftigt, ansonsten wär ich sofort dabei :)

[Hansinator]

Jo, aber niemand verbietet ja dem programm externe ressourcen zu laden!!
Der kernel müsste ja auch nur den executable teil laden, wie man auf die anderen ressourcen zugreift ist ne andere sache.

Das PE format speichert auf ähnliche weise ressourcen, und die programme können die halt irgendwie laden (z.b. der windows kernel, der hat das boot logo als ressource in sich)

Das mit dem multi os stimmt, aber nehmen wir z.b. mal den fli4l router..
Da ist im dl ne exe für win und ein binary für linux drin um disk images zu erstellen, und ne bat und ne .sh ..
Wenn das eh schon so aufgebaut ist, kann man das auch gleich in eine datei stecken.

Das mit dem linker ist richtig, das mein ich eigentlich auch so ;-)
Man muss den binary code ja letztendlich nur in eine MXE zusammenlinken.

Naja, wie wär's denn wenn wir dafür midgard als monolithisch/exokernel mix aufbauen *grins*
Der kernel kann ja verschiedene execute module geladen haben, eins davon kann MXE's ausführen, ein anderes vielleicht elf files ;)

edit: das mit dem linker ist ja kein grosses problem, ich denk mal ne simple struktur kriegt man in 5 minuten zusammengehauen...
Die würde einfach nur aus einem file mit einer base64 encodeten code section bestehen..
Dann ein bisschen xml parser code rippen und n stück base64 decoder nehmen, kombinieren, sodass es den base64teil isoliert und anschliessend decodiert, dann in den speicher müllen, n function pointer draufsetzen und an den scheduler übergeben :D (so die theorie ;))
Je nach dem wie der kernel wächst und was für zusatzfunktionen er bekommt, wird das xml format mit neuen extras ausgestattet, um die möglichkeiten zu nutzen (z.b. dynamisches linken, das brauch ja nicht von anfang an drin sein, xml ist ja flexibel)

dann wollt ich noch sagen:
ich war auch immer ein feind von xml & co, aber wenn man sich das mal anschaut, ist es in der tat ne sehr flexible technologie, von der man immer öfter was hört und die sich jenseits der windows welt schon heimlich überall durchgesetzt hat.
viele daemons haben xml config files, jabber hat das XMPP protokoll (xml basiertes instant messaging, sogar von der IETF zum standart erklärt), RSS ist xml und mozilla/firefox speichern aussschliesslich in xml formaten ;)

auch wenn midgard auf einer seite n bastler os wird, kann man es ja mit supermodernen und übrzeugenden features ausstatten *g*

[foppi]

Obacht, Asbestanzüge anziehen.



Damit es keine probleme gibt mit XML, wird der binary-teil base64 encodet

Ach klar, wir können es uns ja heutzutage leisten, die vorhandenen Ressourcen nicht vollständig auszunutzen. Hallo? XML wurde vom W3C für den Austausch von strukturiertem TEXT entwickelt, niemals für Binärdaten. Sollen wir etwa jetzt auch anfangen, Bilder im Netz in base64 zu kodieren? Hat wohl seine Gründe, dass das niemand gemacht hat.





jabber hat das XMPP protokoll (xml basiertes instant messaging, sogar von der IETF zum standart erklärt),

Tjo, die IETF wird auch immer mehr zum Tummelplatz der Leute mit den $$$. Mit Workgroup-Chartas die nicht darauf zielen, etwas zu diskutieren, sondern für eine möglichst schnelle Absegnung sorgen.


RSS ist xml

und so beschissen, dass der stündliche Poll einem DDOS-Angriff (http://www.infoworld.com/article/04/07/16/29OPconnection_1.html) gleichkommt. Pusht statt Pull, nur die Veränderungen pushen und effiziente Verteilung wären angebracht.

[Hansinator]

Meinetwegen kann man auch die binärdaten direkt dareinschreiben, und in dem tag eine länge angeben, damit es keine probleme mit dem cdata bereich gibt.
Aber das wäre halt nicht konform..

Abgesehen davon gibt es in der tat bildformate in XML.
Das mit dem strunkturierten text ist zumindest heutzutage nur bedingt richtig.
PSI speichert zertifikatsdateien übrigens auch base64 encodet in einem XML file ab.
Mittlerweile lassen sich auch GUIs in XML designen.
(So ähnlich wie HTML Applications von MS, die übrigens von Symantec aktiv genutzt werden. Das Kontrollprogramm zu NAV ist z.B. eine HTA)



Extensible Markup Language (XML) is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere.


edit:
Es hat auch niemand gesagt, dass MXE das primäre executable format von midgard sein wird/muss, midgard wird sicherlich auch ELF unterstützen, oder vielleicht sogar garkein MXE.
Doch ich finde MXE eine interessante sache, und würde gerne mal an sowas basteln. Falls du noch irgendwelche konstruktiven vorschläge hast, immer raus damit!

[Smartie]

fippo, was ich ja neulich auch schon strcat fragen wollte, das kann ich ja bei dir jetzt auch tun: Gehts deiner Ansicht nach, bei diesem Projekt mehr um 100%ige Effizienz und Effektivität, oder um Spass? Und was meinen deiner Ansicht nach hier die 2 Hauptentwickler dazu?

Over and Out :>

[morpheus]

Hallo,

XML wurde vom W3C für den Austausch von strukturiertem TEXT entwickelt, niemals für Binärdaten.
Na ja, so pauschal wuerde ich das jetzt nicht sagen. Siehe der Entwurf des W3C fuer 'XML-binary Optimized Packaging'. [1]

Eigentlich verfuegt XML ueber keine spezielle Methode Binaerdaten einzubinden. Es bietet sich nun die Moeglichkeit an diese Binaerdaten codiert zu speichern, was allerdings nicht besonders effizient ist oder auf diese Binaerdaten zu referenzieren, obwohl man das ja hier nicht moechte.

http://www.xml.com/pub/a/2003/02/26/binaryxml.html
http://www.jeckle.de/xml/protocols.html#binary

@Deknos
Neben meinem Post steht jetzt zwar nicht 'fippo', allerdings moechte ich trotzdem darauf eingehen. ;)
Natuerlich ist der Spass sicherlich im Vordergrund, allerdings wird man sicher auch schauen, dass man die verschiedenen Features/Funktionen moeglichst effektiv und performant implementiert. Deshalb sollte man IMHO auch dankbar fuer mehr oder weniger konstruktive Einwuerfe sein. Na ja, zumindest meine Meinung dazu.

MfG
morpheus

[1] http://www.w3.org/TR/xop10/

[foppi]

Heh Deknos, haste die Sache mit dem Asbestanzug nicht beachtet? (den man übrigens immer anziehen sollte, wenn man in meiner Nähe das Wort jabber erwähnt :)

XMLs Stärke ist der Datenaustausch und Formatkonvertierung via XLST (wobei auf das Problem zugeschnittene Lösungen oft auch da die Nase vorn haben, siehe IGES im CAD-Bereich). Für andere Bereiche hab ich selten eine sinnvolle Anwendung gesehen, die man nicht auf andere Weise besser hätte lösen können.

XML ist nicht das allein selig machende Dingsbums, die einen von der Notwendigkeit entbindet, für den Einzelfall zu evaluieren. Das ist einfach zu stark vereinfacht. Wenn die Nachteile (lahm, verbose, zu komplex für einfache Jobs) die Vorteile überwiegen sollte man es nicht benutzen.



Gehts deiner Ansicht nach, bei diesem Projekt mehr um 100%ige Effizienz und Effektivität, oder um Spass?

Mh... ich mache Sachen entweder, weil sie mir Spass machen / sie interessant sind, ich sie schlicht und einfach brauche oder um jemand ne technische Ohrfeige zu geben. Effizienz geht oft mit sauberen technischen Lösungen Hand in Hand.

ok, fu2p, wenn öffentliches Interesse an einer Diskussion bestellt gibts dafür ja ein Forum

[Hansinator]

Ich find XSLT is einer der grössten schrott-sachen die es bei XML gibt, zumindest bis jetzt ;)

[lizer]

Mittlerweile lassen sich auch GUIs in XML designen.Das würde hervorragend in meinen Plan mit dem puren HTML-Desktop/GUI-Browser passen :)

Über Sinn/Unsinn dieser ganzen Sache will ich gar nicht streiten, dafür weiß ich viel zu wenig über XML. Aber:
Sollen wir etwa jetzt auch anfangen, Bilder im Netz in base64 zu kodieren?Hab am Rande mal mitgekriegt, dass alle OpenOffice-Komponenten standarmäßig XML als Speicherformat benutzen, also auch dieses Präsentations-Gerät und das andere Dingens da zum Malen. Die werden sich schon irgendwas dabei gedacht haben, denke ich jetzt mal.

Des weiteren hätte ich noch den Vorschlag, bestehende Executable-Formate wie z.B. ELF in XML-Files zu verpacken. Im Header könnte dann ein Vermerk auf das Format stehen, evtl. auch als Dependency: steht im Header was von a.out, wird zunächst mal geprüft, ob das entsprechende Modul oder was vergleichbares vorhanden ist, was zum interpretieren des a.out Codes nötig ist.
Wenn man ganz sicher gehen wollte, könnte man auch gleich eine kurze Spezifikation des Formats bzw. 'n simples Schema des Headers eines Binary Formats als Ressource einbinden, anhand welcher dann ein Interpreter/Parser den Binary Code interpretieren oder zumindest in ein anderes Format konvertieren kann. Das ist aber 'ne ganz andere Geschichte.

Was die Ressourcen angeht hatte ich auch noch 'ne relativ simple Lösung. Man könnte einfach für die Sprache seiner Wahl 'nen Header/Unit/Modul und wie sie alle heißen schreiben, der/die/das Datenstrukturen für die Speicherung der Daten solcher Ressourcen enthält. Der Interpreter fertigt eine Liste der Ressourcen mit den benötigten Daten an, lädt sie (die Ressourcen) evtl. gleich in den Speicher und übergibt der Hauptunktion des Programms einen Pointer auf die Liste:
int main(int argc, char ** argv, int resc, struct ressource ** resv) { ... };

/* und */
struct ressource {
int type, len;
void * pointerDrauf;
};


Wie auch immer, so weit sind wir eh noch nicht, also bleibt noch viel Zeit, um über sowas zu diskutieren :) CU,

Lizer

[Hansinator]

Wow, das war aber schonmal sehr gut!
Man könnte in der tat eine art XSLT transformation anwenden um von einem exec format ins andere zu konvertieren ;)
Die ressourcen müssen wie gesagt nicht zwangsweise geladen werden, das programm sollte die erst anfordern müssen, oder sogar selber aus sich laden
entweder greift sie mit load_resource_from_mxe() auf sich zu
oder sie sagt idem interpreter bescheid, dass er die ressource in den speicher stellen soll
kommt aufs gleiche raus eigentlich, nur dass wir beim 2. für's aufräumen zuständig sind wenn die exe sich entläd oder entladen wird ;)

[lizer]

nur dass wir beim 2. für's aufräumen zuständig sind wenn die exe sich entläd oder entladen wirdDas ist kein Ding. Wenn der Speicher für die Ressourcen unter der PID des Programms alloziert wird, wird er beim Terminieren einfach mitgefree()d.

Hab nochmal über die verschiedenen Executable Formate nachgedacht. Die Unterscheiden sich ja im Code an sich nicht wirklich, sondern nur im Header und eben im Aufbau des Codes. Wenn man dann im Header der MXE 'ne Spezifikation dieser unterbringt (oder bei häufigen Formaten 'nen Link auf 'ne zentrale Spezifikation anlegt) wäre es mega-simpel, alle Executable-Formate mit einem Interpreter zu starten. Eine Konvertierung ist dann im Grunde gar nicht nötig.
Je mehr ich darüber nachdenke desto besser find ich die Idee :) Das mit den Ressourcen ist halt noch 'ne andere Sache, aber das kriegen wir auch noch geregelt.

[Hansinator]

Juhu, ich konnte jemanden überzeugen *freu*

Dann mal ran ans laden von progs :)

todo:
ide/floppy treiber, filesystem, shell :p
achja, und ein system womit man treiber im kernel registrieren kann (hab da schon ein paar geniale ideen *gg*)

[morpheus]

Hallo,

Hab am Rande mal mitgekriegt, dass alle OpenOffice-Komponenten standarmäßig XML als Speicherformat benutzen, also auch dieses Präsentations-Gerät und das andere Dingens da zum Malen.
Ja, das machen sie, allerdings wird nur Text und Konfigurationszeug in XML-Dateien abgespeichert. Binaerdaten werden *nicht* im XML-File abgespeichert.


Die werden sich schon irgendwas dabei gedacht haben, denke ich jetzt mal.
Ja, haben sie. Es wurden ueber die verschiedensten Moeglichkeiten diskutiert.

http://xml.openoffice.org/package.html

Letzendlich haben sie sich fuer ein 'XML Package' entschieden, welches aus einem optional komprimiertem JAR/ZIP-Archiv besteht. Darin befinden sich dann XML-Dateien ueber die Informationen des Dokumentes, ueber den Inhalt der Dokumente (Text, Tabellen etc.) Informationen ueber die Verwendung der verschiedenen Formate in dem Dokument etc.

http://de.openoffice.org/doc/faq/xml/#4

Diese Methode hat den Vorteil, dass man kleinere Dateien bekommt, als wuerde man Text und Binaerdaten in ein XML-File packen. Dadurch, dass die Binaerdaten codiert werden muessen, werden diese um den Faktor 1,33 (Base64) oder sogar 2 (Hex) groesser. Noch dazu kommt der Aufwand des Codierens und Encodierens.


Des weiteren hätte ich noch den Vorschlag, bestehende Executable-Formate wie z.B. ELF in XML-Files zu verpacken.
Da stellt sich eben nun die Frage, ob man das tun sollte. XML waere fuer die Header etc. optimal, allerdings fuer die Speicherung von Binaerdaten schlecht.

Was wuerde fuer/gegen ein 'XML-Package' sprechen? ;)

MfG
morpheus

[Hansinator]

Ich weiss nicht!

Ich dachte, dass man eine art service/daemon laufen lassen kann, der compression streams verwaltet.

So könnte man die binärdaten komprimieren und als base64 abspeichern innerhalb des xml files.
Dann würde das mit dem 33% grössenzuwachs nicht so ein problem darstellen.
Wobei ich finde, dass man den grössenzuwachs eh verkraften kann, zumindest bei den ausführbaren daten.

Das mit dem packagen ist ne interessante idee.
Wenn ich das richtig verstanden habe, packen wir die daten in ein jar package (so wie firefox ;)), packen ein XML file dabei, was quasi das inhaltsverzeichniss darstellt, und die ganzen daten-dateien.

Das XML file referenziert dann die datendateien, in etwa so:
<object type="application/x-executable" ref="klaus.obj">

Wenn man die archive nicht solid packt, kann der ewntpacker doch auch geschickt einzelnde dateien rausholen, ohne, dass das ganze paket dekomprimiert werden muss, oder?

Ich würde mal die allgemeinheit bitten, sich zu diesem konzept zu äussern, das ist kein schlechter ansatz!
Das würde die vorteile von XML platzsparend nutzen, und das problem, dass man ne ganze reihe files hat durch das packagen umgehen, perfekt!
(Die vorteile von einer single file lösung liegen in der schnelleren ladezeit bei einer defragmentierten platte)

Zu meiner idee mit dem base64 fiel mir dann noch etwas ein:
Man kann teile der XML datei dann z.b. GnuPG verschlüsseln, so wie mit nem compression stream.

[morpheus]

Hallo,

Wenn ich das richtig verstanden habe, [...]
<object type="application/x-executable" ref="klaus.obj">
Ja, genau so habe ich das gemeint.


Wenn man die archive nicht solid packt, kann der ewntpacker doch auch geschickt einzelnde dateien rausholen, ohne, dass das ganze paket dekomprimiert werden muss, oder?

Access to subdocuments requires unzipping the required subdocuments first. ASCII based tools will in general not work on the package, although (at the user's request) individual subdocuments could be stored uncompressed, thus making them available to ASCII based tools.

Since ZIP files have an index, efficient on-demand loading of subdocuments can be achieved. Subdocuments can be copied from one package to another without uncompressing and compressing them first. With some hackery for on-demand saving, only those files following the newly-written subdocuments need to be written. Due to (optional) compression, files can be small, although not quite as small as .tgz files.
Ja, es sollte auf alle Faelle funktionieren nur einzelne Dateien zu laden anstatt das ganze Paket entpacken zu muessen. Das sieht man ja auch bei den verschiedenen Entpackern mit GUI.


Das würde die vorteile von XML platzsparend nutzen, und das problem, dass man ne ganze reihe files hat durch das packagen umgehen, perfekt!
Jepp. ;)


(Die vorteile von einer single file lösung liegen in der schnelleren ladezeit bei einer defragmentierten platte)
Wuerde ich gar nicht einmal sagen. Du darfst nicht vergessen, dass die Codierung bzw. Decodierung von Base64 gemacht werden muesste, wobei bei einem unkomprimiertem ZIP-Archiv, was immer noch kleiner waere als das Single-File, direkt auf einzelne, kleine Dateien zugegriffen werden kann.


Man kann teile der XML datei dann z.b. GnuPG verschlüsseln, so wie mit nem compression stream.
Allerdings um einiges umstaendlicher, als wie wenn man einzelne Dateien haette und nur eine dieser einzelnen Dateien verschluesseln moechte.

Noch dazu kommt, dass das ZIP/JAR-Format nicht wirklich kompliziert waere:
http://www.wotsit.org/download.asp?f=jar
http://www.wotsit.org/download.asp?f=zip45

MfG
morpheus

[Hansinator]

Jap, du hast recht morpheus .. ;)
Das ZIP Package wäre ja auch eine single-file lösung!!
So wie bei spielen (gutes spiel packt alles in eine datei, z.b. quake, schlechtes hat 10k bmps überall rumfliegen, die überall auf der platet verteilt liegen könnten [physikalisch])

Das zusätzliche komprimieren/verschlüsseln INNERHALB des zip packages ist ja auchnoch möglich.. !
Niemand hindert mich daran eine file.tar.gz.pgp.bz.zip.rar zu bauen :D

[TFA]

Wie waere es denn mit einem MacOS aehnlichen Format fuer Programme ?
(ich versuchs mal _kurz_ zu erklaeren)
Unter MacOS ist ein Programm ein Ordner mit suffix .app (wird in der GUI nur als Programm angezeigt). In diesem Ordner sind in einer festen Struktur alle Ressourcen die das Programm benoetigt (Sprachversionen, Scripte, Bilder....).

Da Installationen unter MacOS per Drag & Drop funktionieren, liest die GUI beim Kopieren / Verschieben eine XML datei im Ordner die beschreibt wozu das Programm gut ist.
Damit kopiert man sich ein Programm auf die Platte und kann direkt damit arbeiten.

ich poste mal ein find eines kleinen Programms..

./
.//Contents
.//Contents/Frameworks
.//Contents/Frameworks/KRM.framework
.//Contents/Frameworks/KRM.framework/Headers
.//Contents/Frameworks/KRM.framework/KRM
.//Contents/Frameworks/KRM.framework/Resources
.//Contents/Frameworks/KRM.framework/Versions
.//Contents/Frameworks/KRM.framework/Versions/A
.//Contents/Frameworks/KRM.framework/Versions/A/Headers
.//Contents/Frameworks/KRM.framework/Versions/A/Headers/CKagiModuleLoader.h
.//Contents/Frameworks/KRM.framework/Versions/A/KRM
.//Contents/Frameworks/KRM.framework/Versions/A/Resources
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/English.lproj
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/English.lproj/InfoPlist.strings
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/Info.plist
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/KRMLang.txt
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/KRMU.txt
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/pbdevelopment.plist
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/Info.plist
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/MacOS
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/MacOS/UIBundle2
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/pbdevelopment.plist
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/Resources
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/Resources/English.lproj
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/Resources/English.lproj/InfoPlist.strings
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/Resources/Java
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/Resources/Java/UIBundle2.jar
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/Resources/kagiA1.jpeg
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/Resources/lock01.jpg
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/Resources/NIB2.nib
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/Resources/NIB2.nib/classes.nib
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/Resources/NIB2.nib/info.nib
.//Contents/Frameworks/KRM.framework/Versions/A/Resources/UIBundle2.bundle/Contents/Resources/NIB2.nib/objects.nib
.//Contents/Frameworks/KRM.framework/Versions/Current
.//Contents/Info.plist
.//Contents/MacOS
.//Contents/MacOS/iBatt
.//Contents/PkgInfo
.//Contents/Resources
.//Contents/Resources/cachekey
.//Contents/Resources/English.lproj
.//Contents/Resources/English.lproj/InfoPlist.strings
.//Contents/Resources/English.lproj/MainMenu.nib
.//Contents/Resources/English.lproj/MainMenu.nib/classes.nib
.//Contents/Resources/English.lproj/MainMenu.nib/info.nib
.//Contents/Resources/English.lproj/MainMenu.nib/keyedobjects.nib
.//Contents/Resources/iBatt Icon.icns
.//Contents/Resources/iBatt Icon.tif
.//Contents/Resources/iBatt Splash.tif
.//Contents/Resources/RSW Logo.tif

[lizer]

Das ist ja so ziemlich das gleiche wie das, was wir oben beschrieben haben. Ist lediglich ein Verzeichnis, kein Package.

[TFA]

Jup, aber es ist leichter zugaenglich...
Ob das Pro oder Contra ist....

[Hansinator]

jo, das ist geil
ich würds aber als zip package machen, der zugriff ist auch nicht viel schwerer, und auf anderen plattformen ist das eine-datei-executable format gängiger ;)
aufjedenfall danke für den hinweis!