bei Android kann ich zumindest in nativen Code voll auf den Kernel zugreifen, wenn ich es nötig hab...
Aber auch nur, wenn du eine Lücke findest um dein Smartphone zu rooten...
Findest du so etwas für iOS oder Windows Phone geht das dort genauso.
Selbst wenn ich das Phone nicht roote habe ich unter Android noch immer mehr Zugriff auf das System als unter Windows Phone oder iOS, da es sich nämlich bei nativen Anwendungen (auch wenn sie nur native Libs eines Java Stubs sind) um volle Linux Anwendungen/Bibliotheken handelt. Und zumindest das Syscall Interface vom Kernel ist voll zugreifbar (FPC nutzt ja dieses, statt die C-Bibliothek). Inwieweit das Dateisystem und dabei insbesondere /dev ohne Root zugänglich ist, kann ich grade jedoch nicht sagen, da ich das bisher noch nicht ausgetestet habe.
Aber mal völlig wertfrei gefragt: Was motiviert einen, auf den Kernel seines Smartphones zugreifen zu wollen? (Jenseits eines softwaretechnischen Spieltriebs)
Ich halte mir solche Möglichkeiten gerne offen. Wie ich bereits geschrieben habe, habe ich bisher noch nicht die Notwendigkeit gehabt damit rumzuspielen, aber wer weiß was die Zukunft bringt
(und ja, der softwaretechnische Spieltrieb ist da natürlich auch mit dabei und trägt bei mir auch immer stark zur Wahl meiner Systeme bei)
Gib es da, ausser "Gefällt mir nicht", auch noch nachvollziehbare Gründe für?
Hauptgrund: Ich kann dafür nicht mit FPC entwickeln. Und fang mir hier jetzt bitte nicht mit ner .Net vs. Delphi/FPC oder Oxygene vs. Delphi/FPC Diskussion an. Für mich ist das ein Grund. Punkt
Nee, ich wollte nur nach potentiellen allgemeingültigen Gründen fragen. Und das hier ist ein *sehr* spezieller individueller Grund.
Allgemeingültige Gründe hab ich nicht. Mich macht Windows Phone unabhängig von FPC auch einfach nicht so sehr an wie Android.
Wobei ich mir nicht vorstellen kann, warum das nicht gehen sollte? Man kann mit normalen C++ für WP8 entwickeln. Warum sollte das mit FPC nicht gehen?
Ja, seit WP8 hat sich die Sachlage wieder etwas geändert, aber das sind dann ja WinRT Anwendungen und hier müssten wir erstmal einen eigenen Port für schreiben, da für einige Kernfunktionen der
RTL über die C++ Runtime gegangen werden muss statt wie bisher direkt über die
WinAPI. Deswegen kann Delphi ja auch noch kein natives WinRT... Es müsste halt nur mal einer machen und auch wenn mich ein WinRT Port potentiell interessieren würde, habe ich aktuell nicht die Zeit dazu...
Gruß,
Sven