[orbb]

Nein, sie ist dafür gedacht, damit die Entwickler ihre Programme auf Kompatibilität prüfen können, so dass sie pünktlich zum OS-Release fertig werden. Die Developer Preview ist nicht ein möglicher Weg, sondern der Weg. Da darf es keine fundamentalen Änderungen mehr geben.

Das mag für Desktopprogramme gelten, für Metro-Apps mitnichten. Schlicht und einfach, weil das Programmiermodell weit davon entfernt ist, fertig zu sein. Lediglich, wer auf HTML/JS setzt, hat da gute Karten.

Die Behauptung war, dass auch Windows PC Programme emuliert oder neukompiliert auf Windows on ARM außerhalb von Metro laufen werden. Das wird nicht passieren und damit ist das Pfund weg.

Dann bin ich auf Einzelheiten gespannt. Ich meine, Sie spekulieren hier ins Blaue. Wenn das .NET-Framework nach ARM portiert wird, ist es dem Programm sowieso egal, worauf es läuft. Die spannendere Frage ist, wie sich Microsoft die Portierung von WP7-Apps vorstellt, da ja Silverlight nicht mehr das Mittel der Wahl ist. Auch in Hinblick auf WP8. Grundätzlich gibt es zwischen Silverlight- und WinRT-Klassen viele Schnittmengen. Aber eben auch einige unangehme Unterschiede.

Die beschauliche Zahl der Windows Phone 7 Apps sind kein Pfund. Wegen der geringen Anzahl verkaufter WP7-Handys gibt es bisher kaum Drittanbieter, die sich für diese Plattform interessieren.

Sie wundern sich, warum ich Fanboi (mit "i") schreibe? Sorry, das ist trolling pur. Oder Ahnungslosigkeit. Suchen'S sich auch, wissender IT-Entscheider.

Die Metro-Oberfläche soll die Bedienung von PCs und Tablets vereinheitlichen, d.h. sowohl maus- als auch touch-basiert funktionieren.

Blödsinn. Ich wüßte nicht, dass behauptet wurde, dass Metro die Desktop-Oberfläche ersetzen soll. Das ist doch genau der Punkt, den DJ Doena schon hervorbrachte. Sollte der 29. Ihre Behauptung untermauern, reihe ich mit in den Chor, der "Die spinnen bei Microsoft" singt, mit ein.

Die Millionen Windows-PC Nutzer sollen zusammen mit den wenigen Tausend Windows-Tablet Nutzern im selben Store einkaufen gehen, damit Metro-Apps nach einem vielversprechenden Markt für Entwickler aussehen. Die Drittanbieter sollen von der Aussicht begeistert sein, nur eine einzige universelle Metro-App (die sowohl für INTEL als auch ARM kompiliert wurde) für beide Käufergruppen zu schreiben. So zumindest der Plan.

Auch das ist so nicht richtig. Ich frage mich, ob Sie sich ernsthaft mit dem Thema auseinandergesetzt haben. Der Grund, weswegen Windows 8 auf x86/x64 und ARM laufen soll, ist der, dass man ein Betriebssystem anbietet, wo die Mitbewerber 2 am Start haben. Vielleicht liegt da der Grundirrtum begründet, dass der Desktop abgelöst werden soll.

[orbb]

HTML5 und JavaScript werden zum Standard für Metro-Apps werden, weil diese Web-Technologien auch auf iPhone und Android funktionieren. Microsofts eigene Programmiersprachen wie C# sind auf dem Markt für mobile Geräte nicht mehr durchsetzbar, weil bereits hunderte Millionen Smartphones ohne Windows laufen.

Das verneine ich auf das Heftigste.

1. HTML/JS ist ein Hype, der recht bald abflauen wird. Das lustige an HTML5 ist, dass das noch nichteinmal verabschiedet ist und sich jeder Browserhersteller was anderes darunter vorstellt. Das gibt ja jetzt schon ein gar lustiges Chaos.

2. Wer sagt denn, dass sich Microsoft an Standards hält? Es wird gemunkelt, dass Chakra-JS inkompatibel zum Browser-JS sein soll. Was auch nicht verwundern würde, muss doch JS gegen Größen wie C++ oder C# antreten. Da muss es schon mehr bieten als den Kindergeburtstag von heute.

