none
Encapsulation d'une DLL (C/C++) dans un objet COM (ATL C++) RRS feed

  • Question

  • Développement sous VS 2010:

    dans web service WCF j'appelle un objet COM (ATL C++) (dans le but d'avoir une instance par session utilisateur). cet objet COM encapsule une DLL N°2 C/C++ (natif) qui communique avec une autre application. Au niveau de mon WCF et du COM la session utilisateur est bien chargée

    Problème: au niveau de la DLL N°2 il n y a qu'une seule instance qui est chargée.

    En principe, cette DLL doit être encapsuler dans la session de l'objet COM? quelqu'un a une idée?


    Cordialement

    lundi 21 juillet 2014 14:39

Réponses

  • Bonjour,

    Il s'agit probablement des effets de bords dont je vous parlais avec ce type de solution. Votre DLL C/C++ ne supportant qu'une seule session, nous avons configuré un pool, si le nombre d'appel surpasse le pool alors votre DLL n'est plus isolé (un composant COM supplémentaire se créé dans un dllhost possédant déjà un objet COM... On tombe alors sur un gros problème puisque la DLL C/C++ ne gérer qu'un composant par process).

    Il est possible avec COM+ de recycler les process et c'est exactement ce que nous allons tenter. Nous allons lui demander de pouvir recycler les process dès qu'un objet à été créé. En clair, si un objet COM est créé dans dllhost.exe, ce dllhoste.exe sera candidat au recyclage dès qu'il n'y aura plus de référence sur le composant COM.

    Tout d'abord, il faut veillez à ce que votre application ne tourne pas en tant que service (elle peut utiliser le compte Local ou Network service windows, mais ne doivent pas tourner en tant que service NT. Dans les propriétés de l'application COM+, dans l'onglet Activation, la case à cocher "Run application as NT Service" doit être décochée). Nous faisons ce réglage afin de pouvoir, dans l'onglet Pooling & Recycling, jouer sur les "limites". En mode service, ces réglages n'ont pas d'impact.

    Ainsi, dans Pooling & Recycling, mettez Activation Limit sur "1".

    Côté Pool Size, si vous n'étiez pas en mode AspNetCompatibility, on pourrait mettre la valeur de 16*Nb de processeurs sur vore machine, ceci afin de correspondre la valeur MaxConcurrentCalls par défaut... On adapterait ensuite MaxConcurrentSessions (par défaut à 100*Nb procc) à à MaxConcurrentCalls et le tour serait joué.

    Dans votre cas de figure, les réglages sur serviceThrottling n'ont pas d'effets (du moins à ce que j'ai pu constater par le passé). Vous allez donc être contraint aux valeurs grandioses d'IIS sur le nb max de connections et de requêtes par CPU... Nous n'allons donc pas nous accoder à ces valeurs mais mettre une valeur théorique max de votre nombre d'utilisateurs. Si ce chiffre est dépassé, comme nous avons réglé  l'ActivationLimit, il devrait  y avoir un TimeOut pr le nouvel utilisateur.

    Information importante... Pensez bien à releasé votre composant COM dès que vous n'en avez plus besoin  côté WCF (utilisation d'using/dispose si vs êtes en C#). Ceci libérera + rapidement les instances du pool.

    Bien cordialement,


    Fabrice JEAN-FRANCOIS, Novencia TS

    • Marqué comme réponse IghzerA vendredi 8 août 2014 09:10
    mardi 29 juillet 2014 16:27

Toutes les réponses

  • Bonjour

    Voir ce thread:

    http://social.msdn.microsoft.com/forums/en-US/fdc5e41c-80ac-4f5f-9c07-350cc83c2d87/multiple-instances-of-a-single-threaded-com-server

    Bien cordialement, 


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    mercredi 23 juillet 2014 07:01
  • Bonjour,

    Je crois je n'ai pas été claire dans ma question. mon objet COM (DLL) charge bien une instance propre à chaque client. Par contre, la DLL C/C++ classique (bibliothèque STL) qui est encapsulée (ou référencée) dans la DLL COM n'a qu'une seule instance pour toutes les instances COM crées.

    Mon objet COM est en APARTMENT_THREADED

    Merci pour votre aide.


    Cordialement

    mercredi 23 juillet 2014 09:25
  • Bonjour,

    Difficile de répondre à votre question car en pratique plusieurs cas sont possibles. Disons que tout va dépendre du fait que vous possédiez ou non les sources des DLL COM et C/C++ classique.

    Votre objet COM est en APARTMENT_THREADED, il est donc STA, c'est à dire que chaque objet COM créé peut être utilisé par son thread appelant sans encombre. En multithread, il y a le coût d'un thread de switch plus le fait que les appels sur le même objet sont  sérialisés. Bonne nouvelle pour vous, avec du WCF, vous devez probablement créé un objet COM par client, soit un objet COM par thread, le comportement souhaité est atteint.

    Toutefois, le fait de posséder un objet COM par client ne présuppose pas que tout se passe de la même façon côté DLL en C/C++ classique.

    Vous utilisez le terme d'instance, mais en fonction des technologies cela veut dire des choses différentes.

    Soyez bien accroché, lol... Je vais tenter d'être clair ;-p

    Ainsi, en C#, C++ et même Java, la création d''instance correspond à l'appel d'un new sur une classe. L'instance en programmation objet est donc l'instanciation d'une classe dans un espace d'adressage. Quelque-chose de simple au final. On réserve de la RAM pour y mettre des valeurs.

    En COM, la création d''instance correspond à un appel CoCreateInstance(Ex) sous-jacent. Vous ne le voyez probablement pas à partir de votre service WCF, mais il est bien là, tapis dans l'ombre. Les choses sont ici bien plus compliquées. L'instanciation COM correspond à l'instanciation d'un composant et non plus d'une classe. Le composant COM est un binaire qui peut s'appeler dans plusieurs langages et gérer des problématiques de localisation (sur une machine locale ou distante, on parle alors de DCOM), ainsi que des problématiques de threading (d'où la notion d'apartment) et même de transactionnel (l'équivalent d'un begin tran/commit tran en base de données. On parle alors de COM+, anciennement MTS). Concrètement, on réserve toujours de la RAM... Mais pas forcément au sein du même process, on peut être un serveur ActiveX, une surrogate, blablaba... On veut que l'appel soit simple pour le programmeur. Si le composant est distant ou transactionnel, tout se passe simplement... Donc on génère pour vous des proxy/stub, gère la sécurité, blablabla.... Bref, vous vous en rendez compte, pour gérer tout cela, on apporte une dose, une sacré dose de technologie.

    Pour une DLL, il y a également la notion d'instance... On parle même de HINSTANCE. C'est ce que vous obtenez comme référence (on dit encore HANDLE... d'où HINSTANCE pour HANDLE INSTANCE) lorsque vous chargez une DLL dans un EXE Widnows. Là aussi, il y a des histoires de RAM et de localisation à bas niveau mais très concrètement, Windows est superbement conçu. A chaque fois que vous chargez une DLL dans un EXE, il n'y a en réalité qu'un seul chargement. On ne va pas charger 10 fois la même DLL puisqu'elle contiendra le même binaire... On ne la charge donc qu'une fois.... Le principe va même plus loin. Pour économiser la RAM, si la même DLL, exactement la même est chargée par plusieurs process, on se partage le même binaire (et vi... super intelligent leur truc. C'est d'ailleurs même pour cela qu'on récupère un handle sur une instance et non pas l'instance elle-même^^)

    Autrement dit, et si vous me suivez tjs, votre DLL C/C++ et votre DLL COM ne sont chargées qu'une fois dans votre process WCF (ou IIS si vous passez par lui). Plus simplement dit, une seule instance de votre DLL C/C++ et une seule instance de votre DLL COM.

    Pourquoi cela fonction avec COM ? Parce que c'est indépendant de l'instance. Vous faîtes qq-part un new qui correspond à un CoCreateInstanceEx sur un objet COM STA qui voit un thread WCF et qui est propre à ce thread et qui possède ses propres valeurs.

    Pourquoi cela ne fonctionne pas avec la DLL bas niveau ? Parce que cela dépend du code de cette DLL bas niveau. Votre composant COM appelant change de monde en appelant la librairie. Si cette librairie n'exporte pas des objets mais des fonctions simples alors il est possible que cela finisse partagé entre toutes les instances de vos composants COM. Je reformule autrement. Chaque client WCF qui possède une instance COM propre finit par se retrouver dans un bout de code qui ne supporte non seulement pas le multithread mais pire, finit par taper dans les mêmes zones de données, donc se partage des variables, membres.

    Si votre DLL exporte des objets, et si elle est bien conçue (car il peut y avoir un singleton qq-part qui rende l'opéraiton impossible), alors la problématique vient de votre DLL COM qui gère en global les objets exportés par votre DLL bas niveau.

    Comment sortir de cette problématique ? Et bien tout dépend de votre possession du code de la DLL COM ou de la librairie. Si c'est votre propre code, on va s'en sortir^^... Sinon c'est plus compliqué. Si la DLL bas niveau est un composant externe, foncez dans la doc et regardez si elle exporte des objets et supporte le multithreading.

    Si vous ne possédez pas le code, téléchargez l'outils Dependencywalker (http://www.dependencywalker.com). Je sais le site est moche, mais l'outil était fourni avant par Microsoft avec VS Studio. Vous pouvez d'ailleurs vérifier ici (http://support.microsoft.com/kb/198038/fr) qu'il est encore conseillé. Chargez votre DLL bas niveau et regardez le nom des méthodes. Si c'est clair, alors elle exporte des fonctions classiques (style C). Si vous voyez des arobases et caractères bizarres, alors elle exporte du C++.

    Cherchez sinon si vous voyez qq part des pdb... Cela vous permettra de débugguer finement, même du compilé.

    Bon courage... Et merci de nous apporter qq précisions ^^

    Bien cordialement,

    Fabrice JEAN-FRANCOIS, Novencia TS

    mercredi 23 juillet 2014 16:54
  • Bonjour,

    Pour répondre à la première question, c'est oui j'ai à ma disposition tout le code (WCF, objet COM et la DLL C/C++). Le WCF est déployé sur un IIS 7.0 (et versions supérieures).

    Je suis d'accord avec votre explication du terme "INSTANCE", c'est juste pour expliquer ma problématique. Le vrai objectif : j'ai implémenté la session avec la compatibilité ASP.NET sur le WCF, cette session est crée pour chaque utilisateur (au sens propre du mot). Maintenant, il faut que la session du user doit être étendue (si on peut dire ainsi) jusqu'à la DLL C/C++, parce que  d'un point de vue métier, on se connecte avec le même login et un environnement (mémoire, var globales, ...) du user est initialisé dans DLL C/C++.

    La DLL C/C++, ne supporte pas le multi-threading et que un exe (dans mon cas w3wp.exe IIS Worker) ne peut chargé une DLL qu'une seule fois, d'où l'idée de passer par COM. La DLL C/C++ expose une quinzaines de fonctions (C), mais les points d'entrée exploités par l'objet COM sont des membres d'une classe (mais ces méthodes de classe appellent d'autres fonctions C ...). Cela dit, on ne peut pas dissocier les traitements de cette classe avec le reste : ex une struct USER déclarée en globale contient le profil utilisateur connecté.

    J'arrive à débugger la DLL C/C++ depuis le WCF (enfin, l'application complète est une app web Silverlight avec un web service WCF). Donc, quand un user se connecte dans l'app web, une session est initialisée dans le WCF et des attribues (ex: string de connexion) dans le COM et reste propre à ce user, mais pas la DLL C/C++ var globale USER = user1, si user2 se connecte aussi alors USER = user2 est user1 est perdu.

    NB: Concernant DependencyWalker: on peut aussi voir les points d'entrée d'une DLL avec DUMPBIN de l'outil ligne de commande de Visual Studio  (dumpbin /EXPORTS nom_complet_dll).

    J'espère avoir donner plus d'informations.

    Cordialement.


    Cordialement

    jeudi 24 juillet 2014 09:55
  • Bonjour, 

    Merci pour ces informations complémentaires mais je crains malheureusement que votre problème soit bien identifié, la struct USER étant globale, COM n'y peut absolument rien en mode in-process (DLL).

    Car bien que vous instanciez plusieurs composants COM, ils finissent tous par le pseudos singleton que constitue USER ou toute variable globale commune à votre DLL C/C++.  Aucune astuce ne peut vous sauver en mode "DLL COM" ne peut vous sauver des contraintes de la DLL C/C++.

    La vraie solution serait donc de casser cette dernière afin de ne plus avoir de variables globales et les mettre en paramètre de vos appels. Je sais toutefois que c'est plus facile à dire qu'à faire et que vous l'auriez assurément déjà fait si c'était aussi simple :-/

    Certains tentent des passages en  ThreadLocalStorage des variables globales car c'est très rapide à implémenter... N'y pensez même pas si vs voyez ce type de réponse sur internet. Si cela fonctionne au sein de services windows, c'est à proscrire au sein de IIS. Le thread de traitement d'une requête pouvant varier au sein de ce dernier, vous aurez de gros effets de bord. 

    Je vois une seconde option bien plus dangereuse et déconseillée en terme d'architecture. Vous pouver  tourner votre composant COM en composant out-of-process, c'est à dire en  exécutable. Ceci fait, l'appel à CoCreateInstance sous-jacent va créer un exe qui lancera votre DLL. La communication sera transparente du point de vue WCF puisqu'une proxy et une stub seront créées pr vous.  L'astuce consiste à enregistrer votre server COM en REGCLS_SINGLEUSE. Vous aurez ainsi la magie d'avoir un exe qui se lance par création de composant COM. Le problème étant évidemment d'avoir un exe par user... Si votre DLL n'est pas grosse, que vous n'avez pas trop d'utilisateur, alors c'est jouable si production/architecte/chefs de projet et consorts sont ok.

    Dans ce cas, pour aller plus vite, vous pourrez mettre en oeuvre la troisième solution. Elle possède les mêmes inconvénients que la seconde, est tout aussi dangereuse, déconseillée, mais immédiate à mettre en oeuvre : passer par des Components Services au lieu de créer l'exe COM.

    Autrement dit, passer par du COM+ 1.5, qui vous offre la possibilité d'enrober tout seul votre DLL COM (et donc la DLL C/C++) par un exe qui vous offre des fonctionnalités de pool et de contrôle d'instance. En clair, vous pourrez configurer le nombre max d'exe à créer automatiquement pour vous, limiter le nombre d'appel, la taille max en mémoire, la release automatique d'instance, etc. Voici les étapes (désolé, je suis au boulot et me base sur mon poste de travail en anglais. Vous devrez faire la traduction :-D) :

    • Allez dans le panneau de config, outils d'administration, puis lancez Component Services.
    • Créez une nouvelle application COM + "vide" sur votre machine, donnez lui un petit nom et mettez là en mode "Server Application".
    • Cliquez sur votre application COM+ nouvellement créez, bouton droit, propriétés. Dans l'onglet Pooling & Recycling, dans Pool Size mettez le nombre max d'utilisateur
    • Dans les "Legacy components", faites new, puis enregistrez votre composant COM
    • Cliquez sur le composant dans la liste "Legacy component", bouton droit, puis promote. Ceci fait il ne sera plus dans la liste Legacy mais désormais dans "Components".

    Ca y est, vous pouvez tester. Créer vous un petit fichier VBS sur votre bureau avec des lignes genre

    Set o =createobject("Simple.Fab2")
    o.Name = "Fabrice"
    Msgbox o.Name

    En remplace "Simple.Fab2" par bien évidemment le progId votre composant COM et une méthode adéquate

    Si vous lancez plusieurs fois votre script, vous verrez apparaître dans le Task Manager plusieurs process dllhost, ce qui signifiera que le pooling de composant COM fonctionne et que que chaque DLL C/C++  aura son propre exe donc sa propre isolation. Vous pourrez également observer dans Component Services l'icone en rotation de votre composant, ce qui signifiera son utilisation. 

    !!! Quelques détails de la plus haute importance !!

    • On s'oriente vers un exe par utilisateur, c'est pourri en terme de design, je sais :-D !! 
    • Le pool d'exe COM doit être supérieur au pool WCF afin d'être sûr qu'aucun composant COM se retrouve dans un exe déjà créé (car la finalité du pool COM+ est une ferme de service et non pas du lancement de process à la volée)
    • COM+ offre de nombreux services. Vous pourrez installer les composants COM sur d'autres machines et faire des appels à distance, etc

    P.S : Bien vu pour DUMPBIN, je l'utilise tellement peu que j'ai tendance à l'oublier ;-)

    Bien cordialement,

    Fabrice JEAN-FRANCOIS

    vendredi 25 juillet 2014 15:23
  • Bonjour,

    J'ai testé la 3ème solution COM+. Donc, j'ai crée le service de composant en "service local" avec 5 utilisateurs max et le rôle "CreatorOwner" avec mon User Windows qui administrateur de la machine Win7 Pro. J'ai ajouté le user Administrateur. Tout de suite après le démarrage, je vois 5 processus dllhost.exe qui se lancent.

    Quand je test l'objet avec script vbs ou directement avec mon application j'ai message d'erreur

    vbs : permission refusée

    WCF : "La création d'une instance du composant COM avec le CLSID {6B1FEB3E-C6A2-486C-AA29-BE8436086191} à partir de IClassFactory a échoué en raison de l'erreur suivante : 80070005 Accès refusé. (Exception de HRESULT : 0x80070005 (E_ACCESSDENIED))."

    J'ai testé le COM+ sur XPMode (xp virtuel de win7) est cela fonctionne avec le script vbs.


    Cordialement


    • Modifié IghzerA lundi 28 juillet 2014 14:03
    lundi 28 juillet 2014 12:07
  • Bonjour,

    Je vous propose de simplifier la partie sécurité pr vos tests.
    Sur votre application COM+, propriétés, dans Sécurité, pourriez-vous svp décocher la case "Enforce access checks for this application" et faire un nouveau test ?

    Si ça ne fonctionne tjs pas, pourriez-vs svp lancer votre vbs en mode administrateur ?

    Bien cordialement,


    Fabrice JEAN-FRANCOIS, Novencia TS

    lundi 28 juillet 2014 15:20
  • Bonjour, J'ai pu tester avec l'app web en désactivant la case à cocher. Il y a bien des envs distincts par session.

    Par contre, en jouant (mode debug) avec l'app et plusieurs sessions, j'ai réussi à faire planter plusieurs sessions (dllhost.exe) sans savoir comment exactement ni pourquoi pour l'instant. Je ne trouve pas qlque chose d'explicite dans les fichiers de trace Windows sauf un réf à ntdll.dll

    j'ai utilisé "Process Monitor" pour voir, j'ai trouvé ces messages:

    sur le dllhost.exe, c'est message qui revient souvent.

    Un autre message sur "propsys.dll" avec BUFFER TO SMALL

    et aussi des tentative de lecture de clé de registre introuvables.

    Ma question concerne surtout un fois que le processus a planté, y a t'il un moyen de le relancer automatiquement (avec une config par exemple)?


    Cordialement

    mardi 29 juillet 2014 12:46
  • Bonjour,

    Il s'agit probablement des effets de bords dont je vous parlais avec ce type de solution. Votre DLL C/C++ ne supportant qu'une seule session, nous avons configuré un pool, si le nombre d'appel surpasse le pool alors votre DLL n'est plus isolé (un composant COM supplémentaire se créé dans un dllhost possédant déjà un objet COM... On tombe alors sur un gros problème puisque la DLL C/C++ ne gérer qu'un composant par process).

    Il est possible avec COM+ de recycler les process et c'est exactement ce que nous allons tenter. Nous allons lui demander de pouvir recycler les process dès qu'un objet à été créé. En clair, si un objet COM est créé dans dllhost.exe, ce dllhoste.exe sera candidat au recyclage dès qu'il n'y aura plus de référence sur le composant COM.

    Tout d'abord, il faut veillez à ce que votre application ne tourne pas en tant que service (elle peut utiliser le compte Local ou Network service windows, mais ne doivent pas tourner en tant que service NT. Dans les propriétés de l'application COM+, dans l'onglet Activation, la case à cocher "Run application as NT Service" doit être décochée). Nous faisons ce réglage afin de pouvoir, dans l'onglet Pooling & Recycling, jouer sur les "limites". En mode service, ces réglages n'ont pas d'impact.

    Ainsi, dans Pooling & Recycling, mettez Activation Limit sur "1".

    Côté Pool Size, si vous n'étiez pas en mode AspNetCompatibility, on pourrait mettre la valeur de 16*Nb de processeurs sur vore machine, ceci afin de correspondre la valeur MaxConcurrentCalls par défaut... On adapterait ensuite MaxConcurrentSessions (par défaut à 100*Nb procc) à à MaxConcurrentCalls et le tour serait joué.

    Dans votre cas de figure, les réglages sur serviceThrottling n'ont pas d'effets (du moins à ce que j'ai pu constater par le passé). Vous allez donc être contraint aux valeurs grandioses d'IIS sur le nb max de connections et de requêtes par CPU... Nous n'allons donc pas nous accoder à ces valeurs mais mettre une valeur théorique max de votre nombre d'utilisateurs. Si ce chiffre est dépassé, comme nous avons réglé  l'ActivationLimit, il devrait  y avoir un TimeOut pr le nouvel utilisateur.

    Information importante... Pensez bien à releasé votre composant COM dès que vous n'en avez plus besoin  côté WCF (utilisation d'using/dispose si vs êtes en C#). Ceci libérera + rapidement les instances du pool.

    Bien cordialement,


    Fabrice JEAN-FRANCOIS, Novencia TS

    • Marqué comme réponse IghzerA vendredi 8 août 2014 09:10
    mardi 29 juillet 2014 16:27
  • Bonjour,

    J'ai déployé la solution sur un serveur de test (Win 2008R2) avec le paramétrage suivant:

    pool = 10, limit d'activation=1, délai d'expiration=2mn, limite de durée de vie=10mn

    j'ai joué avec 3 sessions utilisateurs, je fais planté les dllhost or je n’atteins jamais le nombre max d'instances (dans le gestionnaire de tâches Windows). (peut être aussi qu'il y a une fuite mémoire dans mon code?? je revérifie)

    Dans le WCF, les appels à l'objet COM se font dans les actions suivantes:

    - Login et Logout.

    - Simulation et validation (plantage à ce niveau). La durée d'une requête va de qlques secondes à + minutes

    Il y a aussi une chose que je précise, j'ai Modifié le WCF de tel sort à créer un nouvel objet du COM à chaque appel de celui-ci. Le code précédant, était de le stocker dans "System.Web.HttpContext.Current.Application" et le conserver pour toute la durée de vie de la session utilisateur, mais par moment l'objet est perdu et pourtant j'avais configurer la durée de vie de l'objet COM à 60mn.


    Cordialement

    mercredi 30 juillet 2014 15:29
  • Bonjour,

    Veuillez m'excuser pour la réponse tardive. Je marque la réponse de Fabrice comme solution puisqu'elle répond à la problématique.

    Je remercie Fabrice pour les détails des ses réponses.


    Cordialement

    vendredi 8 août 2014 09:15
  • Moi, j'ai, je pense, une 4ème solution, bien plus low-tech.

    C'est une solution proche de l'utilisation des TLS dans le principe.

    Le problème est, pour moi, de propager un contexte utilisateur entre les objets COM est le code C/C++.

    Pour moi, le plus simple est d'ajouter 2 fonctions C à la Dll C/C++.

    L'une pour créer un contexte utilisateur et qui retournera un handle opaque.

    L'autre pour détruire ce contexte utilisateur en lui fournissant l'handle opaque retourné par la première fonction.

    Il faudra modifier les fonctions déjà existantes de la Dll C/C++ pour qu'elles acceptent un paramètre de handle opaque en plus. Ce paramètre permettra de récupérer le contexte utilisateur, qui ne sera plus une globale mais dans une map globale. Ce contexte sera créé et ajoutée dans la mappe glogale par la 1ère nouvelle fonction et sera détruite par la seconde. Le mécanisme de récupération sera commun à toutes les fonctions exportées donc pourra faire l'objet d'une fonction interne à la Dll C/C++.

    Les modifications au niveau du composant COM, sera d'appeler la première nouvelle fonction avant tout autre appel, de récupérer l'handle pour l'utiliser dans les autres appels et d'appeler la seconde nouvelle fonction lors de ça destruction.

    Je trouve que l'ampleur de ce refactoting n'est pas colossale et facilement maintenable.


    Paul Bacelar, Ex - MVP VC++

    mardi 12 août 2014 13:01
    Modérateur
  • Bonjour Paul,

    Votre point de vu est intéressant, mais je ne comprends pas comment transformer une liste de var globales en une map globale en utilisant des paramètres HANDEL dans la DLL C/C++, puisque les adresses de ces var globales ne changent  pas.

    Par contre je comprends tout a fait l'idée et c'est l'objet d'une étude (disant qu'il ne s'agit pas seulement de cette DLL mais aussi une lib static Fortran compilée dans celle-ci et c'est exactement la même problématique)


    Cordialement

    mercredi 13 août 2014 09:44
  • Elles ne seront plus globales mais générées dynamiquement (1ère fonctions) puis détruite (2ème fonction).

    L'handle permet de récupéré ce "contexte" dans les appels suivants.


    Paul Bacelar, Ex - MVP VC++

    jeudi 14 août 2014 09:33
    Modérateur