Delphi-Entwicklung unter MacOS X

[CalganX]

(Der Artikel befindet sich in der Delphi-PRAXiS und in meinem Blog)

Nicht selten findet man im Internet, auch in der Delphi-PRAXiS, die Frage wie man unter MacOS X ([1]) Delphi-Programme schreiben kann. Die Frage verwundert nicht, schließlich ist MacOS ein konkurrenzfähiges Betriebssystem geworden und erfreut sich unter Apple-Benutzern - zu Recht - sehr großer Beliebtheit. Und Pascal bzw. Delphi wird an vielen Schulen im Informatikunterricht eingesetzt und es gibt genügend (Hobby- oder berufliche) Delphi-Entwickler, die den Schritt hin zur Macintosh-Plattform wagen.
Im Folgenden möchte ich einige Möglichkeiten aufzeigen, wie es möglich ist Delphi- bzw. Pascal-Programme unter MacOS X zu schreiben, zu kompilieren und zu verwenden.

Doch eines Vorweg: Borland/CodeGear beitet kein Developer Studio für MacOS X an. D.h. den Komfort der Delphi-Entwicklung, den man von Windows kennt, wird es nicht geben. Das heißt aber auch, dass es kein wirklich natives Delphi für MacOS X gibt. Darüber hinaus ist die Entwicklung mit einige Frickeleien verbunden; für den produktiven Einsatz an Großprojekten nicht unbedingt zu empfehlen. Aber das muss jeder für sich selber entscheiden.

1. Delphi unter Parallels Desktop
Wer unbedingt nicht auf Komfort verzichten will, kann auch unter MacOS X die Windows-Programme von Borland verwenden. Aber natürlich nicht nativ und die entstehenden Programme bleiben auch Windows Programme und letztlich hat man nur das Windows-Programm unter MacOS X gestartet und verwendet. Virtualisierung heißt das Konzept (von Laien auch häufig Emulation genannt) und ist natürlich nicht neu. Für Windows gibt es Virtualisierungslösungen, wie z.B. VMWare ([2]), was wahrscheinlich die bekannteste ist. Für MacOS X hat Parallels Desktop ([3]) den Markt für sich erobert. Parallels ist jedoch nicht kostenlos: um die 80 Euro (Amazon.de) muss man für diese Software locker machen. Wer jedoch einen Macintosh-Computer besitzt und viele Windows-Anwendungen, u.a. Delphi, weiterhin benötigt investiert hier wahrscheinlich sinnvoll sein Geld.
Besonderes Feature von Parallels Desktop ist der so genannte Coherence Mode (zu Deutsch Kohärenzmodus): Anwendungen erscheinen nicht auf einem virtualisierten Desktop, sondern als eigenes Fenster auf dem MacOS-Desktop. (Dieses Feature ist derzeit nur in der Beta-Version vorhanden und dort auch zu Recht als "Beta"-Feature gekennzeichnet.)

http://stuff.calganx.net/images/scre...ence_thumb.jpg
Abb. 1: Parallels Desktop mit Turbo Delphi im Coherence Mode

Die Entwicklung findet dann in der normalen IDE statt. Doch wie Eingangs bereits gesagt, handelt es sich hier nur um einen virtualisierten Desktop und die Software-Entwicklung hat hier nicht viel mit MacOS zu tun, lediglich das Gastgeber-Betriebssystem ist nicht Windows. Davon bekommt weder Delphi, noch eure Anwendung etwas mit.
Für Entwickler, die native MacOS X-Anwendungen erstellen wollen, sind hier also auf dem falschen Weg. Auch Entwickler, die bewusst native Windows-Anwendungen auf einem Macintosh-Computer erstellen wollen, sollten sich nach Alternativen (z.B. BootCamp ([4])) umsehen, um eine Windows-Installation zu nutzen, denn Parallels benötigt, wie jede Virtualisierungssoftware, Unmengen an Rechenleistung und vorallem an Arbeitsspeicher. Und sofern man nicht gerade das obere Ende der Arbeitsspeicherausstattung verbaut hat, sollte man Windows-Entwicklung auf einem Windows-PC oder zumindest unter einer nativen Windows-Installation tätigen.

