Was bedeutet "Support & Maintenance for Delphi" bei Emba?

[mkinzler]

Zitat:

...sollte ein Versionswechsel nur noch ein Sonntagsspaziergang sein.

Wenn nicht gerade eine Unicode-Umstellung oder der wechsel der Busbreite ansteht.
Btw. sollten die Neuerungen des nextgen compilers auch für die bestehenden Plattformen kommen, käme dies eher einer Mount-Everest-Besteigung ohne Sauerstoff gleich. ;):stupid:

[jaenicke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1226956)

Das kann ich so nicht nachvollziehen. Probleme machen schon mal größere Sprünge, aber von einer Version auf die nächste ist in den meisten Fällen kaum mehr als Öffnen und compilieren.

Das war seit ein paar Versionen so, ist aber leider seit XE3 nicht mehr so.
Fehler wie diese machen leider immer mehr IFDEFs, zusätzliche Casts und Änderungen nötig...
http://qc.embarcadero.com/wc/qcmain.aspx?d=115916

Nicht dass ich mit XE4 unglücklich wäre, aber so etwas nervt leider in letzter Zeit öfter...

[stahli]

Ich bin auch überhaupt nicht gegen (auch gravierende) Neuerungen, selbst wenn ein gewisser Bruch zu alten Quellen entsteht.
Das Problem ist nur, dass Emba selbst grundlegende Qualitätsansprüche nicht einhält und man einen Vertrauensschutz auf getroffene Aussagen vergessen kann.

Bezüglich schnelle Upgrades: Es gibt sicherlich auch viele Delphi-Nutzer, die kein großes Budget für ständige Upgrades haben (kleine Selbständige oder Hobby-Programmierer). Die scheinen immer mehr vergessen zu werden.

[Codehunter]

Zitat:

Zitat von stahli (Beitrag 1226967)

Bezüglich schnelle Upgrades: Es gibt sicherlich auch viele Delphi-Nutzer, die kein großes Budget für ständige Upgrades haben (kleine Selbständige oder Hobby-Programmierer). Die scheinen immer mehr vergessen zu werden.

Das ist ein ganz wichtiger Punkt. Die Community ist doch praktisch tot. Man schaue nur bei torry.net was da noch an Community-NonCommercial-Stuff kommt ist verschwindend gering. Auch hier in der DP sind fast nur noch Berufsdelphianer unterwegs und ein paar Schüler, deren Schulen mit veralteten Computerkabinetten und Delphi 4 unterwegs sind.

Wo ich bei der ständigen Migriererei abwinke ist der ganze Rattenschwanz an Upgrades, die das jedesmal noch mit sich bringt. Mit dem IDE-Upgrade ist es ja nicht getan, man muss noch zicherlei 3rd-Party-Libs upgraden. Da kommen auch noch mal ordentliche Sümmchen zusammen. Bei mir z.B. TMS Component Pack und neuerdings Unidac. Alles schöne Komponenten, keine Frage. Aber will man die bei IDE-Upgrades dann selber patchen? Unmöglich.

Die immer größer werdenden IFDEF-Müllhalden werden meiner Ansicht nach völlig zu Recht beklagt.

In der Konsequenz mache ich wahrscheinlich weiterhin nur sehr große Sprünge bei den IDE-Versionen. Meistens dann wenn große Altprojekte final abgeschlossen sind und neuere Projekte definitiv nicht auf einer 10 Jahre alten IDE begonnen werden. Aber das handhabt jeder anders, ist eben eine Philosophiefrage.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1226980)

Bei mir z.B. TMS Component Pack und neuerdings Unidac.

Das ist einer der Gründe weshalb wir FireDAC benutzen, wir müssen nicht auf ein Update dafür warten und auch nicht dafür zahlen, da es schon bei Delphi dabei ist. Die steigenden Abhängigkeiten haben wir natürlich auch, kaufen aber immer mit Quelltext und hatten bisher auch keine Probleme die Quelltexte selbst auf z.B. XE4 anzupassen bis ein Update da ist.

Zitat:

Zitat von Codehunter (Beitrag 1226980)

Die immer größer werdenden IFDEF-Müllhalden werden meiner Ansicht nach völlig zu Recht beklagt.

Wir ziehen alte Projekte nun immer auf XE4 hoch bevor wir daran Änderungen machen. Auf die Weise brauchen wir in unseren gemeinsamen Units keine großen IFDEFs, auch wenn es manchmal ein wenig Aufwand ist, die alten Projekte von Delphi 5 oder 2006 zu konvertieren. In der Regel klappt das aber gut und schnell, wir wissen ja mittlerweile was wir anpassen und worauf wir achten müssen.

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1227018)

