Delphi 2011 heißt jetzt Delphi XE

[hanspeter]

Zitat von MEissing:

Und was für (fast alle?) Delphi Kunden das mit Abstand wichtigste ist, wurde in den 50 Seiten Thread noch nicht mal erwähnt: Man kann selbst Source-Code aus dem Jahre 1995 von Delphi 1.0 im Jahre 2010 immer nochmit Delphi 2010 kompilieren! Das Migrationstool für Visual Basic aus dem Jahre 1995 für das Jahr 2010 heisst "FDISK" (*1)

... und so definiert sich jeder seinen "technischen Standard" selbst.

Und genau das stimmt definitiv nicht.
Bis D2006 waren die Quellen verwendbar. Mit der Umstellung auf Unicode funktionierten fast alle Drittkomponenten nicht mehr.
Ich erinnere an den Thread, welche Komponente ist bereits umgestellt und welche nicht.
Wir hatten damals IBObjects als Datenzugriffsschicht verwendet. Als nach einem Jahr diese Komponenten immer noch nicht umgestellt waren, haben wir auf IBDAC gewechselt.
Es gab zwar eine Roadmap mit Terminen. Die war aber auf dem Niveau von Em - unglaubwürdig. Nach mehr als 2 Jahren ist wohl inzwischen eine Anpassung erfolgt, aber nun brauchen wir es nicht mehr.
Geschätzt mehr als 50% der Komponenten auf Torry.ru enden bei D7 und sind damit mehr oder weniger unbrauchbar.
Delphi - Superpage hat ja schon vor Jahren den Betrieb eingestellt.
Wir setzen Delphi nach wie vor ein. Grund sind ausschließlich riesige Altlasten die nicht eben mal so auf eine andere Sprache umgestellt sind.
Für Neuprojekte wird Delphi nicht mehr eingesetzt. Das hat aber die Ursache weniger in Delphi selbst, sondern in dem Umstand das wir teilweise Technologien einsetzen müssen,
die Delphi nicht beherrscht. Dazu gehört neben ASP und CF u.a. auch 64 bit.
Hier geht es um eine Bildverarbeitungssoftware für hochauflösende technische Röntgenaufnahmen.
Was wir dringend brauchen ist eigentlich eine Planungssicherheit und die ist mit der gegenwärtigen Informationspolitik von Em nicht gegeben.
Bei uns werden noch andere Nischenprodukte wie z.B. CA Objects oder Powerbuilder eingesetzt. Da sieht die Situation übrigens ähnlich aus.
Hier steht generell der Richtungsstreit gemanagte Software <-> native Software im Raum.
MS wird zwar die 32/64bit API weiter unterstützen. Wenn aber immer mehr Features nur als Net kommen, dann hat man mit nativer Software ein zusätzliches Problem.


Gruß

[himitsu]

Das liegt aber nicht am Unicode.

Wenn man überlall in den alten Codes ordentlich gearbeitet hätte (das Unicode irgendwann kommen muß, war vorher schon klar),
dann gäbe es auch fast keine Probleme. (abgesehn von einigen unnützen Stringumwandlungen, weil Delphi standardmäßig fast keine Ansifunktionen bereitstellt)

[HeikoAdams]

Zitat von hanspeter:

Bei uns werden noch andere Nischenprodukte wie z.B. CA Objects oder Powerbuilder eingesetzt.

<offtopic>Wobei PowerBuilder AFAIR noch nie wirklich native Code erzeugt hat. Die haben doch schon immer eine eigene Runtime gebraucht.</offtopic>

[Robotiker]

Zitat von hanspeter:

Hier steht generell der Richtungsstreit gemanagte Software <-> native Software im Raum.

Die beiden Welten schliessen sich aber nicht gegenseitig aus.

Wir haben damals ironischerweise den C++ Builder X benutzt. Damit haben wir von bestehenden C++ Builder Anwendungen (aus dem Bereich Industrieautomatisierung) die hardwarenahen bzw. performancekritischen Teile nach MS bzw. Intel C++ portiert. Borland hat ja sogar den Intel-Compiler mitgeliefert, damit man sehen konnte, dass der besser ist, als das eigene Produkt.

Diese Teile können heute wahlweise mit nativen (Qt) oder managed (C#, F# über einen dünnen C++/CLI Wrapper) Anwendungen verwendet werden.

Rückwirkend hat sich der "Machts gut und danke für den Fisch" Open Letter von Borland als große Hilfe erwiesen. Unsere Software ist heute modularer und leichter auf neue Plattformen anzupassen.

Grüße