2. Anwendungen unter MacOS X
An dieser Stelle möchte ich auf etwas grundlegende Theorie hinweisen: unter MacOS X unterscheidet man zwischen den wirklichen Binärdateien und den Application Bundles. Letztere sind das, was die meisten Programme dem Benutzer anbieten. Und ein Doppelklick auf diese Bundles (in der Praxis Dateien mit der Endung ".app", wobei die Endung im Standardfall ausgeblendet wird) startet das gewünschte Programm auch. Doch es handelt sich hier nicht um die reine ausführbare Binärdatei, wie es bei Exe-Dateien unter Windows der Fall ist. Denn öffnet man diese Bundles (Rechtsklick -> Paketinhalt anzeigen), so zeigt sich, dass diese Bundles (und daher auch der Name) ein Bündel von Ressourcen und Anwendungen ist. Im Wesentlichen handelt es sich um Ressourcen, wie Bilder, Texte und nib-Files (letztere sind die Beschreibungsdateien für Fenster, ähnlich der DFM-Dateien von Delphi).

http://stuff.calganx.net/images/scre...ndle_thumb.jpg
Abb. 2: Kontextmenü eines Application Bundle

http://stuff.calganx.net/images/scre...ries_thumb.jpg
Abb. 3: Binary innerhalb eines Application Bundle

Innerhalb des Bundles, im Verzeichnis /Contents/MacOS/, befindet sich erst die wirkliche Binärdatei. Diese Binärdatei ist ähnlich denen, die man unter *NIX findet, da sich hinter MacOS X ein BSD-System verbirgt, was viele Gemeinsamkeiten mit *NIX-Systemen besitzt. Diese Binärdateien bilden letztlich das Kernstück der Application Bundles. Zur Vereinfachung der Struktur der ausgelieferten Anwendung, hat man jedoch eben diese Bundles gewählt, was sich in der Praxis auch als überaus sinnvoll erweist. Als Software-Entwickler sollte man sich jedoch über diesen Umstand im Klaren sein, denn es bedeutet auch, dass alle Resourcen, die mit dem Programm ausgeliefert werden, ungeschützt und für jeden ersichtlich sind. Unter Windows mag das zwar auch der Fall sein, jedoch ist hier bisweilen - im Falle von Ressourcen, die in die Anwendung mit einkompiliert wurden - Arbeit mit einem Ressourcen-Hacker erforderlich.

Abgesehen davon muss man wissen, dass Apple im letzten Jahr auf die Intel-Architektur x86 umgestiegen ist (zuvor verwendete man IBMs PowerPC-Architektur). Das bedeutet auch einen Umstieg im Befehlssatz und somit in der Kompilierung der Anwendung selbst. Eine Anwendung, die auf einem alten PowerPC ohne Installation entsprechender Frameworks erstellt wurde, ist auf einem aktuellen Intel-Mac nur noch als Emulation lauffähig. Diese Emulation heißt Rosetta und ist heute relativ ausgereift. Für die meisten Programme entsteht kaum Performance-Verlust. (Adobe Photoshop war bis zur Version CS3 auch nur unter Rosetta lauffähig und für die meisten Benutzer hat das gereicht, auch wenn CS3 wesentlich peformanter ist.)
Programme, die sowohl auf der PowerPC- als auch auf der Intel-Architektur lauffähig sind, werden Universal Binary genannt (es gibt auch ein entsprechendes Logo dazu, das solche Anwendungen kennzeichnen sollte). Das Besondere an Universal Binaries ist, dass sie doppelten Programmcode enthalten: einmal für Intel und einmal für PowerPC. Das hat den Vorteil, dass die Anwendung nativ unter beiden Architekturen läuft, auf der anderen Seite hat es jedoch den Nachteil, dass die Anwendung größer wird und ggf. mehr Speicher verbraucht (im überwiegenden Fall der Fälle wirkt sich das aber nicht aus und ist zu vernachlässigen).
Aktuelle Systeme erstellen meistens Universal Binaries. Diese Option kann man jedoch zugunsten einer Architektur verändern. Deaktiviert man also die PowerPC-Unterstützung, wird eine Software auch auf dieser Architektur nicht laufen, da es keine Rosetta-ähnliche Anwendung für die Emulation der Intel-Architektur gibt. Eine Deaktivierung der Intel-Unterstützung bedeutet lediglich, dass die Anwendung zwangsweise unter Rosetta ausgeführt wird, was aber nicht zu empfehlen ist.
Auch diese Situation sollte einem Software-Entwickler bekannt sein, bevor er mit der Entwicklung von Software auf der MacOS-Plattform beginnt.

