Weshalb ein WP8 Update für WP7 Hardware kontraproduktiv wäre

Ich würde im Moment jedem (guten) Bekannten raten zu warten. [_tw]

Diesbezüglich sind sich hier offenbar alle einig. Ich vermute, dass Weltweit eine ganze Menge so denkt. Aufgrund ihrer Empfehlungen halten Diese eine noch grössere Menschenmasse in "Wartestellung" zurück. Ich bin sehr gespannt, wie sich der Nokia Aktienkurs unter WP8 entwickelt…

Hatte neulich das gleiche Problem. [_tw]

An diese Empfehlungs-Problematik sollten wir uns vermutlich gewöhnen. WP7 war nun zwei Jahre an den S2 SoC „gebunden“. Mit dem S4 SoC, der sich WP8 zunutze macht, wird das gleich funktionieren… beim darauf folgenden SoC auch wieder… und so weiter und so fort. Dies ist WP’s zweijährlicher Technologie-Sprung. Nur wenige Wochen vor dem WP8-RTM will ich keinem Kollegen ein Smartphone mit Hardware aus dem Jahr 2009 empfehlen (obwohl mir das Betriebssystem wesentlich wichtiger erscheint als die Hardware). Diese Empfehlungs-Problematik existiert also völlig unabhängig davon, ob WP8 für WP7 Hardware erscheint oder nicht.

Noch ein Punkt zum ursprünglichen Thema:

Nebst Grafikprozessoren entwickelt die Firma nVidia auch SoCs für Smartphones. Diese werden unter dem Namen „Tegra“ vermarktet. Gleichzeitig unterstützt nVidia die Entwicklung von Spielen. Damit wollen Sie zumindest einige Spiele Tegra-Spezifisch optimieren. Diese Spiele findet man auf der Website TegraZone. Inzwischen sind es etwas über 40 Titel. Eines davon ist Sonic4E2. Scheinbar ist Sonic4E2 auf einem Tegra3 SoC genau wie das Original auf der Sega Konsole. Ohne Tegra3 SoC erhält man eine vom Original abweichende, einfachere Version mit matschigeren Texturen und ohne Lichteffekte. Ich bin über eine Pressemeldung bei Anandtech darauf aufmerksam geworden.

Meine Beiträge waren bisher eher theoretischer Natur und nicht für alle Nachvollziehbar. Mit diesem Beispiel wird das Thema zwar nicht einfacher, aber zumindest sieht man hier die praktischen Auswirkungen der hier besprochenen Theorie:

Diese Verbesserungen werden kaum durch die „bessere“ Tegra3 Hardware ermöglicht. Das Gleiche wäre ebenso auf allen modernen Hardware Plattformen der Konkurrenz möglich. Der Unterschied ist, dass die Entwickler hier gleich wie bei einer Konsole (standardisierter SoC und Grafik-Treiber der nVidia) vorgehen können, was so nicht einmal unter iOS funktioniert, da man dort ältere Hardware (3GS) mitberücksichtigen muss. Die Kommentatoren bei Anandtech kommen zur selben Schlussfolgerung, wobei auch vom „Konsolenansatz“ die Rede ist.

Microsoft will für alle WP Geräte (und sämtlichen Apps die darauf laufen) ein derartiges Vorgehen ermöglichen, wie das nVidia zurzeit bei Tegra3 kann…

O.K., wer Hardcore-Spiele auf dem Handy spielt - ansonsten bekommt man aber ein preiswertes ausgereiftes bedienungsfreundlich durchdachtes und sicheres Smartphone bei WP7.5 und hat dann Geld für den nächsten Wechsel gespart (Preisunterschied bis zu 300%!).

@docsp
Bezüglich der Entscheidung "Kaufen oder Warten" will ich mich _tw anschliessen. Die Anforderungen können in jedem Einzelfall derart unterschiedlich sein, dass es kaum ein generelles "richtig" oder "falsch" gibt. Jetzt noch ein WP7.5 Gerät zu kaufen kann durchaus Sinnvoll sein... oder auch nicht.

Im Konsumerbereich trifft man öfters auf die Neigung zu Abwartungshaltung... das ändert sich nur wenn ganz konkrete Anforderungen vorhanden sind (wie Du sie zu haben scheinst: Sicherheit, Preiswert, usw).

Richtig, man sollte sich von technischen Spezifikationen nur dann das Geld aus der Tasche ziehen lassen wenn man sie wirklich braucht - jedenfalls nicht nur zum Angeben.

@Collin5 und die, die eine Antwort wissen:
Im Netz finde ich leider keine vernünftige Antwort auf meine Frage und ich denke vielleicht finde ich sie hier, da das Thema sehr ähnlich ist:
Benutzen Spiele die eine sehr gute Graphik haben wie z.B. Battlefield 3, MW3 oder ähnliches, die volle Leistung eines Rechners (gute CPU und Graphikkarte vorausgesetzt)? Mit voller Leistung meine ich natürlich nicht nur die Geschwindigkeit. Könnten die Spiele unter ein Konsolensystem besser aussehen? Und wie sieht es mit Programmen aus (Z.B. Photoshop)? Immerhin ist auch an einem PC verschiedene Hardware im Einsatz. Oder funktioniert das unter Windows ganz anders als eine Konsole/Smartphone?

@docsp und Collin5
Ich könnte gut und gerne auf die neue starke Rechen- und Grafikpower verzichten. Deswegen warte ich persönlich nicht auf ein WP8 Gerät. Leider werde ich wohl dazu gedrängt, wenn der Support und die Weiterentwicklung von WP7 Apps gestoppt bzw. runtergefahren wird. Das ist der eigentliche Grund für sehr viele umzusteigen denke ich.

@Taxidroid
Lese dir mal den ersten Teil dieses Threads hier durch und gerade die Beiträge von Collin5 müssten deine Frage hinreichend beantworten.

Selbst die vielen Apps die ich auf dem Handy habe nutze ich zumeist nicht - geschweige denn , dass ich alle Windows 7.5 Apps überhaupt kenne. Ansonsten reizt es schon bei einem Betriebssystemwechsel umzusteigen . Wer aber nur ein Drittel (!) zahlen will bekommt mit WP 7.5 Geräten sichere , moderne und ausgereifte Handys.

Mit anderen Worten WP7.x wird genauso ein Dead End ohne Zukunft sein, wie vorher WM. [_tm]

WP8, WP9 und WP10 werden auch „dead ends“ sein, ich möchte diese Aussage aber etwas relativieren. Wo WM wirklich nur eine Sackgasse war, ist dies WP jeweils nur teilweise. Beispiele:

• Immer wichtiger werden die Online-Dienste. Im Fall von WP ist dies zurzeit das bescheidene und chaotische Windows Live (WL). WL soll in den nächsten zwölf Monaten grundlegend überarbeitet und verbessert werden, was auch allen WP7 Anwendern zugutekommt… kein „dead end“.
• Da WP7 Apps auch unter WP8 laufen, kann jeder WP7 Besitzer seine App-Investitionen bei einem allfälligen Upgrade weiterverwenden…. kein „dead end“.
• Aus Sicht des WP7 App Entwicklers ist jeder neue WP8 Käufer ein potentieller Neukunde, ohne dass er dafür etwas tun muss. Für ihn wächst der Markt einfach weiter. Daher ist der Übergang vom WP7 zum WP8 Markt aus Sicht des Entwicklers ein fliessender… kein „dead end“.

