2010-10-22 4 views
0

Actuellement, je développe une DLL qui est destinée à être liée à des applications tierces afin de tester si cette application est éligible pour s'exécuter à un moment donné.symbian: point d'entrée DLL pour EKA2 ou similaire?

D'abord j'ai pensé à créer une DLL et gérer la vérification nécessaire dans la fonction TInt E32Dll(). Mais j'ai été très surpris quand j'ai lu que cette fonction n'est pas appelée sur DLL load/unload dans EKA2.

Maintenant, j'ai besoin d'un autre moyen pour accomplir ma tâche. Mon but est de créer un mécanisme qui peut être intégré dans des applications tierces. Ce mécanisme doit être appelé au démarrage de l'application, effectuer une vérification (présence du serveur Symbian spécifique), et si la vérification échoue, il doit terminer l'application. Une autre exigence est que ce mécanisme soit au mieux transparent pour les développeurs de ces applications tierces. (La fonction E32Dll() était le meilleur candidat - il suffit de lier une bibliothèque spécifique à un projet et vous avez terminé ...)

J'apprécierai beaucoup d'autres idées. Merci d'avance.

Répondre

0

Je ne suis pas sûr que faire quelque chose dans E32Dll() même si cela fonctionne (mais il ne fonctionne pas comme vous le comprendre) est un bon moyen, car avant de fermer l'application, vous devez afficher une notification ou un dialogue utilisateur. Pourquoi ne pas faire une DLL normale + mince du code de démarrage, qui charge (en utilisant le RLibrary) et appeler la 1ère fonction ordinale:

RLibrary library; 

//UID 
TUidType uidType(TUid::Uid(KDynamicLibraryUidValue), 
        TUid::Uid(KMyInterfaceUid), 
        TUid::Uid(KMyImplementationUid)); 

// Open dll 
User::LeaveIfError(library.Load(KMyDll, uidType)); 

// Check the exported method  
TLibraryFunction ordinal1 = aLibrary.Lookup(1); 

// Call the method... 
if (ordinal1) 
    ordinal1(); 

library.Close(); 

BR Sten


Salut Haspemulator, Il est ma réponse à votre commentaire:

1) non, le 1er ordinale n'est pas E32Dll(), cette méthode ne peut pas être appelé depuis EKA2. Vérifiez la description ci-dessous (http://developer.symbian.org/wiki/Symbian_OS_Internals/10._The_Loader):

Notez que, dans EKA2, le point d'entrée DLL public, E32Dll (TDllReason) n'est plus appelé. Cette fonction doit être présente dans chaque DLL EKA1, pour être appelée lorsque la DLL est attachée ou détachée d'un processus ou d'un thread. Malheureusement, ce système de point d'entrée ne peut fournir aucune garantie que E32Dll() sera appelé avec le paramètre approprié à l'heure spécifiée. Parce qu'il n'est pas possible de supporter cette fonctionnalité de manière fiable, EKA2 supprime son support. Cette suppression simplifie l'architecture du noyau pour la gestion du code chargé dynamiquement, ce qui améliore la fiabilité et la robustesse.

2) Vous pouvez trouver une discussion intéressante au sujet de ce sujet aussi ici: http://discussion.forum.nokia.com/forum/showthread.php?80781-What-is-the-replacement-for-E32Dll-and-TDllReason

3) Dans notre cas, le 1er ordinale sera la 1ère fonction vous exporter à partir de la DLL. Vous pouvez trouver des informations comment écrire une telle DLL ici: http://developer.symbian.org/main/documentation/reference/s3/pdk/GUID-4A56B285-790E-5171-88F3-8C40B2AA9699.html

4) Pour être plus concret ce que je veux dire en exportant une méthode de DLL, vérifiez le code ci-dessous (la méthode peut bien sûr retourner une variable - par exemple nouvellement créé objet):

EXPORT_C void InitDll() 
{ 
    // Put here your code 
} 

Espérons que cela aide ... BR Sten


+0

La première fonction ordinale est-elle toujours E32Dll()? – Haspemulator

+0

Salut, j'ai mis mon commentaire en réponse originale, puisque le commentaire a limité l'espace ... BR – STeN

1

Je l'ai effectivement trouvé un moyen d'atteindre mon objectif - appeler une méthode lorsque DLL est chargé. L'idée m'a été donnée au http://developer.symbian.org/forum/showthread.php?p=30244.

Il suffit de déclarer un objet global dans un module DLL, et son constructeur sera appelé quand la DLL sera chargée. Cette solution fonctionne bien pour moi, et, en effet, cette réponse devrait vraiment être acceptée ...

... Mais puisque je ne suis pas l'auteur de cette solution, et la réponse actuellement acceptée contient encore des informations précieuses, je ' ll ne changera pas la marque d'acceptation. Laissez-le être. :)

+0

Salut, c'est une idée intéressante! Juste être conscient des inconvénients possibles de celui-ci - mais je ne suis pas sûr à leur sujet: 1) Les données statiques normalement inscriptibles ne sont pas autorisés dans la DLL, mais vérifiez le drapeau EPOCALLOWDLLDATA. 2) Comment allez-vous charger la DLL? Si vous utilisez la bibliothèque RL, alors mon chemin est plus pratique, mais si vous voulez vraiment l'automatiser et que vous utiliserez la liaison statique, je ne suis pas sûr de ce qui est réellement initialisé au moment de la création de l'objet DLL, par ex. sera le CleanupStack initialisé ou non? 3) Il y a quelques limitations sur ce qui peut et ne peut pas être fait dans les constructeurs sur Symbian ... BR STeN – STeN

+0

Merci pour l'idée de vérifier la pile de nettoyage! Je suis assez sûr que toutes les bibliothèques sont initialisées avant le point d'entrée principal, donc il n'y aura pas CleanupStack et ActiveScheduler. Et, bien sûr, ce truc ne doit pas partir ... – Haspemulator

Questions connexes