Ist ein binäres C-Hello-World mit allen BSDs lauffähig?

[Ararat++]

Ist ein binäres C-Hello-World mit allen BSDs lauffähig? Oder sogar mit Linux oder Solaris?

MFG

 

[Kamikaze]

Binär? Nee, nicht ohne irgendein Compat-Layer.

 

[Ararat++]

Wieso denn nicht?

Ist doch nur ein Befehl (printf) der verarbeitet wird!?

Aber FBSD+DFBSD und NBSD+OBSD sollten doch kompatibel sein!?

 

[troll]

Wieso denn nicht?

Ist doch nur ein Befehl (printf) der verarbeitet wird!?

Bau die Funktion printf() mal nach, dann merkst du, dass das nicht wenig Code ist.

Oder schau mal in /usr/src/lib/libc/stdio/vfprintf.c

However, es kommt nicht auf die Menge Quelltext an, sondern auf Binärkompatibilität des Codes, den der Compiler ausspuckt.

 

[Kamikaze]

Soweit ich weiß haben alle BSDs unterschiedliche ELF-Formate. Du kannst ja nicht mal FreeBSD-7-Binaries unter FreeBSD-6 ausführen. Wie kommst du dann darauf das irgendein anderes BSD so etwas könnte?

 

[Vincent Vega]

Wieso denn nicht?

Ist doch nur ein Befehl (printf) der verarbeitet wird!?

Aber FBSD+DFBSD und NBSD+OBSD sollten doch kompatibel sein!?

printf(3) ist eine Routine der C Standard Bibliothek. Das ist das, was Du als /usr/lib/libc.so auf Deinem System findest. Im Hintergrund werkelt eine ganze Menge Code, wie troll schon angemerkt hat. Du könntest jetzt Dein HalloWelt-Programm statisch linken, d.h. der printf(3) Code aus der C Bibliothek würde dann im Binärcode Deines Programms landen. Allerdings, und da kommst Du nicht drum herum, muss für die tatsächliche Ausgabe ein Systemaufruf ("syscall") gemacht werden. Technisch gesehen ist ein Systemaufruf ein Software Interrupt, der vom Kernel behandelt wird. Damit der Kernel weiß, welche Systemroutine Du aufrufst, musst Du eine Nummer angeben. Diese Nummer ist von System zu System verschieden.

Theoretisch könntest Du Dein Programm gegen eine "höherwertige" Bibliothek linken, welche die printf(3) Routine um die jeweilige Implementierung der Standard libc herum baut. Allerdings setzt das vorraus, dass diese Bibliothek auf allen System verfügbar ist.

Für alle praktischen Belange ist nicht mal ein HalloWelt-Programm Binärkompatibel.

Soweit ich weiß haben alle BSDs unterschiedliche ELF-Formate. Du kannst ja nicht mal FreeBSD-7-Binaries unter FreeBSD-6 ausführen. Wie kommst du dann darauf das irgendein anderes BSD so etwas könnte?

Nein, ELF ist nicht vom Betriebssystem abhängig. Du denkst vielleicht an das brandelf(1) Utility, mit dem man glaube ich Linux-Binaries bearbeiten muss um sie unter FreeBSD auszuführen. Der Hintergrund ist, dass es in den ELF Metadaten (also ELF Header, Section Header, etc.) einige Felder gibt, deren Interpretation von der verwendeten ABI abhängig ist. Dazu gibt es im ELF Identifizierungs-Header, ganz am Anfang der ELF Datei, ein Byte welches angibt, zu welchem ABI die Datei konform ist.

Leider wird der Begriff ABI auf den FreeBSD Mailinglisten manchmal etwas schwammig verwendet. Oben ist mit ABI das Application Binary Interface gemeint, und zwar die formale Spezifikation, wie Binaries ganz allgemein zusammenspielen. Also wie Parameter übergeben werden, wie der Stack aussieht, etc.