Allerdings wird das Wachstum des WP7 App Markts irgendwann markant abflachen und über kurz oder lang (wie lang?) zum Stillstand kommen… das ist ein „dead end“

Bei WP8, WP9 und WP10 kommen wir aber auch irgendwann ans Ende. Es fragt sich jeweils nur wie markant und über welchen Zeitraum die App Entwicklung für eine WP Generation zum Stillstand kommt. Sofern sich WP8 einen vernünftigen Marktanteil sichert, wird keiner eine Unterversorgung an neuen Apps befürchten müssen (im Gegensatz zu heute).

@Rosetti

Leider werde ich wohl dazu gedrängt, wenn der Support und die Weiterentwicklung von WP7 Apps gestoppt bzw. runtergefahren wird.

Ja, Du wirst dazu gedrängt. Es fragt sich nur über welchen Zeitraum. Zumindest die finanziell motivierten Entwickler, deren Apps nicht WP8 Hardware voraussetzen, werden vorerst bei WP7 bleiben. Einige meinen, dass derartige App Entwickler inexistent sind. In dem Fall, wäre es tatsächlich schnell zu Ende mit der WP7 App Entwicklung. Andernfalls könnte es schon etwas länger dauern.

@Taxidroid

Benutzen Spiele die eine sehr gute Graphik haben wie z.B. Battlefield 3, MW3 oder ähnliches, die volle Leistung eines Rechners

Nein.

Vorerst gehe ich davon aus, dass mit „Rechner“ ein Intel/Windows PC gemeint ist. Alle nachfolgenden Aussagen beschränken sich auf PC, Konsolen und Smartphones.

Es gibt verschiedene Gründe, weshalb die potentielle Leistung eines PCs bei solchen Spielen nie ganz ausgereizt wird. Ich zähle nur drei auf, aber es gibt weitere:

1) Die theoretisch höchstmögliche Leistung auszuschöpfen ist unerwünscht.

Bei der Spielentwicklung wird der Performance-Optimierung oftmals einen höheren Stellenwert beigemessen als andernorts. Dennoch führt die Komplexität der Materie häufig dazu, dass der Hardware nur in den seltensten Fällen der effizienteste Lösungsweg „beigebracht“ werden kann. Software Entwickler sind eben auch nur Menschen, und arbeiten (wie alle anderen) auch unter Zeitdruck. Meistens geht es „nur“ darum der Hardware den bestmöglichen Lösungsansatz „beizubringen“, welcher noch mit zumutbarem/finanzierbarem Aufwand entwickelt werden kann. Dadurch wird die Lücke zwischen theoretisch erzielbarer und tatsächlich erreichter Leistung grösser. Diese Lücke ist oftmals beachtlich (da tiefere Entwicklungskosten wichtiger sind als schnellstmöglich laufende Spiele).

2) PC Hardware ist häufig moderner, als das was die Spiele auszunutzen im Stande sind.

Der wichtigste Grund hierfür ist, dass PC Spiele weiterhin mit DirectX9 GPU ( 2004 ) und üblicherweise mit Intel Core 2 CPU ( 2007 ) kompatibel sein müssen. Neuere Befehlssätze bei CPU und GPU bleiben daher ungenutzt. Viele Spiele behaupten DirectX11 zu unterstützen, tun dies jedoch nur in höchst eingeschränktem Umfang, d.h. nur punktuell (gleich wie bei den Android Datenblätter, geht es hier eher um Marketing als tatsächliche „Features“). Die von BF3 verwendete Frostbyte Engine ist eine seltene, auf DirectX10.1 ( 2008 ) basierende, Ausnahme.

Sämtliche Fähigkeiten (oder Befehlssätze) der vorhandenen Hardware ausreizen ist den Entwicklern nur dann möglich, wenn die Hardwarekonfiguration unveränderlich und genau festgelegt ist. Wie bei den Konsolen.

3) In der Praxis gibt es immer irgendwelche Komponenten die unterbeansprucht bleiben.

Diesen Aspekt habe ich bereits in vorhergehenden Beiträgen zu erklären versucht, aber ich wage einen Weiteren.

Theoretisch ist die „volle“ Leistung eines Rechners erst dann ausgeschöpft, wenn jede eigenständig rechnende Komponente stets zu 100% ausgelastet wird. Jeder einzelne CPU Kern ist eine eigenständig rechnende Komponente. Bei Quad SLI haben wir vier eigenständig rechnende Komponenten. Sogar der DSP des Audioprozessors ist eine eigenständig rechnende Komponente.

Tatsächlich ist es nun so, dass es keine einzige, vom Menschen interaktiv bediente Software gibt (egal ob Spiel oder nicht), welche jede rechnende Komponente des Hostsystems (egal ob PC, Konsole oder Smartphone) stets zu 100% auslastet.

Typischerweise gibt es immer eine Komponente im Gesamtsystem, welche die schwächste ist. Diese ist der „Flaschenhals“. Wer Flaschenhals ist bestimmt die Software. Bei Starcraft ist dies üblicherweise die CPU. Bei BF3 ist es meistens die GPU. Wer Flaschenhals ist kann sich aber auch von einem Moment auf den Nächsten ändern.

Wenn die CPU bereit ist, der GPU die nächste BF3 Szene zu beschreiben, aber die GPU noch mit der Berechnung der vorhergehenden beschäftigt ist, bleibt der CPU nichts anders übrig als Däumchen zu drehen. Während dieser Zeit ist die CPU unter- oder unbeansprucht.

Derartige Unterbeanspruchungen gibt es IMMER! Es fragt sich nur wie lange eine Komponente Däumchen drehen muss. Bestenfalls ist sämtliche Rechenbelastung so auf allen verfügbaren Komponenten verteilt, dass keine Komponente zu keinem Zeitpunkt und unter keinen Umständen allzu lange auf eine Andere warten muss. Schon nur dies ist recht herausfordernd. Berücksichtigt man nun zusätzlich, dass die gleiche Software sowohl auf zwei Komponenten Systeme (1 CPU + 1 GPU) als auch auf acht Komponenten Systeme laufen muss (4 CPU + 4 GPU), und diese Komponenten weit auseinander liegende Leistungsprofile aufweisen können, scheint es auf einmal verständlich, dass eine Optimale Lösung dieser Aufgabe fast unmöglich ist.... wie viele Komponenten wie oft und wie lange Däumchen drehen ist oftmals Glückssache...

Die optimale Auslastung aller Komponenten gelingt den Entwicklern dann am besten, wenn die Hardwarekonfiguration unveränderlich und genau festgelegt ist. Wie bei den Konsolen.

Und wie sieht es mit Programmen aus (Z.B. Photoshop)?

