Delphi-PRAXiS - Delphi Linux - Ick freu mir ;-)

Seite 2 von 2

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Cross-Platform-Entwicklung (https://www.delphipraxis.net/91-cross-platform-entwicklung/)

- - Delphi Linux - Ick freu mir ;-) (https://www.delphipraxis.net/190093-linux-ick-freu-mir-%3B.html)

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Namenloser (Beitrag 1346251)

FreePascal verwendet standardmäßig gar keine libc. Die haben fast alles notwendige selbst implementiert und sprechen direkt mit dem Linux-Kernel via Syscalls. Somit kann man an sich extrem portable Kompilate erstellen. Aufpassen muss man nur, wenn man Units einbindet, die ein vorangestelltes c haben (z.B. cmem). Diese linken gegen die libc. Leider gehört dazu auch cthreads, welche man für Multithreading braucht. Aber der klassische Unix-Weg wäre ja auch eher mit fork und wait statt Threads :roteyes:

Ok, das erklärt mein Problem mit verschiedenen libc Versionen in einem Free Pascal Projekt, das dadurch nicht auf einem älteren Ubuntu als dem meiner Entwicklungsumgebung ausführbar war.

Indy TCP/HTTP Server verwenden Threads. Und vermutlich werden auch viele andere Delphi Servertools wie DataSnap, IntraWeb usw. das tun. Bedeutet: für jede libc-Version neu kompilieren. Viel Spass :)

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Valle (Beitrag 1346245)

Nein, das funktioniert so nicht. Auf irgendetwas musst du ja zurückgreifen, wenn du etwas anzeigen lassen möchtest. Wenn FMX auf Linux portiert würde, dann wahrscheinlich, wie gesagt, direkt auf das X11-Protokoll. Welches, wie gesagt, gerade "am deprecaten" ist. ;-)

FMX basiert doch auf VGScene, und das konnte Linux. Was wurde denn da als Grundlage genommen?

AW: Linux - Ick freu mir ;-)

VGScene verwendete OpenGL. Ich vermute mal unter Linux in Verbindung mit SDL.

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Namenloser (Beitrag 1346251)

Ich arbeite recht viel mit FreePascal unter Linux und bin, ehrlich gesagt, noch nie auf Kompatibilitätsprobleme gestoßen (zumindest unter den Debianderivaten). Kompiliert unter Ubuntu 14.04 (mit Codetyphon) liefen die Kompilate sowohl für Serveranwendungen und grafische Programme (GTK) auch mit cthreads eingebunden problemlos unter neueren (16.04) und älteren (12.04) Ubuntuversionen, Debian (Wheezy und Jessie), Linux Mint (sowohl die Ubuntu- als auch die Debianversion) und sogar Kali Linux.
Kann natürlich sein, dass ich jetzt zufällig überall auf dieselbe Version der libc gestoßen bin, aber dennoch hatte ich so damit trotz langer Nutzung nie Probleme.

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von uligerhardt (Beitrag 1346278)

Zitat:

Zitat von Valle (Beitrag 1346245)

FMX basiert doch auf VGScene, und das konnte Linux. Was wurde denn da als Grundlage genommen?

Auch für OpenGL brauchst du unter Linux X11-Anbindung. Wenn man mal spaßeshalber

hier nach ganz unten scrollt, und sich die main()-Funktion des OpenGL Beispiels anschaut, wird man feststellen, dass die erste Zeile XOpenDisplay(NULL); lautet.

Zitat:

Zitat von Rollo62 (Beitrag 1346268)

Mal dumm gesprochen: Das mache ich für Windows ja auch (XP/7/8/10).
Nur das dort wohl mehr Wert auf Rückwärtskompatibilität gelegt wird (was ich mir
bei Vergleich M$ - Linux aber auch nicht wirklich vorstellen kann).

Doch, ist aber so. Microsoft hat seine Plattform ja voll in eigener Hand. Linux besteht aus sehr vielen unabhängigen Projekten.

Wir Softwareentwickler wissen aber, dass ständige Rückwärtskompatibilität selten etwas gutes für unsere Software bedeutet.

Zitat:

Zitat von Rollo62 (Beitrag 1346268)

Wenn ich mir die Linuxwelt so ansehe dann liest sich alles so als gäbe es 100% Crash-Sicherheit bei komplexen Projekten.
Das kann aber so schlimm doch auch wieder nicht sein, sonst wäre es nicht so erfolgreich.

Könnte man meinen, aber keine Sorge, das ist nicht der Fall. Ich betreue privat, ehrenamtlich und beruflich sehr viele verschiedene Linux-Systeme für alle möglichen Anwendungszwecke. Kaum eines davon verwendet überhaupt selbst kompilierte Programme. Programme, die nicht in den Paketlisten des Distributionsanbieters sind, benutze ich auf Servern quasi nicht. Crashes sind daher unheimlich selten und falls überhaupt vorhanden, sicherlich kein architekturelles Problem.

Man muss ich wohl in erster Linie daran gewöhnen, dass man unter Linux nicht irgendwelche Webseiten besucht und dort irgendetwas herunterlädt. Dein Maintainer stellt alles für dich zusammen. Du benutzt zum Installieren von Software deinen Paketmanager. Ausnahmen sind selten. OpenSource-Programme kann man von extern kompillieren und das läuft meist anstandslos. Binaries wie Google Chrome oder Spotify sind da schwieriger. Google hat bei Chrome gute Arbeit geleistet. Spotify hingegen ist schon deutlich wählerischer bei seiner Plattform.

AW: Linux - Ick freu mir ;-)

Ich freu mich auch, allerdings erst, wenn man auch Linux-Desktop-Anwendungen erstellen kann.

Konsolenprogramme? Was soll das? Selbst ein Konsolen-Serverprogramm muss man administrieren, venünftigerweise macht man das mit einer richtigen Benutzeroberfläche.

Zugegeben, der Markt für kommerzielle Linux-Desktop-Anwendungen ist klein, aber ich finde es gut, dass man den Kunden Lösungen für alle Plattformen anbieten kann. Seit Windows 10 stelle ich vermehrt Wechsler zu Linux fest, die dann bei mir die entsprechende Linux-Variante des bisherigen Windows 10 Programms bestellen.