Manchmal hört bzw. liest man den Begriff ABI auch in anderem Zusammenhang: Wenn es um das Binärinterface einer Bibliothek oder eines Systemaufrufs geht. Also z.B. wenn sich Größen von Strukturen oder Offsets innerhalb von Strukturen ändern. Hier liegt auch der Grund begraben, warum man Binaries nicht ohne weiteres zwischen den verschiedenen FreeBSD Versionen hin- und herschaukeln kann. Es spielt vor allem die Binärkompatibilität der Bibliotheken eine Rolle. Kommen Felder in Strukturen hinzu oder fallen weg, oder ändern sich Parameter und Rückgabewerte ist das im Quelltext oft kein Problem, verhindert aber meist, dass zwei binäre Dateien korrekt miteinander arbeiten.

 

[Ararat++]

Ok, das wird mir jetzt zu komplex

 

[Yamagi]

Computer sind nunmal komplex und kompliziert.

 

[nakal]

Fragen sind hier:

1. Warum willst Du das?
2. Warum nicht einfach n mal kompilieren? (Das frage ich mich übrigens bei kommerziellen Software-Anbietern auch, wie schwierig es ist, das Vorhandene einfach unter jeder Plattform zu kompilieren. Wenn man vernünftig programmiert, sollte es kein Problem darstellen.)

 

[xbit]

Das vernuenftig und plattform-unabhaengig programmieren duerfte in der Regel das groesste Problem sein.

 

[nakal]

Das plattformunabhängige Programmieren geht Hand in Hand mit der Qualität der Software zusammen. Das verstehen leider noch nicht mal die "Großen" unter den Software-Firmen.

Ich rede hier übrigens nicht über Java, falls irgendein PHB hier zuschaut. Nur um das hier klarzustellen.

 

[troll]

Das plattformunabhängige Programmieren geht Hand in Hand mit der Qualität der Software zusammen. Das verstehen leider noch nicht mal die "Großen" unter den Software-Firmen.

Das würd ich nicht pauschalisieren. Plattformunabhängigkeit ist recht leicht bei einigen Konsolenprogrammen, oder Dämonen realisierbar. Bei Apps mit grafischer Oberfläche kommt es eine Menge auf das Framework an, das genutzt wird und das je nach System nicht verfügbar ist, oder einen Mordsinstallationsaufwand beinhaltet, weil es komplett mitinstalliert werden muss. Hier gibts dann auch wieder Lizenzkuddelmuddel.
Auf der anderen Seite stehen Programme, die sehr systemnah Kernelschnittstellen nutzen und schon aus diesem Grund nicht einfach zu portieren sind.

 

[Athaba]

Weil Spiele wohl das Bekannteste sind:
Es klappt relativ mit Quake und UT. Sowohl auf verschiedenen Betriebssystemen, als auch Rechnerarchitekturen.

Ich glaube das Problem bei den anderen dürfte die Sache mit DirectX sein

Und gtk, wxwidgets, tk, qt läuft ja auch so ziemlich überall.

Bei sehr systemnahen Programmen ist es klar, aber ich glaube nicht dass diese gemeint waren.

Zum Thema "Hello world".
Das hat mich auch schon mal interessiert. Gibt es da bzgl. Systemcalls, etc. keine Standards? Zumindest für die Grundlegendsten? Wäre das viel zu aufwendig? Ich kann mir gut vorstellen, dass kleine Konsolenprogramme, die z.B. auf den meisten Unixartigen Systemen lauffähig sind sehr gut zu gebrauchen sind. Vor allem könnte das ja auch beim Entwerfen neuer Systeme den Entwicklungsprozess stark beschleunigen. Plattformunabhängigkeit in Binärcode hätte ja sicher viele Vorteile. Aber vielleicht werden die auch eines Tages durch Virtualisierung gelöst.

Ich glaube ein Thread wie dieser wäre in "Programmieren" besser aufgehoben. Das nächste mal bitte dorthin.

 

[Vincent Vega]

Zum Thema "Hello world".
Das hat mich auch schon mal interessiert. Gibt es da bzgl. Systemcalls, etc. keine Standards? Zumindest für die Grundlegendsten? Wäre das viel zu aufwendig?

