Gerüchte um XE2 Beta-Test

[himitsu]

Das Problem waren eher die vollig getrennten IDEs,
wobei nnur der Quellcode "ähnlich" war, aber man sonst nicht wirklich was Gemainsames hatte und nicht alles überall machen/kompilieren konnte.

Wenn die Delphi-IDE und der Compiler wirklich in Delphi geschrieben sind, dann wird man die vermutlich irgendwann mit XE2+ auch mal für andere Betriebssysteme kompilieren können.

Hier wird man ja bald alles, z.B. via FinalBuilder und Co. oder manuell, auf einem System schreiben+kompilieren.

[mkinzler]

Da ja die VCL aus guten Gründen nicht auf andere Plattformen portiert wird und die IDE ein VCL+Programm ist, wird diese nicht so einfach zu portieren sein. Man müsste die Oberfläche hierfür neu entwickeln. Bei Kylix war ja auch nicht der Compiler das Problem sondern die unvollständige CLX-Bibliothek. Die IDE an sich wurde per WineLib portiert.

[Robotiker]

Ja, dem neuen Ansatz merkt man schon an, dass man die Fehler der vorherigen Ansätze vermeiden will.

Zitat:

Zitat von mkinzler (Beitrag 1115487)

Bei Kylix war ja auch nicht der Compiler das Problem sondern die unvollständige CLX-Bibliothek. Die IDE an sich wurde per WineLib portiert.

Darauf folgte dann der Ansatz mit dem C++ BuilderX, der eine in Java geschriebene IDE verwendete, die auch unter Linux und Mac lief. Dort machte man dann den Fehler, das man sich auf fremde Compiler (GNU, Intel, MS) und Bibliotheken (WxWidgets) verließ.

Jetzt also die normale Windows IDE mit Crosscompilern und Remote Debugging.
FireMonkey als portable GUI-Lib, Teile der VCL (oder wie man das dann nennt) mit elementaren Dingen wie Strings usw. als Basis.

Klingt soweit vernünftig. Wenn der C++ Builder jetzt noch einen moderneren Compiler kriegt, können Teile aus Boost, wie Asio, Filesystem, usw. den Rest beitragen. Auch Libraries wie Poco haben portable Sockets, Xml, usw.
http://www.boost.org/doc/libs/1_47_0...oost_asio.html
http://pocoproject.org/

Sieht durchaus nach einer möglichen Alternative zu Qt aus.

[mkinzler]

Zitat:

Teile der VCL (oder wie man das dann nennt) mit elementaren Dingen wie Strings usw. als Basis.

Ich würde das eher Sprachstandard bzw. RTL nennen

[divBy0]

Ich bin mal gespannt ob es dann auch angepasste Indys für OSX / iOS gibt.

[RWarnecke]

Mich würde interessieren, ob es irgendwo schon Dokumente gibt, wie man mit MacOS un iOS unter Delphi hantieren kann ? Ich denk da so an zum Beispiel die API-Befehle unter Windows.

[mkinzler]

Noch befindet sich das Produkt ja noch im geschlossenen Fieldtest.

[himitsu]

Zitat:

Zitat von mkinzler (Beitrag 1115902)

Noch befindet sich das Produkt ja noch im geschlossenen Fieldtest.

Dennoch sollte es doch irgendwo schon sowas wie das MSDN auch für Mac geben?

Wir sind ja nicht die Ersten (eigentlich eher die Letzten), welche für dieses OS was programmieren wöllten, demnach gibt's sowas bestimmt schon irgendwo. :roll:

[Memnarch]

@Himitsu: Ist vor kurzem verbrannt worde, als man mitbekam das jetzt eine neue Flut Windowsnutzer droht, die MacWelt mit ihren selbstgebastelten Programmen zu infizieren :twisted:

[bernau]

Zitat:

Zitat von RWarnecke (Beitrag 1115885)

Mich würde interessieren, ob es irgendwo schon Dokumente gibt, wie man mit MacOS un iOS unter Delphi hantieren kann ? Ich denk da so an zum Beispiel die API-Befehle unter Windows.

Ich denke, daß man API-Zugriffe sowiso vermeiden sollte, wenn man plattformübergreifend programmiert. Dafür ist das Framework da.