3. Voraussetzungen
Bevor es los geht: unbedingt die Xcode Tools installieren. Diese befinden sich auf der MacOS X-Installations-CD die beim Macintosh-Computer beigelegt ist. Einfach alles installieren (Xcode selber ist eine relativ mächtige IDE, die sehr viele Möglichkeiten bietet). Enthalten ist auch ein gcc-Compiler den ihr spätestens für Lazarus brauchen werdet.

4. Entwicklung mit FreePascal (FPC)
Wer bereits nach Alternativen zu Delphi gesucht hat, wird mit Sicherheit auf FreePascal ([5]) gestoßen sein. FreePascal ist ein kostenloser und freier Compiler für Pascal und Object Pascal und damit auch gewissermaßen für Delphi. FreePascal ist als vorkompiliertes Binary für Windows, Linux, MacOS X und diverse weitere Betriebssysteme erhältlich ([6]).
Wer beim Download aufpasst, wird feststellen, dass die Binaries für MacOS X nur für die PowerPC-Architektur erhältlich sind. Das heißt nicht nur, dass der FPC-Compiler unter Rosetta läuft, sondern dass die erstellten Anwendungen ebenfalls keine Universal Binaries sein werden. Es gibt jedoch eine spezielle Seite auf der FPC-Seite für die Entwicklung für MacOS X ([7]). Dort wird die aktuelle Entwicklung festgehalten und auf entsprechende Snapshots verwiesen. Am sinnvollsten ist es, sich von dort den aktuellen Snapshot herunterzuladen. Benötigt wird nur das fpc-Paket für MacOS X i386 (oder PowerPC, für die, die einen Mac mit PowerPC-Architektur besitzen [diese wissen im Normalfall davon]).
Die Installation gestaltet sich denkbar einfach: .dmg-Image herunterladen, mounten (Doppelklick) und enthaltenes Paket installieren (wieder Doppelklick). Dann noch einmal brav durch die Installation durchklicken und fertig - die Delphiprogrammierung kann los gehen.

Doch der Compiler alleine reicht noch nicht für die Programme mit der schönen Aqua-Oberfläche. Doch der Compiler bietet schonmal etwas: wir können einfache, kleine Konsolenprogramme schreiben. Als Beispiel soll hier Hello World dienen:

Delphi-Quellcode:

program HelloWorld;

begin
  WriteLn('Hello World. This is MacOS X.');
  ReadLn;
end.

Jetzt brauchen wir aber ein Terminal (Programme -> Dienstprogramme -> Terminal), müssen in das Verzeichnis mit der HelloWorld.pas-Datei wechseln und dort

Code:

fpc ./HelloWorld.pas

eingeben. Nachdem Compilieren, Assemblieren und Linken kriegen wir eine Datei, die einfach nur HelloWorld heißt heraus. Ein

Code:

./HelloWorld

beschert uns dann auch das gewünschte Ergebnis und die Ausgabe aus unserem Programm.
Wirklich glücklich macht uns das natürlich nicht, wer aber dennoch ein wenig mit der Konsole herum spielen möchte, sollte sich die Dokumentation auf der FreePascal-Seite ansehen und nachlesen, welche Möglichkeiten der Compiler bietet (vorhandene Units etc.).

5. Entwicklung mit Lazarus
Das Projekt Lazarus ([8]) ist direkt mit FPC verknüpft: während FPC nur den Compiler bereitstellt, ist Lazarus eine OpenSource-IDE für den FPC. Dabei orientiert sich Lazarus an den "alten" Delphi-Versionen (sprich Delphi 5, 6 und 7). Lazarus ist Windows, Linux und MacOS X verfügbar; Download über den bereits genannten Link [7]. Diesmal sind aber drei Pakete erforderlich: fpc, fpcsrc und Lazarus.
Wer alles heruntergeladen und installiert hat, wird feststellen, dass es kein schönes Application Bundle "Lazarus" im Programme-Ordner zu finden ist. Also mal testweise ein Terminal aufmachen und lazarus eingeben.
Aber, ganz so einfach ist es auch nicht. Für gewöhnlich solltet ihr so eine Ausgabe bekommen:

