Wer braucht Delphi XE - go back to the roots!

[himitsu]

Tschuldschung, er hörte bei 4 auf mit Zählen. ps:
Ich meinte den impliziten Anti-Punkt 5. (letzter Absatz)

[mkinzler]

Nur das kann man halt nicht trennen, da das auf jeden Fall Änderungen an der RTL/VCL nach sich zieht.
Idealerweise muss man auch umfangreiche Änderungen an der Compiler-Architektur machen ( Trennung Front/Back-End)
Alt:

Code:

-Compiler für Delphi/Win32/x86
-Compiler für C++/Win32/x86
Nächster Schritt
-Compiler für Delphi/Win64/x86
-Compiler für MacOS(32Bit)/x86
Dann:
-Compiler für Delphi        Win32/x86
-Compiler für C++           Win64/x86
                        ->  MacOS 32Bit
                            MacOS 64Bit
                            Linux ...
Ziel:
-Compiler für Delphi        Win32
-Compiler für C++           Win64        
-Compiler für xxx       ->  MacOS 32   -> x86 
                            MacOS 64      Arm
                            Linux ...

[mquadrat]

- VCL renovieren (Databinding, etc.)
- Fremdkomponenten (Siehe unten)
- Multiplattform (Hier sehe ich vor allem marketingtechnische Möglichkeiten)
- 64bit Compiler (Wird man früher oder später nicht drumrum kommen)

Zu den Fremdkomponenten:

Was an Delphi immer gut war ist, dass vieles einfach schon dabei war (TChart, Report-Generator, etc.). Dazu gab es immer haufenweise Komponentenbauer, die mehr oder weniger sinnvolle Komponenten released haben. Die Anzahl der Komponentenbauer nimmt immer weiter ab. Das bedeutet, dass Emba immer mehr dieser Arbeiten übernehmen muss. Ziel der Übung wäre, das alles was man braucht um funktionierende und konkurrenzfähige Anwendungen zu erstellen verfügbar ist. Neben den bereits eingebauten Komponenten wäre eine Art "App Store" für Komponenten gut. Zentral administriert und am Besten als Add-On Engine direkt in die IDE eingebunden.

[Bernhard Geyer]

Zitat von mkinzler:

-Compiler für MacOS(32Bit)

Ist ein 32-Bit MacOS-Compiler nötig? Die Geräteklasse die mit 32-Bit Prozessoren läuft hat doch iOS. Und dort sperrt doch Apple Fremhersteller per Monopollizenz aus.

[mkinzler]

iOS ist aber für die ARM-Plattform

[Phoenix]

Zitat von Bernhard Geyer:

Zitat von mkinzler:

-Compiler für MacOS(32Bit)

Ist ein 32-Bit MacOS-Compiler nötig? Die Geräteklasse die mit 32-Bit Prozessoren läuft hat doch iOS. Und dort sperrt doch Apple Fremhersteller per Monopollizenz aus.

Zum einen ist das nur für die ARM-Chips in den iOS-Devices. Nix mit x86 - Code der Intel chips in den normalen Macs. Zum anderen gilt die 'Lizenz' nur für Applikationen, die man über den Appstore vertreiben will. Für Enterprise deployment einer eigenen Applikation z.B. ist der Paragraph da gar nicht vorgesehen. Und das dürfte eher der Einsatzbereich sein.

[Bernhard Geyer]

Mit dem Hinweis auf MacOS geht mir eher darum:

Ist für MacOS noch ein 32-Bit Compiler nötig oder reicht es nicht gleich nur nach 64-Bit zu kompilieren.

Der Hinweis auf iOS war eher zweitrangig (würde wie schon angemerkt wegen ARM-Architektur frühestens in Delphi 2020 kommen).

[mkinzler]

Der ist doch zu gut wie fertig. die 64Bit Version wird erst mit dem neune Back/Front-End Compiler in XE3 kommen.

[Phoenix]

XE 2, nicht 3. Nächstes Jahr. Zumindest für Delphi. C++ kommt dann ein Jahr später mit x64.

[mkinzler]

Auch die 64 Bitversion für MacOSX? Pulsr hat laut RoadMap nur einen 32Bit Compiler für MacOSX