Bislang ist das leider relativ aufwändig, einen zusätzlichen Programmcode extra für Linux mit Lazarus zu pflegen (wobei man gegen Lazarus aus meiner Sicht nichts sagen kann, sehr gute Entwicklungsumgegebung, funktioniert auf allen Plattformen hervorragend).

Na ja, insofern aber schon mal ein Lichtblick...

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Harry Stahl (Beitrag 1346737)

Nunja, lustige Leute, die nicht bereits FreePascal nutzen, könnten sich ja mithilfe von HTTP eine durchaus funktionsfähige Administrations-GUI basteln. Geht sogar recht schnell und hat den Vorteil, dass man von überall aus administrieren könnte. :lol:

Zitat:

Zitat von Harry Stahl (Beitrag 1346737)

Bislang ist das leider relativ aufwändig, einen zusätzlichen Programmcode extra für Linux mit Lazarus zu pflegen (wobei man gegen Lazarus aus meiner Sicht nichts sagen kann, sehr gute Entwicklungsumgegebung, funktioniert auf allen Plattformen hervorragend).

Warum pflegst du dann überhaupt noch zwei verschiedene Versionen anstatt gleich ganz auf Lazarus umzusteigen? Crosscompiling ist mit FreePascal ganz einfach und so bräuchte man nicht einmal die Umgebung zu wechseln.

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346738)

Nun ja, an Delphi hängt schon mein Herz...

Davon abgesehen sind da noch die mobilen Versionen für IOS und Android, die man doch am einfachsten mit Delphi entwickeln kann...

Es gäbe natürlich noch die Variante, tatsächlich voll auf Lazarus umzusteigen und die mobilen Versionen mit Swift (IOS) bzw. Android Studio zu entwickeln...

Aber das käme nur ernsthaft in Betracht, wenn die Preispolitik um Delphi völlig abdreht oder Linux wirklich mal so aufholen sollte, dass man da deutlich mehr machen muss und in Delphi dafür weiterhin kein vernünftiges Angebot besteht...

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346738)

Zitat:

Zitat von Harry Stahl (Beitrag 1346737)

Bis auf die "Grundeinrichtung" um das System überhaupt zum laufen zu bekommen wäre eine Linux-GUI sowas von 1995.
Jede Weblösung die sich nicht über das Web (hier http) Administrieren lässt ist keine vollständige Weblösung

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Harry Stahl (Beitrag 1346739)

Wenngleich ich einen etwas holprigen Start mit Lazarus hatte, so sehe ich zwischen Delphi und FreePascal, mittlerweile, nur noch wenig Unterschiede.

Hast du Erfahrungen mit Android Studio? Seit CodeTyphon bin ich für Linux und Windows auf FreePascal umgestiegen und habe lange Zeit dann Delphi fast nur für Android genutzt. Mittlerweile, weil mein XE5 zunehmend unpraktischer wurde (fehlende Features, keine Unterstützung neuerer Androidversion etc.) bin ich dann, als Weg des geringsten Übels (und weil es kostenlos wurde), auf C# mit VS/Xamarin umgestiegen.

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346742)

Wenngleich ich einen etwas holprigen Start mit Lazarus hatte, so sehe ich zwischen Delphi und FreePascal, mittlerweile, nur noch wenig Unterschiede.

Dem würde ich überwiegend zustimmen. In Delphi gibt es allerdings noch einiges obendrauf (u.a. Threading-Library) und viele andere Nettigkeiten. Für MEINEN Anforderungsbereich jedenfalls kann ich aber sagen, dass ich für Windows oder MAC alles auch mit Lazarus erledigen kann (und eben auch noch die Linux-Plattform bedienen kann).

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346742)

Hast du Erfahrungen mit Android Studio?

Nein. Ich hatte mir nur XCode/Swift installiert und einmal näher angesehen, ein Buch mal hierzu kurz überflogen, im Web einen Lehrgang dazu angesehen. Hier habe ich den Eindruck, dass man als Pascal-Entwickler sich schnell zurechtfinden könnte. Das haben auch schon andere im Forum hier bestätigt, die tatsächlich für ihre IOS oder MAC-Projekte auf Swift umgestiegen sind.

Aber zu Delphi möchte ich noch erwähnen, dass mir die Aktivitäten von Emba/Idera in den letzten 1-2 Jahren gut gefallen haben. Was die alles an Webinaren, Informationen etc. zur Verfügung stellen ist schon Klasse, hier bekommt man viele Hilfestellungen. Mit den Aktionen um Delphi-Starter herum versucht man wieder (Neu-) Kunden zu gewinnen und die Rechnung könnte aufgehen. Und je mehr Delphi Entwickler, desto besser.

Ich bin da bei Delphi also noch grundsätzlich in positiver Grundhaltung, auch wenn es bei FMX immer noch ein paar ärgerliche Entwicklungen gibt, wo z.B. Fehlerkorrekturen noch zu lange auf sich warten lassen, oder in der nächsten Version der Source-Code der Vorversion nicht mehr funktioniert, etc. Die IDE ist in 10.1 ist deutlich besser als unter XE5, sie ist schneller, macht sogar kleinere Kompilate, der Installationsprozess ist nun super über das Internet zu bewerkstelligen und anpassbar. Wenn Dein Budget es her gibt, dann gönne Dir das Update auf 10.1...

Wenn ich jetzt noch Linux-Desktop-Versionen entwickeln könnte, das wäre echt super... Ich kann zwar verstehen, dass die Erfahrungen mit Kylix für das Unternehmen eher abschreckend waren, aber bin der Meinung, man sollte nicht direkt nach dem ersten Versuch aufgeben. Linux hat potential (dafür sorgt auch Windows 10)...

AW: Linux - Ick freu mir ;-)

Als ich das las war mein erster Gedanke: ach guck,

Kylix ist zurück. Alter Wein in neuen Schläuchen, sozusagen.

Leider kein Wort davon, daß man hier auch mit GDB debuggen kann. Stichwort gdbserver.

Zitat:

Zitat von Rollo62 (Beitrag 1346201)

Wer kennt sich denn mit Linux'en aus ?

Ich sehe 64-Bit Ubuntu im Beispiel als Platform ...

Ist das bei einem Kompilat ohne SO eigentlich egal, das sollte doch auf ALLEN Linux-Derivaten gleich Laufen.
Also wenn nichts spezielles eingebunden wird.

