Funktionsweise von ausführbaren Dateien
Dominik Schmidt
wie an der Frage sicherlich unschwer zu erkennen, kenne ich mich mit
Linux-Systemen kaum aus.
Ich w�rde gerne wissen, wie ausf�hrbare Dateien unter Linux
"funktionieren", bzw. wie man sich deren Funktionsweise vorzustellen hat.
Unter Windows werden Dateien bekanntlich anhand ihrer Dateiendung
identifiziert.
Die Dateiendung "exe" (wie "test.exe") ist eine ausf�hrbare Datei bzw.
Programmdatei, die beim �ffnen als Programm ge�ffnet wird.
Bei anderen Dateitypen, wie z.B. "jpg" (Bild) �ffnet Windows das damit
verkn�pfte Bildprogramm mit dem Dateipfad des ge�ffneten Bildes als
Parameter.
Bei UNIX-Systemen gibt es wohl keine Dateiendungen.
Eine ausf�hrbare Datei (wie eine Exe-Datei unter Windows) ist nur dann
ausf�hrbar, wenn man das Execute-Bit setzt (z.B. chmod), sonst hat man
einen unbrauchbaren Binaryhaufen.
Ob es sich bspw. bei einer Bilddatei um ein JPEG-Bild oder ein GIF-Bild
(GIF-Bilder scheinen ja z.B. immer mit der 3 Byte langen ASCII-Zeichenfolge
"GIF" zu beginnen) handelt, wird ermittelt, indem der Anfang vom Dateibody
(m�glicherweise in dem Fall also diese ersten 3 Byte) eingelesen wird.
Somit wird diese Information auch benutzt, um beim �ffnen einer Datei (z.B.
mit einem Dateimanager) das verkn�pfte Bildprogramm mit dem Bildpfad als
Parameter zu �ffnen?
Habe ich das soweit richtig verstanden?
Meine n�chste Frage:
Eine Windows-Exe-Datei ist im Allgemeinen auf allen Windows-Systemen
(zumindest Desktop-Systeme ab 9x) zumindest startf�hig.
Sicherlich wird eine Programmdatei, die f�r Windows XP geschrieben wurde,
unter Windows 95 wohl abbrechen, bevor man eine Oberfl�che sieht, weil z.B.
Abh�ngigkeiten fehlen.
Aber im wesentlichen lassen sich doch Programmdateien, die auf einem
Windows 2000 System laufen, auch auf einem Windows 7 System benutzen.
Lange Rede kurzer Sinn: Unter Linux muss man scheinbar die Quelldateien f�r
jede Distribution neu kompilieren, selbst kompilierte ausf�hrbare Dateien
von bspw. SuSE Linux 11.1 sind unter der Version 11.2 angeblich nicht mehr
lauff�hig.
Ist das richtig?
Warum muss f�r jede Distribution neu kompiliert werden?
Dieter Intas
> Hallo,
>
> wie an der Frage sicherlich unschwer zu erkennen, kenne ich mich mit
> Linux-Systemen kaum aus.
> Ich w�rde gerne wissen, wie ausf�hrbare Dateien unter Linux
> "funktionieren", bzw. wie man sich deren Funktionsweise vorzustellen hat.
Einfach mal lesen:
http://www.informatikserver.at/selflinux/html/nutzer_unter_linux05.html
Auf dieser Seite findest du auch noch weitere Grundlagen.
Distributionen sind ja daf�r da dir das alles zu ersparen - du brauchst
nichts kompilieren. Man kann allerdings den Quellcode installieren und dann
selbst kompilieren. Wenn du Programmieren kannst, dann kannst du dir auch
selbst was basteln.
Helmut Hullen
Du meintest am 28.12.09:
> Unter Linux muss man scheinbar die
> Quelldateien f�r jede Distribution neu kompilieren,
Nein.
> selbst kompilierte ausf�hrbare Dateien von bspw. SuSE Linux 11.1 sind
> unter der Version 11.2 angeblich nicht mehr lauff�hig.
Stimmt mindestens meistens nicht.
> Ist das richtig?
Nein.
> Warum muss f�r jede Distribution neu kompiliert werden?
Muss nicht.
-------------------
Pure Neugier: wo hast Du diese Mutmassungen aufgeschnappt?
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Dominik Schmidt
> Einfach mal lesen:
>
> http://www.informatikserver.at/selflinux/html/nutzer_unter_linux05.html
Hab's bis jetzt nur mal kurz �berflogen, aber da steht doch im Grunde das,
was ich auch geschrieben habe?
Also Execute-Bit muss gesetzt sein und Berechtigungen sind notwendig.
Bei Shell-Scripts muss am Anfang ein Shebang (#! /bin/sh) stehen, somit
wird offensichtlich tats�chlich der Anfang der Datei eingelesen, um ihren
Typ festzustellen.
> Distributionen sind ja daf�r da dir das alles zu ersparen - du brauchst
> nichts kompilieren. Man kann allerdings den Quellcode installieren und dann
> selbst kompilieren. Wenn du Programmieren kannst, dann kannst du dir auch
> selbst was basteln.
Das muss ein Missverst�ndnis sein. Selbstverst�ndlich kann man sich selbst
etwas programmieren und muss es dann auch selbst kompilieren.
Ich beziehe mich eher auf (distributions)fremde Programme, die man
installieren oder direkt ausf�hren will.
Zum Beispiel ein Programm, das man aus dem Internet heruntergeladen hat.
I.d.R. bekommt man doch eine Archivdatei (tar o.�.), die man entpacken
muss. Anschlie�end "./make" und "./configure" o.�. ausf�hren, damit das
Programm kompiliert und installiert wird.
Wenn man hingegen gezielt nach (bereits kompilierten) Binaries sucht,
bekommt man h�ufig f�r jede Distribution eine eigene, andere Binary (daher
mein Beispiel mit SuSE 11.1 und 11.2).
Beispiel:
http://www.torproject.org/download-unix.html.de
Hier gibt es nicht nur f�r jede Distribution kompilierte Binaries, sondern
diese sind auch noch beschr�nkt auf eine bestimmte Version ("openSUSE 11
Bin�rdatei" wird wohl nicht unter openSUSE 10 laufen).
Demzufolge l�sst sich z.B. ein Standalone-Programm (1 ausf�hrbare
Programmdatei, die ohne Installation l�uft), das unter SuSE Linux 11 l�uft,
nicht einfach auf ein SuSE Linux 10 oder ein Fedora System kopieren und
dort ausf�hren...?
Arno Welzel
> wie an der Frage sicherlich unschwer zu erkennen, kenne ich mich mit
> Linux-Systemen kaum aus.
> Ich w�rde gerne wissen, wie ausf�hrbare Dateien unter Linux
> "funktionieren", bzw. wie man sich deren Funktionsweise vorzustellen hat.
Stark vereinfacht:
1. Die Datei muss das Executable-Recht f�r den User oder die Gruppe des
Users gesetzt haben, der die Datei ausf�hren will.
2. Der Inhalt der Datei ist entweder ein ELF-Binary (Executable and
Linked Format) oder ein Shell-Script, dessen erste Zeile angibt, welche
Interpreter daf�r zust�ndig ist.
> Unter Windows werden Dateien bekanntlich anhand ihrer Dateiendung
> identifiziert.
> Die Dateiendung "exe" (wie "test.exe") ist eine ausf�hrbare Datei bzw.
> Programmdatei, die beim �ffnen als Programm ge�ffnet wird.
> Bei anderen Dateitypen, wie z.B. "jpg" (Bild) �ffnet Windows das damit
> verkn�pfte Bildprogramm mit dem Dateipfad des ge�ffneten Bildes als
> Parameter.
Nicht Windows, sondern nur der Explorer. Ein CreateProcess() mit einer
jpg-Datei unter Windows scheitern. Nur die Ausf�hrung �ber
ShellExecute() - also dem Explorer - f�hrt zur Ausf�hrung des
zust�ndigen Programms.
> Bei UNIX-Systemen gibt es wohl keine Dateiendungen.
Doch - so wie bei Windows. Je nach Desktop werden sie u.U. auch benutzt,
um z.B. alle ".exe" an WiNE weiterzugeben ;-)
Allerdings gibt es *zus�tzlich* einen Mechanismus, um anhand des
Dateiinhalts auf den Typ zu schlie�en.
> Eine ausf�hrbare Datei (wie eine Exe-Datei unter Windows) ist nur dann
> ausf�hrbar, wenn man das Execute-Bit setzt (z.B. chmod), sonst hat man
> einen unbrauchbaren Binaryhaufen.
> Ob es sich bspw. bei einer Bilddatei um ein JPEG-Bild oder ein GIF-Bild
> (GIF-Bilder scheinen ja z.B. immer mit der 3 Byte langen ASCII-Zeichenfolge
> "GIF" zu beginnen) handelt, wird ermittelt, indem der Anfang vom Dateibody
> (m�glicherweise in dem Fall also diese ersten 3 Byte) eingelesen wird.
> Somit wird diese Information auch benutzt, um beim �ffnen einer Datei (z.B.
> mit einem Dateimanager) das verkn�pfte Bildprogramm mit dem Bildpfad als
> Parameter zu �ffnen?
>
> Habe ich das soweit richtig verstanden?
Im Wesentlichen ja.
> Meine n�chste Frage:
> Eine Windows-Exe-Datei ist im Allgemeinen auf allen Windows-Systemen
> (zumindest Desktop-Systeme ab 9x) zumindest startf�hig.
Das gilt auch f�r Linux.
> Sicherlich wird eine Programmdatei, die f�r Windows XP geschrieben wurde,
> unter Windows 95 wohl abbrechen, bevor man eine Oberfl�che sieht, weil z.B.
> Abh�ngigkeiten fehlen.
Eben. Und deswegen laufen nicht wenige Programme auf einem "frischen"
Windows XP erstmal gar nicht - bis man .NET, MFC usw. in der passenden
Version installiert hat.
In der Praxis f�llt das nur nicht so sehr auf, weil viele Programme die
im Rahmen der Installation die ben�tigten Bibliotheken selber mitbringen
- und wenn man z.B. einmal ein MS Office-Paket oder einen neueren
Internet Explorer installiert, werden neben MS Office eben zahlreiche
DLLs eingerichtet, die wiederum auch viele anderen Programme benutzen.
> Aber im wesentlichen lassen sich doch Programmdateien, die auf einem
> Windows 2000 System laufen, auch auf einem Windows 7 System benutzen.
> Lange Rede kurzer Sinn: Unter Linux muss man scheinbar die Quelldateien f�r
> jede Distribution neu kompilieren, selbst kompilierte ausf�hrbare Dateien
> von bspw. SuSE Linux 11.1 sind unter der Version 11.2 angeblich nicht mehr
> lauff�hig.
> Ist das richtig?
So pauschal - Nein. Es erleichtert h�chstens die Arbeit, wenn man nicht
genau wei�, welche Abh�ngigkeiten f�r das Binary erf�llt sein m�ssen.
> Warum muss f�r jede Distribution neu kompiliert werden?
Muss man nicht. Binaries haben - wie unter Windows - nur Abh�ngigkeiten
zu bestimmten Bibliotheken, als das, was bei Windows DLLs darstellen.
Wenn man die entsprechenden Bibliotheken bereith�lt, laufen Binaries
auch ohne neue Compilierung.
Da aber die Verf�gbarkeit eines Compilers unter Linux eher der
Normalzustand als die Ausnahme ist, werden viele Pakete im Quelltext
ausgeliefert, damit man ein passendes Binary bauen kann, statt jedesmal
erst die zus�tzlich n�tigen Bibliotheken nachinstallieren zu m�ssen.
Unter Windows musst Du halt statt dessen oft weitere Pakete jeweils in
der passenden Version installieren - wie DirectX, .NET, VB-Runtimes in
der passenden Version, MFC-Libaries in der passenden Version usw.
Helmut Hullen
Du meintest am 28.12.09:
>> http://www.informatikserver.at/selflinux/html/nutzer_unter_linux05.h
>> tml
> Hab's bis jetzt nur mal kurz �berflogen, aber da steht doch im Grunde
> das, was ich auch geschrieben habe?
> Also Execute-Bit muss gesetzt sein und Berechtigungen sind notwendig.
> Bei Shell-Scripts muss am Anfang ein Shebang (#! /bin/sh) stehen,
> somit wird offensichtlich tats�chlich der Anfang der Datei
> eingelesen, um ihren Typ festzustellen.
Na ja - du hast ein wenig mehr geschrieben. U.a. beim Vergleich mit
Windows.
>> Distributionen sind ja daf�r da dir das alles zu ersparen - du
>> brauchst nichts kompilieren. Man kann allerdings den Quellcode
>> installieren und dann selbst kompilieren. Wenn du Programmieren
>> kannst, dann kannst du dir auch selbst was basteln.
> Das muss ein Missverst�ndnis sein. Selbstverst�ndlich kann man sich
> selbst etwas programmieren und muss es dann auch selbst kompilieren.
Schlicht falsch. Ich programmiere recht oft, aber ich kompiliere nur
sehr selten.
Liegt daran, dass ich fast nur Shellskripts programmiere.
> Ich beziehe mich eher auf (distributions)fremde Programme, die man
> installieren oder direkt ausf�hren will.
In beiden F�llen: da muss nicht zwingend kompiliert werden.
> Zum Beispiel ein Programm, das man aus dem Internet heruntergeladen
> hat.
> I.d.R. bekommt man doch eine Archivdatei (tar o.�.), die man
> entpacken muss. Anschlie�end "./make" und "./configure" o.�.
> ausf�hren, damit das Programm kompiliert und installiert wird.
Vielleicht. Nicht in jedem Fall.
Dominik Schmidt
>> Unter Linux muss man scheinbar die
>> Quelldateien f�r jede Distribution neu kompilieren,
>
> Nein.
>
>> selbst kompilierte ausf�hrbare Dateien von bspw. SuSE Linux 11.1 sind
>> unter der Version 11.2 angeblich nicht mehr lauff�hig.
>
> Stimmt mindestens meistens nicht.
>
>> Ist das richtig?
>
> Nein.
>
>> Warum muss f�r jede Distribution neu kompiliert werden?
>
> Muss nicht.
>
> -------------------
>
> Pure Neugier: wo hast Du diese Mutmassungen aufgeschnappt?
Sicherlich habe ich irgend etwas falsch verstanden, aber deshalb frage ich
ja hier.
Siehe auch meine Antwort an Dieter Intas:
Beispiel:
http://www.torproject.org/download-unix.html.de
Hier gibt es nicht nur f�r jede Distribution kompilierte Binaries, sondern
diese sind auch noch beschr�nkt auf eine bestimmte Version ("openSUSE 11
Bin�rdatei" wird wohl nicht unter openSUSE 10 laufen).
Oder verstehe ich da etwas falsch?
In einigen weiteren F�llen, in denen ich Programme oder Treiber
heruntergeladen habe, ist es �hnlich.
Ich spreche nat�rlich *nicht* vom Herunterladen und Installieren �ber die
distributionseigene Paketverwaltung (wie YAST bei SUSE).
Ich meine das Herunterladen von Programmen aus distributionsfremden
Quellen.
Oliver Schad
> wie an der Frage sicherlich unschwer zu erkennen, kenne ich mich mit
> Linux-Systemen kaum aus.
> Ich würde gerne wissen, wie ausführbare Dateien unter Linux
> "funktionieren", bzw. wie man sich deren Funktionsweise vorzustellen
> hat.
Es gibt einen Programm-Loader, der das Binary in den Arbeitsspeicher
wirft, dazu die dynamisch gelinkten Bibliotheken dazulädt.
> Unter Windows werden Dateien bekanntlich anhand ihrer Dateiendung
> identifiziert.
Auführbare Dateien werden unter Linux mit dem Ausführbar-Bit
gekennzeichnet. Dann weiß die Shell, dass es diese Datei irgendwie
ausführen muss. Alles weitere ist Magic (d.h. die Datei wird analysiert
und z.B. eine Shell gestartet, weil es ein Shell-Skript ist oder es
direkt dem Kernel zur Ausführung übergeben).
Das siehst du sehr schön, wenn du ein strace auf ein beliebiges Kommando
machst (auch ein Shellskript).
> Ob es sich bspw. bei einer Bilddatei um ein JPEG-Bild oder ein
> GIF-Bild (GIF-Bilder scheinen ja z.B. immer mit der 3 Byte langen
> ASCII-Zeichenfolge "GIF" zu beginnen) handelt, wird ermittelt, indem
> der Anfang vom Dateibody (möglicherweise in dem Fall also diese ersten
> 3 Byte) eingelesen wird. Somit wird diese Information auch benutzt, um
> beim Öffnen einer Datei (z.B. mit einem Dateimanager) das verknüpfte
> Bildprogramm mit dem Bildpfad als Parameter zu öffnen?
Im Prinzip ja, viele Dateiformate haben einen Header. Gibt es so etwas
nicht, dann muss man halt sich die ganze Datei anschauen und nach
merkmalen fahnden (letzteres gilt z.B. für Textdateien), siehe z.B.
http://en.wikipedia.org/wiki/File_format#Internal_metadata
> Lange Rede kurzer Sinn: Unter Linux muss man scheinbar die
> Quelldateien für jede Distribution neu kompilieren, selbst kompilierte
> ausführbare Dateien von bspw. SuSE Linux 11.1 sind unter der Version
> 11.2 angeblich nicht mehr lauffähig.
> Ist das richtig?
> Warum muss für jede Distribution neu kompiliert werden?
Muss nicht, kann aber, das kann von vielen Faktoren abhängen:
- neue Compilerversionen (siehe ABI)
- neue Bibliotheksversionen (siehe 'readelf', 'objdump' oder 'ldd'
angewandt auf Binary bzw. abhängige Bibliotheken)
- Änderungen im Programmlader (was eher nicht vorkommt)
- vermutlich noch 1000 Möglichkeiten
Es spricht nichts dagegen lustig die Versionen der Distribution zu
mischen (in gewissen Schranken, siehe Probleme durch wechselnde ABI
beispielsweise). Dann braucht man aber oft (oder eigentlich immer) eben
nicht nur das Binary selbst, sondern auch die davon abhängenden
Bibliotheken in anderen Versionen ebenso. Das wird dann schnell zu einer
Abhängigkeitshölle.
Da ich das Thema selbst nicht so tief kenne, sollte sich jemand nochmal
auskotzen, warum die Bibliotheksversion überhaupt vermerkt ist (ist eine
wechselnde API der eizige Grund?).
mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
Michael Baeuerle
>
> Unter Windows werden Dateien bekanntlich anhand ihrer Dateiendung
> identifiziert.
> Die Dateiendung "exe" (wie "test.exe") ist eine ausf�hrbare Datei bzw.
> Programmdatei, die beim �ffnen als Programm ge�ffnet wird.
> Bei anderen Dateitypen, wie z.B. "jpg" (Bild) �ffnet Windows das damit
> verkn�pfte Bildprogramm mit dem Dateipfad des ge�ffneten Bildes als
> Parameter.
Das koennen viele Unix-Dateimanager auch (Dateien mit bestimmten
Endungen mit einem bestimmten Programm oeffnen) wenn man sie
entsprechend konfiguriert.
> Bei UNIX-Systemen gibt es wohl keine Dateiendungen.
Ja, fuer das OS selbst ist der Dateiname ziemlich belanglos. Diverse
Tools die bei bestimmten Unixen zum Basissystem gehoeren haben zwar eine
Sonderbehandlung fuer Namen die mit "." anfangen (versteckte Dateien),
das hat aber mit der Ausfuehrbarkeit nichts zu tun.
> Eine ausf�hrbare Datei (wie eine Exe-Datei unter Windows) ist nur dann
> ausf�hrbar, wenn man das Execute-Bit setzt (z.B. chmod), sonst hat man
> einen unbrauchbaren Binaryhaufen.
Genau, ist IMHO auch die logischere Loesung. Bits fuer die
Zugriffsrechte zum Ausfuehren braucht man sowieso.
> Ob es sich bspw. bei einer Bilddatei um ein JPEG-Bild oder ein GIF-Bild
> (GIF-Bilder scheinen ja z.B. immer mit der 3 Byte langen ASCII-Zeichenfolge
> "GIF" zu beginnen) handelt, wird ermittelt, indem der Anfang vom Dateibody
> (m�glicherweise in dem Fall also diese ersten 3 Byte) eingelesen wird.
> Somit wird diese Information auch benutzt, um beim �ffnen einer Datei (z.B.
> mit einem Dateimanager) das verkn�pfte Bildprogramm mit dem Bildpfad als
> Parameter zu �ffnen?
>
> Habe ich das soweit richtig verstanden?
Ja, viele Dateimanager machen sowas. Damit das OS eine Datei via
'exec()' ausfuehrt, muss der User erstmal das Recht haben (Exec Bit),
danach wird aber auch der Inhalt angeschaut um zu sehen ob es ein Binary
(bei Linux sind die heute im ELF-Format) oder ein Script ist das mit
"#!" anfaengt. In letzterem Fall wird der angegebene Interpreter
gestartet und diesem das Script uebergeben.
> [...]
> Lange Rede kurzer Sinn: Unter Linux muss man scheinbar die Quelldateien f�r
> jede Distribution neu kompilieren, selbst kompilierte ausf�hrbare Dateien
> von bspw. SuSE Linux 11.1 sind unter der Version 11.2 angeblich nicht mehr
> lauff�hig.
> Ist das richtig?
Nicht so pauschal. Man kann das so machen, dass ein Programm auf relativ
vielen System laeuft ohne es neu zu compilieren (diese sollten aber wie
bei Windows neuer sein, sonst wird es schwierig). Viele Hersteller von
kommerziellen Programmen machen das und es funktioniert ganz gut.
> Warum muss f�r jede Distribution neu kompiliert werden?
Weil heute quasi 100% der Programm dynamisch gelinkt sind, d.h. sie
enthalten nicht den gesamten zur Ausfuehrung benoetigten Code, sondern
Referenzen auf Bibliotheken. Meistens scheitert es daran, dass
Bibliotheken fehlen oder nur in einer inkompatiblen Version vorliegen.
Beispiel:
----------------------------------------------------------------------
$ file /bin/ls
/bin/ls: ELF 32-bit MSB executable, SPARC, version 1,
dynamically linked (uses shared libs), stripped
$ ldd /bin/ls
libtermcap.so.2 => /lib/libtermcap.so.2 (0x5002a000)
libc.so.6 => /lib/libc.so.6 (0x5003d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x50000000)
----------------------------------------------------------------------
Hier werden 'libtermcap' und 'libc' benoetigt. Die bei Linux verwendete
GNU libc ist z.B. nur abwaertskompatibel, d.h. ein Binary laeuft auch
mit einer neueren, aber nicht mit einer aelteren Version als der, fuer
die das Programm compiliert wurde.
BTW:
'ld-linux' ist der Loader der den Code aus den Bibliotheken in den
Speicher holt. Der muss natuerlich ebenfalls existieren und die
Bibliotheken finden und laden koennen, ansonsten kann das Programm nicht
ausgefuehrt werden.
Micha
--
Alte Maenner sind Kinder mit Rueckenschmerzen.
Raimund Nisius in dse
Dominik Schmidt
> Nicht Windows, sondern nur der Explorer. Ein CreateProcess() mit einer
> jpg-Datei unter Windows scheitern. Nur die Ausf�hrung �ber
> ShellExecute() - also dem Explorer - f�hrt zur Ausf�hrung des
> zust�ndigen Programms.
OK, alternative Dateimanager (wie muCommander) d�rften dann ebenso �ber
ShellExecute(), also �ber den Explorer, Dateien �ffnen, nehme ich an?
Schlie�lich ist das Verhalten das gleiche, wie beim �ffnen �ber den
Explorer.
> Allerdings gibt es *zus�tzlich* einen Mechanismus, um anhand des
> Dateiinhalts auf den Typ zu schlie�en.
Das w�re dann ja meine Vermutung gewesen (Stichwort: "GIF", 3 Byte).
>> Sicherlich wird eine Programmdatei, die f�r Windows XP geschrieben wurde,
>> unter Windows 95 wohl abbrechen, bevor man eine Oberfl�che sieht, weil z.B.
>> Abh�ngigkeiten fehlen.
>
> Eben. Und deswegen laufen nicht wenige Programme auf einem "frischen"
> Windows XP erstmal gar nicht - bis man .NET, MFC usw. in der passenden
> Version installiert hat.
>
> In der Praxis f�llt das nur nicht so sehr auf, weil viele Programme die
> im Rahmen der Installation die ben�tigten Bibliotheken selber mitbringen
> - und wenn man z.B. einmal ein MS Office-Paket oder einen neueren
> Internet Explorer installiert, werden neben MS Office eben zahlreiche
> DLLs eingerichtet, die wiederum auch viele anderen Programme benutzen.
Aha, offenbar sind also Abh�ngigkeiten (= Bibliotheken = DLLs) bzw. genauer
fehlende Abh�ngigkeiten der einzige Grund, warum eine ausf�hrbare Datei,
die unter Fedora l�uft, unter SUSE evtl. nicht l�uft?
>> Warum muss f�r jede Distribution neu kompiliert werden?
>
> Muss man nicht. Binaries haben - wie unter Windows - nur Abh�ngigkeiten
> zu bestimmten Bibliotheken, als das, was bei Windows DLLs darstellen.
> Wenn man die entsprechenden Bibliotheken bereith�lt, laufen Binaries
> auch ohne neue Compilierung.
>
> Da aber die Verf�gbarkeit eines Compilers unter Linux eher der
> Normalzustand als die Ausnahme ist, werden viele Pakete im Quelltext
> ausgeliefert, damit man ein passendes Binary bauen kann, statt jedesmal
> erst die zus�tzlich n�tigen Bibliotheken nachinstallieren zu m�ssen.
>
> Unter Windows musst Du halt statt dessen oft weitere Pakete jeweils in
> der passenden Version installieren - wie DirectX, .NET, VB-Runtimes in
> der passenden Version, MFC-Libaries in der passenden Version usw.
Bedeutet das, dass alle ben�tigten Abh�ngigkeiten im Quellpaket enthalten
sind und beim Kompilieren in die Binary-Datei(en) eingebaut werden, sodass
sie nicht vom System bereitgehalten werden m�ssen?
Dominik Schmidt
>> Das muss ein Missverst�ndnis sein. Selbstverst�ndlich kann man sich
>> selbst etwas programmieren und muss es dann auch selbst kompilieren.
>
> Schlicht falsch. Ich programmiere recht oft, aber ich kompiliere nur
> sehr selten.
> Liegt daran, dass ich fast nur Shellskripts programmiere.
OK, man m�ge mir diese grob fahrl�ssige Formulierung verzeihen. :-)
(Shell)scripts muss man nat�rlich nicht kompilieren, richtig.
Frank Ursel
[..]
> Habe ich das soweit richtig verstanden?
Sieht gar nicht mal so schlecht aus. ;-)
> Lange Rede kurzer Sinn: Unter Linux muss man scheinbar die Quelldateien
> für jede Distribution neu kompilieren, selbst kompilierte ausführbare
> Dateien von bspw. SuSE Linux 11.1 sind unter der Version 11.2 angeblich
> nicht mehr lauffähig.
> Ist das richtig?
Das ist in dieser Pauschalität nicht richtig. Wie unter anderen
Betriebssystem auch, haben die meisten Programme irgendwelche
Abhängigkeiten in Form von Bibliotheken, Toolkits, grafisches Geraffel.
Das muss ebenfalls vorhanden sein, um das Programm zum Laufen zu bewegen.
Die Beispiele unter Windows mit .Net oder passenden Directx-Versionen
wurden schon genannt.
Dass Pakete für verschiedene Distributionen und verschiedene Versionen
derselben angeboten werden, liegt zum einen daran, dass man dem Benutzer
genau sagen möchte - das hier *wild mit dem Finger auf ein Paket zeig*
ist genau das richtige für dich. Zum anderen kann es auch vorkommen, dass
ein Programm eine bestimmte Bibliothek benötigt und diese sich unter
Umständen in der neuen Version verändert hat (Änderung der ABI, etc.)
Unter Windows würde ein entsprechendes Programm häufig *seine* DirectX-
Version oder *seine* Java-Umgebung, etc. mitbringen und zusätzlich
installieren, oder über bereits bestehendes drüberinstallieren. Kennt man
von früher, als Spiel 2 eine Version einer DDL ersetzen wollte, die aber
Spiel 1 brauchte.
Außerdem hat jede Distribution ihre Eigenheiten, die in den einzelnen
Paketen beachtet werden: In der einen Distribution liegen die
ausführbaren Dateien an dem einen Ort, die Konfigurationsdateien liegen
woanders und die Startskripte haben auch ihren festen Platz. In der
nächsten Distribution liegen diese Sachen an leicht unterschiedlichen
Plätzchen oder es werden z.B was die Startskripte angeht, andere
Mechanismen benutzt.
HTH
Frank
Hauke Laging
> Beispiel:
> http://www.torproject.org/download-unix.html.de
> Hier gibt es nicht nur für jede Distribution kompilierte Binaries,
> sondern diese sind auch noch beschränkt auf eine bestimmte Version
> ("openSUSE 11 Binärdatei" wird wohl nicht unter openSUSE 10
> laufen).
Natürlich nicht, aber (zumeist) umgekehrt. Du hast doch selber
gesagt, dass ein XP-Programm unter W98 nicht läuft. Das ist dasselbe
wie mit oS11 und os10, nur dass die Zeitspanne eben größer ist. Das
spiegelt sich in den Abhängigkeiten in der Paketverwaltung wider.
Das Linux-API wird ständig erweitert. Das ist nicht für alle
Programme relevant. Ein Editor wird sich dafür im allgemeinen nicht
interessieren, eine Applikation, die auf den unteren
Netzwerkschichten arbeitet, schon eher. So eine Applikation setzt
dann natürlich einen hinreichend neuen Kernel (und ggf. eine
entsprechend erweiterte Standardbibliothek) voraus.
CU
Henning Paul
> Bedeutet das, dass alle ben�tigten Abh�ngigkeiten im Quellpaket
> enthalten sind und beim Kompilieren in die Binary-Datei(en) eingebaut
> werden, sodass sie nicht vom System bereitgehalten werden m�ssen?
Das kann man so handhaben (das nennt man dann statisches Linken), muss
es aber nicht. Wenn man das nicht will, z.B. aus Platzgr�nden, dann
muss man daf�r sorgen, dass die Bibliotheksdatei, gegen die das Binary
bei der Kompilierung gelinkt worden ist, greifbar ist.
Windowsentwickler l�sen das Problem so, dass sie die Bibliothek
beilegen - aus diesem Grund hat man dann irgendwann zigmal msvc71.dll
o.�. auf der Platte liegen, unter Linux umgeht man das Problem damit,
dass man das Programm eben je einmal f�r die �blichen Distributionen
kompiliert und damit gegen die dort vorhandenen Bibliotheksversionen
linkt.
Kommerzielle Software f�r Linux wird meist "universell lauff�hig"
kompiliert.
Gru�
Henning
Dieter Intas
> On Mon, 28 Dec 2009 11:48:18 +0100, Dieter Intas wrote:
>
>> Einfach mal lesen:
>>
>> http://www.informatikserver.at/selflinux/html/nutzer_unter_linux05.html
>
> Hab's bis jetzt nur mal kurz �berflogen, aber da steht doch im Grunde das,
> was ich auch geschrieben habe?
> Also Execute-Bit muss gesetzt sein und Berechtigungen sind notwendig.
> Bei Shell-Scripts muss am Anfang ein Shebang (#! /bin/sh) stehen, somit
> wird offensichtlich tats�chlich der Anfang der Datei eingelesen, um ihren
> Typ festzustellen.
Na sch�n, dann ist das noch eine Vertiefung.
>> Distributionen sind ja daf�r da dir das alles zu ersparen - du brauchst
>> nichts kompilieren. Man kann allerdings den Quellcode installieren und
>> dann selbst kompilieren. Wenn du Programmieren kannst, dann kannst du dir
>> auch selbst was basteln.
>
> Das muss ein Missverst�ndnis sein. Selbstverst�ndlich kann man sich selbst
> etwas programmieren und muss es dann auch selbst kompilieren.
>
> Ich beziehe mich eher auf (distributions)fremde Programme, die man
> installieren oder direkt ausf�hren will.
> Zum Beispiel ein Programm, das man aus dem Internet heruntergeladen hat.
>
> I.d.R. bekommt man doch eine Archivdatei (tar o.�.), die man entpacken
> muss. Anschlie�end "./make" und "./configure" o.�. ausf�hren, damit das
> Programm kompiliert und installiert wird.
> Wenn man hingegen gezielt nach (bereits kompilierten) Binaries sucht,
> bekommt man h�ufig f�r jede Distribution eine eigene, andere Binary (daher
> mein Beispiel mit SuSE 11.1 und 11.2).
> Beispiel:
> http://www.torproject.org/download-unix.html.de
> Hier gibt es nicht nur f�r jede Distribution kompilierte Binaries, sondern
> diese sind auch noch beschr�nkt auf eine bestimmte Version ("openSUSE 11
> Bin�rdatei" wird wohl nicht unter openSUSE 10 laufen).
Das ist schon richtig, man sollte aber schon die Version beachten, denn von
Version zu Version finden �nderungen statt und da ist Vorsicht angesagt.
> Demzufolge l�sst sich z.B. ein Standalone-Programm (1 ausf�hrbare
> Programmdatei, die ohne Installation l�uft), das unter SuSE Linux 11
> l�uft, nicht einfach auf ein SuSE Linux 10 oder ein Fedora System kopieren
> und dort ausf�hren...?
Kann durchaus der Fall sein, wenn die Abh�ngigkeiten stimmen. Aktuelle
Versionen haben sich aber auch weiterentwickelt, somit kann die Abstimmung
verloren gehen. Es hindert aber keinen (mit dem n�tigen KnowHow) dieses
auszuprobieren.
Auf meinem System (openSUSE 11.2) laufen z.B. KDE4 und KDE3-Versionen mit
verschiedenen Libs und ohne diese l�uft nichts.
Hauke Laging
> 1. Die Datei muss das Executable-Recht für den User oder die Gruppe
> des Users gesetzt haben, der die Datei ausführen will.
Da wir hier ja so gerne klugscheißern:
Die Rechtepriorität ist: User, Gruppe, andere.
Die Datei muss in irgendeinem Block, der den User erfasst,
Ausführrechte haben, und es darf keinen höherrangigen Block geben,
dem das Ausführrecht fehlt.
Wenn eine Datei root:root gehört, was der Normalfall ist, dann reicht
das Ausführrecht der Gruppe:
start cmd:> l /bin/cat
-rwxr-xr-x 1 root root 43K 3. Dez 2008 /bin/cat*
Wenn man sich diese Datei kopiert
start cmd:> l cat
-rw-r--r-x 1 root users 43K 28. Dez 13:27 cat*
kann man sie immer noch ausführen, auch wenn weder der Besitzer noch
die Gruppe Ausführrechte haben – sofern man nicht der Besitzer ist
und der Gruppe nicht angehört.
Das heißt auch, dass die Ausführung möglich ist, wenn man mit ACL
arbeitet und sowohl Gruppen, denen der User angehört, das
Ausführrecht haben, als auch andere solche Gruppen es nicht haben.
Nur der Vollständigkeit halber: Die Ausführrechte sind egal, wenn das
Volume, auf dem die Datei liegt, mit der Option noexec gemountet
ist.
Hauke Laging
> Kommerzielle Software für Linux wird meist "universell lauffähig"
> kompiliert.
Und das heißt? Statisch?
Arno Welzel
> Bedeutet das, dass alle ben�tigten Abh�ngigkeiten im Quellpaket enthalten
> sind und beim Kompilieren in die Binary-Datei(en) eingebaut werden, sodass
> sie nicht vom System bereitgehalten werden m�ssen?
Nicht ganz. Wenn eine Anwendung z.B. Qt braucht, muss Qt nat�rlich
vorhanden sein. Allerdings wird beim Compilieren gegen die jeweils
vorhandene Qt-Version der Distribution gelinkt. Ein fertiges Binary
dagegen setzt u.U. eine ganz bestimmte Qt-Version voraus, die evtl. in
der eigenen Distribution nicht enthalten ist.
Arno Welzel
> Henning Paul schrieb am Montag 28 Dezember 2009 13:16:
>
>> Kommerzielle Software für Linux wird meist "universell lauffähig"
>> kompiliert.
>
> Und das heißt? Statisch?
Ja, meistens.
Oliver Schad
> Das Linux-API wird ständig erweitert. Das ist nicht für alle
> Programme relevant.
Das ist für eigentlich keine Applikation interessant, weil niemand die
API von Linux direkt verwenden will - dafür gibt es eine glibc, die den
Kernel kapselt. Denn niemand will seine Applikation anpassen, weil
gerade Kernel v2.6.33 erschienen ist.
Das ist auch im totalen Widerspruch dazu eine portable Applikation
schreiben zu wollen, selbst schon zwischen 32 und 64-Bit-Systemen wird
es da schwierig innerhalb der gleichen Distribution und
Distributionsversion. Ganz abgesehen von der Portierbarkeit auf andere
Unix-Systeme, die mal gar nicht gegeben ist, wenn man Kernel-APIs nutzt.
Hauke Laging
> Das ist für eigentlich keine Applikation interessant, weil niemand
> die API von Linux direkt verwenden will - dafür gibt es eine glibc,
> die den Kernel kapselt. Denn niemand will seine Applikation
> anpassen, weil gerade Kernel v2.6.33 erschienen ist.
Wobei es IMHO nun keinen so großen qualitativen Unterschied macht, ob
man für seine Applikation eine hinreichend neue glibc oder einen
hinreichend neuen Kernel braucht...
Christoph 1
> Das w�re dann ja meine Vermutung gewesen (Stichwort: "GIF", 3 Byte).
Ein beliebiges Grafikprogramm k�nnte sich nat�rlich am Dateinamen
orientieren "nikolaus.gif" muss (?) ein GIF-Image sein.
Linux-Programme gehen meistens nach dem Dateiinhalt. Diesen
Mechanismus zeigt das Programm file.
Schau dir in einer Shell Konsole verschiedene Dateien mit Hilfe des
file Kommandos an, zum Beispiel:
~> file Dokument.pdf
~> file nikolaus.gif
Dann k�nntest du testweise eine der Dateien umbenennen und noch
einmal testen:
~> mv nikolaus.gif nikolaus.png
~> file nikolaus.png
Jetzt kennst du den Mechanismus, mit dem f�r eine beliebige Datei
herausgefunden wird, mit welchem Programm sie ge�ffnet werden kann.
Viele Gr��e
Christoph
Helmut Hullen
Du meintest am 28.12.09:
>> Nicht Windows, sondern nur der Explorer. Ein CreateProcess() mit
>> einer jpg-Datei unter Windows scheitern. Nur die Ausf�hrung �ber
>> ShellExecute() - also dem Explorer - f�hrt zur Ausf�hrung des
>> zust�ndigen Programms.
> OK, alternative Dateimanager (wie muCommander) d�rften dann ebenso
> �ber ShellExecute(), also �ber den Explorer, Dateien �ffnen, nehme
> ich an? Schlie�lich ist das Verhalten das gleiche, wie beim �ffnen
> �ber den Explorer.
Was auch immer Du unter "�ffnen" verstehen magst. Microsoft hat diesen
schwammigen Begriff f�r "alles und irgendwas" missbraucht.
"�ffnen" ist insbesondere was anderes als "von Anwendung a ausf�hren
lassen".
>> Allerdings gibt es *zus�tzlich* einen Mechanismus, um anhand des
>> Dateiinhalts auf den Typ zu schlie�en.
> Das w�re dann ja meine Vermutung gewesen (Stichwort: "GIF", 3 Byte).
Der/das ist bei Linux nicht n�tig.
> Aha, offenbar sind also Abh�ngigkeiten (= Bibliotheken = DLLs) bzw.
> genauer fehlende Abh�ngigkeiten der einzige Grund, warum eine
> ausf�hrbare Datei, die unter Fedora l�uft, unter SUSE evtl. nicht
> l�uft?
Nein. Etwas pingeliger: das kann eine von mehreren Ursachen sein, nicht
die einzige.
Und es ist auch nicht gottgegeben, dass kein einziges Fedora-Programm
jemals unter SuSE l�uft (oder was auch immer Du wo mischen willst).
Ich benutze auf meinem Slackware-Rechner etliche Binaries, die ich bei
Mandrake, RedHat, Debian, Ubuntu und SuSE ausgeborgt habe.
>> Unter Windows musst Du halt statt dessen oft weitere Pakete jeweils
>> in der passenden Version installieren - wie DirectX, .NET,
>> VB-Runtimes in der passenden Version, MFC-Libaries in der passenden
>> Version usw.
> Bedeutet das, dass alle ben�tigten Abh�ngigkeiten im Quellpaket
> enthalten sind und beim Kompilieren in die Binary-Datei(en) eingebaut
> werden, sodass sie nicht vom System bereitgehalten werden m�ssen?
"Abh�ngigkeiten" ist (wie "�ffnen") ein ausgesprochen schwammiger
Begriff. Shell-Skripts oder Java-Skripts haben damit fast keine
Probleme. Andere Programme k�nnen (beispielsweise) weitere Programme
oder aber spezielle Libraries vermissen.
Stefan Reuther
> Unter Windows werden Dateien bekanntlich anhand ihrer Dateiendung
> identifiziert.
> Die Dateiendung "exe" (wie "test.exe") ist eine ausf�hrbare Datei bzw.
> Programmdatei, die beim �ffnen als Programm ge�ffnet wird.
> Bei anderen Dateitypen, wie z.B. "jpg" (Bild) �ffnet Windows das damit
> verkn�pfte Bildprogramm mit dem Dateipfad des ge�ffneten Bildes als
> Parameter.
Es ist nicht Windows, was das tut. Es ist die Shell (cmd.exe) bzw. die
grafische Oberfl�che (Explorer, ShellExecute).
> Bei UNIX-Systemen gibt es wohl keine Dateiendungen.
> Eine ausf�hrbare Datei (wie eine Exe-Datei unter Windows) ist nur dann
> ausf�hrbar, wenn man das Execute-Bit setzt (z.B. chmod), sonst hat man
> einen unbrauchbaren Binaryhaufen.
> Ob es sich bspw. bei einer Bilddatei um ein JPEG-Bild oder ein GIF-Bild
> (GIF-Bilder scheinen ja z.B. immer mit der 3 Byte langen ASCII-Zeichenfolge
> "GIF" zu beginnen) handelt, wird ermittelt, indem der Anfang vom Dateibody
> (m�glicherweise in dem Fall also diese ersten 3 Byte) eingelesen wird.
> Somit wird diese Information auch benutzt, um beim �ffnen einer Datei (z.B.
> mit einem Dateimanager) das verkn�pfte Bildprogramm mit dem Bildpfad als
> Parameter zu �ffnen?
Die Mechanismen sind unter beiden Betriebssystemfamilien fast die
gleichen. Es gibt zum einen eine Kernelfunktion (Windows: CreateProcess,
Unix: exec), die ein Programm startet. Wie die Programmdatei hei�t ist
dabei v�llig wumpe. Auch unter Windows hei�en nicht alle Programmdateien
".exe", es gibt z.B. auch ".scr" (Bildschirmschoner) oder ".com".
Zus�tzlich hat die entsprechende Shell bzw. grafische Oberfl�che
Mechanismen, Dateien zu Programmen zuzuordnen. In Windows wird das
systemweit �ber die Registry gemacht, welche eine Endung einem Programm
zuordnet (".doc" -> Word). In Linux kann das auf verschiedene Arten
eingerichtet werden. Es gibt einen Kernel-Mechanismus (binfmt_misc), es
gibt mailcap, und es gibt programm-/umgebungsspezifische Mechanismen.
Der Midnight Commander kann z.B. sowohl �ber den Dateinamen, als auch
�ber den Dateiinhalt ("die 3 Bytes am Anfang von GIF") zuordnen,
letzteres �ber file(1).
Au�erdem pr�ft die Linux-Kernelfunktion das x-Bit der Dateirechte, und
unterst�tzt neben den normalen ELF-Binaries auch Scripte (shebang-Zeile).
> Eine Windows-Exe-Datei ist im Allgemeinen auf allen Windows-Systemen
> (zumindest Desktop-Systeme ab 9x) zumindest startf�hig.
> Sicherlich wird eine Programmdatei, die f�r Windows XP geschrieben wurde,
> unter Windows 95 wohl abbrechen, bevor man eine Oberfl�che sieht, weil z.B.
> Abh�ngigkeiten fehlen.
> Aber im wesentlichen lassen sich doch Programmdateien, die auf einem
> Windows 2000 System laufen, auch auf einem Windows 7 System benutzen.
Das ist in der Form nicht richtig. Wenn du z.B. die entsprechende
Version der Visual-C++-Runtime oder der MFC nicht installiert hast oder
mit dem falschen Internet Explorer unterwegs bist, geht es eben nicht,
du bekommst dann von der GUI einen Dialog, dass nicht alle DLLs gefunden
wurden. Allerdings liefert MS da auch immer mehr mit. Nicht ohne Grund
braucht Windows 7 10 GByte f�r eine Installation, die dann nicht mal
Compiler und/oder Tabellenkalkulation enth�lt.
> Lange Rede kurzer Sinn: Unter Linux muss man scheinbar die Quelldateien f�r
> jede Distribution neu kompilieren, selbst kompilierte ausf�hrbare Dateien
> von bspw. SuSE Linux 11.1 sind unter der Version 11.2 angeblich nicht mehr
> lauff�hig.
> Ist das richtig?
> Warum muss f�r jede Distribution neu kompiliert werden?
Solange alle ben�tigten Bibliotheken vorhanden sind, muss nicht neu
compiliert werden. Da man allerdings neu compilieren kann, ist
vermutlich einzusehen, dass man nicht so viele Altlasten mitschleppt wie
unter Windows. Aber zumindest bei FreeBSD erinnere ich mich an Pakete,
die die alten libcs aller alten FreeBSD-Versionen f�r alte Binaries
nachinstallieren, und auch Debian hat fr�her mal der Kompatibilit�t
wegen libc5 mitgeliefert.
Stefan
Hauke Laging
> Wenn eine Datei root:root gehört, was der Normalfall ist, dann
> reicht das Ausführrecht der Gruppe:
Nicht der Gruppe, sondern für others, war natürlich gemeint...
--
http://www.hauke-laging.de/ideen/
Norbert Hahn
>Das kann man so handhaben (das nennt man dann statisches Linken), muss
>es aber nicht. Wenn man das nicht will, z.B. aus Platzgr�nden, dann
>muss man daf�r sorgen, dass die Bibliotheksdatei, gegen die das Binary
>bei der Kompilierung gelinkt worden ist, greifbar ist.
>Windowsentwickler l�sen das Problem so, dass sie die Bibliothek
>beilegen - aus diesem Grund hat man dann irgendwann zigmal msvc71.dll
>o.�. auf der Platte liegen,
Das ist ja mit Windows NT 6.0 (aka Vista) entsch�rft worden: Da gibt
es jede mehrfach ben�tigte DLL genau einmal, abgelegt im Verzeichnis
%windir%\WinSxS\ und in den Bibliotheken der Anwendungsprogramme gibt
es einen Hardlink auf den zentralen Speicher. Dort kann es jedoch
verschiedene Versionen von o.g. msvc71.dll geben. Es ist durchaus
�blich, dass das Verzeichneis WinSxS weit �ber 10 GB gro� ist...
Norbert
Markus Wichmann
> Hallo,
>
> wie an der Frage sicherlich unschwer zu erkennen, kenne ich mich mit
> Linux-Systemen kaum aus.
> Ich würde gerne wissen, wie ausführbare Dateien unter Linux
> "funktionieren", bzw. wie man sich deren Funktionsweise vorzustellen hat.
>
> identifiziert.
> Programmdatei, die beim Öffnen als Programm geöffnet wird.
> Bei anderen Dateitypen, wie z.B. "jpg" (Bild) öffnet Windows das damit
> verknüpfte Bildprogramm mit dem Dateipfad des geöffneten Bildes als
> Parameter.
>
Korrekt. Hat allerdings den Nachteil, dass, wenn du ein AVI-Video in
*.jpg umbenennst, Windows versucht, den Bildbetrachter zu öffnen.
> Bei UNIX-Systemen gibt es wohl keine Dateiendungen.
Doch, auch, aber sie haben nicht die gleiche Bedeutung wie unter
Windows. Hier zählen die Inneren Werte[tm]. Bloß, weil eine Datei *.jpg
heißt, muss sie ja kein Bild sein.
> Eine ausführbare Datei (wie eine Exe-Datei unter Windows) ist nur dann
> ausführbar, wenn man das Execute-Bit setzt (z.B. chmod), sonst hat man
> einen unbrauchbaren Binaryhaufen.
Hmmm... es gibt aber auch Dateien, die bestehen nur aus ASCII und haben
ein Executable-Bit. Und das beste: Das funktioniert sogar. Nennt sich
Skript und funktioniert so: Wenn die erste Zeile mit "#!" beginnt, wird
der Rest der Zeile als Interpreter betrachtet und mit dem Skript als
Argument aufgerufen. Wenn nicht, wird /bin/sh genommen.
> Ob es sich bspw. bei einer Bilddatei um ein JPEG-Bild oder ein GIF-Bild
> (GIF-Bilder scheinen ja z.B. immer mit der 3 Byte langen ASCII-Zeichenfolge
> "GIF" zu beginnen) handelt, wird ermittelt, indem der Anfang vom Dateibody
> (möglicherweise in dem Fall also diese ersten 3 Byte) eingelesen wird.
> Somit wird diese Information auch benutzt, um beim Öffnen einer Datei (z.B.
> mit einem Dateimanager) das verknüpfte Bildprogramm mit dem Bildpfad als
> Parameter zu öffnen?
>
"Das kommt drauf an." Nämlich auf die Art und Weise, wie du die
entsprechende Datei öffnen willst. Vermutlich meinst du das Anklicken im
Konqueror, Dolphin oder Nautilus. Da wird AFAIK so etwas benutzt, wie
das Kommandozeilentool "file", dass Dateien anhand ihres Inhalts
klassifiziert. Dessen Ausgabe wird ausgewertet und dann wird ein
entsprechendes Programm gestartet. AFAIK...
Allerdings müssen es nicht die ersten drei Bytes sein. Bei einem Tape
Archive steht die Magic Number (in dem Falle der String "ustar") erst an
Stelle 251 oder so. Und dann gibt es da noch Verfeinerungen: Beginnt
eine Datei mit "MZ", ist es auf jeden Fall eine DOS-Exe. Kommt
allerdings etwas später ein "PE", so ist die Datei auch eine Win32-Exe
(in Win32-Exen steht vorne ein DOS-Stub drin, der DOS-Nutzer dazu
auffordert, Windows zu installieren. Das ist sauberer designed als das
grausliche .NET-Framework, das, wenn es kein .NET gibt, einem die
hübsche Fehlermeldung bringt "Das Programm konnte nicht richtig
initialisiert werden." Und daraus soll einer Schlau werden!)
> Habe ich das soweit richtig verstanden?
>
> Meine nächste Frage:
> Eine Windows-Exe-Datei ist im Allgemeinen auf allen Windows-Systemen
> (zumindest Desktop-Systeme ab 9x) zumindest startfähig.
> Sicherlich wird eine Programmdatei, die für Windows XP geschrieben wurde,
> unter Windows 95 wohl abbrechen, bevor man eine Oberfläche sieht, weil z.B.
> Abhängigkeiten fehlen.
Richtig. Das ist einer der wenigen Fälle, wo Windows mal vernünftige
Fehlermeldungen ausgibt, nämlich "Die DLL foo.dll wurde nicht gefunden"
oder "Der Prozedureinsprungpunkt foobar wurde nicht in foo.dll
gefunden."
> Aber im wesentlichen lassen sich doch Programmdateien, die auf einem
> Windows 2000 System laufen, auch auf einem Windows 7 System benutzen.
>
Richtig. Manchmal klappt das sogar mit Treibern (für meine WLAN-Karte
gibt es nur einen WinXP-Treiber, der aber auch bei Win7 tadellos seinen
Dienst versieht).
> Lange Rede kurzer Sinn: Unter Linux muss man scheinbar die Quelldateien für
> jede Distribution neu kompilieren, selbst kompilierte ausführbare Dateien
> von bspw. SuSE Linux 11.1 sind unter der Version 11.2 angeblich nicht mehr
> lauffähig.
> Ist das richtig?
> Warum muss für jede Distribution neu kompiliert werden?
"Kommt drauf an". Und zwar hat jede Distribution andere (Versionen von)
Shared Libs parat. Debian sarge dürfte wohl kaum mit einer libslang von
letztem Dienstag aufwarten können, oder so. Und jede Software hat andere
Abhängigkeiten. Die einen linken rpm noch gegen libdb, die anderen gegen
libsqlite etc. pp.
Es gibt einen Standard namens Linux Standard Base, in dem drin steht,
was ein Programm alles an Bibliotheken erwarten darf. Alles was da nicht
drin steht, müsste man theoretisch per libdl nachladen, aber wozu der
Aufwand? Damit nicht der dynamische Linker die Fehlermeldung herausgibt,
sondern das Programm selbst? Kann ich mir auch sparen.
Im übrigen könnte ein Programm für SuSE Linux 11.1 durchaus noch auf
11.2 laufen. Es könnte sogar sein, dass ein Programm von Debian Sarge
auf SuSE Linux 11.2 läuft. Es ist nur nicht garantiert. Garantieren
jedoch kann man, dass der Quellcode auf beiden Distributionen
kompiliert. Genauer gesagt ist das Kompilieren oft nicht das Problem,
sondern das Linken. Der proprietäre nVidia-Treiber macht sich das
zunutze: Die liefern Objektdateien aus, die nur noch gelinkt werden
müssen.
HTH,
Markus
--
Nur weil ein Genie nix reißt, muß ja nun nicht gleich jeder Idiot
pausieren... Bully hats ja auch geschafft.
-- gUnter nanonüm in de.alt.anime
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Florian Diesch
> On 28 Dec 2009 11:49:00 +0100, Helmut Hullen wrote:
>
>>> Unter Linux muss man scheinbar die
>>> Quelldateien f�r jede Distribution neu kompilieren,
>>
>> Nein.
>>
>>> selbst kompilierte ausf�hrbare Dateien von bspw. SuSE Linux 11.1 sind
>>> unter der Version 11.2 angeblich nicht mehr lauff�hig.
>>
>> Stimmt mindestens meistens nicht.
>>
>>> Ist das richtig?
>>
>> Nein.
>>
>>> Warum muss f�r jede Distribution neu kompiliert werden?
>>
>> Muss nicht.
>>
>> Pure Neugier: wo hast Du diese Mutmassungen aufgeschnappt?
>
> Sicherlich habe ich irgend etwas falsch verstanden, aber deshalb frage ich
> ja hier.
> Siehe auch meine Antwort an Dieter Intas:
> Beispiel:
> http://www.torproject.org/download-unix.html.de
> Hier gibt es nicht nur f�r jede Distribution kompilierte Binaries, sondern
> diese sind auch noch beschr�nkt auf eine bestimmte Version ("openSUSE 11
> Bin�rdatei" wird wohl nicht unter openSUSE 10 laufen).
Solche Paketdateien sind speziell f�r die jeweilige Distribution
optimiert und enthalten z.B. keine Bibliotheken, die auch �ber die
Paketverwaltung der jeweiligen Distribution installierbar sind, sondern
definieren nur Abh�ngigkeiten, so dass die entsprechenden Pakete
automatisch installiert werden. Au�erdem ist vermutlich die
Standardkonfiguration und die Platzierung der Dateien im Dateisystem an
die jeweilige Distribution angepasst, so dass die Installation m�glichst
einfach, sicher und reibungslos verl�uft.
Florian
--
<http://www.florian-diesch.de/grundgesetz.html>
Arno Lutz
>I.d.R. bekommt man doch eine Archivdatei (tar o.ä.), die man entpacken
>muss. Anschließend "./make" und "./configure" o.ä. ausführen, damit das
>Programm kompiliert und installiert wird.
damit das auch klappt, müssen in aller Regel die passenden "-devel"-Pakete
installiert sein um Abhängigkeiten auflösen zu können.
So kompilierte Programme sind natürlich lauffähig aber: sie werden von der
systemeigenen Paketverwaltung nicht erkannt und eventuell über diese aktualisiert.
Die Pflege dieses Programmes obliegt dann dir.
Gruß
Arno
--
Die kürzesten Wörter, nämlich "ja" und "nein" erfordern das meiste Nachdenken.
(Pythagoras)
Jan Schmidt
> Hallo,
>
zu all dem, was schon gesagt wurde, sollte noch genannt werden, dass
die verschiedenen Distributionen unterschiedliche "Installationsdateien"
verwenden, die meist auch unterschiedlich benannt werden.
Oder irgendwann zwischen zwei Versionen wird eine Bibliothek aus einem
Paket entfernt und in ein eigenes gepackt.
Wenn Du jetzt ein Programm mit z.B. rpm installieren willst, wird rpm
suchen, ob alle Abh�ngigkeiten erf�llt sind und in den obigen F�llen
rummeckern obwohl die tats�chlich ben�tigten Dateien bereits installiert
sind / sein k�nnen. Das ist imho der "wahre" Grund f�r die vielen
verschiedenen Pakete.
Au�erdem sei noch angemerkt, dass es zwar (meist) m�glich ist, ein
Programm aus dem Source zu �bersetzen aber oft werden daf�r
"devel"-Pakete, d.h. Headerfiles der ben�tigten Bibliotheken zus�tzlich
zu installieren sein.
Und mit den Sourcen ist es eben auch genau so wie oben genannt. Werden
diese mittels rpm kompiliert klappt alles wunderbar (nachdem man die
devel-Pakete installiert hat) aber wenn jemand nur eine .tgz und eine
Liste mit Abh�ngigkeiten bereitstellt ist meist erstmal l�ngeres suchen
angesagt (im einfachsten Fall: wie hei�t das rpm, das die Bibliothek
enth�lt).
Au�erdem hast Du dann einen "Parallelweg" auf Deinem Rechner
und mu�t Dich selbst k�mmern, dass die von Dir �bersetzten Programme
nach einem Update einer Bibliothek auch noch funktionieren. Aktiviertes
Online-Update ist in so einer Konfiguration oft gef�hrlich.
(Das ist z.B. schon so, wenn man vmware-Server 1.x auf einem SuSE-11.2
verwenden will. Jedes Kernel-Update erfordert Neukompilierung der
vmware-Module.)
jan
Arno Lutz
>(Das ist z.B. schon so, wenn man vmware-Server 1.x auf einem SuSE-11.2
>verwenden will. Jedes Kernel-Update erfordert Neukompilierung der
>vmware-Module.)
ist da bei VMWare nich bei _jedem_ Kernelupdate fällig oder hab ich da was
verschlafen?
Jan Schmidt
> Jan Schmidt schrieb:
>> (Das ist z.B. schon so, wenn man vmware-Server 1.x auf einem SuSE-11.2
>> verwenden will. Jedes Kernel-Update erfordert Neukompilierung der
>> vmware-Module.)
>
> ist da bei VMWare nich bei _jedem_ Kernelupdate fällig oder hab ich da was
> verschlafen?
immer dann, wenn es keine vorkompilierten Module im vmware-Paket gibt.
Bei einem Kernelupdate dürfte das wohl recht häufig so sein ;-)
jan
Martin Schmitz
> Lange Rede kurzer Sinn: Unter Linux muss man scheinbar die
> Quelldateien für jede Distribution neu kompilieren, selbst kompilierte
> 11.2 angeblich nicht mehr lauffähig.
> Ist das richtig?
Nein.
Martin
Arno Welzel
Diesen Mechanismus gibt es auch schon bei NT 5.1, aka Windows XP und bei
da ist WinSxS auch keine �ber 10 GB gro�, sondern in der Regel deutlich
weniger. So viele Versionen der Visual C-Runtimes oder der MFC-Libraries
gibt es auch wieder nicht ;-)