Linux - Ick freu mir ;-)

[bernau]

http://blog.marcocantu.com/blog/2016...hi-coming.html

[Mavarik]

Das Erkläre mal einem Dritten, Deiner Freundin oder so...

Warum Du Dich über eine 8 am Bildschirm - so freuen kannst... 8-)

[bernau]

Zitat:

Zitat von Mavarik (Beitrag 1346124)

Das Erkläre mal einem Dritten, Deiner Freundin oder so...

Warum Du Dich über eine 8 am Bildschirm - so freuen kannst... 8-)

Die inneren Werte zählen. Man muss in der Lage sein das zu erkennen. Meine Freundin versteht das. :lol:

[bra]

Wenn es wenigstens 42 wäre... aber so... :lol:

[DeddyH]

Wo ist da jetzt das Killer-Feature gegenüber FP/Lazarus?

[lowmax_5]

Geht das nicht bereits jetzt schon?!... http://www.crossfpc.com/

[mkinzler]

Der FreePascal-Compiler ist aber nicht ganz zu Delphi kompatibel.

[bernau]

Zitat:

Zitat von DeddyH (Beitrag 1346130)

Wo ist da jetzt das Killer-Feature gegenüber FP/Lazarus?

Wahrscheinlich der gleiche Grund, weshalb ich Delphi für die Windows-Programmierung verwende und nicht FP.

Ich brauche nur eine IDE

[DeddyH]

Zitat:

Zitat von bernau (Beitrag 1346135)

Ich brauche nur eine IDE

Und dafür einen PAServer auf dem Zielsystem.

[jaenicke]

Zitat:

Zitat von DeddyH (Beitrag 1346130)

Wo ist da jetzt das Killer-Feature gegenüber FP/Lazarus?

Lazarus hat z.B. weder Datasnap noch FireDAC. Von der trotz deutlich weniger Fehlern unproduktiveren IDE mal ganz zu schweigen.

[Der schöne Günther]

Zitat:

Zitat von DeddyH (Beitrag 1346136)

Und dafür einen PAServer auf dem Zielsystem.

Danach wollte ich grade fragen.

[DeddyH]

Da die deutlich produktivere IDE unter Windows, Windows und Windows läuft, geht es ja gar nicht anders, auf dem Screenshot ist es auch zu sehen.

[Der schöne Günther]

Ich hatte mir das Konsolenfenster nicht genau angesehen. Als ewiger Schwarzmaler hätte ich befürchtet dass es keinen PA Server für Linux gibt und man erst ein zwei Jahren seine Anwendungen auch debuggen kann.

Alles in Butter 8-)

[mkinzler]

Zitat:

- We don't plan migrating the IDE and compilers outside of Windows
for now

Der Compiler wäre schon nicht schlecht

[TBx]

Zitat:

Zitat von DeddyH (Beitrag 1346145)

... unter Windows, Windows und Windows ...

so frei nach Herrn Eißing ;-)

[p80286]

Ja und?
Die alten Säcke können sich vllt. noch erinnern, TP 2.1 lief unter CP/M und DOS. Auf einem System entwickeln auf zweien (nach Kompilierung auf dem Zielsystem)lauffähig.
Das war Spitze, einzig die Diskettenwechselei war nervig.

a) ich hab einen Job zu erledigen.
b) dazu benötige ich ein Programm
...
h) ich nutze Delphi
...
k) auf allen Zielplatformen habe ich den gleichen Komfort

Das sind meine Prioritäten, und wenn es nichts besseres gibt (schneller zur Hand/preisgünstiger) dann nehme ich sogar Basic oder sonst eine Scriptsprache.

(Mein Job ist es Daten zu schaufeln, da sind die Ansprüche an eine Oberfläche eher gering)

Gruß
K-H

[DeddyH]

Zitat:

Zitat von TBx (Beitrag 1346150)

Zitat:

Zitat von DeddyH (Beitrag 1346145)

... unter Windows, Windows und Windows ...

so frei nach Herrn Eißing ;-)

Egg freelight (Ei freilicht) :lol:

[Rollo62]

Icke freu mir oooch :stupid:

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.

Oder sehe ich das falsch ?
Eine einfach Kommandozeile sollte doch bei ALLEN gleich sein.

Rollo

[Sherlock]

Es kommt dann noch auf die Prozessorarchitektur an. Freilich werden Kompilate von Godzilla (offizieller Name mit Sicherheit Tokio) zB nicht auf einem Raspberry mit Raspbian (der Raspberry Variante von Debian) laufen, wegen ARM-Chip und so.

Sherlock

[Valle]

Zitat:

