Nokias Smartphones kommen mit Windows Phone 8 und Dual-Core-CPU

Die ersten Geräte werden die Cortex-A9-Dual-Core-CPU U8500 von ST-Ericsson einsetzen. Dafür muss Microsoft erst einen neuen Kernel entwickeln. Der aktuelle unterstützt nur ausgewählte Single-Core-Modelle von Qualcomm.

So sollen Nokia-Handys mit Windows aussehen (Bild: Nokia).
So sollen Nokia-Handys mit Windows aussehen (Bild: Nokia).

Nokia wird keine Windows-Phone-7-Smartphones auf den Markt bringen, sondern nächstes Jahr gleich mit Windows Phone 8 als Betriebssystem an den Start gehen. Das erklärte Carlo Bozotti, CEO von STMicroelectronics, gegenüber dem Forbes-Magazin.

Laut Bozotti hat sich Nokia dafür entschieden, für sein erstes Smartphone mit Windows-Betriebssystem die NovaThor-CPU U8500 von ST-Ericsson einzusetzen. Im Laufe des Jahres 2012 werde der finnische Hersteller zwölf weitere Windows-Phone-Handys auf Basis künftiger Versionen des U8500 anbieten. ST-Ericsson ist ein Joint-Venture zwischen STMicroelectronics und Ericsson.

Der U8500 ist ein SoC-Computer auf Basis einer Dual-Core-CPU mit zwei ARM-Cortex-A9-Kernen. Der Kernel von Windows Phone 7 – ein Hybrid aus Windows CE 6.0 und 7.0 – unterstützt jedoch keine Multi-Core-CPUs. Offensichtlich arbeitet Microsoft an einem neuen Kernel für sein Smartphone-Betriebssystem, der vollständig auf Windows CE 7.0 basiert und SMP für ARM-CPUs bietet. Windows CE 7.0 ist am 1. März 2011 unter dem Namen „Windows Embedded Compact 7“ erschienen.

Der Name Windows Phone 8 für eine neue Version seines Smartphones-OS ist von Microsoft bisher nicht bestätigt, gilt aber als wahrscheinlich. Auch technische Details hat Microsoft noch nicht bekannt gegeben. Am Dienstag wird das Unternehmen in Berlin zunächst das sogenannte Mango-Update für Windows Phone 7 vorstellen, das im Herbst erscheinen soll und dessen Features bereits bekannt sind. Details finden sich in dem ZDNet-Artikel „Windows Phone 7: mit Mango endlich auf iPhone-Niveau?„.

Bisher erlaubt Microsoft Hardwareherstellern nur die Qualcomm-Snapdragon-Modelle QSD8250 und QSD8650 als CPU zu verwenden. Sie verfügen lediglich über einen Core und werden in der veralteten 65-Nanometer-Technologie hergestellt. Für das marktführende Android-Betriebssystem sind bereits zahlreiche Dual-Core-Modelle erschienen, etwa das LG Optimus Speed, das HTC Sensation und das Samsung Galaxy S2. Bei Microsoft wird es mit Dual-Core-Unterstützung wohl dauern, bis Nokia die ersten Geräte mit Windows Phone 8 bringt.

Windows Phone 7 ist bisher wenig erfolgreich: Gestern veröffentlichte Gartner die Verkaufszahlen für Mobiltelefone mit Smartphone-Betriebssystemen. Trotz des im Oktober 2010 erschienenen Betriebssystems hat sich Microsofts Marktanteil gemessen an den Neuverkäufen im 1. Quartal 2011 gegenüber dem Vorjahresquartal fast halbiert. Er sank von 6,8 auf 3,6 Prozent. Von den knapp 3,7 Millionen verkauften Smartphones laufen nur etwa 1,6 Millionen mit Windows Phone 7. Die übrigen sind mit dem veralteten Betriebssystem Windows Mobile ausgestattet.