Also wenn die glibc eingebunden wird, kommt es ganz auf den Linker bzw. die Steuerung des Linkers an. Die glibc ist nämlich nur vorwärtskompatibel. Will heißen, daß du ein Programm welches gegen eine neue Version von glibc linkst nicht unbedingt auf einer anderen Distro mit älterer glibc oder derselben Distro aber in älterer Version laufenlassen kannst.

Das kann man, wie geschrieben, steuern. Aber es bringt auch kleine Nachteile mit sich. Dennoch: prinzipiell ist es möglich auch mit einer aktuellen Toolchain Programme zu verfassen die auf uralten Systemen, bspw. 2.6.2er Kernel aufwärts (glibc hängt naturgemäß stark vom Kernel ab), laufen.

Den großen Nachteil einer statisch gelinkten Datei hat Valle natürlich tunlichst verschwiegen: die LGPL. Ja, die LGPL ist hier insofern relevant, weil sie verlangt, daß wahlweise der Quelltext zu eurem Programm mitgeliefert werden muß oder alternativ ihr die Objektdateien mitliefern dürft, damit der Benutzer sie mit einer neuen Version der Bibliothek (bspw. glibc) linken darf.

Man kann mutmaßen, daß die

"GCC Runtime Library Exception" (

FAQ) hier greift, aber eigentlich bezieht sich die ausschließlich auf die libgcc. Aber ihr könnt ja immernoch einen Anwalt anheuern um das ggf. klären zu lassen.

Zitat:

Zitat von Valle (Beitrag 1346206)

Unter Linux ist statisches Linken eher unüblich, zumal gelinkte Bibliotheken dann die Betriebssystemupdates nicht bekommen würden, aber das ist unter Windows ja sowieso immer der Fall.

Auch nur in den Fällen in denen es auf Linux der Fall ist, wenn wir über statisch gelinkte Bibliotheken reden. Ansonsten kommt es auf die Bibliothek an. Die C Runtime von Visual C++ 6.x wurde irgendwann in den Stand einer Systembibliothek erhoben. Ansonsten obliegt es dir die C Runtime Redistributables mitzuliefern.

Zitat:

Zitat von Valle (Beitrag 1346206)

Statisch gelinkte Kompilate sollten mit jeder Distribution auf x86/x64 laufen. Die Kernelversion hat vermutlich wenig Einfluss darauf.

Das kommt allein darauf an welche Systemaufrufe (system calls) in der statisch gelinkten Bibliothek Verwendung finden. So pauschal kann man das nicht sagen.

Ach ja und wenn Delphi hier wie der Linker von Binutils im ELF-Header gewisse Hinweise hinterläßt über die Kompatibilität mit dem Kernel, wirkt das auch einschränkend. Ich empfehle einmal

Code:

file <Dateiname>

auszuführen und die Ausgabe hier zu zeigen. Das hat Herr Cantu leider versäumt.

Zitat:

Zitat von mjustin (Beitrag 1346215)

Mit Free Pascal und Ubuntu 12.04 / 14.04 Single-Exe Anwendungen hatte ich das Problem, dass wegen einer neueren eingebundenen libc die in Ubuntu 14.04 erzeugte Anwendung nicht auf 12.04 ausgeführt werden kann (anders herum habe ich es nicht getestet).

Ich benutze kein FPC, aber mit GCC läßt sich das relativ einfach umgehen. Es handelt sich genaugenommen nämlich nur um eine Handvoll von Funktionen gegen die auf dem neueren System gelinkt wird, welche in der älteren Bibliotheksversion nicht existent sind. Das ist alles steuerbar.

Zitat:

Zitat von Valle (Beitrag 1346245)

Wenn FMX auf Linux portiert würde, dann wahrscheinlich, wie gesagt, direkt auf das X11-Protokoll.

Meiner Meinung nach Wunschdenken. Die werden wohl den Weg des geringsten Aufwands gehen. Und das wäre eine existierende Lösung ala Qt. Was dann wiederum eigene Vorteile (aber auch ein paar Nachteile) mit sich brächte.

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Das größte Problem wird sein das die Libc-Files nicht konvertiert sind zu Delphi, und wahrscheinlich
auch nicht immer 1:1 oder überhaupt konvertierbar sind.

Wieso? Im Gegenteil, wenn diese Linuxversion direkt auf den Systemaufrufen aufsetzen würde, wäre dies lizenztechnisch für kommerzielle Anbieter ein nicht zu verachtender Vorteil (s.o.). FPC macht dies ja scheinbar so - siehe Beiträge von Mitdiskutanten weiter oben.

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Aber was ich generell nicht verstehe ist wie die verschiedenen Libc-Versionen in Linux organisiert sind.
Auch unter Linux muss alles aus dem gleichen Versionsraum kommen, sonst kracht es da auch.

Ich verweise auf

diese Frage&Antwort. Es gibt da auch ein paar Artikel zum Thema

von Herrn Drepper und einigen anderen.

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Gibt es immer mehrere Versionen des Kernels und der Libraries auf jedem System ?
Ich denke das ist eines der Probleme bei Linux, das jede Distribution da alt und neu mischen kann und
auch an anderen Stellen/Bezeichnern ablegen kann.

Leider ist das Problem nicht Linux, sondern dein mangelndes Verständnis :)

Kernel und libc sind aufeinander bis zu einem gewissen Punkt abgestimmt. Viele der Funktionen aus der C-Laufzeit sind nämlich direkt in Systemaufrufe übertragbar. Lesetip: "Designing BSD Rootkits" (Kong), "The Linux Programming Interface" (Kerrisk) und "Advanced Programming in the UNIX Environment" (Stevens, Rago), "The Design and Implementation of the FreeBSD Operating System" (McKusick, Neville-Neil).

Dazu kommen noch die Versionsnummern auf welche ich weiter oben verwies und nicht zuletzt

Versionsskripte, welche einzelnen Funktionen innerhalb einer Bibliothek ebenfalls Versionen mitgeben.

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Vielleicht gibt es aber auch standarisierte Methoden um Libc-Version und Kernelversion bei allen Distributionen rauszufinden, so ähnlich (aber hoffentlich besser strukturiert) wie bei COM ?

Ja, die Methode heißt Dynamic Linker (ld.so) und ist

dokumentiert. Funktioniert allerdings etwas anders als in Windows.

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Ein GCC Compiler hat aber genau die gleichen Probleme, das liegt nicht an Delphi an sich.