Zitat von Rollo62 (Beitrag 1346201)

Wer kennt sich denn mit Linux'en aus ?

Da bin ick! :stupid:

Statisch gelinkte Kompilate sollten mit jeder Distribution auf x86/x64 laufen. Die Kernelversion hat vermutlich wenig Einfluss darauf. Statisch gelinkte Dateien werden dann allerdings auch sehr groß. 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. Generell ist der Binary-only Ansatz unter Linux unüblich.

Bei grafischen Programmen könnte es unter Umständen schwieriger werden. Sollten die mit Delphi geschriebenen Programme mal Qt oder GTK unterstützen, würde die Abhängigkeit vom laufenden System zu Gunsten der grafischen Integrität vergrößert werden. Eine andere Option wäre eine direkte Anbindung an X11, dessen Interface sich schon länger nicht mehr verändert hat und daher weitgehend unterstützt wird. Dann würden grafische Programme ähnlich wie viele Java-Programme optisch aber sehr herausstechen. Ich weiß aber nicht inwiefern das überhaupt geplant oder möglich ist. Bis es mal soweit ist, könnte X11 bereits von Wayland verdrängt worden sein. (Hoffe ich!)

Leider wird in letzter Zeit häufig Ubuntu mit Linux gleichgesetzt und der Unterschied zwischen Kernel und Betriebssystem ignoriert. Insbesondere bei Delphi finde ich das komisch, da ich vermute, dass mit Delphi geschriebene Programme für Linux eher den Enterprisesektor bedienen werden, wo Ubuntu bisher noch nicht so viel Anklang gefunden hat. Hier wäre eher RedHat mein erster Gedanke gewesen. Aber man wirbt bei Microsoft ja jetzt auch mit "Ubuntu for Windows". Das ist ja auch nicht falsch, da die Paketlisten und Kompilate tatsächlich von Ubuntu stammen, aber die eigentliche Arbeit die das ermöglicht bezieht sich mehr auf Linux als auf Ubuntu. Ich schweife ab. ;-)

[mkinzler]

Falls irgendwann etwas "grafisches" kommt, dann sicherlich FMX, also keine Abhängigkeit von einer Bibliothek, aber das Problem, des "Fremdaussehens".

[DeddyH]

Da gehe ich auch davon aus, man hat ja seinerzeit mit Kylix nicht die besten Erfahrungen gemacht.

[mjustin]

Zitat:

Zitat von Valle (Beitrag 1346206)

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

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).

Für Delphi Single-Exe unter Linux könnte vermutlich dann die gleiche Unverträglichkeit bestehen?

[frapo]

Mir ist schon klar, dass ich da eindeutig zur Minderheit zähle - da ich vornehmlich Linux-Anwender bin. Was habe ich davon, dass ich nun für Linux Konsolenprogramme erstellen kann? Das kann ich schon recht lange, und wenn es Object Pascal sein soll, dann mit fpc.

Natürlich habe ich die Hoffnung, dass diesem ersten Schritt weitere folgen werden. Beispielweise der Compiler oder gar die IDE für Linux.. was ja erst mal als ausgeschlossen gilt.

Außerdem denke ich, dass für die Plattform Linux ernsthaft entwickeln zu können, erfordern wird, Architect oder Enterprise kaufen zu müssen, ohne auf der Plattform entwickeln zu können die ich eigentlich bevorzuge.
Warum darf man eigentlich nicht wählen, für welche Plattform man entwickelt? Auch preislich meine ich. Warum muss ich für Plattformen bezahlen, für die ich gar nicht entwickeln möchte? Smartphones, OS X in meinem Falle.

Für mich eine nette Spielerei das Ganze, aber mir persönlich fehlt konkret ein realistisches Anwendungsszenario.

Wenn ich für Windows entwickeln muss, nehme ich VS und C#. Bei Anders Hejlsberg war man immer in guten Händen, was Sprache und IDE angeht. Vor allem bei dem Preis-Leistungsverhältnis.

Ansonsten, wenn ich übergreifend Software erstelle, bleibe ich bei Java.

Delphi (dank der derzeitigen Promotion) nutze ich am allerliebsten auf meinem Nebensystem(Win 7), dass sagt aber nur das Herz, die Vernunft lässt mich andere Werkzeuge nutzen.

Und das finde ich sehr Schade, ist aber ein von Embarcadero generiertes Problem, nicht meins.

Wie gesagt: ich weiß, dass ich ein Nischenuser bin.

[himitsu]

Embarcadero will erstmal nur Server-Anwendungen für Linux ermöglichen.