3. Neben dem HTML5-Chaos spielt noch eine ganz andere Komponente gegen eine App für alle Plattformen rein: die UI. Jeder Hersteller hat andere Designvorgaben. Kippe ich eine in Metro gestylte App bei Apple ein, setzt es mit Sicherheit eine Ablehnung. Mich wundert sowieso, dass Microsoft seine Xbox-App in den AppStore bekommen hat. Damit verspielt HTML5 schon mal seinen größten Vorteil.

4. Mit dem Mono-Framework steht ein Werkzeug zur Verfügung, mit dem - zumindest auf der Logikebene - für alle 3 Plattformen programmiert werden kann. Durch die saubere Schichtentrennung mit C# (MVVM) werden UI und Logik nicht vermanscht, so dass lediglich die UI für jede Plattform angepasst werden muss.

Wenn es schwer wird eine Android oder iOS-App nach Metro zu portieren, dann wird es keiner machen. Aber ohne die bekannten iOS-Apps wie "Cut the Rope" werden sich Metro-Geräte nicht verkaufen.

Für fast jede bekannte App aus der iOS-/Android-Welt gibt es einen Pendant. Die Macher von WhatsApp haben sich offiziell bis kurz vorm Mango-Update auch geziert, um dann pünktlich im September die Chartspitze zu übernehmen.

Deswegen muss Microsoft ... für offene Programmiersprachen werben, denn die dominierende proprietäre Programmiersprache in diesem Bereich ist Apples Objective-C. Die Entwickler müssen davon überzeugt werden, dass es Sinn macht nicht in ObjC sondern in JS und damit gleich für alle drei Plattformen zu programmieren.

Wenn ich in die Charts der gefragten Programmiersprachen schaue, ist Objective C zwar nach oben gegangen, hat aber mitnichten eine dominierende Stellung. Die hat nämlich Java mit 18%. Davon abgesehen, habe ich bereits erläutert, dass HTML/JS nicht wirklich ernstzunehmen ist.

Die Synergien für die verschiedenen Plattformen liegen auf den Servern. Auf dem Phone wird werden die Dienste konsumiert und angezeigt. Gerade auf WP7 mit Silverlight ist das relativ simpel zu bewerkstelligen. iOS und Android vermag ich schwer abzuschätzen. Ich weiß soviel, dass Entwickler, die sowohl Objective C als auch Silverlight programmiert haben, von der Produktivität mit Silverlight schier begeistert sind. Passend dazu eine Fallstudie, welche die Produktivität zwischen WP7 und Android vergleicht: Nilzor's Techblog: Android vs WP7 for developers - a case study Und den Vorteil soll man mit der obskuren Kombo HTML5/JS aufgeben?

[Guderian]

Schlicht und einfach, weil das Programmiermodell weit davon entfernt ist, fertig zu sein. Lediglich, wer auf HTML/JS setzt, hat da gute Karten.

Nehmen sie Metro doch einfach so, wie Microsoft es vorgestellt hat, als eine Umgebung für HTML/JS Apps.

Dann bin ich auf Einzelheiten gespannt. Ich meine, Sie spekulieren hier ins Blaue.

Nein ich treffe begründete Vorhersagen aufgrund meines halben Zweidrittel-Wissens über die Leistungsfähigkeit unterschiedlicher Prozessor-Architekturen. Eine Spekulation wäre es, die künftige Entwicklung von ARM und INTEL vorhersagen zu wollen, so z.B.:

Why You’ll Probably Never Own A Mac With An ARM Processor

Wenn das .NET-Framework nach ARM portiert wird, ist es dem Programm sowieso egal, worauf es läuft.

Abgesehen von dem Performance-Problem, das sich wohl nicht lösen lässt, ohne dass sich jemand den Code nochmal anschaut.

Die spannendere Frage ist, wie sich Microsoft die Portierung von WP7-Apps vorstellt, da ja Silverlight nicht mehr das Mittel der Wahl ist. Auch in Hinblick auf WP8.

Das ist vollkommen umspannend, denn diese Software läuft ja bereits auf ARM. Die muss nicht einmal neu kompiliert werden. Da gibt es dann halt eine Laufzeitumgebung für alte WP7-Apps und fertig.