Hinzu kommt, dass Gartner auf Schätzungen angewiesen ist. Microsoft hat lediglich bekannt gegeben, dass es seit dem Marktstart zwei Millionen Geräte verkauft habe. Die Redmonder veröffentlichen aber keine Zahlen darüber, wie viele Handys von den Nutzern aktiviert wurden. Das ist ein sicherer Hinweis darauf, dass sich die bei Händlern befindlichen Geräte als Ladenhüter erwiesen haben.

Windows Phone 7 bietet Kritikern zahlreiche Angriffspunkte: Da der Kernel keinerlei Security beinhaltet, muss Microsoft den Zugriff auf sensible Daten über User-Mode-APIs beschränken und erlaubt keine nativen Applikationen. Entwickler haben derzeit keinen Zugriff auf Geräte wie Kamera oder Kompass. Der Internetzugang ist auf URIs beschränkt, was etwa die Entwicklung von VoIP-Apps verhindert. Ferner lassen sich native Anwendungen wie Mozilla Firefox oder Adobe Flash nur mit einem so hohem Aufwand portieren, dass die Entwickler davon Abstand nehmen. Mit Mango erhält Windows Phone 7 zwar zahlreiche zusätzliche APIs, aber der native Zugang bleibt Entwicklern weiterhin verwehrt.

Das wird sich auch mit Windows Phone 8 vermutlich nicht ändern, denn auch Windows Embedded Compact 7 besitzt keine Sicherheitsmechanismen im Kernel. Entwickler werden weiterhin nur die APIs nutzen können, die Microsoft unter hohem Zeitdruck schafft, in .NET und C# zu implementieren.

Themenseiten: Betriebssystem, Ericsson, Handy, Hardware, Kommunikation, Microsoft, Mobil, Mobile, Nokia, Smartphone, Windows Phone

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

7 Kommentare zu Nokias Smartphones kommen mit Windows Phone 8 und Dual-Core-CPU

