Windows phone - top oder flop?

Zitat

Original geschrieben von Gag Halfrunt
Der Kernel ist derselbe, die Anwendungsschicht unterscheidet sich. Und RT ist kein "vollständiges" Windows, da ja die ganzen x86-Anwendungen nicht darauf laufen.
Die Universal-Apps laufen sowohl auf Windows Phone, als auch auf Windows für ARM und x86.

Das dachte ich auch erst. Bis ich die letzten Wochen von einem studierten Informatiker aufgeklärt wurde. Grundsätzlich laufen bzw. können alle Windows Programme auch unter Windows RT zum laufen gebracht werde. Sie müssen "nur" vorher transkodiert werden. Und damit kann es dann zu Problemen kommen. Es gab aber schon einige, erfolgreich Versuche, wie er meint. Nur ist es halt ein sehr großer Aufwand.

Und ob bzw. Das Windows RT doch ein vollständiges Windows ist, zeigt sich ja in den ganzen, möglichen Einstellungen und Systemanwendungen.

Zitat

Und ob bzw. Das Windows RT doch ein vollständiges Windows ist, zeigt sich ja in den ganzen, möglichen Einstellungen und Systemanwendungen.

So ist es. Genaugenommen liegt Windows 8.1 RT von den Features irgendwo zwischen Windows 8.1 und Windows 8.1 Pro. Beispielsweise läßt sich mit Windows 8.1 keine Gruppenrichtlinien modifizieren, wohl aber mit RT und Pro. (gpedit.msc)

Nochmal:

Ich meine nicht die Möglichkeit, dieselbe Anwendung auf verschiedenen Windows-Versionen lauffähig zu bekommen.

Was ich meine ist eine Ankündigung, nach der es kein Win RT mehr geben wird. Wenn ich den Bericht (leider erinnere ich die Quelle momentan nicht) richtig verstanden habe, soll es ein gemeinsames mobiles Windows geben, welches gleichermaßen auf Tablets und MobilePhones läuft. Vor diesem Hintergrund würde eine Anpassung der Apps überhaupt nicht notwendig sein, weil auf beiden Geräteklassen dasselbe Betriebssystem (1:1) läuft.

Oder habe ich etwas grundlegend falsch verstanden?

(Natürlich wird es weiterhin Tablets mit dem Windows für PC geben)

Edit

Vielleicht noch mal so:
Windows RT wird eingestellt. Tablets wird es danach nur noch mit Windows und WindowsPhone (Tablets "light") geben. Zudem habe ich in Erinnerung, dass WindowsPhone vor diesem Hintergrund wieder in Windows CE oder WindowsMobile umbenannt werden soll.

Ich bin mir sicher, dass ich den Bericht (vor wenigen Tagen) so verstanden hatte. Weil alles plausibel klang, hatte ich den Inhalt nicht in Frage gestellt und mir die Quelle daher auch nicht zur Verifikation gemerkt.

Zitat

Was ich meine ist eine Ankündigung, nach der es kein Win RT mehr geben wird. Wenn ich den Bericht (leider erinnere ich die Quelle momentan nicht) richtig verstanden habe, soll es ein gemeinsames mobiles Windows geben, welches gleichermaßen auf Tablets und MobilePhones läuft.

Naja da muss man mal trennen, was Microsoft selbst gesagt hat und was versucht wird von verschiedenen Blogs zu interpretieren (meist aus Unwissenheit)

Technisch wird es weiterhin Windows (egal ob x86 oder ARM) und Windows Phone als zwei getrennte Entwicklungen geben. App Kompatibilität wird man wohl versuchen herzustellen. Feature parity? - no way!
Davon unabhängig stellt sich praktisch die Frage, ob Microsoft in Zukunft weiterhin Windows oder doch eher Windows Phone für seine eigenen Tablets vorsieht.
Letzteres halte ich einfach für dumm weil dann ein Surface mit einem Schlag sämtliche liebgewonnen Features verlieren würde während alle konkurrierenden Tablets (mit x86) weiterhin Windows benutzen würden.

Zitat

Windows RT wird eingestellt. Tablets wird es danach nur noch mit Windows und WindowsPhone (Tablets "light") geben