Wir ziehen alte Projekte nun immer auf XE4 hoch bevor wir daran Änderungen machen. Auf die Weise brauchen wir in unseren gemeinsamen Units keine großen IFDEFs, auch wenn es manchmal ein wenig Aufwand ist, die alten Projekte von Delphi 5 oder 2006 zu konvertieren. In der Regel klappt das aber gut und schnell, wir wissen ja mittlerweile was wir anpassen und worauf wir achten müssen.

Ich denke das ist stark fallabhängig. Wenn man sehr auf das Budget achten muss und z.B. das simple Einfügen eines zusätzlichen Close-Buttons irgendwo plötzlich 200 Mannstunden kosten soll, dann ist das kaum zu vermitteln. Sieht eben nach außen hin so aus als wollte man Zeit schinden. Für so was gibts weiterhin ein D7 irgendwo.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1227092)

Ich denke das ist stark fallabhängig. Wenn man sehr auf das Budget achten muss und z.B. das simple Einfügen eines zusätzlichen Close-Buttons irgendwo plötzlich 200 Mannstunden kosten soll, dann ist das kaum zu vermitteln.

Wenn es so lange dauern würde, würden wir das auch nicht machen. Selbst bei unserem größten Projekt sind wir für die reine Konvertierung nicht auf so viele Arbeitsstunden gekommen. Ein paar kleinere Probleme kamen zwar nach, aber dann war das auch erledigt.
Die Projekte, die ich jetzt bei uns meine, sind aber viel kleiner. Deshalb geht es schneller diese zu konvertieren und für Änderungen komfortabel mit XE4 arbeiten zu können als die alten Delphiversionen zu nutzen und deshalb Zeit zu verschwenden...

Dass das fallabhängig ist, ist klar. Und vor allem kommt es sehr auf die Codequalität an. Wer problematische Befehle wie with einsetzt oder z.B. nicht explizit PWideChar oder PAnsiChar bei Schnittstellen usw., der hat viel größere Probleme als wenn man sauberen Code geschrieben hat.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1227116)

Und vor allem kommt es sehr auf die Codequalität an. Wer problematische Befehle wie with einsetzt oder z.B. nicht explizit PWideChar oder PAnsiChar bei Schnittstellen usw., der hat viel größere Probleme als wenn man sauberen Code geschrieben hat.

Well said :thumb:

[DeddyH]

Natürlich hat jeder Programmierer zu Delphi 5-Zeiten bereits die Unicode-Problematik beherzigt, da ja klar war, dass Delphi irgendwann einmal komplett von Ansi zu Unicode umschwenkt. Und Weihnachten folgt direkt auf Ostern, genau wie die Erde eine Scheibe ist :roll:

[Sherlock]

Ganz abgesehen davon, daß jedem immer schon klar war, daß auch mal eben sowas wie dieses hier:
D2007-Messages.pas:

Delphi-Quellcode:

TMessage = packed record
    Msg: Cardinal;
    case Integer of
      0: (
        WParam: Longint;
        LParam: Longint;
        Result: Longint);

Jederzeit zu
D-XE2-Winapi.Messages.pas:

Delphi-Quellcode:

  TMessage = record
    Msg: Cardinal;
    case Integer of
      0: (
        WParam: WPARAM;     // Das ist natürlich in Winapi.Windows deklariert als:   WPARAM = UINT_PTR;
        LParam: LPARAM;
        Result: LRESULT);

werden kann. Was unter Umständen zu einem hohen Grad an Verwirrung führen kann. :D
Aber damit muss man eben von Release zu Release rechnen, weshalb es sich schon aufgrund der eingesparten Mannjahre lohnt im Zyklus wenigstens ein Release auszulassen.

Sherlock

[jaenicke]

Zitat:

Zitat von DeddyH (Beitrag 1227139)

Natürlich hat jeder Programmierer zu Delphi 5-Zeiten bereits die Unicode-Problematik beherzigt, da ja klar war, dass Delphi irgendwann einmal komplett von Ansi zu Unicode umschwenkt.

Auch da gab es schon die konkreten API-Funktionen usw., deshalb habe ich auch schon lange vor Delphi 2009 entweder nur die Metatypen benutzt oder nur die konkreten. Genauso bei Integer oder Real, wo es relevant sein könnte habe ich auch immer (also nach ein paar Jahren lernen halt) LongInt usw. benutzt.

[Codehunter]

