Wer braucht Delphi XE - go back to the roots!

[himitsu]

Tschuldschung, er hörte bei 4 auf mit Zählen. :ops:
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:

Zitat von mkinzler (Beitrag 1047214)

-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:

Zitat von Bernhard Geyer (Beitrag 1047751)

Zitat:

Zitat von mkinzler (Beitrag 1047214)

-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

[Tonic1024]

Zitat:

Zitat von Bernerbaer

Das ist nicht mehr Ironie, das ist Ignoranz! [..] (die du wohl gerne ignorierst) [..] (den du ja nicht komplett zu lesen gewillt bist)

Muss ich mich nun irgendwie angegriffen fühlen, bloß weil ich deine Meinung nicht (vollständig) teile? Ich glaub nicht...

Zum Thema inline c# (Also wenn, dann inline prism - falls es nicht morgen schon wieder vom Markt ist):
Wär schon geil... Soweit ich mich erinnere kann man in .Net Standard (win32) DLLs laden und damit interagieren. Und Hydra kann sowas in die andere Richtung. Es ist, ohne dass ich jetzt der Fachmann auf dem Gebiet wäre, bestimmt was machbar in dieser Richtung. Ob das Resultat dann praxistauglich wäre und ob es überhaupt Sinn macht potentiell portierbare Anwendungen an eine Plattform zu binden lasse ich mal offen jetzt. Zumal es ja nicht das erste Produkt wäre, das eigendlich keinen Sinn macht. ;)

Gruß,

Toni

[mkinzler]

Man kann aus C# per P/INVOKE auf nativ Programmbestandteile (EXE/DLL) zugreifen, das ist wegen den Sicherheitfeaturen von .NEt (CAS) nicht besonderst performant.
COM/INVOKE ist da besser.
Aber das wäre ja nicht inline. In diesem Fall müsste ja 2 getrennte Programme erstellt werden.

[Tonic1024]

Stimmt... Aber wenn das im Hintergrund geschehen würde und man das Geschwindigkeitsdefizit in Kauf nähme? das käme inline-code, auch wenn er den namen nicht verdient hätte, schon sehr nahe.

Man könnte Wrapper für Hardwarezugriffe verwenden die der Hersteller nur als Assemblies liefert (mir passiert) und könnte dann immernoch entscheiden ob man sein "Monsterprojekt" in .Net neu schreibt oder an einer Stelle auf Geschwindigkeit verzichtet.

[Edit]Ich hab mal mit System.Runtime.InteropServices experimentiert. Das meinte ich. War mir entfallen wie das heisst. [/Edit]

Toni