Du hast es noch nicht ganz verstanden. Windows RT gibt's es aus Entwicklungs-Sicht faktisch nicht und kann deshalb auch nicht eingestellt werden. RT _IST_ Windows für ARM übersetzt.
Es handelt sich einfach nur im die Frage ob Microsoft weiterhin Windows oder Windows Phone für seine Tablets benutzten wird.

Zitat

Original geschrieben von frank_aus_wedau
Vor diesem Hintergrund würde eine Anpassung der Apps überhaupt nicht notwendig sein, weil auf beiden Geräteklassen dasselbe Betriebssystem (1:1) läuft.

Oder habe ich etwas grundlegend falsch verstanden?

Ich glaube schon, daß du da wirklich etwas grundsätzlich falsch verstehst. Schon jetzt laufen die Universal bzw. Windows Runtime Apps sowohl auf Windows (RT) als auch Windows Phone, weil eben seit 8.1 alle Systeme (Windows, Windows RT und Windows Phone) die Windows Runtime (Apps) 1:1 unterstützten (extrem hypothetisch: würde Microsoft die Windows Runtime auf Android portieren, können auch dort die Windows Apps 1:1 laufen). Microsoft will ja auch alle drei Systeme/Varianten dann mit der nächsten Version 10 einfach nur noch "Windows" nennen.
Aus Entwicklersicht ist es jetzt schon unwichtig ob die App auf Windows RT oder Windows Phone laufen wird. Es müssen nur fürs Publishing im Windows Store auch alle Geräte(klassen) freigegeben werden. Anpassungen einer App an Bildschirmgrößen, -auflösungen und Pixeldichten etc sind immer eine Frage der UI/UX Anpassung- was aber auch schon für die sehr unterschiedlich ausgestatteten Lumias gilt, man vergleiche nur das Lumia 1520 mit dem Lumia 520.
Und aus Entwicklersicht gab und gibt Microsoft für Windows RT auch nur Windows Runtime Apps zur Installation von Drittanbietern frei (natürlich nur via Windows Store)- macht also auch keinen Unterschied zu Windows Phone. Windows RT kann/könnte für ARM rekompilierte Win32 Anwendungen (siehe MS Office) und natürlich .NET Anwendungen ausführen, was aber Microsoft so gut wie möglich zu verhindern versucht.
Aus Anwendersicht bietet Windows RT -wie Tala schon geschrieben hat- aber sehr viel mehr Möglichkeiten als Windows Phone.
Edit: Oder um es mal so zu sagen- hätte Microsoft schon gleich 2012 zum Start von Windows (Phone) 8 Universal Apps (und die entsprechende Developer Tool Unterstützung) mitgebracht, würde WP heute wahrscheinlich schon besser dastehen...

Das verdeutlicht natürlich einiges und lässt den von mir erinnerten Bericht möglicherweise in einem anderen Licht erscheinen.

Ich hatte mich immer schon gefragt, warum Software für verschiedene Windows-Versionen nicht (in geeigneten Fällen) dieselbe Programmiersprache nutzt, so dass sie sie unter allen Versionen lauffähig ist, wodurch über die Implementierung passender Schnittstellen bereits in der Vergangenheit Kompatibilitätsprobleme hätten vermieden werden könnten - was nun wohl durch die gemeinsame Runtime-Umgebung realisiert wird.

Gerade für Synchronisationssoftware (aber nicht nur) würden hieraus immense Vorteile resultieren.

Für mich ist es ohnehin ein Armutszeugnis, dass mehrere Outlook-Installationen nicht schon entwicklerseitig miteinander kommunizieren können. In MS OneNote macht Microsoft vor, wie eine perfekte Koexistenz mehrerer Installationen zu organisieren ist. OneNote ist für mich zwischenzeitlich der Dreh-und Angelpunkt meiner Arbeit am privaten PC. Nur Outlook-Installationen auf Clients machen bei der Synchronisation nicht mit.

Zu welchem mobile OS ich tendiere, ist noch nicht raus ... durch die Adaption von MS Office an Android hat Microsoft die Karten für mich neu gemischt.

Dennoch würde ich im Zweifel zu Microsoft tendieren - denn mit diesen Produkten bin ich groß geworden. Meinen ersten eigenen IBM-PC (XT) muss ich um 1983/1984 erworben haben - dessen IBM PC-DOS war mit MS DOS weitestgehend identisch. Danach war ich IBM bis zur Mitte der 1990er Jahre treu geblieben, Microsoft bis zum heutigen Tage. Das prägt wohl fürs Leben ...