Derartige Programme verbringen 99% ihrer Laufzeit damit, auf Eingaben des Anwenders zu warten. Wenn ein Programm grösstenteils nichts tut, lässt sie sich schwerlich durch mehr Rechenleistung oder durch effizientere Ausnützung der vorhandenen Rechenleistung verbessern.

Vielen Dank für die ausführliche und informative Antwort.

Zitat von Collin5

WP8, WP9 und WP10 werden auch „dead ends“ sein, ich möchte diese Aussage aber etwas relativieren. Wo WM wirklich nur eine Sackgasse war, ist dies WP jeweils nur teilweise. Beispiele:

Du hast meinen Satz mit dem "dead end" leider aus seinem Zusammenhang gerissen und damit wird nicht mehr klar, worauf ich mich mit dem "dead end" eigentlich bezogen habe. Nämlich nur darauf, welche Apps man für alte WP7-Geräte in Zukunft noch erwarten kann und wie lange es Support für alte gibt, wenn WP8 erscheint und ob man sich dann jetzt noch ein neues WP7-Telefon holen sollte (wenn es nicht so spottbillig ist, dass es eh egal ist).

Der Zusammenhang war folgender:

Zitat von tw_

Alle bisherigen WP Apps sind in Silverlight oder XNA entwickelt. Beides hat offensichtlich keine Zukunft. Die Zukunft wird WinRT sein und ich gehe mal davon aus, dass sich zumindest große Teile des Codes zwischen Windows RT (das ist Windows 8 auf ARM) und WP8 austauschen lassen werden.

Die Apps-Entwickler würden vielleicht noch ab und zu Patches liefern für die Silverlight-basierten Apps. Aber letztlich müssen sie auf WinRT umschwenken, weil das auch auf Windows RT Tablets nutzbar ist und das die Zukunft laut MS ist. Mit anderen Worten WP7.x wird genauso ein Dead End ohne Zukunft sein, wie vorher WM. Neue Versionen für Apps wird es dann nur noch für WP8 geben.

Ein WP9 und WP10 wären in ähnlicher Weise nur "dead ends" für Apps, wenn MS noch mal so dramatisch auf eine in großen Teilen völlig andere API umschwenken würde, wie es - nach allem was wir bisher wissen - Apollo ( WP8 ) mit dem Umstieg auf WinRT tun wird. Leider ist die Schnittmenge zwischen Silverlight und WinRT sehr klein. Siehe z.B. hier:
http://programmerpayback.com/2011/11...enome-project/

Es gibt mit WinRT auch keine CLR mehr und daher auch keine IL, wie sie auch Silverlight nutzt. WinRT basiert (wieder) auf COM und der Compiler erzeugt auch (wieder) nativen ("unmanaged") Code, wie vor den Zeiten von .NET oder Java. Natürlich gab es viele Bereiche, da wurde trotz .NET und Java weiterhin nativ entwickelt und dem Entwickler sollen durch WinRT ja auch weitestgehend die hässlichen Tiefen der COM-Komponenten-Programmierung verborgen bleiben. Ich will das hier auch gar nicht werten oder die Diskussion über die Spekulationen über die Hintergründe aufmachen (angeblicher interner Machtkampf bei Microsoft), weil das hier das falsche Forum ist. Trotzdem ist es auf jeden Fall ein ziemlich großer Paradigmen-Wechsel.

Wie ich auch bereits geschrieben habe, ist das zumindest der Stand den wir jetzt wissen. Mehr wird Microsoft hoffentlich auf der WP Dev Konferenz jetzt im Juni sagen. Ich erwarte aber keine große Kehrtwende. WinRT ist offensichtlich für Microsoft die Metro-API der Zukunft schlechthin. Das haben sie völlig klar gesagt.

Zitat von Collin5

• Immer wichtiger werden die Online-Dienste. Im Fall von WP ist dies zurzeit das bescheidene und chaotische Windows Live (WL). WL soll in den nächsten zwölf Monaten grundlegend überarbeitet und verbessert werden, was auch allen WP7 Anwendern zugutekommt… kein „dead end“.

Das ist das Prinzip Hoffnung. Nützlich sind diese Dienste, wenn sie ins System bzw. in Apps integriert sind. Entwickelt Microsoft z.B. das EAS-Protokoll so weiter, dass ein Update erforderlich wird, muss man als Besitzer eines WP7-Gerätes hoffen, das so was noch für WP7 kommt, wenn WP8 draussen ist. Da noch nicht mal die volle EAS-Funktionalität bisher in WP7 umgesetzt ist, geschweige den bestimmte System-Bugs gefixt werden und außerdem die Verbreitung der WP7-Geräte insgesamt gesehen eher sehr gering ist, ist das mir viel zu vage um einem Freund guten Gewissens zu empfehlen, er solle sich jetzt ein neues teures WP7-Gerät kaufen.

Zitat von Collin5

• Da WP7 Apps auch unter WP8 laufen, kann jeder WP7 Besitzer seine App-Investitionen bei einem allfälligen Upgrade weiterverwenden…. kein „dead end“.
• Aus Sicht des WP7 App Entwicklers ist jeder neue WP8 Käufer ein potentieller Neukunde, ohne dass er dafür etwas tun muss. Für ihn wächst der Markt einfach weiter. Daher ist der Übergang vom WP7 zum WP8 Markt aus Sicht des Entwicklers ein fliessender… kein „dead end“.

Allerdings wird das Wachstum des WP7 App Markts irgendwann markant abflachen und über kurz oder lang (wie lang?) zum Stillstand kommen… das ist ein „dead end“

Also trotz einiger "Erfolgsmeldungen" zuletzt, die aber genau betrachtet nur Hoffnungsschimmer waren, hat WP7 bisher keinen wirtschaftlich relevanten Marktanteil. Wenn WP8 im Herbst kommt, werden WP7-Geräte nur noch abverkauft. Jedenfalls in den relevanten Märkten der Industrieländer in Nordamerika, Europa und Asien. Wenn die Lager über sehr günstige Abverkaufspreise geräumt werden, ähnlich wie schon mal letztes Jahr, könnte das noch mal einen kleinen Mini-"Boom" geben. Aber letzten Endes wird das eher im Rauschen untergehen. Daher werden sich für Firmen bzw. Entwickler fortgesetzte Investitionen in die alte Codebasis der Apps für WP7 nicht rechnen. Höchstens im Sinne einer Kundenbindung, wenn man einen relevanten Kundenstamm hat. Was aber nur sehr wenige Apps betreffen wird.

Ich würde mich zwar auch nicht unbedingt wundern, wenn WP8 dann noch zumindest eine Untermenge von Silverlight 5 unterstützen wird, aber das wird dann allenfalls "Kosmetik" sein, wenn die strategische Zukunft bei WinRT liegt. Investitionen in Entwicklungen neuer Apps, gerade bei den Firmen und Entwicklern die bisher WP7 mehr oder weniger ignoriert haben, werden mit Sicherheit dann auch in Win8 + WP8 gehen und nicht mehr in WP7. Denn gerade die wahrscheinliche Möglichkeit der Austauschbarkeit des WinRT-basierten Codes zwischen Telefon und Tablets wird WinRT sehr interessant für die Entwickler machen. Windows 8 werden im Tablet-Markt gute Chancen vorhergesagt.