Grundätzlich gibt es zwischen Silverlight- und WinRT-Klassen viele Schnittmengen. Aber eben auch einige unangehme Unterschiede.

Silverlight war doch auch nur Microsofts gescheiterter Versuch Adobe Flash zu kopieren. Für die Zukunft setzen Apple und Microsoft auf einen PlugIn-freien mobilen Browser. Flash war auch nicht performant genug, um den Übergang zum mobile Computing zu überstehen, warum sollte es dem kleinen Bruder Silverlight besser ergehen?

Auch das ist so nicht richtig. Ich frage mich, ob Sie sich ernsthaft mit dem Thema auseinandergesetzt haben. Der Grund, weswegen Windows 8 auf x86/x64 und ARM laufen soll, ist der, dass man ein Betriebssystem anbietet, wo die Mitbewerber 2 am Start haben. Vielleicht liegt da der Grundirrtum begründet, dass der Desktop abgelöst werden soll.

Nein, der Grund ist wie ich sagte, Microsoft will sein Monopol im PC-Bereich nutzen, um Entwickler für den Tablet-Bereich zu gewinnen. Und die PC-Nutzer sind dabei der Köder. Der Desktop soll dabei nicht abgelöst, aber ausgenutzt werden.

Zwar hat Apple zwei Betriebssysteme am Start, aber programmiert wird für beide in derselben Programmierumgebung (Xcode) in derselben Programmiersprache (ObjC), nur die Klassen, mit denen die Benutzeroberfläche geschrieben werden unterscheiden sich, weil sie sich unterscheiden müssen.