Der GCC hat keine Probleme, der Linker gehört noch nicht einmal zu GCC, sondern zu Binutils. Zugegeben, als ich nur Delphi kannte, unterlag ich auch der Illusion daß es eines Schritts von Quelltext zur Binärform bedarf. Lesetip: das "Drachenbuch" über Compiler-Design (auf dt. "Compiler: Prinzipien, Techniken und Werkzeuge").

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Wenn man die richtigen Libs und deren Position kennt kann man das zusammenbauen.
Also wäre ein C++Builder vielleicht geeigneter als Delphi um GCC Projekte zu kompilieren und einzubinden ?

Es ist herzlich irrelevant welcher Compiler genutzt wird. Das vermeintliche Problem entsteht durch die Standardeinstellung des Linkers (und der kann gesteuert werden, so daß es überhaupt kein Problem gibt, wenn man sich damit beschäftigt).

Zitat:

Zitat von Namenloser (Beitrag 1346251)

Aber der klassische Unix-Weg wäre ja auch eher mit fork und wait statt Threads :roteyes:

Sehe ich auch so, aber bei uns in der Firma werden seltsamerweise oft trotzdem Threads bevorzugt. Finde es seltsam, denn bei einem Fehler ist es ja der Kernel welcher den Prozeß abschießt. Einen Mechanismus wie SEH gibt es da nicht. Kurzum: ich bevorzuge mindestens ein fork() denn nur dann kann ich den Kindprozeß überwachen und ggf. Maßnahmen ergreifen falls etwas passiert. Ist übrigens zusammen mit AFL oder den Sanitizern von Clang (und mittlerweile ja auch GCC) unschlagbar für automatisiertes Testen.

Zitat:

Zitat von mael (Beitrag 1346266)

Zitat:

Zitat von Valle (Beitrag 1346245)

Aber ich sprach von statisch gelinkten ELFs. (keine Exen, die gibt's unter Linux nicht ;-) ).

Wo wir schon genau sind :p
Unter Linux kann eine executable (=eine Datei die das executable-Recht gesetzt hat) jede Dateiendung haben die sie will, auch ".exe", nur hat sie üblicherweise keine Endung (oder es ist ein Skript wie .pl .sh oder eine ELF-Bibliothek .so). Das Gegenstück zu ELF in Windows sind PE-Dateien (die auch unterschiedliche Dateierweiterungen erlauben für "normale" ausführbare Dateien aber auch DLLs/Bibliotheken/Treiber).

Ich finde exe ist da klarer als das häufige binary (was alles sein kann).

Es kann gerade nicht alles sein. Auf Linux ist für Skripte nicht das x ausschlaggebend, sondern die Hashbang (#!). Für binäre Programme hingegen gibt es eine Möglichkeit

beliebige Formate interpretieren zu lassen.

Falls du immer verwirrt bist worum es sich bei einer Datei handelt, empfehle ich das oben bereits erwähnte Tool "file", welches dir auf unixartigen Systemen üblicherweise zur Verfügung steht.

Zitat:

Zitat von Rollo62 (Beitrag 1346268)

Zitat:

Zitat von Valle (Beitrag 1346261)

Normalerweise kompilierst du dein Programm exakt für deine Zielplattform.

Ist das so? Mal dumm geantwortet: auf Linux überwiegen Programme mit offenen Quellen, macht da Rückwärtskompatibilität mit Präprozessor-Direktiven (ifdef etc) soviel Sinn wie auf Windows? Abgesehen davon scheint dir der Begriff DLL-Hölle unbekannt zu sein. Möglicherweise der Segen eines jungen Lebens? ;)

Zitat:

Zitat von Rollo62 (Beitrag 1346268)

Ich habe bisher nur ein bischen mit Bash und Konsolen-GCC rumgespielt, das Hauptproblem was ich damit hatte ist "wo ist was ?".

Dann empfehle ich bspw. "apropos", "man" und "info". Wobei man die entsprechenden Handbücher vorher installieren sollte. Wer das nicht möchte, wendet sich vertrauensvoll an linux.die.net oder man7.org.

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346288)

Kann natürlich sein, dass ich jetzt zufällig überall auf dieselbe Version der libc gestoßen bin, [...]

Bist du bei den genannten Versionen von Ubuntu definitiv nicht. Und selbst wenn die Versionsnummer stimmt, heißt das auf Linux oft wenig. Viele der Kernel die als 2.4er firmierten (ich sage nur Redhat) waren schon soweit gepatcht, daß sie halbe 2.6er waren. Offenliegende Quellen eben ...

Zitat:

Zitat von Valle (Beitrag 1346334)

Doch, ist aber so. Microsoft hat seine Plattform ja voll in eigener Hand. Linux besteht aus sehr vielen unabhängigen Projekten.

Linux besteht aus einem Kernel - Punkt. Was du vermutlich meinst ist der GNU-Aufsatz auf dem Linuxkernel ;)

Zitat:

Zitat von Valle (Beitrag 1346334)

Wir Softwareentwickler wissen aber, dass ständige Rückwärtskompatibilität selten etwas gutes für unsere Software bedeutet.

Den müßtest du - zumindest mir - nochmal erklären.

Zitat:

Zitat von Harry Stahl (Beitrag 1346739)

Nun ja, an Delphi hängt schon mein Herz...

Das zu hören freut die Verkaufsabteilung ;)

Zitat:

Zitat von Harry Stahl (Beitrag 1346739)

Aber das käme nur ernsthaft in Betracht, wenn die Preispolitik um Delphi völlig abdreht [...]

Ich finde sie schon seit Jahren völlig abgedreht. Weiter oben erwähnte einer der Mitdiskutanten, daß es Wahnsinn sei, daß er gebündelt Pakete mit kaufen müsse, welche er nicht benötigt. Dem kann ich nur aus ganzem Herzen zustimmen. Genau deshalb habe ich mich von Delphi abgewandt.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1346741)

Jeder "Administrator" der eine GUI benötigt um sich durchzufrickeln ist kein Administrator. Und da haben wir über die vielen Sicherheitslücken noch nicht gesprochen, welche allein aufgrund der webseitigen Administrationsoberflächen entstanden sind und entstehen.

AW: Linux - Ick freu mir ;-)

Zitat:

Leider kein Wort davon, daß man hier auch mit GDB debuggen kann. Stichwort gdbserver.

