DLL für Android oder iOS?

[zeras]

Hallo,

ich habe eine DLL für Windows, mit der ich auf eine Steuerung zugreifen kann. Nun wollte ich das ganze über Android oder iOS versuchen.
Gibt es generell ähnliche Möglichkeiten (ähnlich einer DLL für Windows) für Android oder iOS oder müsste der Hersteller der CPU mir die Sourcen zur Verfügung stellen? Bevor ich an den Hersteller herantrete, wollte ich mal fragen, ob es so etwas generell gibt, denn ich glaube kaum, dass er mir Quellen zur Verfügung stellen würde.

[himitsu]

Joar, im Prinzip gibt es .dll (Windows) .a .dylib (iOS) .so (Android) überall.

Nur ob es so einfach ist den Code in ein anderes OS zu portieren, hängt vorallem davon ab was innerhalb der DLL alles benutzt wird und ob und wie es das auch für die anderen Systeme gibt und wie groß der Aufwand ist das umzuschreiben.

Auf Delphi bezogen:
CreateFile gibt es in anderen OS so nicht und man muß die Windows-API-Aufrufe durch die entsprechenden APIs der jeweiligen OS ersetzen. (falls es dort Vergleichbares gibt)
Bei TFileStream hat Emba die Portierung bereits eingebaut.

Versuch mal ein VCL-Programm im iOS zum Laufen zu bringen. :zwinker:

[mjustin]

Zitat:

Zitat von himitsu (Beitrag 1282955)

Joar, im Prinzip gibt es .dll (Windows) .dylib (iOS) .so (Android) überall.

Marco Cantú schrieb neulich zum Thema "Using Open SSL in Delphi iOS":

Zitat:

In fact, as you probably know, on iOS you cannot use dynamic libraries but have to link external compiled libraries (.a files) to your executable.

Der Artikel beschreibt, wie man die Open SSL Bibliothek kompiliert und statisch (d.h. in die ausführbare Datei der App) linken kann.

Update: ab iOS 8 werden dynamische Bibliotheken untersützt:

http://stackoverflow.com/questions/4...hem-at-runtime

[himitsu]

Zitat:

Zitat von mjustin (Beitrag 1282983)

Update: ab iOS 8 werden dynamische Bibliotheken untersützt:

Wobei das Dynamisch nicht wirklich geklärt ist.
Sowas wie DLLs lassen sich doch in iOS schon immer laden. Es war nur das dynamische Laden (LoadLibrary) verboten, aber das statische Einbinden (via External-Aufruf) ging dennoch.

[arnof]

Zitat:

Zitat von himitsu (Beitrag 1282987)

Zitat:

Zitat von mjustin (Beitrag 1282983)

Update: ab iOS 8 werden dynamische Bibliotheken untersützt:

Wobei das Dynamisch nicht wirklich geklärt ist.
Sowas wie DLLs lassen sich doch in iOS schon immer laden. Es war nur das dynamische Laden (LoadLibrary) verboten, aber das statische Einbinden (via External-Aufruf) ging dennoch.

iOS ist sowas verboten no way! Kann man nur statisch via .a dazulinken lassen, hier gibt es ein Beispiel für den Barcodescanner (XE4)

Bei MacOSX gibt es, wenn das din in den Appstore soll so gut wie keinen weg, ich versuche hier nur seit Monaten ein Miniprg in den Store zu bekommen, gestern bekam ich wieder eine Ablehnung (echt zum :kotz: )

[Sherlock]

Ich finds eigentlich gar nicht schlecht, daß die Abhängigkeit von DLLs unterbunden wird. Monolithische Applikationen haben den entscheidenden Vorteil, daß sie nunmal einfach laufen, weil es keine Abhängigkeiten von Drittinstallationen gibt. Klar kann die DB kaputt sein oder sowas, aber das lässt sich fixen. Wenn man erstmal in der DLL-Hölle ist, lässt sich da auf potentiell tausenden Endgeräten wirklich nur noch schwer etwas machen. Das ist dann eine negative "User-Experience" und fällt am Ende immer auch auf den Gerätehersteller zurück.

Wenn man also unter Windows auf eine DLL angewisen ist, muss man sich eben bei anderen Systemen umsehen, ob man nicht ein Äquivalent fest einbinden kann.

Sherlock

[mjustin]

Zitat:

Zitat von Sherlock (Beitrag 1282998)

Ich finds eigentlich gar nicht schlecht, daß die Abhängigkeit von DLLs unterbunden wird.

Dass jede Anwendung ihre eigene OpenSSL Bibliothek einkompiliert haben muss, hat auch Nachteile. Nicht wegen der Speichernutzung, sondern weil jedes OpenSSL Update erst einmal vom App-Hersteller in die App integriert werden muss, Anwender eine Sicherheitslücke daher nicht selber schliessen können, sondern warten müssen bis das Update eintrifft.

[Sherlock]

Und SSL Routinen des OS zu nutzen geht nicht weil? Ernste Frage, denn ich brauch das für gewöhnlich nicht.

O'Neill

[himitsu]

Bei den mobilen "Apps" ist das doch Anders.
Die laufen quasi alle unabhängig und nutzen keine gemeinsamen Fremdkomponenten.
Jede App bringt ihre eigenen Fremdkomponenten mit und somit gibt es diese DLL-Hölle aus Windows nicht, welche dort auch nur auftritt, wenn die DLLs in irgendwelchen globalen Verzeichnissen rumliegen.

[Sherlock]

Meine Rede. Ich wollte nur noch erläutern, warum das mMn so ist.

Sherlock

[mjustin]

Zitat:

Zitat von himitsu (Beitrag 1283004)

Bei den mobilen "Apps" ist das doch Anders.
Die laufen quasi alle unabhängig und nutzen keine gemeinsamen Fremdkomponenten.
Jede App bringt ihre eigenen Fremdkomponenten mit und somit gibt es diese DLL-Hölle aus Windows nicht, welche dort auch nur auftritt, wenn die DLLs in irgendwelchen globalen Verzeichnissen rumliegen.

Unter Android werden SSL Funktionen von der Android Umgebung direkt bereitgestellt (z.B. HttpsUrlConnection), sie müssen nicht mit der eigenen App mitgeliefert werden. Das bedeutet natürlich, dass man auf die Sicherheitsfixes angewiesen ist, die je nach Hersteller schnell, langsam, oder überhaupt nicht eintreffen.