Delphi am "Ende"?

[MEissing]

Zitat von Assarbad:

Zitat von MEissing:

Noch einer, der die Lizenzvereinbarungen vom MSDN nicht verstanden hat.

Wenn man hinausposaunt, sollt man auch 'was zu sagen haben...

Kommt außer dem argumentum ad hominem noch etwas?

Mitnichten hat man das OS zum Arbeiten:
Mitnichten hat man eine Wartung (ohne verlängertes, jährliches) MSDN Abo.

Was kostet eine Verlängerung von MSDN, was kostet die Wartungsverlängerung von Delphi?

http://msdn.microsoft.com/en-gb/subs.../cc150618.aspx

[Assarbad]

Zitat von MEissing:

Mitnichten hat man das OS zum Arbeiten:

Kann mich nicht entsinnen das behauptet zu haben. Es ging darum was enthalten ist.

Vielleicht, denn ich gucke mir Signaturen eher selten und dann beiläufig an, bist du ja mehr geschmeichelt wenn ich Embarcadero mit Apple vergleiche. Bei denen ist es auch so, daß ich heute ein Produkt kaufen kann und nächste Woche wird schon die nächste Produktgeneration herausgebracht, weswegen ich mir dann die Hutkrempe beiße. Genauso ging es mir mit den diversen Sonderangeboten von Embarcadero im letzten Jahr. Jedes Mal kam keinen Monat nach dem Kauf (erst 2010, dann XE).

Zitat von MEissing:

Mitnichten hat man eine Wartung (ohne verlängertes, jährliches) MSDN Abo.

Ich könnte jetzt im gleichen Format antworten wie du ... es gibt nicht nur die Vanilleversion von MSDN Pro, sondern diverse "Programme". Und meines ist nunmal zweijährig mit besagtem Preis. Es gibt auch sowas wie Leasing-Programme. Einfach mal bei dem Softwarehändler deines Vertrauens nachfragen ...

Zitat von MEissing:

Was kostet eine Verlängerung von MSDN, was kostet die Wartungsverlängerung von Delphi?

... und was ist bei Kauf der Wartung von Delphi (bzw. in meinem Fall RAD Studio) enthalten? Die nächste große Produktversion? Jupp. Produktwartung des aktuellen Produkts? Nicht wirklich.

[MEissing]

Zitat von Assarbad:

Zitat von MEissing:

Mitnichten hat man das OS zum Arbeiten:

Kann mich nicht entsinnen das behauptet zu haben. Es ging darum was enthalten ist.

Du sprachst von Entwicklertools und Betriebssystemen...

Zitat:

Vielleicht, denn ich gucke mir Signaturen eher selten und dann beiläufig an, bist du ja mehr geschmeichelt wenn ich Embarcadero mit Apple vergleiche. Bei denen ist es auch so, daß ich heute ein Produkt kaufen kann und nächste Woche wird schon die nächste Produktgeneration herausgebracht, weswegen ich mir dann die Hutkrempe beiße. Genauso ging es mir mit den diversen Sonderangeboten von Embarcadero im letzten Jahr. Jedes Mal kam keinen Monat nach dem Kauf (erst 2010, dann XE).

Jedes Jahr (seit 1995) kam ein Delphi Release auf den Markt.... in den letzten Jahren immer im Herbst. Seit 15 Jahren. Etwas verlässlicheres, absehbareres habe ich nicht in der Softwarebranche erleben dürfen. Auch ist es üblich kurz vor dem Release einer neuen Version noch Angebote für die dann auslaufende Version zu erstellen. Das gibt es überall. Nicht nur bei Software. Wir selber empfehlen (kurz vor dem Release) unseren Kunden auch evtl auf die neue Version zu warten... aber da wir im Direktverkauf häufig teuerer sind, als die Onlineshops, die nur über den Preis verkaufen, werden wir auch nicht gefragt...

Zitat:

... und was ist bei Kauf der Wartung von Delphi (bzw. in meinem Fall RAD Studio) enthalten? Die nächste große Produktversion? Jupp. Produktwartung des aktuellen Produkts? Nicht wirklich.

Du sprichst aus Erfahrung? ... ich dachte du hättest gar keine Wartung...?

[himitsu]

Zitat von MEissing:

Jedes Jahr (seit 1995) kam ein Delphi Release auf den Markt.... in den letzten Jahren immer im Herbst. Seit 15 Jahren. Etwas verlässlicheres, absehbareres habe ich nicht in der Softwarebranche erleben dürfen.

Dafür bekommt man auch schonmal den eindruck, daß die Software mit Fremdkomponenten aufgemotzt werden muß, weil nicht wirklich was Neues geboten werden kann.

Ich erinnere gern mal an die XE-Diskusionen.
Ja, ein bissl was hat sich schon getan, aber das was vorher groß versprochen wurde (64 Bit und Cross-Compiling) war nicht enthalten.

Zitat von MEissing:

Auch ist es üblich kurz vor dem Release einer neuen Version noch Angebote für die dann auslaufende Version zu erstellen.

Also, ihr empfehlt lieber die alte Version zu kaufen, anstatt noch 'nen Monat zu warten und dann das Neue zu nehmen?