Bei WP8, WP9 und WP10 kommen wir aber auch irgendwann ans Ende. Es fragt sich jeweils nur wie markant und über welchen Zeitraum die App Entwicklung für eine WP Generation zum Stillstand kommt. Sofern sich WP8 einen vernünftigen Marktanteil sichert, wird keiner eine Unterversorgung an neuen Apps befürchten müssen (im Gegensatz zu heute).

Ich will jetzt nicht auf die "Konsolenmodell"-Theorie eingehen, die hier wieder durchscheint - schon gar nicht auf die Hardware-Seite - weil m.E. wir dafür nicht genug aktuelle Informationen über die weitere Strategie von Microsoft haben. Deswegen habe ich mich da weiter oben auch rausgehalten. Einiges haben sie ja schon selber zumindest in Teilen revidiert. Siehe Tango, oder "ST-Ericsson breaks Qualcomm Windows Phone monopoly" usw.. Letzten Endes ist das alles Spekulation.

Ich erwarte aber zumindest was das Betriebssystem angeht, nach dem bisher von Microsoft bekannt gewordenen, dass Microsoft die Entwicklungslinien von Windows 8, Windows RT und Windows Phone über den Kernel und die APIs wie WinRT sehr eng zusammenführt. Daher erwarte ich dann bei WP8 -> WP9 nur noch gleich harte (oder weiche) Schnitte, wie dann parallel bei Windows 8 -> Windows 9. Wie hart oder weich die auch immer sein mögen. Die Vergangenheit lehrt jedoch, dass sich die Schnitte bei Windows in engen Grenzen hielten. Windows 8 mit dem Touch-Metro-UI auch für Desktop ist natürlich ein gewagter Schnitt, mit dem man auch potentiell viele eingefleischte Windows-User vergraulen könnte. Ob sie dann so was bei Windows 9 noch mal wiederholen, bezweifele ich. Außer wenn Windows 8 floppt. Aber selbst beim letzten Flopp (Vista) war ja der Sprung auf Windows 7 dann minimal.

Wie dem auch sei, solange Microsoft nicht mehr zur Strategie sagt, empfehle ich jedem Bekannten sich im Moment kein teures WP7-Gerät zu holen (Schnäppchen mal aussen vor gelassen), sondern entweder zu warten bis MS sich klar äußert (so oder so) oder bis das erste WP8-Gerät erscheint und wir endlich wissen woran wir sind. Ich weiß, Du glaubst nicht dran, aber ich habe auch noch nicht ganz ausgeschlossen, dass MS, doch ein WP8-Upgrade bringt. Zumindest für die Nokia Lumia 800 und 900, weil das sonst Image-mäßig verheerend für Nokia bzw. Stephen Elop sein könnte, nach dem ganzen Android-Bashing was Upgrades angeht.

Mit weiteren Vermutungen und Spekulationen warte ich zumindest jetzt erstmal bis 20.6./21.6..

Du hast meinen Satz mit dem "dead end" leider aus seinem Zusammenhang gerissen und damit wird nicht mehr klar, worauf ich mich mit dem "dead end" eigentlich bezogen habe. [_tw]

Ich weiss. Dies geschah nicht mit „bösen“ Absichten. Mir ging es darum klarer festzuhalten, dass WP7 nicht im gleichen Ausmass wie WM ein „dead end“ darstellt… Deine Aussage betrifft einen Teilbereich des Gesamtsystems. Ich wollte potentiellen Missverständnissen vorbeugen. Da es den Anwendern schlussendlich egal ist, wie unter WP7 entwickelt wird, wollte ich auch die Auswirkungen aus Anwendersicht nochmals stärker betonen, was ich folgendermassen versuchte:

Allerdings wird das Wachstum des WP7 App Markts irgendwann markant abflachen und über kurz oder lang (wie lang?) zum Stillstand kommen… das ist ein „dead end“ [Collin5]

Was das Schicksal des WP7 Marktes betrifft, sind wir jedenfalls gleicher Meinung.

Immer wichtiger werden die Online-Dienste.[Collin5]

Das ist das Prinzip Hoffnung. Nützlich sind diese Dienste, wenn sie ins System bzw. in Apps integriert sind.[_tw]

Sofern Du nur dann einen Mehrwert erkennst, wenn WL vollumfänglich direkt in WP integriert ist, bin ich einverstanden. Ich erkenne hingegen auch dann einen Mehrwert, wenn die Online-Dienste (von denen mein Smartphone Gebrauch macht) bezüglich Desktop Zugriff verbessert werden. Beides findet, wohl nicht nur bei mir, täglich Verwendung.

…
Daher werden sich für Firmen bzw. Entwickler fortgesetzte Investitionen in die alte Codebasis der Apps für WP7 nicht rechnen. Höchstens im Sinne einer Kundenbindung… [_tw]

Einverstanden.

WP8, WP9 und WP10 werden auch „dead ends“ sein

Ein WP9 und WP10 wären in ähnlicher Weise nur "dead ends" für Apps, wenn MS noch mal so dramatisch auf eine in großen Teilen völlig andere API umschwenken würde]

Bei Deiner Argumentationsweise scheint die Andersartigkeit der zugrundeliegenden Softwaretechnik eine zentrale Stellung einzunehmen. Sofern wir wirklich nur Diese berücksichtigen, bin ich mit Dir einverstanden. Die zugrundeliegende Technik in WP7 ist Tod. Eine Sackgasse, die so bei WP8 hoffentlich nicht wiederholt wird (äusserst unwahrscheinlich).

Ich wollte hingegen eine Aussage über die zu erwartenden Marktverhältnisse machen. Diesbezüglich ist eine dramatische softwaretechnische Andersartigkeit keineswegs eine Voraussetzung, um in die gleiche Situation zu gelangen, wie wir sie heute schon kennen. Beispiel:

Was ist, wenn mit WP9 nur eins oder zwei ganz neue API's dazukommen, aber die bestehenden grösstenteils gleich bleiben? Was ist, wenn WP9 Apps mit neueren Versionen der .Net BCL assemblies verlinkt werden (was sicherlich der Fall sein wird)? Antwort:

WP9 Apps laufen dann nicht auf WP8. Auf WP8 Hardware laufen neue Apps nur dann, wenn es ein WP9 update gibt. Dies wäre mit der heutigen Situation identisch, obwohl das Ausmass der technologischen Änderungen nicht einmal ansatzweise vergleichbar wäre.

Zumindest aus Sicht des Endkunden ist die Grundsituation dieselbe. In beiden Fällen ist es nur noch eine Frage der Zeit, bis WP8 Geräte nicht mehr mit Updates und neuen Apps versorgt werden. Die Dauer dieser Schonfrist ändert meiner Meinung nicht viel daran, dass wir in einer Sackgasse gelandet sind... der Weg bis zum Ende dauert nur länger. Das wollte ich damit aussagen.