Code:

dyld: Library not loaded: /sw/lib/libglib-1.2.0.dylib
  Referenced from: /usr/local/bin/lazarus
  Reason: image not found
Trace/BPT trap

Jetzt fängt der Spaß erst richtig an. Und ich empfehle jedem, der sich nicht wirklich damit beschäftigen will, zum nächsten Kapitel zu gehen, denn die Installation von Lazarus ([9] bietet da einen englisch-sprachigen Ansatz, ich werde aber im Folgenden einen anderen Weg wählen) ist ein wenig frickelig.

Zuerst brauchen wir ein wenig Kram, damit wir los legen können:
- X11 (Von der MacOS X-CD installieren: CD 1, Optional Installs.pkg)
- Fink ([10])
X11 ist schnell installiert, die Installation von Fink ist auch noch relativ einfach. Beschrieben ist sie unter [11]. Dieser Anleitung bitte folgen.
Wenn Fink installiert ist, braucht ihr noch gtk+. Und damit fängt der Spaß erst richtig an, denn gtk ist ein Linux-Paket und MacOS X ist zwar entfernt mit Linux verwandt, aber eben nicht das Gleiche. Darum ist eben Fink (oder alternativ MacPorts) erforderlich. Fink bietet die Möglichkeit Linux-Projekte unter MacOS X zu kompilieren und zu verwenden. An sich natürlich eine schöne Idee, aber Mac-User sind für gewöhnlich keine Frickler und meiden daher im Normalfall die Terminal-Akrobatik. An dieser Stelle werdet ihr aber nicht drum herum kommen.
Wir brauchen das gtk+-Paket (schlimmerweise verwendet Lazarus noch Gtk1):

Code:

sudo /sw/bin/apt-get install gtk+

Ins Terminal und fertig. Das geht zum Glück relativ schnell, weil apt-get direkt die Binaries runterlädt. Wer

Code:

sudo fink install gtk+

oder mit MacPorts

Code:

sudo port install gtk1

verwendet wird wesentlich länger warten müssen, da diese Software die SourceCodes herunterladen und diese kompilieren.
Außerdem braucht es noch gdk-pixbuf also in's Terminal:

Code:

sudo /sw/bin/apt-get install gdk-pixbuf

Sollte es zu irgendwelchen Problemen bisher gekommen sein, dann bitte unter [11] gucken. Insbesondere das Update von fink und apt-get durchführen.

Jetzt ist alles Wichtige installiert und wir können Lazarus starten: unter Programme:Dienstprogramme: sollte eine X11.app sein (ansonsten von der MacOS X-CD nachinstallieren). Dieses Bundle starten. Es öffnet sich ein xterm. Ich habe die Erfahrung gemacht, dass darüber Lazarus nicht richtig gestartet wird. Also zusätzlich (!) ein normales Terminal aufmachen und lazarus eingeben. Ohne Probleme sollte jetzt das entsprechende Programm starten.
Wir können jetzt als Beispiel einfach mal ein Button mit einem OnClick-Ereignis mit
ShowMessage('Hello World. This is MacOS X.'); basteln. Die Bedienung ist im Wesentlich, wie unter Windows. Vorsicht aber mit Hotkeys, wie z.B. F9: standardmäßig sind die vom System mit Exposè belegt. Deswegen wird unter Umständen das Programm nicht starten. Aber ein Klick tut es ja auch und siehe da: es kompiliert und es wird uns auch eine Messagebox angezeigt.

http://stuff.calganx.net/images/scre..._ide_thumb.jpg
Abb. 4: Die Lazarus-IDE im Einsatz