Wahrscheinlich schon. Auch bei der der OSX-Variante ist das so.

Zitat:

Entweder FMX oder gar keine UI. Für die Linuxplattform wird man keinen Sonderweg gehen.

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von mkinzler (Beitrag 1346807)

Entweder FMX oder gar keine UI. Für die Linuxplattform wird man keinen Sonderweg gehen.

Es ging ja auch um den Unterbau welcher am wahrscheinlichsten wäre.

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Assarbad (Beitrag 1346799)

Den großen Nachteil einer statisch gelinkten Datei hat Valle natürlich tunlichst verschwiegen: die LGPL.

Nicht verschwiegen, aber vergessen, ja.

Zitat:

Zitat von Assarbad (Beitrag 1346799)

Linux besteht aus einem Kernel - Punkt. Was du vermutlich meinst ist der GNU-Aufsatz auf dem Linuxkernel ;)

Für

diese Diskussion bist du leider 20 Jahre zu spät.

Zitat:

Zitat von Assarbad (Beitrag 1346799)

Zitat:

Zitat von Valle (Beitrag 1346334)

Wir Softwareentwickler wissen aber, dass ständige Rückwärtskompatibilität selten etwas gutes für unsere Software bedeutet.

Den müßtest du - zumindest mir - nochmal erklären.

Für mich bedeutet Rückwärtskompatibilität mehr Arbeitsaufwand. Die Kompatibilität erhält sich leider meist nicht von selbst. Mehr Arbeit und das "Herumschleppen" alten Codes sind für mich Nachteile. Auch

sich daraus ergebene APIs tendieren dazu, weniger schön zu werden. Das bedeutet nicht, dass es nicht notwendig sei. Manchmal will man gern alten Kram über Board werfen, aber das geht nun mal nicht immer.

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Valle (Beitrag 1346842)

Zitat:

Zitat von Assarbad (Beitrag 1346799)

Den großen Nachteil einer statisch gelinkten Datei hat Valle natürlich tunlichst verschwiegen: die LGPL.

Nicht verschwiegen, aber vergessen, ja.

Hmm, da habe ich Vorsatz unterstellt wo es keinen gab. Verzeihung :oops:

Zitat:

Zitat von Valle (Beitrag 1346842)

Für

diese Diskussion bist du leider 20 Jahre zu spät.

Der Standpunkt von RMS ist mir leidlich bekannt. Die Frage ist nur in der Tat, wie man kurz und bündig von einem Linuxkernel mit GNU-Userland spricht und dies gleichzeitig von nicht GNU-basierten Systemen abgrenzt? Android läuft ja auch auf einem Linuxkernel, aber mit eigener C-Laufzeitbibliothek (Bionic) und einer Menge Komponenten die nicht unter GPL stehen oder dem GNU-Projekt unterstellt sind.

Dem Wikipediaartikel entnehme ich auch keine endgültige Entscheidung in die eine oder andere Richtung. Aber wir können uns ja einigen, daß wir da einfach verschiedener Ansicht sind was wann sinnvoll ist ;) ... hab ich kein Problem mit.

Zitat:

Zitat von Valle (Beitrag 1346842)

Für mich bedeutet das Erstellen von x Varianten desselben Projekts viel mehr Aufwand als einmal (wir sprachen ja über glibc) eine Lösung zu erarbeiten und diese konsequent einzusetzen. Oft läuft es ja auch darauf hinaus alte Distros vorzuhalten zu denen man nicht einmal mehr Medien bekommt. Denn jede Variante will getestet sein. Wenn aber nicht nur die C-Laufzeit, sondern auch andere Bibliotheken ins Spiel kommen, kann es zugegebenermaßen schnell unübersichtlich werden überhaupt eine Rückwärtskompatibilität herzustellen (wie in deinem Beispiel mit MySQL). Zum Glück habe ich dieses Problem nur mit der glibc [1] und nicht mit anderen Bibliotheken.

[1] und dann kann man mit musl-libc oft selbst statisch gelinkte Dateien kleiner bekommen als dynamisch gegen die glibc gelinkten.

AW: Linux - Ick freu mir ;-)

Hallo Asserbad,

dankesehr für deine Erleuchtungen und Lesetips :-)
Es ist doch gut zu wissen das sich hier schon einige Linux-Experten tummeln.

Zitat:

Zitat von Assarbad (Beitrag 1346799)

Vielleicht habe ich das nicht korrekt beschrieben, mit GCC meinte ich die ganze Toolchain im Vergleich zu BCB (auch mit Compiler/Linker).

Jedenfalls denke ich das die Headerkonvertierung von den Libs zu Delphi nicht immer 1:1 und einfach sein wird, oder hat FPC schon vorgemacht das man alles butterweich eingebunden bekommt ?

Deshalb ist mein Gedanke (eigentlich genau wie unter Windows), das man besser mit C++Builder direkt auf die GCC Projekte losgeht.
Und bestenfalls die vielen bestehenden Linux-Projekte 1:1 mit GCC oder C++Builder kompilieren könnte.

Das wünschte ich mir übrigens auch unter Windows, um VC Projekte direkt im C++-Builder kompilieren zu können, aber immer wenn ich das mal versucht hatte artete das in komplette rewrites aus.

So könnte man die ganzen bestehenden Projekte in Linux/Windows direkt ohne Umweg nutzen.
Da könnte ich einen Vorteil von C++Builder zu Delphi sehen.
Wie oft habe ich schon versucht eine VC++ DLL einzubinden, und konnte keine Lösung für bestimmte Konstrukte finden.

Ich sehe aber das es Zeit wird sich mal tiefer mit Linux zu beschäftigen
(das wollte ich schon seit Jahren).

Rollo

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Rollo62 (Beitrag 1346888)

dankesehr für deine Erleuchtungen und Lesetips :-)

Gern.

Zitat:

Zitat von Rollo62 (Beitrag 1346888)

Es ist doch gut zu wissen das sich hier schon einige Linux-Experten tummeln.

Naja, also als Experten würde ich mich nicht sehen. Aber auch nicht mehr als blutiger Anfänger.

Zitat:

Zitat von Rollo62 (Beitrag 1346888)

Jedenfalls denke ich das die Headerkonvertierung von den Libs zu Delphi nicht immer 1:1 und einfach sein wird, oder hat FPC schon vorgemacht das man alles butterweich eingebunden bekommt ?

