Mit Hilfe von wine (ab Version 0.9.11) ist Delphi in Linux lauffähig.

Das funktioniert garantiert mit SuSE 10.0 und Delphi 7PE. Mit anderen Versionen habe ich das noch nicht ausprobiert.

Zur Installation:
1. Delphi in Windows installieren
Danach Linux starten und
2. die Delphi-Installationsdatei mit wine ausführen und Anweisungen folgen.
Problem: Es werden nicht alle Dateien in dem von wine erstellten Programmordner von Delphi kopiert. Also ist noch folgender Schritt notwendig:
3. Den von wine erstellten Delphi-Ordner (im virtuellen wine-Laufwerk) durch den Delphi-Ordner der in (1) installierten Windows-Version ersetzen.

Fertig.
Wenn Ihr andere Delphi-Versionen in anderen Linux-Distributionen zum Laufen bringt, könnt Ihr das hier melden...

[rant]
Jetzt braucht man nur noch einen brauchbaren Compiler.

Die Binaries werden nach wie vor Windows-Binaries sein. Daß Delphi mit Wine läuft ist nicht erst seit gestern so und auch kein Geheimnis: appdb.winehq.org/appview.php?appId=42
Wenn man von ein paar kosmetischen Probleme absieht, geht das schon seit 2 Jahren.
Die Sache ist nur: niemand könnte sowas wollen.
[/rant]

Kann man eigentlich von wine aus normale Linux Konsolenanwendungen starten? Wenn ja, dann sollte es mit CrossKylix oder einem eigenen Plugin, dass nicht noch Linux in Wine unter Linux emuliert, funktionieren. Ggf. noch den Remotedebugger anwerfen und unter localhost debuggen. (Möglich ist alles

AndyB hat folgendes geschrieben:

Kann man eigentlich von wine aus normale Linux Konsolenanwendungen starten?

Sieht nicht so aus (zumindest nicht "the standard way"). Und es würde mich *sehr* erschüttern, wenn ein Windows-Programm aus der Windows-Umgebung fliehen kann und Code im Unix-System ausführen kann. Das wäre eine enorme Sicherheitslücke ohne gleichen. Aber Cygwin soll in Wine laufen (oder was es umgekehrt, Wine läuft in Cygwin?).

Das Problem bleibt aber: Ein brauchbarer Pascal-Compiler für Linux fehlt. Die RTL von Kylix ist veraltet und FreePascal ist nicht brauchbar. Ich habe am Anfang versucht, auch unter Linux mit Pascal zu programmieren. Mittlerweile hat sich herausgestellt, daß es deutlich effektiver war, C++ zu lernen und meine Zeit nicht damit zu vergeuden, hinter irgendwelchen Unzulänglichkeiten in irgendwelchen RTLs herzujagen. Für Linux ist C und C++ die effektivste Programmiesprache im Sinne von "Ich kann alles machen, was ich will und wie ich es will, und an mein Ziel gelange ich schnell.". Das mag alles nicht auffallen, wenn man kleine "Hello World"-Programme (inklusive Taschenrechner) schreibt, aber irgendwann fängt man an, Bibliotheken zu vermissen.

Der FreePascal-Compiler ist, denke ich, garnichtmal so schlecht. Nur Lazarus steckt noch in den Kinderschuhen.
Dennoch gibt es inzwischen auch professionelle Anwendungen aus dem OpenSource-Bereich, die Lazarus als Entwicklungsumgebung benutzen. (Z.B. das populäre virtuelle Planetarium SkyChart)

Zur Zeit verwende ich Delphi 7 unter Linux. Delphi 7 erzeugt zwar Windows-Binärdateien; meine bisher entwickelten Anwendungen liefen jedoch in Linux unter wine nicht schlechter als in Windows. Die Geschwindigkeitseinbußen machen etwa 3-4% aus.

Der FPC und Lazarus werden laufend weiterentwickelt. Daher hoffe ich, dass die Pascal-Sprache bald unter Linux ähnlich unproblematisch wird wie unter Windows.

Aristoteles hat folgendes geschrieben:

Der FreePascal-Compiler ist, denke ich, garnichtmal so schlecht.

Ich habe vor etwa einem Jahr mit einer Beta-Version von FPC 2 gearbeitet (zwei Versionen vor dem endgültigen Release, wenn ich mich richtig erinnere). Damals war er verdammt schlecht, um Linux-Programme zu schreiben, die sich wie Linux-Programme verhalten.

Aristoteles hat folgendes geschrieben:

Dennoch gibt es inzwischen auch professionelle Anwendungen aus dem OpenSource-Bereich, die Lazarus als Entwicklungsumgebung benutzen. (Z.B. das populäre virtuelle Planetarium SkyChart)

Dieses: www.southernstars.com/skychart/ ? Kostet 50 Dollar und gibt es nicht für Linux. Möglicherweise aus gutem Grund.

Aristoteles hat folgendes geschrieben:

Zur Zeit verwende ich Delphi 7 unter Linux. Delphi 7 erzeugt zwar Windows-Binärdateien; meine bisher entwickelten Anwendungen liefen jedoch in Linux unter wine nicht schlechter als in Windows. Die Geschwindigkeitseinbußen machen etwa 3-4% aus.

Ich frage mich, warum man es nicht gleich richtig macht und Linux-Programme schreibt. Hier ist es eine Prinzip-Sache. Ich benutze Wine, wenn ich Programme unter Linux benutzen will, für die es für Linux kein oder nur ein unzureichendes Äquivalent gibt. Aber doch nicht aus Jux. Wenn ich neue Programme schreibe, mache ich es richtig, dann hat jeder etwas davon und jeder kann es erweitern und nicht nur die, die Delphi unter Linux benutzen.

Aristoteles hat folgendes geschrieben:

Der FPC und Lazarus werden laufend weiterentwickelt.

Ja, aber derzeit hinken sie C und C++ einfach hinterher. Ich habe ja nichts gegen Pascal als Sprache, ich habe etwas gegen die verwendeten Entwicklungswerkzeuge.

Aristoteles hat folgendes geschrieben:

Der FreePascal-Compiler ist, denke ich, garnichtmal so schlecht.

Genauso wie Delphi, diverse C++-Umgebungen, oder gar Linux und Windows ist alles Geschmackssache. Du hältst den FPC für schlecht, andere halten ihn für gut. Und alle haben recht, da solche Wertungen was subjetives sind.

Aristoteles hat folgendes geschrieben:

Dennoch gibt es inzwischen auch professionelle Anwendungen aus dem OpenSource-Bereich, die Lazarus als Entwicklungsumgebung benutzen. (Z.B. das populäre virtuelle Planetarium SkyChart)

www.ap-i.net/skychart/index.php
Das ist das mit Abstand populärste OpenSource-Planetarium. In Lazarus programmiert. Genauer: In der aktuellen Beta von Delphi zu Lazarus gewechselt.
Die Qualität des Planetariums hält mit kommerzieller Software mit, ist sogar praxistauglicher als z.B. RedShift, wie ich finde.

Aristoteles hat folgendes geschrieben:

Zur Zeit verwende ich Delphi 7 unter Linux. Delphi 7 erzeugt zwar Windows-Binärdateien; meine bisher entwickelten Anwendungen liefen jedoch in Linux unter wine nicht schlechter als in Windows. Die Geschwindigkeitseinbußen machen etwa 3-4% aus.

Das klingt merkwürdig, keine Frage. Es handelt sich aber um ein größeres Projekt mit mehreren Beteiligten, die nicht alle Linux-Fans sind...

Aristoteles hat folgendes geschrieben:

Der FPC und Lazarus werden laufend weiterentwickelt.

Ja, da stimme ich dir zu. Vorsichtig möchte ich sogar vermuten, dass auch die Sprache C++ sich schneller und komplexer entwickelt, als es die Sprache Pascal derzeit macht. Das liegt ganz einfach an der rießigen Polulatität von C++ und meiner Meinung nach nicht an den Eigenschaften von FPC.
In Sachen Bibliotheken lassen sich mit dem FPC (neben den Hauseigenen) die von Delphi einbinden. Das sollte kein Grund gegen FPC sein.

Aristoteles hat folgendes geschrieben:

Genauso wie Delphi, diverse C++-Umgebungen, oder gar Linux und Windows ist alles Geschmackssache.

Wenn ich auf der FAQ-Seite immer noch lese, daß der FPC-Linker keinen relocatable code in ELF-Dateien erzeugen kann (und somit Shared Objects unter Linux), ist er nicht nur subjektiv, sondern ganz objektiv für mich bei größeren Projekten die modular sein sollen, unpraktisch. Von monolithischen Builds haben wir uns eigentlich seit einigen Jahren entfernt. Dann hatte ich mit der "2 Versionen vor Final"-Version immer noch das Problem, daß der Linker (unter Linux) nicht in der Lage war, virtuelle Klassen gescheit zu erkennen. Resultat: Ein Lazarus-Programm mit lediglich einem Fenster hatte eine Größe von über einem Megabyte. Damals habe ich in den Mailinglisten keinen brauchbaren Hinweis darauf gefunden, daß das in absehbarer Zeit besser wird, das war einer der Gründe warum ich mich nicht weiter mit dem Compiler beschäftigt habe. Der zweite Grund war die fehlende Interoperabilität mit der Libc. Etliche Funktionen, die dokumentiert waren, waren schlichtweg nicht vorhanden. Bei einigen Funktionen wich die Deklarierung in der entsprechenden Pascal-Datei von der Dokumentation ab, was mich stutzig machte. Der Sache bin ich nachgegangen und ich habe festgestellt, daß einige Funktionen, die in der glibc implementiert sind, in Pascal nachprogrammiert wurden, und zwar nicht der Dokumentation entsprechend. Eine einfache extern-Deklaration hätte gereicht, stattdessen programmiert man es falsch in Pascal nach.
Das ist keine Geschmackssache oder persönliches Unbehagen, das sind für mich praktische Gründe, warum ich diesen Compiler nicht verwendet habe und stattdessen C++ gelernt habe. Das war für mich auch ein Aufwand. Hätte ich weiterhin mit Object Pascal arbeiten können (die Betonung liegt auf arbeiten, nicht frickeln oder rumprobieren), hätte ich das liebend gerne getan.

Aristoteles hat folgendes geschrieben:

Vorsichtig möchte ich sogar vermuten, dass auch die Sprache C++ sich schneller und komplexer entwickelt, als es die Sprache Pascal derzeit macht.

Nicht unbedingt. ISO-C++ ist, wie unschwer zu vermuten, ISO-standardisiert. Der gesamte Standardisierungskörper ist da sehr viel träger als die Firma Borland, die "mal eben" Feautres erweitern kann. Und das haben sie in den letzten zwei Jahren gewaltig. Bei ObjectPascal (Win32, nicht Delphi.NET) sind in letzter Zeit enorm viele Dinge hinzugekommen, die die Sprache langsam wieder mit C++ aufholen lässt. (Object)Pascal hat also in letzter Zeit enorme Schritte gemacht, während C++ seit mittlerweile fast 10 Jahren unverändert ist (von technischen Ergänzungen abgesehen).
Wenn ich also sage, daß der FPC C++ hinterhinkt, dann meine ich das so, auch wenn ich hier eine Sprache mit einem Compiler vergleiche. Lies es meinetwegen als "Der FPC hinkt jedem C++-Compiler hinterher". Die Sprache ObjectPascal hat damit nichts zu tun, die ist seit Delphi2006 mit C++ beinahe gleichgezogen.

Meine Äußerung, dass FPC offenbar garnicht so schlecht ist, stützt sich nicht auf große eigene Erfahrungen. Sondern vielmehr darauf, dass es offensichtlich große Projekte gibt, die mit dem FPC programmiert werden. Das eben genannte Programm war ursprünglich ein Delphi-Programm, es wurde aber kürzlich auf Lazarus umgemünzt. Und ich nahm dabei an, dass rational denkende Menschen sich nicht auf einen unfertigen Compiler einlassen.
Bei den Erfahrungen, die du gemacht hast kann ich deinen Frust nachvollziehen. Obwohl ich bei einer Beta keine fehlerfreie Dokumentation annehmen würde: Die Dokumentation wird in der Regel zuletzt aktualisiert. Niemand schreibt zuerst eine Dokumentation und dann das Programm dazu.
Außerdem erscheint es mir logisch, dass manche Routinen der Betriebssystem-Unabhängigkeit wegen nachprogrammiert werden müssen. Des Weiteren unterliegt der FPC den LGPL, was heißt, dass auch alle von FPC verwendeten Routinen dieser Lizenz genügen müssen.

Es freut mich zu hören, dass Delphi langsam wieder an C++ heranreicht. Ich bin deiner Meinung, dass dies auf den FPC in seiner jetzigen Form noch nicht zutrifft. (ich habe auch nie etwas andere behauptet)
Bei den Iso-Standards handelt sich nicht um die Standards von 1996. Die Standards werden jährlich um Notwendigkeiten erweitert und nach Erfahrungen aus der Praxis Änderungen vorgenommen. Die meisten Compiler kommen sogar der schnellen Entwicklung der ISO-Standards nicht hinterher. In sofern sehe ich die ISO-Standards nur bedingt als ein Hindernis.


Die Tatsache, dass ganz offensichtlich mit dem FPC und sogar mit Lazarus programmiert wird, sowie die Tatsache, dass es Menschen gibt, die den FPC für schlecht halten lässt in meinen Augen nur einen Schluss zu:
Es ist eben Geschmackssache.

Guten Morgen,

nach ca. 1 Jahr Abstinenz habe ich Linux neu installieren wollen. Trotz neuem Computer (2 GB RAM) lief nicht viel. Suse 10 OSS machte Schwierigkeiten wegen meines Laser Nagers (Maus) und fuhr nicht sauber herunter. Knoppix konnte ich nicht sauber auf die Festplatte bannen. Ubunti und Kubunti als ISO heruntergeladen, ging nicht. ! Tag Frust und Ärger. Dann habe ich Xandros 3.1 basierend auf Debian 3.1 gekauft, es enthält Cross Over Office. Installation 20 Minuten. Alles läuft, Internet WLan muß ich mich noch schlau machen. Delphi installiert und läuft einwandfrei. Als Datenbank Kompo TDBF und Fastreport Free und damit unabhängig von der BDE. Für die Linux Programmierung geht meineserachtens kein Weg an QT von Trolltech vorbei.

Gruß Ralli

Aristoteles hat folgendes geschrieben:

Und ich nahm dabei an, dass rational denkende Menschen sich nicht auf einen unfertigen Compiler einlassen.

Es kommt auf das Einsatzgebiet drauf an. Sind in den acht (in Worten: acht) Megabyte (gepackt!) schon die Bilder und Texturen enthalten, oder befinden sich diese in dem zusätzlich runterzuladendem "Data File"? Immerhin ist der Quellcode nur 4 Megabyte groß, da ist es schon ein ziemliches Glanzstück, 8MB Code zu erzeugen.
Wer also auf große Binaries steht, unter Linux keine modularen Programme mit Shared Objects erstellen möchte, nicht POSIX-kompatibel sein möchte und die üblichen von Delphi bekannten Eigenarten haben will, der kann genausogut FreePascal nehmen.
Für waschechte Linux-Programme war er vor einem Jahr nicht zu gebrauchen. Wenn sie die von mir angesprochenen Probleme in den Griff gekriegt haben (wovon ich nicht ausgehe, sonst wäre die aktuelle Version sicherlich nicht 2.0.2, sondern eher 2.1), dann wird er zu einem ernstzunehmenden Linux-Compiler.

Aristoteles hat folgendes geschrieben:

Obwohl ich bei einer Beta keine fehlerfreie Dokumentation annehmen würde

Nein, es handelte sich um die Dokumentation der GNU C Library. Auf GNU-Systemen nahezu der einzige Weg, POSIX-kompatible Programme zu schreiben. Unter Kylix gab es eine Unit libc.pas (oder clib.pas), die Funktionen dieser Bibliothek exportierte (zugegeben, eine mittlerweile veraltete Version, Kylix hat ja schon ein paar Jahre auf dem Buckel). Die Freepascal-RTL wollte etwas ähnliches bieten und hat oben geschildertes Verhalten an den Tag gelegt. Wenn bei einer Beta die Dokumentation zum Beta-Programm selbst nicht stimmt, verstehe ich das. Aber wenn ein Programm entsprechend einer externen Dokumentation Funktionalität zur Verfügung stellt, und diese, anstatt vorhandene Bibliotheken zu nutzen einfah selber implementiert und sich dabei nicht an die externe Dokumentation hält, ist das Murks. Und wenige Wochen später kam die Finale Version raus, ich kann mir beim besten Willen nicht vorstellen, daß in der Zeit jemand die libc-Unterstützung gefixt hat, weil die Entwickler damals andere Probleme hatten.

Aristoteles hat folgendes geschrieben:

Außerdem erscheint es mir logisch, dass manche Routinen der Betriebssystem-Unabhängigkeit wegen nachprogrammiert werden müssen.

Nicht bei der GNU Libc. Entweder, das Zielsystem ist ein GNU-System, dann nutzt man sie, oder das System ist kein GNU-System, dann nutzt man eine andere (dann nennt man aber die Unit auch anders, nämlich so, wie die passende Bibliothek auf dem Zielsystem heißt). Wenn man eine allgemeine POSIX-Unit haben will, nennt man sie posix.pas. Dort alles plattformunabhängig nachzuprogrammieren ist nur schwer möglich (weil einige Systeme nicht POSIX-kompatibel sind). Bei derartigen Dingen empfiehlt es sich immer, plattformabhängig zu sein und dem Entwickler die Wahl zu lassen, ob er nur POSIX-Plattformen unterstützen will oder alle möglichen (dann bietet die RTL den kleinsten gemeinsamen Nenner aller unterstützten Plattformen).
Das libc-Problem hatte also mit Sicherheit nichts mit Plattformunabhängigkeit zu tun, weil auf anderen Plattformen die GNU C Library ohnehin nicht zur Verfügung steht und auch nicht benutzt wird (beispielsweise unter Windows, dort verwendet man Microsofts Bibliotheken wie user32.dll und so weiter). Außerdem wurden einige Funktionen ja vollkommen korrekt aus der GNU C Libary importiert, andere hingegen nicht. Entweder alles selber machen (dann aber richtig) oder gar nichts (dann aber auch richtig). Eine Mischung aus importierten Funktionen, die sich an die Doku halten, und selbstgestrickten, die vorne und hinten nicht stimmen, hilft niemandem.

Aristoteles hat folgendes geschrieben:

Des Weiteren unterliegt der FPC den LGPL, was heißt, dass auch alle von FPC verwendeten Routinen dieser Lizenz genügen müssen.

Alle GNU-Bibliotheken stehen unter einer der GNU-Lizenzen, das ist entweder die LGPL oder die GPL.

Aristoteles hat folgendes geschrieben:

Es freut mich zu hören, dass Delphi langsam wieder an C++ heranreicht.

Leider zu spät. Die einzige Plattform, die Delphi unterstützt, ist Windows. Dort (und übrigens auch unter Linux) wird mittlerweile der .NET-Zug immer schneller. Alte Projekte profitieren von den neuen DelphiLanguage-Features nicht, weil sie ja auf alten Compilern entwickelt wurden, die noch nichts von Methoden in Records, vernünftigen Sichtbarkeiten und so weiter wussten. Fängt man große Projekte neu an, denkt man heute eher darüber nach, .NET zu nehmen, weil es ein nettes Framework (vom Umfang) mitbringt und weil es weitgehend sprachunabhängig ist, man also ungeheuer flexibel bleibt wenn man später mal weitere Programmierer dazukaufen will. Da kommen die DelphiLanguage-Features, die Delphi wieder auf C++ aufholen lassen, leider ein wenig zu spät. Vor 5 Jahren hätte das noch prima etwas gebracht. Aber das gehört nicht zum Thema "Delphi unter Linux" und lässt sich in den vielen Threads zu den Releases von Delphi2005 und Delphi2006 nachlesen.

Aristoteles hat folgendes geschrieben:

Bei den Iso-Standards handelt sich nicht um die Standards von 1996. Die Standards werden jährlich um Notwendigkeiten erweitert und nach Erfahrungen aus der Praxis Änderungen vorgenommen.

Jein. Es werden regelmäßig Mailings und Technical Reports veröffentlicht, die derartige Notwendigkeiten und Mängel dokumentieren. Änderungen, die keine anderen Bereiche betreffen, werden als Technical Corrigendum zum bestehenden Standard vorgeschlagen. Tatsächliche Änderungen am Kern des Standards sind aber schon länger her, nämlich 1998. Vielleicht kennst du die boost-Bibliothek für C++. Einige Klassen dieser Bibliothek sollen seit einiger Zeit in den Standard aufgenommen werden. Das wird mit der nächsten Version des C++-Standards geschehen, aber nicht früher. Ich meine mich erinnern zu können, daß beim Boost-Smartpointer feststeht, daß er übernommen werden soll.

Aristoteles hat folgendes geschrieben:

Die meisten Compiler kommen sogar der schnellen Entwicklung der ISO-Standards nicht hinterher.

Ja, aber sie kommen mit den Original-Standards nicht hinterher. Selbst der GNU C Compiler unterstützt C99 (nicht C++) nicht vollständig. Und der Standard wurde vor 7 Jahren verabschiedet.

ralph hat folgendes geschrieben:

Trotz neuem Computer (2 GB RAM) lief nicht viel.

Hihi, vielleicht wegen dem neuen Computer?

ralph hat folgendes geschrieben:

Suse 10 OSS machte Schwierigkeiten wegen meines Laser Nagers (Maus) und fuhr nicht sauber herunter.

Mit meiner MX1000 habe ich keine Probleme mit dem X.org-Server (7.0.0). Bei USB-Mäusen empfiehlt sich da, evdev als Treiber auszuwählen und einen Kernel zu benutzen, der evdev-Devices zur Verfügung stellt. Bisher habe ich Linux auf jedem Rechner zumindest zum Laufen gebracht, selbst wenn bei weitem nicht alles zufriedenstellend lief. Aber Ausgabe, Maus und Tastatur gingen bisher immer.

ralph hat folgendes geschrieben:

Ubunti und Kubunti als ISO heruntergeladen, ging nicht.

ralph hat folgendes geschrieben:

Dann habe ich Xandros 3.1 basierend auf Debian 3.1 gekauft

Geld für Linux? Ich glaube es geht los!
Wenn du es irgendwann nochmal mit Ubuntu probieren willst, stehe ich per PN für Support bereit.

ralph hat folgendes geschrieben:

Alles läuft, Internet WLan muß ich mich noch schlau machen.

Je nachdem, was du für eine WLAN-Karte hast, könnte es sein, daß du nur mit dem ndiswrapper zufrieden wirst. Nur als Stichwort für die Suche

ralph hat folgendes geschrieben:

Für die Linux Programmierung geht meineserachtens kein Weg an QT von Trolltech vorbei.

Nicht wenn du Gnome-Anwendungen schreiben willst und nicht wenn du so nah wie möglich an C++ sein willst. Für KDE ist Qt das richtige.
Außerdem wirst du mit freien Toolkits (OpenMotif, Gtk+, ...) immer frei bleiben. Niemand garantiert dir aber, daß Trolltech mit der nächsten version von Qt macht, was sie wollen. Und für kommerzielle Closed-Source-Anwendungen sind bei Qt immer noch Lizenzgebühren fällig.
Außerdem produzierst du mit strikter Qt-Nutzung nie und nimmer sauberen ISO-C++-Code. Qt bringt eine eigene STL mit und ignoriert dabei die existierende. Außerdem haben sie irgendwelche Erweiterungen eingeführt, die so mit keinem Wort im C++-Standard stehen. Das ist der Grund, warum moc existiert. Wenn du eine Qt-Anwendung hast, ist das irgendein kranker C++-Dialekt, aber nie im Leben ISO-C++.
Mit Gtk+ kannst du C++ so einsetzen, wie es im Standard steht, und es mit jedem x-beliebigen Compiler kompilieren. Und wer QString als Unicode-String nachweint, kann entweder Gtk--s ustring nehmen, oder bastelt sich mit std::string_base<wchar_t> seinen eigenen Container.

tommie-lie hat folgendes geschrieben:

Niemand garantiert dir aber, daß Trolltech mit der nächsten version von Qt macht, was sie wollen. Und für kommerzielle Closed-Source-Anwendungen sind bei Qt immer noch Lizenzgebühren fällig.

Die OpenSource Gemeinde wird das herzlich wenig interessieren, da sie Qt mittels GPL weiter nutzen können. Die Kommerziellen Programmierer sind dabei die einzigen die in die Wäsche kucken würden. Aber genau die bringen Trolltech das Geld.

Zitat:

Qt bringt eine eigene STL mit

Das liegt wohl daran, dass das von Qt 1.0 mitgezogen wird. Und damals war noch nicht so viel mit der STL anzustellen, weil jeder Compiler Hersteller sein eigenes Süppchen gekocht hat.

Zitat:

und ignoriert dabei die existierende.

Dann solltest du mal Qt 4 ausprobieren. So lange man beim übersetzen von Qt selbst nicht NO_STL als Config-Schalter übergibt, hat man STL Unterstützung.

Zitat:

Außerdem haben sie irgendwelche Erweiterungen eingeführt, die so mit keinem Wort im C++-Standard stehen. Das ist der Grund, warum moc existiert.

MOC generiert die nötiogen "Property" Typinformationen und Methoden, die fürs Signal/Slot Konzept notwendig sind, was nichts anders als ein Multicast-Delegate System darstellt. Mittlerweile könnte man das ganze auch mittels Templates nachprogrammieren, aber das würde dann vom Code ganz anders aussehen und mehr Tipparbeit sein. Und das will man seinen "langjährigen" Kunden wohl nicht antun.

Zitat:

Wenn du eine Qt-Anwendung hast, ist das irgendein kranker C++-Dialekt, aber nie im Leben ISO-C++.

Klar ist es nicht ISO, wenn man "QObject::connect(btn, SIGNAL( clicked() ), myobj, SLOT( btnClicked() ));" schreiben kann. Aber wenn man ein Qt Programm schreibt, dann schreibt man ein Qt Programm, dass überall dort kompiliert werden kann, wo man auch Qt nutzen kann. MOC macht daraus schon wieder ISO-C++.
Mir persönlich geht die Qt Programmierung um Welten leichter von der Hand als die Gtk+ programmierung (liegt aber wahrscheinlich an meiner optischen Abneigung zu Gtk). [und bei Gnome drücke ich immer Abbrechen, wenn ich OK meine, woran das wohl liegen mag?].

@tommie-lie: du erzählst ganz schönen schmarn.
Der Linker über den du die ganze zeit herziehst ist der gnu-ld den du als c++ gnu Programmierer jeden Tag nutzt.
Das ist so weil bisher der Aufwand einen eigenen Linker zu schreiben zu gross war.
Da die freien Linker Entwickler es bis heut nicht geschafft haben einen i386-64 bit Linker zu schreiben und Die Fpc Community in der Lage sein wollte 64 bit Programme zu erstellen wurde dann vor ein paar Monaten doch ein eigener Linker entwickelt und vorgestellt.
Dieser erzeugt weitaus kleinere Executables und kann auch 64 bit Programme linken. Leider gibt es noch ein paar Probleme mit debugsymbolen aber im grossen und ganzen bin ich sehr zufrieden mit dem Linker.

Ich für meinen Teil arbeite jetzt seit fast 2 Jahren mit Fpc/Lazarus und bin heilfroh Borland entkommen zu sein. Ich finde es sehr schade das immer wieder Leute meinen sie können sich nach einer Woche ein Urteil über Lazarus bilden.
Es ist eine durchaus sehr gut benutzbare Entwicklungsumgebung. Mit betonung auf Entwicklung und nicht auf Das-kann-jeder System ein wenig wissen was man tut sollte man schon denn es finden sich nur sehr wenig Leute die sich an der herstellung der Dokumentation beteiligen.
Ebenso gibt es in der IDE noch einige Baustellen aber damit kann man gut Leben.
Die Codetools sind wesentlich weiter als die Hilfen in der Delphi IDE und so geht das verfollständigen von Code und erstellen von Klassengerüsten wesentlich schneller von der Hand.

Und zu .net kann ich nur sagen, warum soll ich mir einen Interpreter ins boot holen wenn ich einen Compiler haben kann der mit für fast jede Plattform nativen und guten Code erzeugen kann.

Die LCL ist für gtk und win32 ebenfalls recht stabil womit man dann also ohne änderungen an den Programmen in der Lage ist für Win32,Linux und MacOS(X) Programme zu erzeugen.
Mit kleinen Einschränkungen auch für WinCE.

Gruß
Christian

christian_u hat folgendes geschrieben:

Der Linker über den du die ganze zeit herziehst ist der gnu-ld den du als c++ gnu Programmierer jeden Tag nutzt.

Interessantes Statement. Dagegen spricht, daß sie sich von Anfang an mit "ihrem" smart linker gebrüstet haben, und dagegen spricht ein mittlerweile nicht mehr existierender Eintrag in den FAQ von Lazarus, in dem auf die Frage, warum man bei der Installation von Komponenten jedes Mal die IDE neu kompilieren musste geantwortet wurde, daß der Linker unter Linux nicht in der Lage sei, Shared Objects zu erzeugen, die Lazarus dynamisch linken könnte (siehe die ersten paar Sätze dieses Posts). Wenn FPC wirklich den GNU Linker benutzt hat, und es damals trotzdem hieß, der Linker könne dies nicht und der Linker könne jenes nicht, dann schiebe ich es halt nicht mehr auf den Linker, sondern auf die Inkompetnz der Entwickler, GNU ld richtig zu bedienen. Ob das nun besser ist, sei mal dahingestellt.

christian_u hat folgendes geschrieben:

Da die freien Linker Entwickler es bis heut nicht geschafft haben einen i386-64 bit Linker zu schreiben

Hmm...
Da hat zwar einer die Copyright Note nicht angepasst und die binutils 2.17 sind in Wirklichkeit von Juni 2006 (dafür kann LD das schon seit binutils 2.13 oder so), aber ich frage mich doch glatt, wer hier Schmarrn erzählt. Ich weiß ehrlich gesagt auch nicht, warum Linux schon seit Jahren 64bit unterstützt, sowohl auf IA64 als auch auf x86-64. Vielleicht ist Linux ja in Freepascal mit seiner 64bit-Unterstützung geschrieben und ich habe es nur noch nicht mitgekriegt.

christian_u hat folgendes geschrieben:

Ich finde es sehr schade das immer wieder Leute meinen sie können sich nach einer Woche ein Urteil über Lazarus bilden.

Kann man. Wenn man etwas ganz bestimmtes vorhat, das nicht geht, man in den MLs sucht und es immer noch nicht geht, dann bildet man sich ganz natrlich das Urteil: "Geht nicht, ich nehm' was anderes".

christian_u hat folgendes geschrieben:

Und zu .net kann ich nur sagen, warum soll ich mir einen Interpreter ins boot holen wenn ich einen Compiler haben kann der mit für fast jede Plattform nativen und guten Code erzeugen kann.

Ah ja. Du möchtest wirklich nicht nochmal überlegen, wer Schmarrn erzählt?

>Interessantes Statement. Dagegen spricht, daß sie sich von Anfang an mit "ihrem" smart >linker gebrüstet haben

kein Statement sondern Realität Fpc hat schon immer die bintools genutzt um zu assemblieren und zu linken. Und schade, das der beitrag "plötzlich" verschwunden ist obwohl noch beiträge von vor 6 Jahren im Forum zu finden sind ...

>>Da die freien Linker Entwickler es bis heut nicht geschafft haben einen i386-64 bit Linker >>zu schreiben
>Hmm...

richtig, er kann elf linken pe64 bit kann er bis heute nicht es ist also mit ld nicht möglich 64 bit windows applikationen zu linken weshalb für den fpc ein interner linker geschrieben wurde sicherlich etwas irreführend das ich "freie Linux Entwickler" geschrieben habe.

>Ah ja. Du möchtest wirklich nicht nochmal überlegen, wer Schmarrn erzählt?

warum, ist .net nicht interpretiert ? wär mir neu.
Und Fpc erzeigt nativen Code und sogar wesentlich schnelleren als jeder andere mir bekannte Pascal Compiler. Und dazu noch für alle gängigen Architekturen (ausser mips).
Ich glaube sogar mich noch an ein paar Benchmarkergebnisse zu erinnern wo der gcc mit c++ code gnadenlos gegen ihn verloren hat müsst ich aber nochmal suchen.

Hallo,

gnadenlos? Ist wohl übertrieben und kommt sehr selten vor.
shootout.alioth.debi...pp&lang2=fpascal

Gruss Horst

christian_u hat folgendes geschrieben:

Und schade, das der beitrag "plötzlich" verschwunden ist obwohl noch beiträge von vor 6 Jahren im Forum zu finden sind ...

Ich habe ihn wiedergefunden, ich hatte nur in der falschen Abteilung geschaut. Leider mittlerweile in modifizierter Form (jetzt geht es um Objekte und Strings, was lediglich ein ABI-Problem ist und durch den Compiler und nicht durch den Linker bestimmt wird. Ich würde aber meine Hand dafür ins Feuer legen, daß mal die Rede vom reinen Erzeugen von Shared Objects war.

christian_u hat folgendes geschrieben:

richtig, er kann elf linken pe64 bit kann er bis heute nicht es ist also mit ld nicht möglich 64 bit windows applikationen zu linken weshalb für den fpc ein interner linker geschrieben wurde sicherlich etwas irreführend das ich "freie Linux Entwickler" geschrieben habe.

Wenn ich richtig lese hast du "freie Linker entwickler" geschrieben. Ich bezog mich auf Linux als Entwicklungsumgebung. Always did, denn unter Windows verwende ich auch eher selten die GNU Standard Library, die bei meinen damaligen Tests im FPC genauso kaputt war. Ich weiß nicht, ob die GNU Foundation irgendwelche Pläne bezüglich PE64 hat, schließlich gibt es offiziell keine frei zugängliche Plattform. Vielleicht wird es sehr schnell unterstützt werden, wenn ich in den Laden gehen kann und mir ein 64bit-Windows kaufen kann. Vorher hat es wenig Sinn für die binutils, das Format zu unterstützen.
Das würde aber nicht erklären, warum die Binaries unter Linux so unglaublich groß waren (sind?). Es liegt definitiv nicht am Linker, wenn ld benutzt wurde, denn sämtliche anderen Compiler kriegen's richtig gebacken. Die Erklärung, die ich damals gefunden habe, war, daß abstrakte Klassen nicht korrekt aufgelöst werden können und deswegen im Binary landen, obwohl nur eine Ableitung verwendet wird, da der Smart Linker nur auf einzlene Funktionen funktioniert. Das hätte zur Folge, daß, wenn ich eine Klasse relativ weit unten im Vererbungsbaum benutze, der Code aller Vorfahrenklassen ebenfalls im Binary landet.
Schau, ich habe nichts spezielles gegen FreePascal. Im Gegenteil, ich denke Konkurrenz belebt das Geschäft und ich finde freie Alternativen immer besser als proprietäre. Die Situation für mich damals war, daß ich schneller als gewollt auf Linux umgestiegen bin, weil ich durch ein paar Spielereien meine Windows-Partition zerschossen habe. Da ich zu faul war, um es neu zu installieren, und sonst alles unter Linux funktionierte, ich aber eigentlich nur Delphi Language konnte ("richtig" konnte, mit C++ hatte ich gerade erst angefangen), *wollte* ich wirklich einen Pascal-Compiler für Linux haben. Ich habe FreePascal gefunden und ihn ausprobiert und er hat mir aus technischen Gründen nicht gefallen. Das war für mich damals der Grund, warum ich mich verstärkt mit C++ auseinandergesetzt habe. Meine heutige Einstellung zu Delphi ist zwar die, daß mir die Sprache einfach zu wenig leistet im Vergleich zu C++, aber das war damals nicht so. Ich fand es schade, daß FPC für mich nicht brauchbar war. Wenn bei dir also der Eindruck herrschen sollte, daß ich prinzipiell etwas gegen FPC habe oder ihn aus esoterischen Gründen *mist*e finde, kann ich dir sagen, daß dem nicht so ist, und daß der Umstieg auf andere (aus heutiger Sicht bessere) Programmiersprachen nur eine Notlösung war (für die ich mittlerweile dankbar bin). Man hatte ja nichts anderes (Kylix war inoffiziell bereits tot und lief auch nur mit Ach und Krach auf einem aktuelleren Kernel).

christian_u hat folgendes geschrieben:

warum, ist .net nicht interpretiert ? wär mir neu.

Nein, .NET-Code wird kompiliert, und zwar just in time. Interpretiert wurde QBASIC. In einigen Situationen kann .NET deutlich schneller sein als nativer Code. Frag mal Robert_G, der kann dir dazu mehr erzählen, ich bin leider etwas aus der Übung, was .NET angeht.

christian_u hat folgendes geschrieben:

Ich glaube sogar mich noch an ein paar Benchmarkergebnisse zu erinnern wo der gcc mit c++ code gnadenlos gegen ihn verloren hat müsst ich aber nochmal suchen.

Ah, Benchmarks... Klick. Ich kenne das von dir angesprochene Benchmark nicht, aber mit dem richtigen Code kann man so ziemlich alles beweisen, sogar daß Assembler langsamer ist als QBASIC.

Horst_H hat folgendes geschrieben:

gnadenlos? Ist wohl übertrieben und kommt sehr selten vor. shootout.alioth.debi...pp&lang2=fpascal

Ach, auf Alioth gibt's auch Benchmarks, wusste ich noch nicht. Wie gesagt, mit dem richtigen Code kann ich dir so ziemlich alles durch ein Benchmark beweisen. Auch dem Alioth-Benchmark unterstelle ich zunächst einmal, daß es nicht repräsentativ ist, bis ich das Gegenteil erfahre, auch wenn die Leute dort eigentlich schon ziemlich kompetent sind.

Ist so was wirklich nötig :

tommie-lie hat folgendes geschrieben:

Wenn ich auf der FAQ-Seite immer noch lese, daß der FPC-Linker keinen relocatable code in ELF-Dateien erzeugen kann (und somit Shared Objects unter Linux)...

Wem willst Du damit WAS sagen ? Eine Anhäufung von Abkürzungen und Fachbegriffen ist immer verdächtig. Insofern zumindest, daß sich jemand dahinter versteckt, der in Wirklichkeit keine Ahnung hat. Wegen der überlangen Zitat-Orgien habe ich jetzt nicht mal alles lesen können.

Jetzt eine Frage zum Thema. Habe kürzlich folgendes gelesen : ein bekannter Software-Hersteller setzt für Windows Delphi ein und bei Linux entweder Lazarus oder Delphi in Verbindung mit Wine. Finde jetzt die Quelle nicht mehr, könnte auch FPC statt Delphi bei Linux sein. Jedenfalls besteht kein Anlass zur Sorge, dass es unmöglich ist, ein Pascal-Programm unter Linux zum laufen zu bringen. Wie gesagt, Firlefanz am Rande interessiert hier nicht. Ich will vielmehr folgendes wissen : läßt sich eine ähnliche Konstellation mit Suse 8 oder besser 7 realisieren ? Besser 7 deshalb, weil ich das hier liegen habe und die 8 verliehen ist. Gibts eventuell eine Kurzanleitung irgendwo ?

hansa hat folgendes geschrieben:

Ist so was wirklich nötig : tommie-lie hat folgendes geschrieben: Wenn ich auf der FAQ-Seite immer noch lese, daß der FPC-Linker keinen relocatable code in ELF-Dateien erzeugen kann (und somit Shared Objects unter Linux)... Wem willst Du damit WAS sagen ?

Jemandem, der weiß, um was es geht.
Eine Anhäufung von Fachbegriffen ist nicht verdächtig, sondern üblich. Wieso sollte ich mir die Mühe machen, Fachbegriffe Idiotensicher zu übersetzen, nur um dabei Fehler zu machen und Mehrdeutigkeiten entstehen zu lassen? Ich sage "Shared Object" und jeder, der überhaupt weiß, worum es geht, weiß auch, was gemeint ist. Wenn ich einem Kindergarten erklären will, was das ist, wären die Texte deutlich länger.

hansa hat folgendes geschrieben:

Ich will vielmehr folgendes wissen : läßt sich eine ähnliche Konstellation mit Suse 8 oder besser 7 realisieren ?

Ja. Entweder FreePascal mit Lazarus installieren, oder Wine (die aktuellen Versionen von Wine sind sehr benutzerfreundlich geworden, das sollte eigentlich ohne Probleme hinzukriegen sein). Bei der Wine-Lösung ist aber zu beachten, daß, wenn man Delphi in Wine ausführt, man keinen Crosscompiler erhält, man also immer noch Windows-EXEn erzeugt, die nur unter Windows (oder wiederum unter Linux in Wine) laufbar sind. Es wäre also genauso wie wenn du unter Windows entwickelst und einfach deine EXE unter Linux mit Wine startest. Lediglich das Neustarten des Rechners entfällt.
Für aktuelle Versionen der Software sind unter Umstände aktuellere Versionen von Bibliotheken notwendig, als jene, die SuSE 7 mitbringt. Wenn du nicht durch Kundenwünsche auf so alte Versionen angewiesen bist, wäre ein Update auf eine neuere Version von SuSE der Weg, bei dem du deutlich weniger Steine haben wirst. OpenSuSE (wie es mittlerweile heißt) gibt es hier. Wenn dir der Download zu groß ist, verschickt dvd-iso die DVD-Version für kleines Geld. Die teurere Alternative wäre der SuSE Linux Enterprise Desktop von Novell, dafür gibt es dann einen schicken Karton drumrum


Edit: Aktuelle Wine-Versionen für SuSE setzen laut der offiziellen Seite SuSE 9.1 vorraus, vermutlich machen die das nicht zum Spaß. Wenn du bereits bei deiner SuSE 7 auf CD eine Wine-Version findest, wird sie hoffnungslos veraltet sein, ob du damit problemlos Delphi oder deine Anwendungen zum Laufen kriegst, ohne viel Zeit in die Konfiguration und die Installation nativer DLLs zu stecken, weiß ich nicht.