Zitat von Assarbad:

Zumindest in kernel32.dll auf Windows 7 (als Stichprobe) ist dies noch nicht der Fall. Aber überfällig wäre es allemal. Denke aber, daß MS das aufgrund von Rückwärtskompatibilität nicht machen kann.

Ja, es gibt einige "modernere" APIs, welche nur als Wide-Version vorhanden sind,
aber von den meisten alten APIs existieren seit NT immernoch Ansi-Wrapper, welche den Aufruf dann an die Unicode-Version weiterreichen.
Und ich denke mal nicht, daß die soooo schnell abgeschafft werden, jedenfalls nicht slange Windows die API nicht wieder grundlegend ändert, so wie zu 9x>NT-Zeiten.
Genauso wird das mit der 32 Bit-API sein.

OK, irgendwann wird MS vermutlich dann doch mal die 32-Bit-API abschaffen, aber wenn man bedenkt, daß 16 Bit erst in Win7 entsorgt wurde, dann haben wir wohl noch etwas Zeit.
Auch wenn der 64-Bit-Compiler gefallen würde, auf welchen wir schon seit Jahren warten (für 2008 war er ja mal angekündigt)

[holliesoft]

Zitat von himitsu:

OK, irgendwann wird MS vermutlich dann doch mal die 32-Bit-API abschaffen, aber wenn man bedenkt, daß 16 Bit erst in Win7 entsorgt wurde, dann haben wir wohl noch etwas Zeit.

Microsoft hat ja gerade erst angekündigt, dass die nächste Windows-Version auch ARM-Prozessoren unterstützen wird. Das ist denke ich mal der Anfang vom Ende von Win32 der nativen Windows-Entwicklung. Sicher, es wird nicht sofort aussterben, aber spätestens dann wird Microsoft sagen: Leute, entwickelt für .net. Denn da muss eigentlich nur Microsoft die entsprechende Runtime für die neuen Prozessoren anpassen.

[himitsu]

Für hardwarenahe Programmierung ist aber dennoch ein entsprechendes natives Programm oftmals besser geeignet.

Dort bezieht man sich eh nur auf eine Bestimmte Hardwareumgebung, weswegen da soeine Cross-Plattform-Fähigkeit, wie bei .Net, nicht benötigt wird.

[Sherlock]

Abschließend:
Delphi ist genausowenig am Ende wie Cobol, Algol oder meinetwegen auch Lisp.

Sherlock

[mkinzler]

Zitat von holliesoft:

Zitat von himitsu:

OK, irgendwann wird MS vermutlich dann doch mal die 32-Bit-API abschaffen, aber wenn man bedenkt, daß 16 Bit erst in Win7 entsorgt wurde, dann haben wir wohl noch etwas Zeit.

Microsoft hat ja gerade erst angekündigt, dass die nächste Windows-Version auch ARM-Prozessoren unterstützen wird. Das ist denke ich mal der Anfang vom Ende von Win32 der nativen Windows-Entwicklung. Sicher, es wird nicht sofort aussterben, aber spätestens dann wird Microsoft sagen: Leute, entwickelt für .net. Denn da muss eigentlich nur Microsoft die entsprechende Runtime für die neuen Prozessoren anpassen.

Diese Ankündigung hat aber nichts mit .Net zu tun; Windows8 wird nativ auf den Plattformen laufen.

[Namenloser]

Zitat von mkinzler:

Diese Ankündigung hat aber nichts mit .Net zu tun; Windows8 wird nativ auf den Plattformen laufen.

Windows selbst schon, aber Fremdprogramme nicht, wenn sie nicht für die entsprechende Plattform neu kompiliert werden.

[Assarbad]

Zitat von holliesoft:

Microsoft hat ja gerade erst angekündigt, dass die nächste Windows-Version auch ARM-Prozessoren unterstützen wird. Das ist denke ich mal der Anfang vom Ende von Win32 der nativen Windows-Entwicklung.

Win32 ist eine API (wobei die NT-APIs sozusagen eingemeindet wurden, was man sehr gut an diversen Inkonsistenzen sehen kann) und hat mit der Bittigkeit reineweg garnix zu tun. Nativ ist so eine Sache, wenn sich das auf Win32 bezieht, hast du vermutlich recht. Ansonsten kann es sich auch noch auf die "NT Native API" beziehen (sozusagen das Interface zum Kernel und teils im Kernel) und sicherlich auf die Architektur ...

In jedem Fall bezieht sich nativ immer auf irgendwas ...

Zitat von holliesoft:

Sicher, es wird nicht sofort aussterben, aber spätestens dann wird Microsoft sagen: Leute, entwickelt für .net. Denn da muss eigentlich nur Microsoft die entsprechende Runtime für die neuen Prozessoren anpassen.

Steht zu befürchten.

Zitat von himitsu:

Für hardwarenahe Programmierung ist aber dennoch ein entsprechendes natives Programm oftmals besser geeignet.

Worauf spielst du an? Hardwarenah sind eigentlich nur Treiber und die sind immer auf die jeweilige Architektur ausgerichtet (zumindest noch).