Zitat

Original geschrieben von frank_aus_wedau
Ich hatte mich immer schon gefragt, warum Software für verschiedene Windows-Versionen nicht (in geeigneten Fällen) dieselbe Programmiersprache nutzt, so dass sie sie unter allen Versionen lauffähig ist, wodurch über die Implementierung passender Schnittstellen bereits in der Vergangenheit Kompatibilitätsprobleme hätten vermieden werden könnten - was nun wohl durch die gemeinsame Runtime-Umgebung realisiert wird.

Du wirfst da ein bisschen was durcheinander. Ich versuche da mal, ein wenig Licht hinein zu bringen.

Fangen wir beim Prozessor an. Es gibt unterschiedliche Prozessoren. Jeder Prozessor hat einen bestimmten Satz an Operationen, die er ausführen kann, und einen unterschiedlichen Aufbau. In Windows-PCs steckt ein Prozessor der x86-Familie drin, die seit 20 Jahren nach demselben Schema aufgebaut sind und über den gleichen Befehlssatz beherrschen. Mit jeder Prozessorgeneration werden diese weiter entwickelt, optimiert und erweitert. Der Grundstock bleibt jedoch derselbe. So kannst du auch heute noch einen modernen Prozessor mit denselben Befehlen wie vor 20 Jahren steuern. Es sind jedoch auch neue hinzu gekommen, die bestimmte Operationen vereinfachen oder beschleunigen.

Ein Programm ist nichts weiter als eine Aneinanderkettung von Befehlen und Speicheroperationen, die der Prozessor ausführt.

Da diese Maschinensprache jedoch sehr umständlich ist, gibt es Programmiersprachen, die das vereinfachen. Der Quellcode eines Programms ist also in einer bestimmten Sprache geschrieben, aber wird am Ende wieder in Maschinencode übersetzt, damit das auf dem Prozessor läuft.
Dabei gibt es zwei Varianten: Entweder übersetzt man den Quellcode einmalig in eine Datei mit Maschinencode, die dann so direkt ausführbar ist. Das nennt man Kompilieren.
Oder man nutzt einen Interpreter, der bei jeder Ausführung des Programms den Quellcode direkt übersetzt.
Ein kompiliertes Programm liegt im fertigen Maschinencode vor und kann sofort ausgeführt werden. Jedoch muss man diesen Maschinencode für jeden Prozessor einzeln erzeugen.
Ein interpretiertes hingegen muss während der Ausführung übersetzt werden. Dabei kann dann jeweils der Interpreter verwendet werden, der den Befehlssatz des jeweiligen Prozessors kennt. Das hat den Vorteil, dass man nicht für jeden Prozessor eine eigene Version des Programms zur Verfügung stellen muss, sondern nur den Quellcode, den Rest erledigt der Interpreter dann zur Laufzeit. Das kostet jedoch Rechenleistung, weshalb diese Programme wenig performant sind.

Natürlich gibt es noch diverse Zwischendinger, also dass ein Programm vorkompiliert ist, so dass der Interpreter dann weniger Leistung benötigt.

Doch leider ist das alles nicht so einfach, denn auch innerhalb der Programmiersprache verwendet man zwangsläufig Befehle und Strukturen, die von der jeweiligen Plattform abhängen, auf der man arbeitet. Das betrifft zum Beispiel die Größe von Variablen, die u.a. davon abhängt, ob man ein 8-, 16-, 32- oder 64-Bit-System verwendet. Ohne jetzt zu sehr ins Detail gehen zu wollen: Diese "Bit"-Angaben besagen, wieviele Daten parallel vom Prozessor verarbeitet bzw. mit dem Speicher ausgetauscht werden kann.
So muss auf einem System mit schmaler Busbreite z.B. eine Rechenoperation mit großen Zahlen in mehrere Einzelschritte aufgespalten werden, da die gesamte Zahl nicht in eine Speicherzelle passt. Musst du dir so vorstellen wie die angezeigten Stellen bei deinem Taschenrechner.

All diese kleinen Unterschiede führen dazu, dass ein Programm, auch wenn es in einer eher allgemeinen Programmiersprache verfasst ist, nicht so ohne weiteres für einen anderen Prozessor kompiliert oder interpretiert werden kann.

