Ich muss jetzt auch mal meckern. Aber in etwas anderer Richtung.
Wer braucht denn 64 Bit ? Gut, ein Architekt, der komplette Häuserpläne abspeichern muss, der könnte das schon brauchen, oder eben CAD-Anwendungen. Könnte aber auch gut sein, dass es wegen 64 Bit die Datenbank sprengt, neue Rechner gekauft werden müssen etc.
Und was ist mit den Office-Plugins wenn ein 64-Bit MS-Office installiert ist? oder den Windows-Explorer-Plugins auf 64-Bit Systemen. Auch wird in einiger Zeit für IE-User auch die 64-Bit-Version des Browsers standard sein (mus nur noch Adobe nachziehen). dann sind alle Delphi-IE-Plugins tod.
Und dann die ganzen Treiberanbindungen. Oracle installiert bei verwendung von 64-Bit Oracle nur den 64-Bit OCI-Treiber. Also nix mit
DB-Zugriff auf Oracle wenn dort der 64-Bit Treiber nur vorliegt (Lässst ich bei oracle aber per Instant-Client + Umgebungsvariable lösen).
Jetzt versetze man sich aber mal in die Lage dieses Versicherungsvertreters.
Der sitzt jetzt bei dem Chinesen im Wohnzimmer und soll den original geschriebenen Namen in sein Notebook eingeben. Haha.
Ist doch unter Windows seit Jahren keine Problem. Oder glaubst du das alle Chinesen sich nur auf Englisch per Mail/Twitter/... unterhalten? Diese können problemlos chinesischen Text eingeben. Übrigens können chinesiche Texte auch mit alten Delphi-Programmen auf chinesischen Systemen eingegeben werden.
Wie hoch ist da jetzt der Anteil der Delphi-Programme, die 64 Bit /
Unicode zwingend brauchen ? Wohl <5%.
Ohne
Unicode würde es unsere Firma nicht mehr geben. Hatten aber Glück das mit ElPack (und Zeitweise TNTWare) entsprechend Komponenten am Markt waren und wir rechzeitig die Unterstützung begonnen hatten.
Aber ehrlich gesagt, mir wärs lieber, wenn sie das Augenmerk mehr auf Verbesserungen legen würden, anstatt dauernd Erweiterungen für relativ kleine Gruppen zu machen. Baustellen gibts ja wirklich noch genug. D8 war aber auch schon genug der Zumutung. Die sollen sich mal besser hinsetzen und sich überlegen, was noch gut wäre, anstatt mit immensem Aufwand eine eierlegende Wolfsmilchsau zu machen, die im Endeffekt doch nicht geht.
Der
IDE-Hersteller muß seine Hausaufgaben machen. Das war/ist
Unicode/Win64 wenn man noch ein bischen relevanz bezüglich "Beste Windows-
IDE" haben will. "Gimicks" wie
SVN-Integration (hier reicht eine Tools-
API-Interface), sind nicht das was einen Neukauft sinnvoll macht (wer
SVN & Co. benötigt hat schon seit Jahren entsprechende Lösungen im Einsatz).
Ich kann mir z.B. bis heute nicht erklären, warum sie keinen Compiler-Schalter Für
Unicode-Ein/Aus gemacht haben. Einzige Vermutung : Zeitdruck. Werde DavidI in Berlin mal fragen, warum sie das so gemacht haben.
Wurde doch schon öfter erklärt. Ich sehe auch keine notwendigkeit dafür. Einfach darauf aufpassen das der Code vernünftig implementiert ist dann gibt es auch keine größeren Problem mit dem Port nach D2009/2010.