Meistens ist es ja so, dass man mit dem selbst produzierten Code am wenigsten Probleme hat. Zum Teil ging man ja dazu über, eigene Basistypen zu deklarieren, sodass man später nur an einer einzigen Stelle was ändern musste.

ABER: Bei nicht wenigen Projekten hat man 3rd-Party-Komponenten eingesetzt. Die waren für die damalige Zeit sehr mächtig und haben einem viel Arbeit abgenommen (wie z.B. Unidac, Firedac etc. heute) also wurden sie gern und oft verwendet.

Das Rad der Zeit drehte sich weiter, aber es fehlte stehts an den (seitens Geschäftsführung hier oder Kunde da) eingeplanten Migrationspfaden. Also blieb für die Altprojekte die Zeit quasi stehen. Irgendwann kommt man an den Punkt, da kann man einfach nicht mehr weiter machen auf der Basis und dann ist der Berg an notwendigen Anpassungen natürlich riesengroß.

Ich sag nur: Altprojekt läuft noch auf BDE, Kunde verlangt jetzt native 64-Bit-Anwendungen. *PLONK* 3rd-Party-Komponenten haben Design- und Runtime-Packages nicht sauber getrennt und desgnide im Runtime-Package verwendet. *PLONK*

So vergeudet man dann später die einstmals eingesparte Zeit wieder. Traurig aber wahr. Dann sind immer die Programmierer doof und unfähig. Fragt man aber, wer denn eigentlich aus Kostengründen kein Delphi 2009 kaufen wollte ist plötzlich Ruhe im Chefbüro.

Da kann froh sein wer selbstständiger Programmierer ist und in der Lage ist die Upgrades reinzuwirtschaften.

[Furtbichler]

Ich habe eine kommerzielle Software, die unter D3 entwickelt und bis D6 portiert wurde. Danach hat der Kunde die Portierungskosten nicht mehr übernommen. Das Teil läuft heute noch, D6 ist bei mir immer noch installiert. Bis ich D6 nicht mehr verwenden kann, weil Windows entweder eingestellt oder inkompatibel ist, vergehen noch Jahre. Aber selbst wenn, kann man einen Entwicklungs-PC oder eine VM mit der alten IDE so belassen.

Wieso man auf Deibel komm raus unbedingt *alle* seine Projekte upgraden muss, ist mir ein Rätsel. Natürlich ist es besser, hübscher, einfacher, aber wenn es nicht bezahlt wird... Mein D6 läuft sehr gut, die 3rd-Party-Komponenten (ausgewählte) sind auf dem aktuellsten Stand, und einige Komponenten sind im Laufe der Zeit eben rausgeflogen (meist Hobby-Komponenten). Also... WTF. Dann habe ich für dieses Projekt eben keine tolle (verbuggte) Super-IDE-Unterstützung. Na und? Die Delphi-IDE ist eh suboptimal.

Ich mach das Gleiche übrigens mit VS-Projekten. Für einen Kunden wurde das unter .NET 2.0 und VS2003 entwickelt. Wozu das Projekt portieren?

Wenn ich mal meinen Betrieb ruinieren möchte, würde ich Kundenprojekte ungefragt portieren. Hätte ich damals Unittests geschrieben, wäre das nicht so wild. Hab ich aber nicht, denn die waren damals noch gar nicht erfunden.

Und das es Leute gibt, die das lustige Kinderspiel 'Hinterher tue ich einfach so, als ob ich von vorneherein daran gedacht hätte' spielen, ist Teil einer pluralistischen Gesellschaft.

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1227357)

Wenn ich mal meinen Betrieb ruinieren möchte, würde ich Kundenprojekte ungefragt portieren.

Das ist bei dir auch etwas anderes. Bei uns gehören die Tools zum Gesamtpaket unserer Kassensoftware und werden meistens nicht nur bei einem Kunden eingesetzt, sondern sind allgemein gehalten.
Dass das bei reinen Kundenprojekten auf Anforderung etwas anderes ist, ist klar.

Zitat:

Zitat von Furtbichler (Beitrag 1227357)

Dann habe ich für dieses Projekt eben keine tolle (verbuggte) Super-IDE-Unterstützung. Na und? Die Delphi-IDE ist eh suboptimal.

Bei XE4 kann ich mich nicht beschweren. Probleme machen nur noch die wenigen Riesenunits mit mehr als 10k Zeilen :kotz:, die noch übrig geblieben sind...
Da funktioniert dann Error Insight nicht richtig und der Editor wird etwas langsamer.
In allen sauberen Units nach dem Refactoring oder gleich Umschreiben z.B. mit Generics funktioniert Error Insight bei mir aber nun korrekt und schnell, von ein paar Sperenzchen mit meiner Trickserei mit einem generischen Pointer mal abgesehen.