Was aber direkt auffällt: es handelt sich um eine GTK-Anwendung. Auch hier wird man die beliebte Aqua-Oberfläche vermissen. Trotzdem haben wir damit eine MacOS X-Anwendung mit Delphi bzw. Pascal erzeugt. Für kleinere Projekte mag das ausreichen.
Es fallen aber noch zwei Dinge auf: Erstens entsteht kein Application Bundle, sondern eine Intel-Binary. Das erklärt auch die fehlende Aqua-Oberfläche: es handelt sich um keine MacOS X-Anwendung, sondern eine Unix-Anwendung und deswegen wird auch X11 zur Ausführung der erstellten Programm benötigt. Eine native MacOS X-Anwendung wird hier also auch nicht erstellt.

6. Xcode und das Integration Kit
Xcode ist die IDE, die Apple kostenlos zusammen mit MacOS X anbietet. Sie ist Teil der Developer Tools und ist im Prinzip die IDE für Software-Entwickler unter MacOS X. Xcode ist aber nicht auf die üblichen Sprachen (C++, Objective-C (dazu komme ich später nochmal) und Java) beschränkt. Legt man Hand an, an einige Teile von Xcode, so kann man auch Pascal in Xcode integrieren.
Dazu wird aber erstmal Software benötigt:
- Xcode (ist Teil der Developer Tools, die sich auf CD1 der MacOS X-Installation befindet)
- FreePascal (s.o.)
- Apple Universal PInterfaces (Direkter Download: [12])
- Xcode Integration Toolkit ([13] Nur das Toolkit herunterladen!)
Diese vier Tools werden dann auch in dieser Reihenfolge installiert. Im Wesentlichen hat man dann auch alles wichtige erledigt. Doch man sollte noch einige weitere Schritte vornehmen: [14] ist eine englischsprachige Anleitung, um die notwendigen Templates zu erstellen. Ich möchte das jetzt nicht hier Schritt für Schritt erläutern, die meisten von euch sollten ja des Englischen mächtig sein.

http://stuff.calganx.net/images/scre..._fpc_thumb.jpg
Abb. 5: FPC-Anwendungen in Xcode

Nun kann man eine FPC Carbon Application erstellen (über File -> New Project, einfach ein wenig nach unten scrollen). Diese Anwendung ist nun eine Carbon-Anwendung (was das bedeutet, später). Man kann ja mal einen Blick in die beiliegenden PAS- und NIB-Dateien werfen. NIB-Dateien sind die Fensterdefintionsdateien, die mit Hilfe des Interface Builders bearbeitet werden. Ein Klick auf Build and Go wird euch die Anwendung erstellen und anzeigen.

http://stuff.calganx.net/images/scre...late_thumb.jpg
Abb. 6: Die Demo-Carbon-Anwendung

Nun habt ihr eine echte, native MacOS X-Anwendung vor euch. Das Carbon-Framework ist eine Apple-Entwicklung und somit ist das Starten der Anwendung auf anderen Computern nicht von Dritt-Anbieter-Bibliothek, wie X11 oder Gtk+, abhängig. Außerdem ist die Anwendung ein echtes Application Bundle mit allen Vor- und Nachteilen.
Aber: es gibt derzeit keine vernünftige Dokumentation zu dieser Lösung. Es gibt zwar eine Referenz zu den Carbon Interfaces ([15]), aber es sind nicht alle Header-Dateien korrekt übersetzt worden. Das bedeutet, dass viele Dinge nicht so oder gar nicht funktionieren, wie in der Referenz angegeben. Außerdem ist Carbon inzwischen überholt (s.u.).

7. Carbon-Integration für Lazarus
Laut [16] gibt es eine Möglichkeit Lazarus "carboonproofed" zu machen. D.h. mit Hilfe von Lazarus Carbon-Anwendungen zu erzeugen. Dazu sollte man sich [17] zu Gemüte führen. Außerdem sollte man sich dieses Shellskript [18] herunterladen, um die Application Bundles zu erzeugen.
Ist man den Anweisungen gefolgt, so kann man auch mit Lazarus Carbon-Anwendungen erzeugen. Diese sind dann auch echte, native MacOS X-Anwendungen.

http://stuff.calganx.net/images/scre...tion_thumb.jpg
Abb. 7: Carbon-Anwendung mit Lazarus

Es ist aber zu erwähnen, dass hier ein Snapshot von Lazarus verwendet wird. Es ist also weit von der finalen Version entfernt und die Wahrscheinlichkeit von Bugs ist extrem hoch.