Darum gibt es noch eine Möglichkeit: Eine Virtuelle Maschine.

Die bekannteste Variante ist Java. Die Java-VM ist nichts anderes, als ein Simulator eines Prozessors, der immer gleich ist. Das Java-Programm hat also immer dieselbe Umgebung, die Java-VM kümmert sich dann darum, dass dies in die Befehle, Variablen, usw. übersetzt wird, die das jeweilige Gerät kennt. Es ist also auch eine Art Interpreter, nur dass eben hier alles simuliert wird.

Deshalb laufen Java-Programme auch auf einem Windows-PC genauso wie auf einem Mac, sind jedoch auch keine Performance-Wunder.

So. Das wäre erstmal die Prozessor-Seite. Jetzt zum Betriebssystem. Dessen Aufgabe ist es, über standardisierte Schnittstellen einem Programm eine Umgebung zur Verfügung zu stellen, um z.B. ein Dateien von der Festplatte zu lesen, Fenster zu zeichnen oder einen Ton abzuspielen. Das Programm muss nicht wissen, was das für ein Datenträger ist, welcher Monitor angeschlossen ist oder welche Soundkarte im Rechner steckt. Das erledigt alles das System.

Auch hier haben wir jetzt wieder das Problem, dass jedes Betriebssystem natürlich andere Schnittstellen zur Verfügung stellt. Ein Windows-Programm läuft daher nicht unter Linux und auch nicht auf dem Mac, auch wenn in allen drei Rechnern derselbe Prozessor steckt.

Bei Java wird auch das alles so weit standardisiert gekapselt, dass das Programm immer dieselbe Umgebung vorfindet, aber die Java-VM sich eben darum kümmert, dass ein Dateitzugriff bei Windows so, bei MacOS eben so läuft.

Eine solche Generalisierung hat den Vorteil, dass man eben nicht plattformspezifisch programmieren muss, aber den Nachteil, dass man nicht die spezifischen Eigenschaften der jeweiligen Plattform nutzen kann. Man einigt sich innerhalb der Java-VM eben mehr oder weniger auf den kleinsten gemeinsamen Nenner.

Womit wir jetzt zur Windows Runtime kämen. Im weitesten Sinne könnte man diese Technik mit der Java-VM vergleichen. Eine Universal App unter Windows nutzt die Windows Runtime, um den generalisierten Befehlssatz auf dem jeweiligen System nutzen zu können. Aber genau genommen sind es intern letztlich mehrere Programmversionen, die sowohl plattformspezifische als auch universelle Teile enthalten können.
Ich schrieb ja bereits, dass der Kernel des Betriebssystems der gleiche sei. Das ist nicht ganz richtig, denn selbstverständlich haben ARM und x86 unterschiedliche Systemkerne. Sie bieten jedoch zur Anwendungsseite hin dieselben Schnittstellen und verhalten sich auch gleich. So kann eine Anwendung eben sowohl unter ARM, als auch unter x86 auf dieselben Funktionen des Betriebssystems zugreifen.
Unterschiede gibt es dann jedoch wieder bei den höheren Schichten, wie z.B. die Oberfläche oder die Peripheriegeräte.

Warum kann man nun ein herkömmliches Windows-Programm nicht auf Windows-Phone oder Windows RT laufen lassen, wenn es doch zur Anwendungsseite derselbe Kernel ist? Ganz einfach. War gibt es dieselben Basis-Schnittstellen zum Betriebssystem, jedoch sind diese Programme für einen bestimmten Prozessortyp kompiliert – nämlich x86. Und bei Windows Phone sind eben nicht alle Schnittstellen vorhanden, wie auf dem "richtigen" Windows.

Ich hoffe, dass das damit ein bisschen klarer wurde. Also soooo einfach ist das alles nicht. Man hat eben immer die Wahl zwischen hoch performanter Software, die dann plattformspezifisch sein muss, oder eine universelle, die dann in einer Zwischenschicht an Leistung einbüßt.

Zitat

Für mich ist es ohnehin ein Armutszeugnis, dass mehrere Outlook-Installationen nicht schon entwicklerseitig miteinander kommunizieren können.