Kommentar hinzufügen
  • Am 25. Mai 2011 um 10:30 von Skeptiker

    Welche Kernel Sicherheitsfunktionen fehlen?
    Hallo,

    in ihren Artikeln erwähnen Sie immer überdeutlich, dass der Windows Embedded Compact 7 Kernel keine Sicherheitsfunktionen bieten würde. Können Sie das genauer erläutern? Ein Blick auf die Produktseite listet mir aber Sicherheitsfunktionen auf wie:
    – Address Space Randomization randomizes the load address of DLLs in Compact 7, reducing the possibility of successful attacks based on guessing where DLLs are located in the virtual address space
    – Data Execution Prevention, ensures malicious code can?t execute outside of data pages (available only on ARM v7 processors only)
    – Kerberos 5.0, provides compatibility with Windows
    – NT LAN Manager v2, provides compatibility with Windows

    Darüber laufen ja normale Anwendungen seit eh und je unter CE im Usermode und und nicht im Kernelmode.

    Ich halte diese Aussage von Ihnen auch deshalb fragwürdig, weil ja die Vorgängerversionen von WP7 (und somit basierend auf CE 6) als äußerst sicher galten und auch in Unternehmen weit verbreitet waren. Und da konnte man ebenfalls native Programme entwickeln.

    Ich halte es für wahrscheinlicher, dass man mit WP7 die normalen 3rd Party Entwickler einfach gleich zu .NET und Silverlight zwingen möchte, weil das ja auf dem Desktop nicht so einfach war/ist, wie sich das Microsoft erhofft hat (gerade was den Einsatz von WPF betrifft).

    Außerdem bietet die Plattform durch die Laufzeitumgebung einen gewissen Standardschutz auch eine gewisse Prozessorunabhängig. Keiner weiß ja richtig, wohin die Reise im mobilen Bereich geht und ob die ARM Architektur auch weiterhin Nummer 1 bleibt, wenn die Leistung auch immer mehr steigt.

    • Am 25. Mai 2011 um 13:33 von Christoph Hochstätter

      AW: Welche Kernel Sicherheitsfunktionen fehlen?
      Es fehlt die grundsätzliche Funktion, dass alle Prozesse mit einem Security-ID ausgestattet werden und dass das Filessystem ACLs besitzt, so dass man sicherstellen kann, dass beispielsweise nicht jede App einfach die Kontaktdatenbank auslesen und „nach Hause tetefonieren“ kann.

      Da diese Funktion fehlt, ist Microsoft gezwungen, den nativen Zugang zum Betriebssystem zu unterbinden und APIs nur über einen Managed-Code-Layer (.NET/C#) zu erlauben, der sicherstellt, dass Apps nicht auf die Daten anderer Apps zugreifen können.

      • Am 25. Mai 2011 um 15:20 von Skeptiker

        AW: AW: Welche Kernel Sicherheitsfunktionen fehlen?
        Hallo,

        Um auf das Filesystem zu schreiben/lesen, wird doch eh Isoltated Storage verwendet, der an die App gekopelt ist. D.h. eine Fremdanwendung kann eh nicht auf den Isolated Storage einer anderen Anwendung zugreifen (mit oder ohne managed Code). Dazu kann man das ganze ja noch extra verschlüsseln.

        Die Anwendungen selbst laufen ja auch unter verschiedenen Privilegien. Ob das nun im nativen Prozess gehandelt wird oder auf .NET Ebene ist eigentlich egal. Alle 3rd Party Anwendungen laufen mit den geringsten Privilegien (wahrscheinlich ähnlich UAC).

        • Am 25. Mai 2011 um 17:04 von Christoph H. Hochstätter

          AW: AW: AW: Welche Kernel Sicherheitsfunktionen fehlen?
          Isolated Storage ist auf der .NET-Ebene realisiert. Eine native App auf dem WP7-Kernel hat immer Vollzugriff auf das Dateisystem. Deswegen verbietet das Microsoft.

          Verschlüsselung funktioniert auch nicht, weil der Schlüssel irgendwo abgelegt sein muss. Also könnte ihn jede App auslesen. Es sei denn, jede App muss nach dem Schlüssel, z.B. in Form eines Passworts, jedes Mal den Benutzer fragen, bevor sie Zugriff bekommt

          • Am 25. Mai 2011 um 18:15 von Skeptiker

            AW: AW: AW: AW: Welche Kernel Sicherheitsfunktionen fehlen?
            Also ob das Konzept von Isolates Storage durch .NET APIs oder nativen APIs umgesetzt wird, ist doch letztendlich egal. Die entsprechende API (on .NET oder nativ) könnte immer anhand des aufrunfenden Prozesses und der damit verbundenen Anwendung sowie den Privilegien unter denen die Anwendung läuft prüfen, ob der Zugriff über die API erlaubt ist oder nicht.

            Und da alle 3rd Party Anwendungen mit den geringsten Privilegien ausgeführt werden und auch nicht nativ sind, kann eben nicht jede Anwendung auf das gesamte Dateisystem zugreifen.

            Mit der Verschlüsselung hat man leider immer das Problem, dass am lokalen Rechner oder sobald man Speicher ausbaut und woanders dranhängt, man nie 100%ige Sicherheit hat. Daran ändern auch keine ACLs, um an den Schlüssel zu kommen, wenn man denn möchte.

  • Am 25. Mai 2011 um 8:16 von Maddin

    Ok
    … vergesst den Post – die meinen von allen WINDOWS-basierten; ok, dann mag das sein 8-)

  • Am 25. Mai 2011 um 8:12 von Maddin

    Prozentsatz?
    „Von den knapp 3,7 Millionen verkauften Smartphones laufen nur etwa 1,6 Millionen mit Windows Phone 7.“

    Ich glaube, davon träumen so manche in Redmond… So die eine oder andere Zehnerpotenz ist da wohl abhanden gekommen :-)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *