Artikel: Windows Phone wird internationaler Unterstützung von nativem Code kommt später

Zitat:

---

Zitat von StevieBallz

Über die Grafiken gab es einiges an Diskussion (bzgl. deren Klarheit) aber was du hier siehst sind die WinRT-APIs auf denen dann entweder C#/VB.Net Managed läuft oder eben C++ mit nativem Zugriff (bzw. in C++ funktioniert das ganze dann über das altbekannte COM).

Nachzulesen, z.B. hier: http://www.heise.de/developer/artike...artikelseite=2

---

Jetzt erklär mir bitte noch warum das indirekte Aufrufen der Kernelfunktionen durch eine Komponente WinRT und die Com Methode (die MS nach Managed mit Native Code verbindet) nativer Code ist, während der gleiche Vorgang woanders Managed Code ist. Die WinRT (Windows Runtime) bietet eine Laufzeitumgebung in der C++ und C# sowie javascript Apps laufen, also alles Managed Code... Das WinRT dann nativ läuft ergibt sich, heißt aber längst nicht, dass eine C++ Metro Awendung nativ läuft.

Wenn allerdings bei Win Phone das genauso umgesetzt werden soll, dann nehme ich alle zurück, dann ändert sich ja quasi nichts.

Mann, Mann, Mann, du und der StevieBallz, ihr schenkt euch nix, oder?
Kampf der Superbrains.... :P ;)

Aber wenigstens kann ich jetzt sicher sein, das mir hier von kompetenten Leuten Rat gegeben wird.... ;)
Mit der kostenlosen PocketPC.ch App von meinem 7 Mozart aus geschrieben.

Native Code => Code wird kompiliert und liegt in Maschinensprache vor, haben wir ja eingangs festgestellt. Dies ist bei WinRT und C++ der Fall. Also ich schreibe C++ Code und am Schluss kommt x86, x64 oder ARMv7 Maschinencode heraus. Speicher wird über die C-Standard APIs vom Betriebssystem angefordert, direkte Operationen auf den Speicheradressen inkl. Pointerarithmetik ist möglich.

Managed Code => Code wird kompiliert und liegt dann in MSIL vor, wird von der Common Language Runtime Just in Time in Maschinencode übersetzt (im Falle von Microsofts CLR nämlich immer, bei Javas Hot Spot VM nur die kritischen Teile). An dieser Stelle können noch zusätzliche Checks durchgeführt werden. Speicher wird von der CLR und dem dazugehörigen Garbage Collector verwaltet (auch bei Managed C++).

Die WinRT ist auch wenn sie Runtime heißt eigentlich keine Laufzeitumgebung wie die CLR sondern eine neue API zur Systemkommunikation, die Metro-Anwendungen anstatt des Win32-API nutzen (müssen). Letzten Endes wird hier bei Windows Phone und Windows 8 derselbe Mechanismus bzgl. Sandboxing genutzt werden. Also zumindest insofern ist es gleich sicher/unsicher. Aber was definitiv der Fall ist, ist dass eben der Code direkt in den Befehlssatz der Zielmaschine übersetzt wird => Native Code und er trotzdem nicht alles tun können wird.

Hier nochmal ein Bild das den Sachverhalt ein bisschen übersichtlicher darstellt als das von Microsoft damals bei der Präsentation genutzte (wie gesagt, es gab zu dem Bild aus genau den Gründen wieso wir hier diskutieren einige Unsicherheit): http://1.bp.blogspot.com/-uUSc-JjjBD...w-platform.png

Diese nativer Code Unterstützungsgeschichte hat aber nicht zufällig was mit dem Interop Unlock zu tun?
Oder ist der Interop Unlock wieder ganz was anderes (da wird auch von nativem Code geredet)?

Interop ist ein Verfahren, um nativen Code von Managed code aus aufzurufen. siehe http://pinvoke.net/