Und solche Sachen wie in Delphi 7... ich wollte gestern eigentlich nur für einen Forenpost im DF einen Assembler-Codeabschnitt kopieren... naja... wurde leider noch nicht so richtig unterstützt. Man konnte nur 30 Zeilen ab einer bestimmten kopieren, wobei es geflackert hat als würde der Editor dabei jede Zeile der Reihe nach markieren und kopieren :shock:. Markieren? Fehlanzeige.
Aber das ist ja nur das was mich aktuell genervt hat, der Rest würde Seiten füllen.

Gerade bei den ganzen Änderungen und Erweiterungen, die es in den letzten Jahren gab, macht daher finde ich ein Wartungsvertrag Sinn. Und standardmäßige Projektupgrades machen z.B. Sinn, wenn es sich um Projekte handelt, die standardmäßig zur Verfügung stehen, also zu erwarten ist, dass diese einmal z.B. an eine neue Softwarearchitektur angepasst werden müssen.

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1227362)

ich wollte gestern eigentlich nur für einen Forenpost im DF einen Assembler-Codeabschnitt kopieren... naja... wurde leider noch nicht so richtig unterstützt. Man konnte nur 30 Zeilen ab einer bestimmten kopieren, wobei es geflackert hat als würde der Editor dabei jede Zeile der Reihe nach markieren und kopieren :shock:. Markieren? Fehlanzeige.

Huh? Ich habe ja bekanntermaßen 10 Jahre mit D7 pro gearbeitet aber ein derartiges Problem ist mir dabei nie unter gekommen. Ob da evtl. ein Addon wie GExperts oder CnPack Probleme macht?

[Union]

Das hat mich aber auch schon geärgert bei D7. Ich hatte schon oft im Rahmen von Extremst-Optimierungen die Notwendigkeit, den bestehenden asm-Code beim Debuggen/Profilen zu kopieren um evtl. schnellere Varianten für Sonderfälle zu erstelllen. Das musste ich dann abtippen, was bei längerem asm ekelhaft werden kann.

[Patito]

?!

Also ich habe hier im D7 im RechtsClick-Menü ein "Kopiere ASM Code" das funktioniert (kommt vom CnPack).

[jaenicke]

Zitat:

Zitat von Patito (Beitrag 1227921)

Also ich habe hier im D7 im RechtsClick-Menü ein "Kopiere ASM Code" das funktioniert (kommt vom CnPack).

Mit Markierung mehrerer Zeilen?

Zitat:

Zitat von Codehunter (Beitrag 1227907)

Huh? Ich habe ja bekanntermaßen 10 Jahre mit D7 pro gearbeitet aber ein derartiges Problem ist mir dabei nie unter gekommen. Ob da evtl. ein Addon wie GExperts oder CnPack Probleme macht?

Standardinstallation von Delphi 7 Personal. Mag an der Edition liegen, das kann ich nicht beurteilen. Ich hätte jetzt aber nicht erwartet, dass man das dann in der Form (die einfach nach "kann die IDE nicht" aussieht) macht.

Wie sieht das denn bei dir aus, wenn du in der CPU Ansicht mehrere Zeilen markierst und das Kontextmenü aufrufst?

[Union]

Also bei Delphi 7 Enterprise kann man im CPU-Fenster nichts markieren oder kopieren.

[jaenicke]

Hmm, vielleicht ist da doch das CnPack bei mir drin und das macht das. :?
Das erklärt dann auch die Umsetzung.

Naja, damals beim Lernen von Delphi habe ich das ja nie gebraucht und danach gab es ja schon bessere Delphiversionen, deshalb wusste ich das gar nicht, dass das da nicht ging.

[Codehunter]

Hahaha... Du hattest ja nicht gesagt dass du im CPU-Fenster was markieren und kopieren willst *gg*

Ich hab mich echt gefragt, warum man Inline-Assembler nicht genauso wie alles andere im Code-Editor kopieren können sollte *lol*

[jaenicke]

Die anderen haben es ja verstanden, aber ich habe gerade noch einmal nachgeschaut, du hast Recht, ich hatte es nicht explizit dazu geschrieben. :oops:

[Codehunter]

Kein Problem :-) Ich hab wahrscheinlich genauso zu schnell gelesen wie du geschrieben. ;-)