Bei Microsoft haben sie schon von vornherein zwei vollkommen verschiedene Programmiersprachen, eine objektorientierte (C#) und eine Skriptsprache (JavaScript). Unnötig zu sagen, dass sie da keine einzige Zeile Code wieder verwenden können. Darum sage ich ja, es gibt kein Pfund mit dem Microsoft wuchern kann.

[Guderian]

1. HTML/JS ist ein Hype, der recht bald abflauen wird. Das lustige an HTML5 ist, dass das noch nichteinmal verabschiedet ist.

Also HTML ist sicher kein Hype und wer Html-Seiten eine gewisse Funktionalität geben will, der kommt um JavaScript nicht drumrum.

2. Wer sagt denn, dass sich Microsoft an Standards hält? Es wird gemunkelt, dass Chakra-JS inkompatibel zum Browser-JS sein soll.

Dann ist Chakra also gar keine JS-Engine? Dann sollte man es vielleicht lieber JS++ nennen, in Anlehnung an J++.

3. Neben dem HTML5-Chaos spielt noch eine ganz andere Komponente gegen eine App für alle Plattformen rein: die UI. Jeder Hersteller hat andere Designvorgaben.

Eine App wie Cut the Rope hat keine Designvorgaben zu fürchten, sobald sie gestartet ist, ist alles nur noch Artwork.

4. Mit dem Mono-Framework steht ein Werkzeug zur Verfügung, mit dem - zumindest auf der Logikebene - für alle 3 Plattformen programmiert werden kann. Durch die saubere Schichtentrennung mit C# (MVVM) werden UI und Logik nicht vermanscht, so dass lediglich die UI für jede Plattform angepasst werden muss.

Also wie das Model View Controller Konzept in Xcode. Das Mono-Framework klingt interessant, für C#-Entwickler. Allerdings darf man auf dem iPhone nicht einfach so ein Framework installieren, d.h. jede C#-App müsste mit ihrem eigenen Mono gepackt werden, bei über 300 Apps sicher auch keine Patent-Lösung.

Für fast jede bekannte App aus der iOS-/Android-Welt gibt es einen Pendant.

Ich finde kein Pendant für iOutBank.

Die Macher von WhatsApp haben sich offiziell bis kurz vorm Mango-Update auch geziert, um dann pünktlich im September die Chartspitze zu übernehmen.

Und wie hoch sind die Downloadzahlen? Wieviel Geld wird mit Mango-Apps umgesetzt? Auf welcher Plattform erscheinen die neuen tollen Apps zuerst? Microsoft befindet sich bei Smartphones in derselben Situation wie Apple bei PCs, die Auswahl ist geringer und Titel erscheinen später.

Wenn ich in die Charts der gefragten Programmiersprachen schaue, ist Objective C zwar nach oben gegangen, hat aber mitnichten eine dominierende Stellung.

Wir reden nur vom Teilmarkt des mobile Computing. Und davon eigentlich auch nur über Tablets. Und da ist das iPad dominant.

Ich weiß soviel, dass Entwickler, die sowohl Objective C als auch Silverlight programmiert haben, von der Produktivität mit Silverlight schier begeistert sind.

Kann ja sein, aber ich weiß, dass die Handykäufer nicht von WP7 begeistert waren. Und wo keine Kunden, da keine Softwareentwickler.

Passend dazu eine Fallstudie, welche die Produktivität zwischen WP7 und Android vergleicht: Nilzor's Techblog: Android vs WP7 for developers - a case study Und den Vorteil soll man mit der obskuren Kombo HTML5/JS aufgeben?

Android kostet die Handy-Hersteller kein Geld, deswegen gibt es Android-Handys millionenfach. WP7 kostet Lizenzgebühren, deswegen gibt es nur wenige WP7-Handys. Die Leute, die heute für Android programmieren, benutzen kein Silverlight. Aber genau diese Leute muss Microsoft dazu bringen, ihre Apps nach Metro zu portieren.

[orbb]

Nehmen sie Metro doch einfach so, wie Microsoft es vorgestellt hat, als eine Umgebung für HTML/JS Apps.

Warum?

Nein ich treffe begründete Vorhersagen aufgrund meines halben Zweidrittel-Wissens ...

Nun wundert mich gar nix mehr.

Das ist vollkommen umspannend, denn diese Software läuft ja bereits auf ARM. Die muss nicht einmal neu kompiliert werden. Da gibt es dann halt eine Laufzeitumgebung für alte WP7-Apps und fertig.

Na was denn nun? .NET ist unperformant, deswegen geht es nicht, WP7-Apps sind in einer Laufzeitumgebung (?) welche aber .NET (Silverlight) ist? Verwirrung!

Silverlight war doch auch nur Microsofts gescheiterter Versuch Adobe Flash zu kopieren.

Ganz großes Kino! Einfach mal nachplappern, was man so gelesen hat, aber nicht wirklich wissen, was es ist. Silverlight ist eine Teilmenge der WPF und .NET, welches als Mini-Framework für verschiedene Szenarien ausgeliefert wird. Für den Browser ist es ein Plugin. Auf dem Windows Phone ist es fest integriert. Aber nicht (!) im Browser, der kann nämlich kein Silverlight.

Richtig ist auch, dass Silverlight thematische Überschneidungen, wie Filmstreaming und RIA, mit Flash hat. Silverlight geht aber weit über Flash hinaus und ist eher mit JavaFX zu vergleichen.

Zwar hat Apple zwei Betriebssysteme am Start, aber programmiert wird für beide in derselben Programmierumgebung (Xcode) in derselben Programmiersprache (ObjC), nur die Klassen, mit denen die Benutzeroberfläche geschrieben werden unterscheiden sich, weil sie sich unterscheiden müssen.

Ich glaube langsam, sie wissen es nicht besser oder lesen nicht richtig. Was hat XCode damit zu tun, dass die Intention von Microsoft ist, dass ein OS für alle Systeme ausgerollt wird? Das ist in erster Linie ein Vorteil für Microsoft, weil sie nicht verschiedene Plattformen separat pflegen müssen. Möglicherweise auch ein Vorteil für Administratoren, da sie alle Devices identisch pflegen können. Kompetent kann da sicher ein Administrator Auskunft geben. Das hat erstmal nix mit der Programmierung zu tun.

Bei Microsoft haben sie schon von vornherein zwei vollkommen verschiedene Programmiersprachen, eine objektorientierte (C#) und eine Skriptsprache (JavaScript). Unnötig zu sagen, dass sie da keine einzige Zeile Code wieder verwenden können. Darum sage ich ja, es gibt kein Pfund mit dem Microsoft wuchern kann.

Ja und? Für .NET gibt es zig Sprachen. Was genau der Vorteil ist, theoretisch. Jeder kann in seiner Lieblingssprache entwickeln und durch .NET verstehen sich trotzdem alle. Entscheidend sind die Schnittstellen. Ob es unter WinRT ähnlich sein wird, spekulation. Und falls Sie auf Plattformunabhängigkeit anspielen, die ist eh theoretisch, wie bereits weiter oben ausführte.

Also HTML ist sicher kein Hype und wer Html-Seiten eine gewisse Funktionalität geben will, der kommt um JavaScript nicht drumrum.

Oder programmiert serverseitig. Aber was haben HTML-Seiten mit einer App zu tun?

Dann ist Chakra also gar keine JS-Engine? Dann sollte man es vielleicht lieber JS++ nennen, in Anlehnung an J++.

Es ist eine. Die Frage ist, ob sie kompatibel ist.

[orbb]

Also wie das Model View Controller Konzept in Xcode.

Nicht wie. Ähnlich. MVC kennt kein ViewModel, welches explizit für die Datenaufbereitung zur Anzeige verantwortlich ist und nicht zum Datentopf durchgreifen darf.

Das Mono-Framework klingt interessant, für C#-Entwickler. Allerdings darf man auf dem iPhone nicht einfach so ein Framework installieren, d.h. jede C#-App müsste mit ihrem eigenen Mono gepackt werden, bei über 300 Apps sicher auch keine Patent-Lösung.

Nein. Mono übersetzt die fertige App native. Damit muss weder ein Framework installiert noch Apples Kontrolle gefürchtet werden. Bei HTML/JS ist es ja ähnlich. Da wird ja nicht die App in dieser Technik abgeliefert, sondern bekommt als Rahmen das WebBrowser-Control und wird dann ebenso native eingereicht.

Ich finde kein Pendant für iOutBank.

http://www.windowsphone.com/de-de/search?q=bank

Und wie hoch sind die Downloadzahlen? Wieviel Geld wird mit Mango-Apps umgesetzt?

TV Spielfilm vermeldet hohe Downloadzahlen im 100.000er Bereich. Hat man eine gute Idee, kann man auch als Hobbyentwickler auf hohe Downloadzahlen kommen. Es gibt Titel, die erscheinen exklusiv auf der Plattform. Es gibt Titel, die wurden bis heute nicht umgesetzt.

WhatsApp scheint nicht schlecht zu fahren, die schieben ein Update nach dem anderen raus. Aktuell sind die bei 1.7.

Wir reden nur vom Teilmarkt des mobile Computing. Und davon eigentlich auch nur über Tablets. Und da ist das iPad dominant.

Ja und? Es geht nicht nur um das hier und jetzt. Es geht auch um die Zukunft. Und da kommt man um die Windows-Plattform nicht drumherum. Da spielt die Gesamtverfügbarkeit schon eine große Rolle. Kommt ja nicht von ungefähr, dass Android von der Anzahl der Apps zu aufholen konnte. Die haben ein Becken voller Java-Entwickler, die sie relativ leicht auf die Spur setzen konnten.

Kann ja sein, aber ich weiß, dass die Handykäufer nicht von WP7 begeistert waren. Und wo keine Kunden, da keine Softwareentwickler.

Das ist definitiv falsch. Die, die ein Windows Phone gekauft haben, sind überdurchschnittlich zufrieden. Es gibt eher ein Problem, Windows Phone zu verkaufen, weil das schlechte Image von Microsoft und Windows Mobile wirkt.

Android kostet die Handy-Hersteller kein Geld, deswegen gibt es Android-Handys millionenfach. WP7 kostet Lizenzgebühren, deswegen gibt es nur wenige WP7-Handys.

Nein. Mit den Lizenzgebühren hängt das bestimmt nicht zusammen. Für die Gebühren bekommen die Hersteller Windows Phone mundgerecht serviert und haben nicht den Aufwand, Updates anzupassen wie unter Android. Dazu kommt, dass die Hersteller ja auch Aufwand haben, Android anzupassen. Deswegen ist das Argument "kostet nix" ein Nullargument.

"Kostet nix" ist auch eher die Philosophie von Google, um Android so weit wie möglich zu streuen, damit man Werbung generiert.

Die Leute, die heute für Android programmieren, benutzen kein Silverlight. Aber genau diese Leute muss Microsoft dazu bringen, ihre Apps nach Metro zu portieren.

Das mag sein. Da wende ich jedoch ein, dass Leute, die für Android entwickeln wegen der syntaktischen Verwandheit wohl eher zu Silverlight als zu HTML/JS greifen werden.