8. Carbon? Cocoa? Frameworks? Objective-C?
Die beiden zuletzt genannten Ansätze, um Delphi-Anwendungen unter MacOS X zu erzeugen, kompilieren Anwendungen gegen das Carbon-Framework. Dieses Framework wurde von Apple mit MacOS X 10.0 eingeführt, um den Umstieg von MacOS 9 und älter ("Classic") auf MacOS X zu erleichtern. Darum funktionieren Carbon-Anwendungen auch noch im alten MacOS.
Inzwischen wird MacOS 9 kaum noch eingesetzt. Das heißt, dass auch Carbon mehr und mehr an Bedeutung verliert und in der Zukunft wahrscheinlich auch nicht mehr in MacOS X zu finden sein wird. Viel mehr wird vermehrt auf das Cocoa-Framework gesetzt. Dieses Framework bildet heute den wesentlichsten Bestand der Software-Entwicklung unter MacOS X. Derzeit wird das Cocoa-Framework nur von zwei Sprachen offiziell unterstützt: Objective-C und Java, wobei letztere nicht weiter entwickelt wird.
Das zeigt, dass Carbon-Anwendungen zwar mehr oder weniger echte MacOS X-Anwendungen sind, aber es fehlen hier wesentliche Features von MacOS X. Seien es Features in der Aqua-Oberfläche (wie bspw. Panes und Sheets) oder Frameworks wie Quartz. Letztere lassen sich unter Xcode noch nachträglich einkompilieren, unter Lazarus ist das aber auch wieder mit Arbeit verbunden und es ist auch immer davon abhängig, welche Frameworks bereits übersetzt wurden. Carbon-Anwendungen sind also nett zum Spielen, aber für Software, die im produktiven Praxis-Einsatz verwendet werden soll, ist das wohl effektiv keine Lösung.

Was ist Objective-C? Objective-C ist eine Programmiersprache, die an C++ erinnert. Ziel von Objective-C, der Name legt es nahe, der C-Sprache Objektorientierung zu vermitteln. C++ (auch C with classes genannt) bietet solche Möglichkeiten auch, wer aber schonmal damit entwickelt hat, weiß, dass es weit von den Möglichkeiten der Objektorientierung von Java oder Delphi entfernt ist (wobei es auch hier Leute geben soll, die es produktiv und gerne einsetzen).
Objective-C geht hier einen anderen Weg der im Implementierung von Klassen. Man greift auf so genannte Delegates und Nachrichten zurück. Für Delphi-, C#- und Java-Entwickler wird das Konzept der Sprache sehr ungewohnt sein und es erfordert auch einige Eingewöhnungszeit, aber die Praxis zeigt, dass das Konzept effektiv und durchaus konkurrenzfähig ist. Es gibt auch Versuche dieses Konzept auf andere Sprache, unter anderem Pascal, und andere Betriebssysteme zu übertragen.

Im Internet gibt es diverse Ressourcen ([19][20][21]) zu diesem Thema.

9. Fazit
Mit diesem Artikel wollte ich einige Möglichkeiten zeigen, wie man die Sprache "Pascal" bzw. "Object Pascal" bzw. "Delphi Language" unter MacOS X einsetzen kann. Das Ergebnis ist ernüchternd: es gibt ein OpenSource-Projekt (FreePascal / Lazarus), das aber für den produktiven Einsatz letztlich nicht zu gebrauchen ist. Hobby-Entwickler werden wohl ihren Spaß haben und auch einige nette Anwendungen zaubern können, doch Entwickler, die beruflich Software für MacOS X entwickeln sollen, sollten in Erwägung ziehen, Objective-C zu lernen. Die gesamte Software-Entwicklung für MacOS X läuft nämlich auf Objective-C/Cocoa hinaus.