Man könnte bestimmt auch eine VCL-DFM nehmen und daraus für verschiedene Linuxe eine GUI generieren. :stupid:
Entweder man parst die DFM selber (TReader) oder man bastelt sich parameter-kompatible Klassen für die wichtigsten GUI-Komponenten.
Aber so kann man zumindestens den vorhandenen Form-Designer verwenden.

[mjustin]

Zitat:

Zitat von frapo (Beitrag 1346216)

Mir ist schon klar, dass ich da eindeutig zur Minderheit zähle - da ich vornehmlich Linux-Anwender bin. Was habe ich davon, dass ich nun für Linux Konsolenprogramme erstellen kann? Das kann ich schon recht lange, und wenn es Object Pascal sein soll, dann mit fpc.

DataSnap oder andere Technologien wären unter Umständen günstiger, wenn man keine Windows-Serverfarmen sondern z.B. einen 48 Kern Linux Rechner betreiben kann. Unter Umständen, weil man natürlich auch jemanden braucht, der diese Systeme betreut.

[frapo]

Zitat:

Zitat von himitsu (Beitrag 1346217)

Embarcadero will erstmal nur Server-Anwendungen für Linux ermöglichen.

Stimmt, das habe ich auch so gelesen und verstanden.

Aber da tauchen bei mir schon Fragezeichen auf. Wie soll dieser Nutzer oder Entwickler den real aussehen? Das meine ich auch alles völlig wertfrei.
Ich stelle mir da einfach jemanden vor, der Win 8.1 oder Win 10 Anwender ist und dessen Hauptwerkzeug Delphi ist - dies ist er wahrscheinlich "quasi" sein Leben lang. Und der soll jetzt einfach mal einen Demon/Service eine Serveranwendung für ein System schreiben, auf dem er sich womöglich recht wenig auskennt, da er es recht wenig benutzt und damit auch kennt? Was wäre den überhaupt seine Motivation? Der hat doch vielleicht in seinem Netz einen Win-Server oder nutzt einen Win-Client als Server im Netz.. damit würde er sich ja auf sicherem Terrain bewegen.
Natürlich gibt es Entwickler, die beide Systeme aus dem Effeff kennen. Aber wie häufig trifft man so einen?

Ich zum Beispiel würde mir eher zutrauen so etwas auf Linux zu machen als auf Windows. Eben weil ich mir einbilde auf dem einen System heimischer sein. Klar, am Ende ist das alles kein Hexenwerk aber die Tücke liegt ja bekanntermaßen oft im Detail.

Im Endeffekt begrüße ich diesen Schritt Richtung Linux sehr! Und ich gebe auch zu das ich auf sehr viel mehr hoffe oder davon träume.

Irgendwie bin ich in gespannter und freudiger Erwartung, auch wenn mir klar ist, das Emba sich eindeutig weiterhin auf Win fokussieren wird.
Aber vielleicht sehen sie irgendwann neue Märkte. :thumb:

Zitat:

Zitat von mjustin (Beitrag 1346221)

Zitat:

Zitat von frapo (Beitrag 1346216)

Mir ist schon klar, dass ich da eindeutig zur Minderheit zähle - da ich vornehmlich Linux-Anwender bin. Was habe ich davon, dass ich nun für Linux Konsolenprogramme erstellen kann? Das kann ich schon recht lange, und wenn es Object Pascal sein soll, dann mit fpc.

DataSnap oder andere Technologien wären unter Umständen günstiger, wenn man keine Windows-Serverfarmen sondern z.B. einen 48 Kern Linux Rechner betreiben kann. Unter Umständen, weil man natürlich auch jemanden braucht, der diese Systeme betreut.

Das wäre natürlich ein Argument, welches mir einleuchtet. Da ich nur die Starter habe, kenne ich Dinge wie DataSnap nur aus der Theorie ein wenig. Aber für solche Sachen (Vermeidung von Serverkosten) macht das natürlich wirklich Sinn.

[bernau]

Zitat:

Zitat von frapo (Beitrag 1346225)

Aber da tauchen bei mir schon Fragezeichen auf. Wie soll dieser Nutzer oder Entwickler den real aussehen? Das meine ich auch alles völlig wertfrei.
Ich stelle mir da einfach jemanden vor, der Win 8.1 oder Win 10 Anwender ist und dessen Hauptwerkzeug Delphi ist - dies ist er wahrscheinlich "quasi" sein Leben lang. Und der soll jetzt einfach mal einen Demon/Service eine Serveranwendung für ein System schreiben, auf dem er sich womöglich recht wenig auskennt, da er es recht wenig benutzt und damit auch kennt? Was wäre den überhaupt seine Motivation? Der hat doch vielleicht in seinem Netz einen Win-Server oder nutzt einen Win-Client als Server im Netz.. damit würde er sich ja auf sicherem Terrain bewegen.