FPC umgeht das allem Anschein dadurch, daß sie eine eigene Laufzeit implementieren, welche direkt auf den Systemaufrufen aufsetzt. Das macht total viel Sinn und erleichtert bspw. die Portierung auf andere unixartige Systeme ungemein, denn die glibc ist nicht gerade dafür bekannt sich an Standards zu halten. Nicht nur daß man das Lizenzproblem mit glibc umschifft, nein man kann je nach Zielsystem bspw. einfach die Nummern der Systemaufrufe anpassen und hat sofort eine lauffähige Laufzeitumgebung. Das ist exakt weswegen es SUS (ehemals POSIX) gibt. Denn die Portierbarkeit bezieht sich ja in der Tat vor allem auf die standardisierte Schnittstelle Systemaufruf, sowie die C-Laufzeit welche zu einem bestimmten Grad standardisiert ist.

Zitat:

Zitat von Rollo62 (Beitrag 1346888)

Das wünschte ich mir übrigens auch unter Windows, um VC Projekte direkt im C++-Builder kompilieren zu können, aber immer wenn ich das mal versucht hatte artete das in komplette rewrites aus

Klingt auch irgendwie wie das schlechteste aus beiden Welten, es sei denn nur der BCB-Compiler würde benutzt und als Linker der von MSVC und das ganze würde in Debugsymbolen resultieren welche WinDbg lesen kann. Wobei vermutlich dazu Anpassungen seitens BCB notwendig wären. Aber Clang beweist, daß es geht.

Zitat:

Zitat von Rollo62 (Beitrag 1346888)

So könnte man die ganzen bestehenden Projekte in Linux/Windows direkt ohne Umweg nutzen.

Also einige Kommandozeilenprogramme solltest du im Prinzip ohne Umweg sowohl mit BCB als auch MSVC und auf Linux mit Clang oder GCC kompilieren können. Da gibt es nur im Detail Unterschiede oder verschiedene #ifdef-Blöcke je nach System oder Compiler (siehe auch predef.sf.net).

Zitat:

Zitat von Rollo62 (Beitrag 1346888)

Ich sehe aber das es Zeit wird sich mal tiefer mit Linux zu beschäftigen
(das wollte ich schon seit Jahren).

Viel Spaß und Erfolg!

@Valle: ich wollte nur noch anfügen, daß ich mittlerweile daran arbeite meine Test- und Buildumgebung als "ephemeral container" laufen zu lassen, also einen Container der aus einer Vorlage zum Erledigen einer Aufgabe und darauffolgendem Wegwerfen erstellt wird. x86_32 Linux lassen sich hervorragend auch auf einem x86_64-Host als Container betreiben (LXC oder sogar chroot über schroot).

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Assarbad (Beitrag 1346893)

@Valle: ich wollte nur noch anfügen, daß ich mittlerweile daran arbeite meine Test- und Buildumgebung als "ephemeral container" laufen zu lassen, also einen Container der aus einer Vorlage zum Erledigen einer Aufgabe und darauffolgendem Wegwerfen erstellt wird. x86_32 Linux lassen sich hervorragend auch auf einem x86_64-Host als Container betreiben (LXC oder sogar chroot über schroot).

Ja, natürlich. Hab ich das irgendwo abgestritten?

(Wobei strenggenommen läuft da kein Linux in deinem Container, da die Container den Hostkernel verwenden. Da läuft nur GNU. Soviel dazu.)

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Valle (Beitrag 1346895)

Ja, natürlich. Hab ich das irgendwo abgestritten?

Nein. Verzeih. Ich dachte nur die Information könnte interessant sein für dich. Immerhin ist das nirgends offiziell dokumentiert, daß man auch 32-bittige Gäste auf einem x86_64-Kernel laufenlassen kann (chroot oder LXC).

Zitat:

Zitat von Valle (Beitrag 1346895)

(Wobei strenggenommen läuft da kein Linux in deinem Container, da die Container den Hostkernel verwenden. Da läuft nur GNU. Soviel dazu.)

Kommt auf die verwendete Technik an, bei Namensräumen (LCX) kann man schon davon sprechen, daß auch ein Teil des Kernels im Container läuft, bei chroot eher nicht. Es ging aber oben auch um die Distro (also den Teil den du als Linux bezeichnetest). Da habe ich mich deiner Sprachregelung angepaßt und nun wirfst du es mir vor ... :roll:

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Assarbad (Beitrag 1346896)

Zitat:

Zitat von Valle (Beitrag 1346895)

Ja, natürlich. Hab ich das irgendwo abgestritten?

Achso, danke, vielleicht brauche ich das mal. :thumb:

Zitat:

Zitat von Assarbad (Beitrag 1346896)

Zitat:

Zitat von Valle (Beitrag 1346895)

(Wobei strenggenommen läuft da kein Linux in deinem Container, da die Container den Hostkernel verwenden. Da läuft nur GNU. Soviel dazu.)

Achso, du hast dich angepasst. Entschuldigung, ich dachte nur du kämst jetzt selbst damit durcheinander. Das fand ich lustig. Nichts für ungut. :cyclops:

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Assarbad (Beitrag 1346893)

FPC umgeht das allem Anschein dadurch, daß sie eine eigene Laufzeit implementieren,...

Ja wahrscheinlich macht das Sinn einen LAyer dazwischenzuhaben.
Generell verstehe ich bei diesen POSIX-Funktionen nicht ganz WAS sih eigentlich ändert.
Ich sehe das ein bischen so wie die API zur DOS-CommandZeile, oder zu WMI, da gibt es verschiedene Katgorien:
"Mature"-Funktionen ?
- Memory Zugriff
- Filezugriff
- Sockets
- IPC
- Pipes
- Regex
- Math
- etc.
Funktionen vielleicht in "Änderung"
- SystemManagement
- ???

Von der Seite der System-Stabilität her würde ich erwarten das 98% der glibc API doch
komplett "durchentwickelt" sein müsste, zumindest hinsichtlich der APIs.
Und mögliche Änderungen beziehen sich hoffentlich nur auf Neue oder "Sonder"-Funktionen.

Oder wird auch ständig an den Grundpfeilern herumgebastelt ?

Solange die APIs gleich bleiben, und nur an der Performance verbessert wird, sollte die Anpassung
auf neue Versionen doch relativ simpel bleiben.
Ich kann mir einfach nicht vorstellen das man bei jeder Version alles wieder auf den Kopf stellt.