10. Blick in die Glaskugel
Ein Blick in die Zukunft der Software-Entwicklung von MacOS X: Am Gespann Objective-C und Cocoa wird sich in Zukunft nicht viel ändern. Wenn im Oktober MacOS X 10.5 "Leopard" veröffentlicht wird, so wird es neben Xcode 3.0 eine Überarbeitung der Objective-C-Sprache enthalten. Es werden viele neue Features zur Sprache hinzukommen, die in der Vergangenheit noch gefehlt haben oder unvollständig waren.
Microsoft hat angekündigt .NET auf die MacOS X-Plattform zu bringen ([22]). Wann jedoch mit einer Vorstellung zu rechnen ist, bleibt abzuwarten. Ist aber erstmal das .NET-Framework vollständig für MacOS X verfügbar, wäre es denkbar, dass bspw. das BDS in Zukunft auch für MacOS X erhältlich ist. Das ist aber auch davon abhängig, ob die Mac-Gemeinde .NET überhaupt akzeptieren wird.
Was FreePascal und Lazarus betrifft, ist die Zukunft ungewiss. Dies ist ein grundsätzliches Problem von OpenSource-Projekten: man wird sehen müssen, was die Zukunft bringt und inwieweit Pascal durch die Bemühungen des FPC-Projektes Einzug in Cocoa erhält. Ich persönlich gehe aber nicht davon aus, dass sich in Zukunft viel in diese Richtung tun wird. Vielmehr wird die Lazarus-IDE ausgereifter und stabiler werden, aber kaum eine grundsätzliche Veränderung, wie das Cocoa-Framework erfahren.

Ich hoffe der Artikel war für viele Leute mehr oder weniger hilfreich. Feedback, wie Lob, Kritik und Verbesserungsvorschläge, ist wie immer erwünscht. Einfach melden. Hier in der DP oder in meinem Blog oder per Email. ;)

[Bernhard Geyer]

Zitat von CalganX:

Microsoft hat angekündigt .NET auf die MacOS X-Plattform zu bringen ([22]). Wann jedoch mit einer Vorstellung zu rechnen ist, bleibt abzuwarten. Ist aber erstmal das .NET-Framework vollständig für MacOS X verfügbar, ...

Stop! WPF/E ist kein vollständiges .NET-Framework. Es soll primär eine Browsererweiterung werden. Damit will soweit ich es verstehe MS primär Flash angreifen, offiziell natürlich um erweiterte Möglichkeiten für den Browser zu bieten. Aber sich darauf zu verlassen das MS auch bei genügen Marktakzeptanz auch in Zukunft einen Mac-Port von WPF/E bringt wäre mir zu unsicher.

[mkinzler]

Aber Mono läuft auf MacOS X

[Bernhard Geyer]

Zitat von mkinzler:

Aber Mono läuft auf MacOS X

Jepp. Den wenn schon Plattformunabhängig dann richtig.

[CalganX]

Hi Bernhard,
stimmt. Du hast natürlich Recht: Mit Silverlight ist dieser Teil des Frameworks bereits veröffentlicht worden. In diesem Zusammenhang habe ich dennoch vor einiger Zeit gelesen, dass ein Microsoft-Mitarbeiter gesagt hat, dass auch weitere Teile des Frameworks folgen werden. Ich müsste die Quelle dafür aber nochmal suchen...

Mono läuft auf MacOS X, ja. Aber hier von Plattformunabhängigkeit zu sprechen... Mono läuft auch nur mit den Gtk-Bibliothek in einer X11-Umgebung. Diese Umgebung ist praktisch nur eine Möglichkeit das Unix-Subsystem (BSD bzw. Darwin) anzusprechen. Wirklich MacOS ist das deswegen, m.M.n., nicht. Außerdem weiß ich nicht, inwieweit Delphi und Mono sich kombinieren lassen. Dazu habe ich mich dann aber auch bisher nicht näher informiert.

Chris

[mkinzler]

Zitat:

Außerdem weiß ich nicht, inwieweit Delphi und Mono sich kombinieren lassen.

WinForms läuft.
http://www.mono-project.com/CocoaSharp

[Khabarakh]

Zitat von CalganX:

Mit Silverlight ist dieser Teil des Frameworks bereits veröffentlicht worden.

Silverlight benutzt .Net? Das wäre mir neu .

[CalganX]

Silverlight ist der neue Name der, von Bernhard angesprochenen, WPF/E. Ich würde es demnach als Teil von .NET ansehen.

Aber fangt jetzt bitte nicht an, hier über .NET zu diskutieren. Ich hab es in dem Artikel nur ein einziges Mal erwähnt, kein Grund deswegen jetzt hier eine Diskussion darüber zu loszutreten.

Chris