Mit Delphi kann man seit Uhrzeiten Service-Anwendungen (für Windows) schreiben. Also kein neues Terrain.

Ich programmiere seit 25 Jahren Pascal/Delphi. natürlich nur Desktop unter Windows. Ich habe einige Linux-Server. Hier in der Firma und und einige im Rechnenzentrum. Einmal eingerichtet laufen die Dinger stabil. Musste letztens bei einem Server einen Lüfter auswechseln. Der hatte eine Uptime von knappen 1000 Tagen gehabt. Lüfter gewechselt. Hochgefahren und läuft wohl die nächsten tausend Tage.

Ich brauche für Linux nur Konsolenprogramme oder Webservermodule. Bestimmte Dinge musste ich dann mit PHP zusammenwurschteln. Grauselig.

Daher freue ich mich richtig auf die neue Delphi-Version.

[Daniel]

Zitat:

Zitat von frapo (Beitrag 1346225)

Ich stelle mir da einfach jemanden vor, der Win 8.1 oder Win 10 Anwender ist und dessen Hauptwerkzeug Delphi ist - dies ist er wahrscheinlich "quasi" sein Leben lang. Und der soll jetzt einfach mal einen Demon/Service eine Serveranwendung für ein System schreiben, auf dem er sich womöglich recht wenig auskennt, da er es recht wenig benutzt und damit auch kennt? Was wäre den überhaupt seine Motivation?

Sofern sich die Anforderungen stellen, dass ein Linux-Server bedient werden muss, kann man es wohl von jedem Entwickler erwarten, dass er sich wenigstens soweit in das System einarbeitet, dass er dafür einen Service schreiben kann. Ich denke, dass man das Stichwort "Weiterbildung" nennt. Da trennt sich dann die Spreu vom Weizen: Die einen sagen "Och nö - Linux ist doof, da habe ich keine Lust" und die anderen sagen "Klar, gib her, da fuchse ich mich rein." Und das mit den Anforderungen kann schnell passieren. Ich habe seit vergangener Woche acht Linux-Server, die mir Daten zuliefern. Es ist nur eine Frage der Zeit, bis man sich da nicht nur bedient, sondern auch mit eigenen Diensten drauf geht.

[Valle]

Zitat:

Zitat von mkinzler (Beitrag 1346207)

Falls irgendwann etwas "grafisches" kommt, dann sicherlich FMX, also keine Abhängigkeit von einer Bibliothek, aber das Problem, des "Fremdaussehens".

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. ;-)

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).

Für Delphi Single-Exe unter Linux könnte vermutlich dann die gleiche Unverträglichkeit bestehen?

Wenn es wegen unterschiedlichen Libc Versionen nicht funktioniert, dann war die Datei nicht statisch gelinkt. Dann ist man in der Tat sehr abhängig von der Distribution. Aber ich sprach von statisch gelinkten ELFs. (keine Exen, die gibt's unter Linux nicht ;-) ). Ein kleines Beispiel wie das aussieht ist Anhang.

[Rollo62]

Hallo Valentin,

dankesehr für die Ausführeungen.

Ich denke auch X11 oder Wayland sollte man ansprechen können, da ist aber harte Handarbeit angesagt.
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.
Emba hat das ja anscheinend nicht auf dem Plan.

Vielleicht noch Posix, und dann ist erstmal Schluss denke ich.
Das ist aber schonmal was.

Aber es könnte ein Blick zu FreePascal lohnen, dort ist man sicher schon etwas weiter.

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.

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.
Und dann gibt es noch zig Paketmanager, jeder kocht leider sein eigenes Süppchen.

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 ?
Hab ich aber noch nicht gesehen.

Ein GCC Compiler hat aber genau die gleichen Probleme, das liegt nicht an Delphi an sich.
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 ?

Ubuntu ist auf Debian basierend, und ich denke eine ganze Reihe von Distributionen basieren auf Debian.
Das läst mich hoffen.

Rollo

[Namenloser]

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:

[frapo]

Zitat:

Zitat von bernau (Beitrag 1346234)

Mit Delphi kann man seit Uhrzeiten Service-Anwendungen (für Windows) schreiben. Also kein neues Terrain.

Das ist mir schon klar :). Mit neuem Terrain meinte ich einen Dienst dann für Linux zu schreiben. Aber wie an anderer Stelle hier schon gesagt wurde: wer Interesse daran haben wird, wird sich da auch sehr gerne reinfuchsen.