Nein, es gibt keine Standards. Wie schon oben erwähnt, eigentlich sind auch weniger die Syscalls als die Bibliotheken das Problem.

 

[FreeBSDuser]

perl -e'print"Hallo Welt!"'

funzt überall !

(some restrictions apply, see manual for details)

 

[soul_rebel]

perl -e'print"Hallo Welt!"'

funzt überall !

(some restrictions apply, see manual for details)

Ja, genau, wenn man was will, was überall geht ohne zu kompilieren, dann man nimmt einfach eine Skriptsprache. Die wurden genau dafür erfunden und der mögliche loss an performance sollte bei so kleinen Progrämmchen unwichtig sein.

 

[Athaba]

Skriptsprache != Interpretersprache (was du wohl mit Skriptsprache sagen wolltest)

 

[soul_rebel]

Skriptsprache != Interpretersprache (was du wohl mit Skriptsprache sagen wolltest)

Hm wo wäre da denn bitte der Unterschied? Welche "Skriptsprache" wird nicht interpretiert? Welche "Interpretersprache" kommt nicht in Skripten?

 

[Kamikaze]

Ist Java nicht eine Interpretersprache ohne eine Skriptsprache zu sein? Seit wann ist Perl bitte keine Skriptsprache mehr?

 

[soul_rebel]

Ist Java nicht eine Interpretersprache ohne eine Skriptsprache zu sein?

Ist Java überhaupt eine Programmiersprache?
Na gut vielleicht eine der wenigen Ausnahmen. Aber insgesamt würde ich das jetzt doch gerne von Athabe erklärt bekommen!

 

[Athaba]

Jup, ich hätte an Java gedacht.
Lisp ist IIRC eine Skriptsprache, die man kompiliert.

Ist Lisp eine Skriptsprache? *g*

Ich hatte mal eine Diskussion mit jemanden. Viele sind es nicht, aber ein paar gibt es.
Aber es gibt ein paar Interpretersprachen, die keine Skriptsprachen sind.

Und die meisten Programmiersprachen (C, Pascal, ...) gibt es auch in interpretierten Versionen. Aber eigentlich wollte ich keine große Diskussion darüber beginnen und das nur (klugscheißerisch) nebenbei erwähnen. Man könnte dazu auch die beiden Wikipediaartikel miteinander vergleichen. In der Praxis werden die Begriffe meist für das Selbe verwendet.

P.S.: Gibt es nicht auch Basic in kompilierten Varianten?

 

[hippodriver]

Eine gewagte These: C++ ist auch eine Interpretierte Sprache.

Begründung: virtuelle Funktionen werden nicht vom Compiler direkt umgesetzt, sondern zur Laufzeit in der virtual function table nachgeschlagen ;-)

Daraus folgt die Verallgemeinerung: Alle Sprachen mit Polymorphismus sind Interpretersprachen.

Ach ja, es soll auch Java native compiler geben.

Alles außer Assembler ist interpretiert ;-)

MfG
Michael Krauss

 

[Athaba]

Dafür gibt es ja PASM (Parrot Assembly language)

 

[FreeBSDuser]

Perl wird auch erst in einen bytecode übersetzt... sh ist vielleicht eine richtige Scriptsprache

Und fancy "D" kann man auch unkompiliert ausführen (heisst nicht das es dann nicht kompiliert wird...)

 

[danlei]

Ist Lisp eine Skriptsprache?

Auch. (Skriptsprache des Emacs beispielsweise.)

Alles außer Assembler ist interpretiert ;-)

Selbst der heutige Maschinencode ist – man korrigiere mich, wenn ich falsch liege – interpretiert, da er intern auf den RISC-Befehlssatz abgebildet wird. (bei i386) Zumindest hab ich mal etwas in der Art gelesen …

EDDI:
Damit ich nicht ganz ohne Quellen dastehe:

Internally, a RISC processor has a number of hardwired instructions.
This was also true of the early CISC processors, but these days a typical CISC processor has a heart which executes microcode instructions which correlate to the instructions passed into the processor. Ironically, this 'heart' tends to be RISC. :-)