Einiges haben sie ja schon selber zumindest in Teilen revidiert. Siehe Tango, oder "ST-Ericsson breaks Qualcomm Windows Phone monopoly" usw.. Letzten Endes ist das alles Spekulation.

Welche Teile meiner Aussagen Spekulation sind und welche nicht habe ich schon klargestellt ( siehe Beitrag #28 ).

ST-Ericsson hat während den letzten zwei Jahren schon tausend Mal genau das Gleiche verlauten lassen. Bisher ist nie etwas daraus geworden. Möglicherweise stimmt es nun beim 1001’sten Mal. Keine Ahnung.

Sofern die Pressemeldung dieses Mal stimmt, und ansonsten alle anderen Rahmenbedingungen unverändert bleiben, würde Microsoft somit die Weiterverfolgung ihres ersten WP Zieles aufgeben. Das ist möglich, aber unwahrschenlich.

Sofern die Pressemeldung dieses Mal stimmt, erwarte ich dass die Rahmenbedingungen ändern. Beispielsweise könnte Microsoft entscheiden, dass Apps auf solchen billigst Geräten nicht installiert werden können. Insofern wären diese Geräte bezüglich der hier diskutierten Thematik irrelevant. Ausser Microsoft müsste sich niemand darum kümmern. Die Vorteile der Konsolenähnlichkeiten blieben WP erhalten.

Ausser ST-Ericsson profitiert niemand von einem solchen Vorgehen. Bis ich so ein SoC in einem WP Gerät sehe, bleibe ich aufgrund bisheriger Erfahrungen eher skeptisch.

@_tw

Soweit ich feststellen kann, gibt es bisher nur eine Gruppe von Aussagen, bei denen wir wirklich anderer Meinung sind. Daran ist primär Microsofts Informationspolitik schuld, die in letzter Zeit sehr zu wünschen übrig lässt.

Eigentlich gehört diese Diskussion nicht hierher, aber ich werde trotzdem kurz darauf eingehen. Unter Umständen führen wir diese Diskussion dann andernorts fort. Dabei geht es um die Frage, ob aus Sicht des Entwicklers bei WinRT tatsächlich eine derart dramatische Andersartigkeit (wie geschildert) gegeben ist:

WinRT basiert (wieder) auf COM und der Compiler erzeugt auch (wieder) nativen ("unmanaged") Code

Nein. Der C# compiler erzeugt weiterhin ausschliesslich IL code.

...Trotzdem ist es auf jeden Fall ein ziemlich großer Paradigmen-Wechsel.

Nein. Alle paradigmen der WPF/Silverlight Entwicklung (Deklarativ UI Beschreibung, MVVM Ansatz, usw) gelten weiterhin. Die Bedeutung von COM und native code, die zum vermeintlichen Paradigmen-Wechsel führen, sind tatsächich fast irrelevant. Jede .Net Applikation verwendet zumindest indirekt native Code des Betriebssystems… das war schon immer so. Bei WinRT ist dies also weder anders noch neu. Von der Interaktion mit native Code merkt der C# Entwickler nichts, weil dies von der .Net BCL versteckt wird. Bei WinRT merkt der C# Entwickler genau so wenig davon, nur wird dies hier nicht von der BCL, sondern von der erweiterten COM Technologie versteckt.

Schlussendlich gibt es nur eine einzige änderung die als Paradigma-Wechsel durchgehen könnte, nämlich dass die Kontrolle der Benutzerschnittstelle wieder vollumfänglich in den Verantwortungsbereich des Betriebssystems fällt (wieder wie zu .Net Anfangszeiten bei WinForms). Abgesehen von der massiv besseren Performance, sind die praktischen Auswirkungen jedoch eher bescheiden.

Leider ist die Schnittmenge zwischen Silverlight und WinRT sehr klein. Siehe z.B. hier:
http://programmerpayback.com/2011/11...enome-project/

Hier werden alle Silverlight Typen mit allen aus WinRT verglichen. Sofern es dem Genom Projektmitarbeiter darum ging aufzuzeigen wie ähnlich die GUI relevanten Teile sind, ist dies eine eher ungeeignete Vorgehensweise.

WinRT soll mittelfristig das gesamte Win32 API ersetzen. Hingegen ist Silverlight nur ein UI Framework. Logischerweise wird WinRT daher einiges mehr enthalten als Silverlight. Hätte er sich auf die GUI relevanten namespaces von WinRT beschränkt, wäre die Überlappung massiv grösser gewesen.

Ich habe selbst ein (zugegebenermassen kleines) WP7 Projekt auf WinRT portiert und fand den Aufwand von wenigen Stunden akzeptabel.

Zitat von Collin5

Was ist, wenn mit WP9 nur eins oder zwei ganz neue API's dazukommen, aber die bestehenden grösstenteils gleich bleiben? Was ist, wenn WP9 Apps mit neueren Versionen der .Net BCL assemblies verlinkt werden (was sicherlich der Fall sein wird)? Antwort:

WP9 Apps laufen dann nicht auf WP8. Auf WP8 Hardware laufen neue Apps nur dann, wenn es ein WP9 update gibt. Dies wäre mit der heutigen Situation identisch, obwohl das Ausmass der technologischen Änderungen nicht einmal ansatzweise vergleichbar wäre.

Zumindest aus Sicht des Endkunden ist die Grundsituation dieselbe. In beiden Fällen ist es nur noch eine Frage der Zeit, bis WP8 Geräte nicht mehr mit Updates und neuen Apps versorgt werden. Die Dauer dieser Schonfrist ändert meiner Meinung nicht viel daran, dass wir in einer Sackgasse gelandet sind... der Weg bis zum Ende dauert nur länger. Das wollte ich damit aussagen.

Eigentlich habe ich das schon beschrieben. Es geht um die Codebasis. Wenn in WP9 nur ein oder zwei neue APIs gegenüber WP8 hinzukommen, laufen nur genau die neuen Apps unter WP8 nicht, die genau diese brauchen. Alle anderen neuen Apps die nach WP9 entwickelt werden, würden auch weiterhin unter WP8 laufen auf der gleichen Codebasis. Der Aufwand für die Entwickler WP8 weiter zu unterstützen wäre minimal. Selbst wenn eine neue WP9 API interessant wäre, liesse die sich je nachdem ggf. auch für z.B. ein optionales Feature in eine WP9-Version nutzen, ohne eine völlig andere App programmieren zu müssen. Wobei es im Einzelfall natürlich auf die konkrete API ankommt. Was wieder alles reine Spekulation ist.

Das gleiche gilt aber nicht für WP7 und WP8. Wenn man, Stand Wissen jetzt, eine WP8-App entwickelt auf Basis von WinRT läuft die nicht unter WP7. Man kann allenfalls Teile der Business-Logik u.U. in beiden verwenden in einer sogenannten "Portable Library". Die sind jedoch stark eingeschränkt.

Zitat von Collin5

@_twSoweit ich feststellen kann, gibt es bisher nur eine Gruppe von Aussagen, bei denen wir wirklich anderer Meinung sind. Daran ist primär Microsofts Informationspolitik schuld, die in letzter Zeit sehr zu wünschen übrig lässt.

Eigentlich gehört diese Diskussion nicht hierher, aber ich werde trotzdem kurz darauf eingehen. Unter Umständen führen wir diese Diskussion dann andernorts fort. Dabei geht es um die Frage, ob aus Sicht des Entwicklers bei WinRT tatsächlich eine derart dramatische Andersartigkeit (wie geschildert) gegeben ist:

Nein. Der C# compiler erzeugt weiterhin ausschliesslich IL code.

Ich habe gar nicht geschrieben, dass ich oben C# meinte. Ok, ich hätte das natürlich schreiben müssen, dass ich mich auf den "first class citizen" von WinRT beziehe, nämlich den C++/CX-Compiler oder diesen Ausflug ganz weg lassen sollen. Dann hätte ich mir diese "Belehrungsrunde" erspart. Aber ist meine eigene Schuld, ich hätte das natürlich ganz präzise formulieren müssen (nicht ironisch gemeint).

Warum ich das geschrieben habe, liegt daran, dass meine persönliche Meinung (womit ich allerdings nicht "ganz" alleine bin, aber das ist hier offtopic und dazu gibt es andere Foren) ist, dass C# und .NET in WinRT nur noch auf dem Rücksitz sitzen. Jedenfalls was Metro-style Apps angeht. Das folgende schreibe ich nur, nicht um Dich zu belehren, sondern um zu vermeiden, dass ich wieder belehrt werde, über Grundlagen von WinRT, die ich mir selber seit dem Herbst leider anschauen muss.

Also natürlich kann man, zumindest in Win8 (von WP8 wissen wir es noch nicht) Metro-style Apps auch in C# oder VB.NET schreiben, wenn man will. Das habe ich nicht bestritten. Dazu muss man jedoch das .NET-Profile für Metro verwenden (wenn man Metro adressieren will). In diesem Profil fehlen aber sehr viele .NET-Klassen und viele die drin sind, sind nicht identisch mit den Klassen aus dem vollständigen .NET-Framework, so dass man sowieso WinRT-Klassen verwenden muss. Vorhandener WPF oder Silverlight UI Code in C# lässt sich nicht einfach durch Neukompilieren in die WinRT-Welt übernehmen. Es ist fast eine Art "durcheinandergewürfelte" API die die Fragmentierung in der .NET-Welt extrem verstärkt.

Aber die Meinungen dazu und den nötigen Aufwand sind geteilt und werden auch je nach Projekt, ob neu oder was man auf WinRT bzw. Metro portieren will, variieren. Kommt auch auf die Struktur der Codebasis an, so eine vorhanden ist. Leider habe ich keine Zeit hier eine detaillierte Diskussion dazu führen. Wenn man sich in C# "wohler" fühlt als in C++ mag man den Weg gehen. Ich persönlich (aber wie gesagt nicht nur ich) halte dieses "Mischkonstrukt" nicht für wirklich langfristig zukunftsfähig und werde neue Projekte auch nicht damit beginnen und empfehle es selber auch nicht. Ich denke, dass Microsoft die Zukunft bei "reinem" WinRT sieht. Für Entwickler, die vor C#-Zeiten mal mit C++ angefangen haben, wie ich, ist es natürlich auf der anderen Seite "back to the roots".

Zitat von Collin5

Nein. Alle paradigmen der WPF/Silverlight Entwicklung (Deklarativ UI Beschreibung, MVVM Ansatz, usw) gelten weiterhin. Die Bedeutung von COM und native code, die zum vermeintlichen Paradigmen-Wechsel führen, sind tatsächich fast irrelevant. Jede .Net Applikation verwendet zumindest indirekt native Code des Betriebssystems… das war schon immer so. Bei WinRT ist dies also weder anders noch neu. Von der Interaktion mit native Code merkt der C# Entwickler nichts, weil dies von der .Net BCL versteckt wird. Bei WinRT merkt der C# Entwickler genau so wenig davon, nur wird dies hier nicht von der BCL, sondern von der erweiterten COM Technologie versteckt.

Auch mit dem Paradigmenwechsel (=Abkehr von .NET) bezog ich mich auf den "first class citizen" C++/CX (daneben natürlich auch HTML5/JS). Was ich von C# für Metro UI Apps im Moment halte, habe ich ja schon geschrieben. Ich weiß natürlich auch nicht, wie die Zukunft von .NET im Bereich Client-UI Entwicklung aussieht, aber im Moment geht für mich der Trend bei MS davon weg. Letztlich hat man in den Business Units für Windows (wo Sinofsky herkommt) und Office nie auf .NET gesetzt und die scheinen sich nun durchgesetzt zu haben (wie gesagt, die Gerüchte dazu bitte selber googeln).

Aber ich glaube Du verwechselst hier was. Natürlich war das OS bzw. Win32 immer nativ und .NET ruft letztlich auch über Win32 das OS. Das sind ja Allgemeinplätze. Aber in WinRT versteckt COM selber gar nichts vor dem C# Entwickler. COM unten drunter war und bleibt rein nativ. Mit allen alten "Hässlichkeiten" von COM. Ich empfehle dazu:
http://www.interact-sw.co.uk/iangblo...l-native-winrt

COM wird vor dem C#-Entwickler durch das versteckt, was Microsoft jetzt "projection" nennt. Es wird allerdings auch vor dem C++ Entwickler versteckt, wenn er C++/CX verwendet und nicht rein natives C++. Ich erspare mir jetzt mal langatmige "Belehrungen" über Basics, weil ich vermute, dass Du das wohl meintest, nur falsch formuliert hast. Jedenfalls selbst wenn man nicht mit C++/CX arbeiten will, bleiben im Detail einem aber auch in C# oder VB.NET, Sachen wie das bevorzugte asynchrone Pattern von WinRT nicht erspart, WinRT Komponenten schreiben beim Deployment wieder in die Registry rein (wie COM-Komponenten), was mir schon wieder Ärger macht usw.

Zitat von Collin5

[...] Abgesehen von der massiv besseren Performance, sind die praktischen Auswirkungen jedoch eher bescheiden.

Wenn Du damit die Auswirkung der Umstellung auf den Entwickler meinst, liegst Du, zumindest in jedem nicht trivialen Projekt, in dem Punkt um Meilen daneben. Diese Erfahrung habe ich bereits selber machen müssen.

Zitat von Collin5

WinRT soll mittelfristig das gesamte Win32 API ersetzen. Hingegen ist Silverlight nur ein UI Framework. Logischerweise wird WinRT daher einiges mehr enthalten als Silverlight. Hätte er sich auf die GUI relevanten namespaces von WinRT beschränkt, wäre die Überlappung massiv grösser gewesen.

Das ist falsch. Die Silverlight-Runtime ist eine abgespeckte Version des vollen .NET und Silverlight-Apps stehen nicht nur UI-Klassen zur Verfügung, sondern auch ein Subset .NET-Klassen für IO, Netzwerk usw.. Sonst wären der Nutzen von Silverlight-Apps auch extrem eingeschränkt. Ein Vergleich dieses Umfanges mit WinRT oder anderen .NET Profilen ist völlig legitim. Nur die GUI relevanten Teile zu vergleichen, wäre irreführend.

Ok, ich sehe das nun auch so. Wenn Du meine Kommentare alle so verstanden hättest wie sie gemeint waren (oder ich jede erdenkliche semantische Lücke geschlossen hätte), hätten wir uns beide auch diese „Belehrungsrunde“ sparen können. Ich glaube hier erzählt keiner dem Anderen etwas Neues, und zu 99% sind wir uns (sofern wir uns verstehen) einig. Da dies die wenigsten hier interessant finden dürften, schlage ich vor, dass wir diese Diskussion allenfalls anderswo weiterführen, falls Du dies möchtest. Ich finde es interessant wie man sich gedanklich aus einer anderen Richtung einem Thema nähern kann, aber grundsätzlich „richtiger“ ist keiner von uns. Ich habe auch 12 Jahre C++ / Win32 / COM Erfahrung.

Zurück zum Thema:

Was ist, wenn mit WP9 nur eins oder zwei ganz neue API's dazukommen, aber die bestehenden grösstenteils gleich bleiben?

Es geht um die Codebasis. Wenn in WP9 nur ein oder zwei neue APIs gegenüber WP8 hinzukommen, laufen nur genau die neuen Apps unter WP8 nicht

Richtig. Genau darum ging es mir. WP9 Apps welche WP9 spezifische Funktionalitäten verwenden, würden weder automatisch noch Aufwandsfrei unter WP8 laufen.

Du argumentierst (sofern die API’s relativ stabil bleiben und keine neuen WP9 Funktionalitäten verwendet werden), dass der Entwickler bei einer WP9 App höchstens kleine Änderungen vornehmen und nochmals kompilieren müsste, um WP8 Besitzern eine leicht angepasste Version der App anbieten zu können. Das ist alles richtig.

Aber wozu überhaupt das Ganze? Wenn die App keine WP9 spezifischen Funktionalitäten benötigt, könnte der Entwickler absolut Konsequenzfrei einfach unter WP8 weiterentwickeln. Der App fehlt es an nichts, kein Anwender merkt etwas davon, und der Entwickler müsste überhaupt nichts zusätzliches dafür tun. Mit einem einzigen Programm (statt zwei Versionen desselben Programms) könnte der Entwickler sowohl an WP8 als auch WP9 Besitzer verkaufen.

Mein Punkt ist nun der, dass dies auch schon heute der Fall ist. Wenn eine App keine WP8 spezifischen Funktionalitäten benötigt, gibt es keinen Grund eine App sofort von WP7 auf WP8 zu portieren. Diejenigen App Entwickler, welche primär finanzielle Ziele verfolgen, werden dies auch nicht tun. Umstellen werden sie erst dann, wenn der WP7 Markt soweit geschrumpft ist, dass sie dort keine nennenswerten Verkäufe mehr erwarten können. Im Fall von WP7 ist diese letzte Aussage etwas problematisch, weil im WP7 Markt gar nie nennenswerte Verkäufe zu erwarten waren. Dafür ist der WP7 Marktanteil zu klein. Ein Dilemma, dessen Auswirkungen ich nicht wirklich abschätzen kann, aber eher Nagatives erwarte.

Wird die Mehrheit aller Apps auf eine neuere Version von WP portiert, so heisst dies, dass die Entwickler keine Nennenswerte Verkäufe mehr an Besitzer älterer Geräte erwarten. Danach wird es keine Updates mehr für ältere Geräte geben, auch wenn dies nur mit verhältnismässig wenig Aufwand verbunden ist. Sobald diese portierungsphase eingeleitet ist, sind diejenigen mit älteren Geräten am Ende der Sackgasse angelangt. Daher bleibe ich dabei, dass auch WP8, WP9 usw. schlussendlich "Sackgassen" sein werden, auch ohne dramatische Technolgieänderungen.

Fazit: Ich finde Deine Aussagen grundsätzlich richtig. Ich glaube nur nicht, dass der WinRT Technologie-Wechsel für den WP7 „dead end“ die Hauptschuld trägt. Zumindest dann nicht, wenn wir nicht nur von der Technologie selbst, sondern auch von deren Konsequenzen sprechen. Die Diskussion nur auf den technologischen „dead end“ zu beschränken finde ich müssig. Schlussendlich sind nur die Auswirkungen auf den Endkunden und den Marktanteil von Relevanz.

Man kann es auch umgekehrt formulieren: Wenn der WP7 Markt derart aktiv ist, dass über die nächsten anderthalb Jahren ausreichende Verkäufe erwartet werden können, werden auch die Entwickler den WP7 Markt weiterhin bewirtschaften. Technologie-Wechsel hin oder her.

Zitat von Collin5

Ok, ich sehe das nun auch so. Wenn Du meine Kommentare alle so verstanden hättest wie sie gemeint waren (oder ich jede erdenkliche semantische Lücke geschlossen hätte), hätten wir uns beide auch diese „Belehrungsrunde“ sparen können. Ich glaube hier erzählt keiner dem Anderen etwas Neues, und zu 99% sind wir uns (sofern wir uns verstehen) einig. Da dies die wenigsten hier interessant finden dürften, schlage ich vor, dass wir diese Diskussion allenfalls anderswo weiterführen, falls Du dies möchtest. Ich finde es interessant wie man sich gedanklich aus einer anderen Richtung einem Thema nähern kann, aber grundsätzlich „richtiger“ ist keiner von uns. Ich habe auch 12 Jahre C++ / Win32 / COM Erfahrung.

Ok, kein Problem. Ich sehe auch keinen Sinn darin hier akademisch alle semantische Feinheiten herauszuarbeiten. (Auch für mich erschreckend wie die Zeit vergeht...) Ich lasse jetzt auch mal die theoretischen Vergleiche mit WP9 außen vor und komme gleich zum zentralen Punkt:

Zitat von Collin5

[...]
Mein Punkt ist nun der, dass dies auch schon heute der Fall ist. Wenn eine App keine WP8 spezifischen Funktionalitäten benötigt, gibt es keinen Grund eine App sofort von WP7 auf WP8 zu portieren.

Diejenigen App Entwickler welche primär finanzielle Ziele verfolgen werden dies auch nicht tun. Umstellen werden sie erst dann, wenn der WP7 Markt soweit geschrumpft ist, dass sie dort keine nennenswerten Verkäufe mehr erwarten können. Im Fall von WP7 ist diese letzte Aussage etwas problematisch, weil im WP7 Markt gar nie nennenswerte Verkäufe zu erwarten waren. Dafür ist der WP7 Marktanteil zu klein. Ein Dilemma, dessen Auswirkungen ich nicht wirklich abschätzen kann, aber eher Nagatives erwarte.
[...]

Fazit: Ich finde Deine Aussagen grundsätzlich richtig. Ich glaube nur nicht, dass der WinRT Technologie-Wechsel für den WP7 „dead end“ die Hauptschuld trägt. Zumindest dann nicht, wenn wir nicht nur von der Technologie selbst, sondern auch von deren Konsequenzen sprechen. Die Diskussion nur auf den technologischen „dead end“ zu beschränken finde ich müssig. Schlussendlich sind nur die Auswirkungen auf den Endkunden und den Marktanteil von Relevanz.

Das ist alles soweit richtig. Aber mein eigentlicher Punkt dazu, von weiter oben war ein anderer, aber auch wirtschaftlicher Art. Der nur mittlerweile etwas untergegangen ist: also wenn es nur WP8 kommen würde: ja, dann würde ich Dir hierbei in allem mehr oder weniger zustimmen. Es kommt aber irgendwann ab Herbst nicht nur WP8, sondern eben auch Windows 8 für Tablets - Intel und ARM - mit Metro UI und WinRT. Und das macht m.E. den entscheidenen Unterschied im diesem Fall. Wenn die Win8-Tablet-Verkäufe gut laufen (wenn sie nicht zu teuer sind usw.) könnte sich das in wenigen Monaten ganz schnell hochschaukeln. Die WinRT-Plattform wird dann interessant für mehr Firmen und Freelancer-Entwickler. Wenn WinRT-Code dann noch für WP8 und Win8 Metro in weiten Teilen austauschbar sein sollte (was die meisten erwarten/hoffen), wird es auch einfacher sein sozusagen "nebenbei" Tablet-Metro-Apps auch für WP8 tauglich zu machen.

Zitat von Collin5

Man kann es auch umgekehrt formulieren: Wenn der WP7 Markt derart aktiv ist, dass über die nächsten anderthalb Jahren ausreichende Verkäufe erwartet werden können, werden auch die Entwickler den WP7 Markt weiterhin bewirtschaften. Technologie-Wechsel hin oder her.

Ja, möglicherweise über Tango für Low-End-Geräte und sich davon Millionen verkaufen würden. Ich persönlich bezweifle das aber. Wenn aber umgedreht, die von Microsoft für Windows 8 erhoffte Dynamik wirklich eintritt, wird das bedingen, dass nicht nur dann neue Apps nur noch für Metro-Win8 + WP8 kommen, sondern auch das Pflegen alter Apps für WP7 für Entwickler wegen des Dilemmas der geringen WP7-Verbreitung, wie Du es oben auch erwähnt hast, sich nicht mehr rentiert.

Ok, ich bin da auch skeptisch, denn das sind natürlich viele Fragezeichen. Aber eben genau deswegen - um darauf wieder zurückzukommen - rate ich ja im Moment eben zum Warten und kein (teures) WP7-Gerät im Moment zu kaufen. Erst mal sehen, was Microsoft am 20.6./21.6. verkündet. Danach kann man weiter sehen. Aber wie gesagt, kann das jeder halten wie er will.

Bei Deiner Vorahnung bezüglich Metro-W8 Dynamik sind wirklich viele „wenn“ und „aber“ involviert, aber dennoch absolut plausibel. Einverstanden.

also wenn es nur WP8 kommen würde: ja, dann würde ich Dir hierbei in allem mehr oder weniger zustimmen.

Also, ich sehe jetzt woran Du Dich störst… und welch Wunder… ich bin einverstanden.

Wir sind sicherlich beide schuld, aber mann, das war ein ganz langer Umweg um hier anzukommen.

Sofern die Metro-W8 Dynamik so zum Tragen kommt, ist das ein weiterer Faktor welcher die Entwicklung/Wartung von WP7 Apps frühzeitig beendet. Nicht zuletzt, weil Keiner WP8 Apps zurück auf WP7 portieren wird... auch da sind wir uns einig (nur meine ich, dass dies bei WP9, WP10 usw. gleich gehandhabt wird, egal wie ähnlich sich die API's sind).

Wir bezweifeln beide, dass die erzielten Verkäufe die Weiterentwicklung von WP7 Apps gewährleisten kann. Das die Low-End Geräte da noch was retten könnten bezweifle wir ebenso. Nur! Wenn ich raten müsste, meinte ich dass die Entwicklung/Wartung von WP7 Apps relativ schnell zum Stillstand kommt, und dies völlig unabhängig von der Metro-W8 Dynamik.

Aus Sicht des Anwenders „streiten“ wir jetzt also nur noch darum, welches Ereignis den florierenden WP7 App Markt zuerst um die Ecke bringt. Sag bitte das es nicht so ist… wäre ja langweilig…

Wenn WinRT-Code dann noch für WP8 und Win8 Metro in weiten Teilen austauschbar sein sollte (was die meisten erwarten/hoffen), wird es auch einfacher sein sozusagen "nebenbei" Tablet-Metro-Apps auch für WP8 tauglich zu machen.

Diesbezüglich weiss ich nicht mehr als andere, aber ich würde auch nichts anderes erwarten. Ich vermute, dass die Portierung von MinWin von W8 auf WP8 primär dazu diente, auch die CLR und Metro grösstenteils unverändert aus W8 übernehmen zu können.

Falls WP8 und W8 Metro nicht zu grossen Teilen austauschbar sind, verstehe ich nicht was der Sinn der MinWin Portierung gewesen ist. Dann hätte Microsoft auch bei Win CE 7.0 und dem Compact Framework bleiben können, was schneller geschaft und daher günstiger gewesen wäre.

Also ich würde es toll finden, wenn ihr die Diskussion hier weiterführen würdet und euch austauscht. Ich verstehe in der Tiefe zwar nichts mehr von der Thematik, weswegen ich mich auch raushalte und nur mitlese, aber finde es trotzdem sehr interessant.
Kompetenz möchte man doch gerne im Forum halten.

Jetzt ist es mehr oder weniger offiziell- es wird KEIN Apollo Update geben. Auch nicht für die Lumias. Nur ein letztes Feature Update, wie ich immer gesagt habe... Sprich ein Windows Phone 7.6 oder 7.7 mit paar Features von WP8 http://winfuture.de/news,70106.html


Aber von WP7 Geräten, auch den neuen Lumias (610, 710, 800, 900') wird man NICHT updaten können auf Apollo.

Daraus "Wenn die Leute dieselben Funktionen auf ihren Smartphones haben, ist ihnen egal, welche Versionsnummer das Betriebssystem hat." Abgesehen von der psychischen Obsoleszenz mit der das Marketing den Leuten das Geld aus der Tasche zieht.

Ja und wo ist jetzt das Problem ? Wenn mein Wp 7.7 Handy das selbe kann wie ein WP8 dann ist doch alles in Butter. Die von WP8 Unterstützte Hardware könnte ich ja so oder so nicht nützen, auch wenn ich WP8 auf meinem Lumia hätte....

http://wmpoweruser.com/german-busine...le-for-wp-7-7/ hab ich grad gelesen mal schauen ins stimmt

Mit der kostenlosen PocketPC.ch App von meinem 7 Mozart T8698 aus geschrieben.