[ralfstocker]

Das wird wieder mal nix werden. Wie schon bei Kylix. Linux-Marktanteil Desktop: 1%. Und auf dem Server wird der free gcc verwendet.

[Valle]

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.

Richtig. Aber das ist normalerweise kein Problem.

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.

Nein, gibt es normalerweise eher nicht. Verschiedene Kernelversionen sowieso nicht, Libraries gibt es manchmal in verschiedenen Major-Versionen parallel. Aber genau das ist die Aufgabe deiner Distribution: Sie achtet auf die Kompatibilität deiner Libraries und Programme und kompiliert und linkt diese so, dass sie funktionieren. Das funktioniert natürlich nur, weil quasi alle Programme, die in der Distribution enthalten sind, OpenSource sind. Deshalb wird es Delphi hier sehr schwer haben.

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

Und dann gibt es noch zig Paketmanager, jeder kocht leider sein eigenes Süppchen.

Naja, ob man hier leider sagen kann ist fragwürdig. Primär gibt es nur DEB und RPM. Die anderen sind eher vernachlässigbar. Und Konkurrenz und Alternativen sind in der Unixwelt eine wichtige Philosophie, die dazu beigetragen haben, dass Dinge so sind wie sie jetzt sind.

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 ?
Hab ich aber noch nicht gesehen.

Normalerweise kompilierst du dein Programm exakt für deine Zielplattform. Distributionen wie Ubuntu vereinfachen das, da du dann nur ein Mal für Ubuntu linken musst und dieses Binary dann auf jedem Ubuntu dieser Version und Architektur funktioniert. Lieferst du nur ein Binary aus, linkt man häufig statisch. Dann sind alle Libraries eingebunden und das Programm ist unabhängig von seiner Umgebung. So kommst du aber nicht in die Paketlisten großer Distributionen.

Zitat:

Zitat von Rollo62 (Beitrag 1346248)

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

Richtig! Aber: gcc gibt es für Linux. Die meisten Programme bieten also ihren Sourcecode zum Download an. Die Debian Maintainer nehmen den Source und lassen ihn automatisch für passende Zielplattformen kompilieren. Einen Delphicompiler für Linux gibt es noch nicht. Und der Aufwand für alle passenden Platformen selbst zu Linken ist vermutlich zu hoch. Daher vermute ich, dass statisches Linken die einzig sinnvolle Alternative sein wird.

[BUG]

Zitat:

Zitat von ralfstocker (Beitrag 1346258)

Und auf dem Server wird der free gcc verwendet.

Naja, den vorhandenen Business-Code und die gewohnten Tools benutzen zu können kann schon viel wert sein.

[mael]

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).

[himitsu]

Selbst in Windows muß eine EXE nicht EXE heißen.
Nur gibt es für andere Dateiendungen standardmäßig selten Verknüpfungen im Windows, damit es diese auch starten kann. (Windows weiß ja nicht, daß es eine PE ist, da nicht im Fileheader nachgeschaut wird).

Man kann auch eine EXE und DLL kombinieren, also alleine lauffähig und/oder als DLL ladbar. Die EXE kann sogar eigene exportierte Funktionen von sich selber dynamisch laden.

[Rollo62]

[QUOTE]

Zitat:

Zitat von Valle (Beitrag 1346261)

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

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).

Wahrscheinlich gibt es unter Linux einfach mehr Versionen als unter Windows-Libraries,
aber ob es 150 oder 200 Library-Versionen gibt macht doch auch wenig Unterschied.

Die Unterschiede liegen IMHO in den verschiedenen Basisauslegungen, wie Filesystem, Mounting, Graphiksystem, Desktop, etc., das kann ich ja verstehen.
Aber ein Linux mit gleicher Auslegung (z.B. Debian-Basis) sollte sich doch sehr ähnlich verhalten.
Ich könnte dann u.U. auch fehlende Komponenten einfach nachinstallieren.

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.

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

Das es gehen muss zeigen doch Libre-Office, Firefox und zig andere.
Wie bekommen die das denn eigentlich kompatibel zu allen Distris, mit Milliarden von IFDEFs ?

Rollo

[Rollo62]

Noch ein Gedanke zum fehlenden FMX:

Das Einbinden von Chromium Embedded (mit DCef3) sollte doch überschaubar sein.
DCef3 hat zumindest FPC schon als define mit drin, obs läuft weiss ich nicht.

Dann hätte man auf einen Schlag ein state-of-the-Art visuelles GUI, mit HTML/JS Frontend und Delphi Backend.

Rollo