Rollo

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Rollo62 (Beitrag 1346939)

Generell verstehe ich bei diesen POSIX-Funktionen nicht ganz WAS sih eigentlich ändert.

Bin mir nicht sicher was genau du damit meinst. Wenn du meinst von System zu System (bspw. GNU/Linux vs. FreeBSD) oder über die Zeit, dann wäre beispielsweise die Änderung von time_t von einem 32-bittigen Typen zu 64-bit eine ABI-inkompatible Änderung, die aber bei einfacher Neukompilierung keine Rolle spielt. Denn SUS/POSIX sorgt für Kompatibilität auf Quelltextebene (Stichwort: Portierbarkeit).

Zitat:

Zitat von Rollo62 (Beitrag 1346939)

Ich sehe das ein bischen so wie die API zur DOS-CommandZeile, oder zu WMI, da gibt es verschiedene Katgorien:
"Mature"-Funktionen ?
- Memory Zugriff
- Filezugriff
- Sockets
- IPC
- Pipes
- Regex
- Math
- etc.
Funktionen vielleicht in "Änderung"
- SystemManagement
- ???

In der Tat. Wenn du willst, kann ich dir das Inhaltsverzeichnis von The Linux Programming Interface schicken. Melde dich ggf. per PN.

Zitat:

Zitat von Rollo62 (Beitrag 1346939)

Von der Seite der System-Stabilität her würde ich erwarten das 98% der glibc API doch komplett "durchentwickelt" sein müsste, zumindest hinsichtlich der APIs.
Und mögliche Änderungen beziehen sich hoffentlich nur auf Neue oder "Sonder"-Funktionen.

Oder wird auch ständig an den Grundpfeilern herumgebastelt ?

Eine Prozentzahl kann ich dir nicht geben, aber manchmal wird in der Tat auch an Grundpfeilern herumgebastelt um bspw. die Sicherheit zu erhöhen (bspw. Schutz gegen Pufferüberläufe und dergleichen). Aber in der Tat ändert das an den Schnittstellen wenig. Nur leider ist es so, daß einige Anwendungen sich auf glibc festlegen statt einfach eine C-Laufzeitbibliothek zu erwarten. Das tun sie wahlweise indem sie glibc-spezifische Schnittstellen verwenden oder indem sie Interna benutzen. Nicht zuletzt führt auch die falsche Benutzung von Defines (auch in glibc selbst) zu Inkompatibilitäten auf Quelltextebene (hier wird also eine Neukompilierung angestrebt).

Zitat:

Zitat von Rollo62 (Beitrag 1346939)

Solange die APIs gleich bleiben, und nur an der Performance verbessert wird, sollte die Anpassung
auf neue Versionen doch relativ simpel bleiben.
Ich kann mir einfach nicht vorstellen das man bei jeder Version alles wieder auf den Kopf stellt.

Da hast du recht. Aber ich verstehe nicht ganz worauf du hinaus willst?!

Ein altes Programm welches, sagen wir mal, vor 10 Jahren gegen glibc gelinkt wurde auf einer damals aktuellen Distro, läuft ja üblicherweise problemlos auf einer neueren Distro. Umgekehrt aber nicht. Also ein auf einer neueren Distro gelinktes Programm mit älterer glibc.

Hier zwei Beispiele von Funktionen bei denen man die Kompatibilität mit älteren glibc-Versionen erzwingen muß: memcpy und realpath. Das erreicht man folgendermaßen. Man erzeuge ein Macro entsprechend der glibc-Version zu der man Kompatibilität herstellen möchte:

Code:

			#ifdef __amd64__

#   define GLIBC_COMPAT_SYMBOL(fct) __asm__(".symver " #fct "," #fct "@GLIBC_2.2.5");

#else

#   define GLIBC_COMPAT_SYMBOL(fct) __asm__(".symver " #fct "," #fct "@GLIBC_2.0");

#endif /* __amd64__ */

Hinweis: 2.2.5 war die erste Version mit Unterstützung für amd64 bzw. x86_64. Der Parameter fct ist dabei der Name der Funktion, welcher mithilfe des Stringification-Operators (#) zu einem Literalstring wird.

Zu .symver siehe hier.

Angewendet wird das Makro dann wie folgt:

Code:

			GLIBC_COMPAT_SYMBOL(realpath)

GLIBC_COMPAT_SYMBOL(memcpy)

Mit dem Effekt, daß nunmehr nicht die neueste Version von memcpy und realpath, sondern die älteste Version benutzt wird. Die Methode kann man übrigens der Datei include/libc-symbols.h entnehmen welche sich in (e)glibc befindet.

Für jene die nachvollziehen wollen welche Symbole in welcher Version vorliegen, hier eine Möglichkeit:

Code:

			$ readelf -a /lib/x86_64-linux-gnu/libc.so.6|grep ' memcpy@'

  1123: 0000000000091620    61 IFUNC   GLOBAL DEFAULT   12 memcpy@@GLIBC_2.14

  1125: 000000000008c420    71 IFUNC   GLOBAL DEFAULT   12 memcpy@GLIBC_2.2.5

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Rollo62 (Beitrag 1346939)

Zitat:

Zitat von Assarbad (Beitrag 1346893)

FPC umgeht das allem Anschein dadurch, daß sie eine eigene Laufzeit implementieren,...

Ja wahrscheinlich macht das Sinn einen LAyer dazwischenzuhaben.

eigentlich genau das Gegenteil, in diesem Fall unnötige Abhängigkeiten zu reduzieren

http://wiki.freepascal.org/libc_unit

AW: Linux - Ick freu mir ;-)

Ja dankesehr für das Beispiel, das macht es schon etwas klarer.
Also kommt man ggf. doch in die IFDEF-Hölle, wenn man nicht aufpasst.

Ich versuche meistens immer eher einen Grundsatz von Funktionen zu verwenden, und Spezialitäten erstmal wegzulassen.
Also z.B. strcpy, memcpy, etc. solche Funktionen die es schon seit den 60ern unverändert geben sollte.

Sollte doch möglich so einen Satz Grundfunktionen zu finden wo die API nicht komplett verrückt spielt,
und ich gehe für mich jetzt mal vom aktuellsten Linux aus.
Muss ja bei Neuprojekten nicht 20 Jahre rückwärtskompatibel sein.