Selbstverständlich kann Outlook das – über den Exchange-Server. Denn genau dafür wurde Outlook entwickelt und ist in dieser Form weltweit millionenfach im Einsatz. Und wenn mir diese Bemerkung erlaubt sei: Erst mit einem Exchange-Server kann man mit Outlook richtig gut arbeiten. Es funktioniert bestens, alle Geräte sind stets synchron. Egal, ob ich einen Kalendereintrag im Handy setze oder an einem meiner PCs – Sekunden später sind die anderen Clients auf dem aktuellen Stand. So muss es sein.

Zitat

In MS OneNote macht Microsoft vor, wie eine perfekte Koexistenz mehrerer Installationen zu organisieren ist. OneNote ist für mich zwischenzeitlich der Dreh-und Angelpunkt meiner Arbeit am privaten PC. Nur Outlook-Installationen auf Clients machen bei der Synchronisation nicht mit.

OneNote erzeugt Dateien, genauso wie Word, Excel, usw. Da wird nichts "synchronisiert".

Für die Synchronisierung ist ein Sharepoint Server notwendig – oder eben neuerdings die Cloud.

Ui, das war doch mal ein langer Beitrag.
Danke, schön ausführlich alles erklärt.

Edit: Skype geht jetzt nach Neustart wieder.

Zitat

Für mich ist es ohnehin ein Armutszeugnis, dass mehrere Outlook-Installationen nicht schon entwicklerseitig miteinander kommunizieren können.

Eigentlich ist das ziemlich vernünftig. Outlook ist ein Client und kein Server. Der Lehre nach synchronisieren sich alle Clients mit dem Server und nicht die Clients untereinander. Outlook hat demnach auch keine Server Funktionalität eingebaut.
Wenn man irgendwas "lokal" synchronisieren möchte ist in fast allen Fällen eine on-premises Server Installation das Mittel der Wahl.

Zitat

In MS OneNote macht Microsoft vor, wie eine perfekte Koexistenz mehrerer Installationen zu organisieren ist

Hmm, wär mir neu dass OneNote ohne Server irgendeine Synchronisations-Funktionalität hätte, mal von der Möglichkeit abgesehen das Notebook zu speichern und mit einem anderen Client zu laden.

Zitat

Original geschrieben von Gag Halfrunt
...
OneNote erzeugt Dateien, genauso wie Word, Excel, usw. Da wird nichts "synchronisiert".

Für die Synchronisierung ist ein Sharepoint Server notwendig – oder eben neuerdings die Cloud.

Das ist nicht richtig!

In meinem Netzwerk betreibe ich 5 Rechner mit MS OneNote. Das Notizbuch ist auf allen Rechnern synchron. Ändere ich mit Rechner 1 was im Notizbuch und rufe dann mit Rechner 5 das Notizbuch auf, erscheint es dort selbstverständlich mit den zuvor an Rechner 1 vorgenommenen Eintragungen.

Gemeinsame Notizbücher werden in Echtzeit synchron gehalten, solange sich OneNote-Installationen im Netzwerk befinden. Außerhalb des Netzwerks auf mobilen Geräten vorgenommene Änderungen werden beim Einbuchen ins heimische Netzwerk automatisch synchronisiert.

Und das ganz ohne Serverstruktur. Während dabei die Daten stets sternförmig zwischen Server und Clients ausgetauscht werden und der Server die Referenz des aktuellen Datenbestands bildet, kommunizieren OneNote-Installationen direkt untereinander und übernehmen vom Partner den jeweils aktuellsten Stand, so dass die Teilmenge der im Netzwerk befindlichen Rechner immer auf gleichem Stand ist. Es reicht also, dass immer irgendeiner der Rechner eingebucht ist, um immer auf dem aktuellsten Stand zu sein, sobald man sich einloggt.

Diese abweichende Form der Vernetzung von Geräten existiert schon lange und wird verschiedentlich eingesetzt. Jede Argumentation, OneNote könne dies nicht, wird durch die Realität widerlegt.

Durch diese Funktionalität halte ich gerade OneNote für einen wichtigen Bestandteil der Software auf mobilen Geräten, die daheim Anbindung an ein Windows-Netzwerk haben. Zudem eignet sich OneNote als "Universalanwendung" für viele Bereiche, denn die Funktionalität von OneNote geht weit über die eines Notizbuchs hinaus.