Ich warte mal ab wie das im neuen Delphi umgesetzt wird, da bin ich schonmal gespannt.

Rollo

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Rollo62 (Beitrag 1346991)

Unter FreePascal habe ich ein paar recht große Projekte laufen, die sowohl für Windows als auch Linux kompiliert werden. In allen zusammen genommen findet sich genau zwei IFDEFs, und zwar zur Festlegung des Pfadtrenners (Slash/Backslash) und zur Ermittlung der Systemsprache. Es ist also halb so wild.

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346999)

In allen zusammen genommen findet sich genau zwei IFDEFs, und zwar zur Festlegung des Pfadtrenners (Slash/Backslash)

Da Windows auch den Slash unterstützt, ist das noch nicht einmal unbedingt immer nötig, je nachdem was man damit macht.

AW: Linux - Ick freu mir ;-)

Zitat:

Zitat von Benedikt Magnus (Beitrag 1346999)

Das geht und weist auf eine von zwei Möglichkeiten (oder beide) hin: 1.) die grundlegenden Bibliotheken von FreePascal sind saugut konzipiert und/oder 2.) dein Projekt benutzt überhaupt nur wenige systemspezifische Konstrukte.

Vergessen darf man auch nicht, daß du den gleichen Compiler benutzt, möglicherweise sogar denselben, falls du cross-kompilierst. Wenn du jeweils GCC auf Windows, Linux, AIX und Solaris benutzt können dir viele Probleme anderer Leute mit ifdefs auch wumpe sein. Sobald aber schon ein Strauß verschiedener GCC-Versionen benutzt wird, kommste u.U. in unruhige Gewässer. Wenn dann dein Code auch noch gewisse Anforderungen an den Compiler hat (Speicherausrichtung auf 64-bit SPARC [1], bspw.) und der GCC in seiner vorhandenen Version genau dort schwächelt, kommste um eine Alternative für GCC schon nicht mehr herum (SunC/Sun Studio). Wenn du aber bspw. auf Windows auch sinnvoll post-mortem Debugging mit Minidumps machen willst, brauchste DbgHelp-kompatible Symbole, welche der GCC (bzw. der benutzte Linker) nicht erstellt. Also stellste in Windows auf MSVC um. Und so weiter und so fort. Dann sind wir bei vier Systemen schon bei drei Compilern (jeweils gleiche Sprache C/C++), wobei die Versionsunterschiede noch nicht mitgerechnet sind. Da lassen sich #if und #ifdef selten vermeiden. Bei der Software für die ich beruflich verantwortlich zeichne, habe ich es, je nach Paket, mit bis zu 14 Plattform/Prozessorarchitektur-Paaren zu tun. Und da sind dann die OS-Versionen noch nicht mitgerechnet, sei es wegen glibc oder wegen einer inkompatiblen ABI-Änderung.

Aber ich hoffe daß hier die Konkurrenz (FPC vs. Delphi) die treibende Kraft ist und sich die Entwickler von Delphi ein Beispiel an der tollen Umsetzung bei FPC nehmen. Bei Clang vs. GCC hat es ja geklappt. Die hilfreichen Fehlermeldungen gibt es nun schon eine Weile auch mit dem GCC und die Sanitizer wurden auf GCC portiert.

Zitat:

Zitat von Rollo62 (Beitrag 1346991)

Also kommt man ggf. doch in die IFDEF-Hölle, wenn man nicht aufpasst.

Der Nachsatz ist wichtig: wenn man nicht aufpaßt, ja. Und selbst wenn man aufpaßt, sollte das Aufpassen so sorgfältig geschehen, daß man sich keine eigenen Probleme schafft (bspw. statt mit den IFDEFs Unterschiede zu betonen, lieber Gemeinsamkeiten der jeweiligen Varianten betonen).

Zitat:

Zitat von Rollo62 (Beitrag 1346991)

Ich versuche meistens immer eher einen Grundsatz von Funktionen zu verwenden, und Spezialitäten erstmal wegzulassen.
Also z.B. strcpy, memcpy, etc. solche Funktionen die es schon seit den 60ern unverändert geben sollte.

Sollte doch möglich so einen Satz Grundfunktionen zu finden wo die API nicht komplett verrückt spielt,
und ich gehe für mich jetzt mal vom aktuellsten Linux aus.
Muss ja bei Neuprojekten nicht 20 Jahre rückwärtskompatibel sein.

Der Witz ist, daß es mit SUS/POSIX vermutlich in vielen Fällen dennoch (quelltext-)rückwärtskompatibel ist. Es sei denn du machst eklige Sachen wie eigene Typen in Fällen einzusetzen wo eingebaute und Bibliothekstypen benutzt werden sollten (bspw. direkt irgendwelche Integer statt ptrdiff_t, off_t).

Und viele der API-Funktionen die spezifisch nur für ein System entwickelt wurden (vfork, wait3, wait4), haben es auch schon in andere Systeme geschafft (bei Linux/FreeBSD mehrfach), bei anderen gibt es gute Alternativen. Aber in vielen Fällen wird das erst dann relevant wenn du deinen Code auf Geschwindigkeit trimmst oder ähnliches. Solange du ein 08/15-Programm schreibst (also keinen Datenbank- oder Webserver) und mit der Geschwindigkeit zufrieden bist, tun es auch jene Funktionen für Speicherverwaltung, Stringverarbeitung und E/A, welche auf allen unixartigen Systemen quelltextkompatibel implementiert sind.

Zitat:

Zitat von Rollo62 (Beitrag 1346991)

Ich warte mal ab wie das im neuen Delphi umgesetzt wird, da bin ich schonmal gespannt.

Ich auch. Hoffe auf Rückmeldungen in diesem Thema. Da werd' ich dann ja benachrichtigt.

[1] Speicherausrichtung wird relevant wenn du bspw. auf Integer zugreifst die nicht korrekt ausgerichtet sind. Zwar geht auch das bspw. in SunC und GCC, aber es führt zu einer Geschwindigkeitsreduktion, weil die Ausrichtung auf Prozessorebene erwartet wird. Sind Daten falsch ausgerichtet, kommt es zu einem Fehler ähnlich wie bei einer Division durch Null. Dieser Fehler kann abgefangen und behandelt werden, aber diese Behandlung führt eben zu Performanceverlusten.

Seite 2 von 2