Les valeurs changent elles dans une DLL

Version imprimable

15/02/2017, 23h50
VRVI44

Les valeurs changent elles dans une DLL

Bonsoir

J'ai tâché de trouver un titre évocateur mais c'est pas simple donc je vais exposer mon souci

Bon déjà pour commencer je sais qu'il est possible de créer .DLL en c++ et les réutiliser dans un programme en C ou VB

Ce que je souhaiterais savoir c'est si un programme peut mettre à jour en temps réel des valeurs dans une bibliothèque et que ces dernières sois réutilisées dans un programme d'un autre langage

A l'heure actuel j'ai un programme ConsoleWin32 en c++ avec lequel je récupére des variables dans une partie de la mémoire de mon PC. C'est variables sont des paramètres de vol du simulateur Falcon BMS.
Je voudrais donc envoyer ces variables en temps reel dans une DLL pour les récupérer sur un autre programme sur lequel je pourrais avoir une interfaces graphique (bouton, affichage de texte)

Est-ce possible ?

Merci
16/02/2017, 03h31
Remilia

Bonjour. Non les DLLs ne sont pas faites pour stocker des donnés, mais des fonctions , rien a voir donc.

Par contre pour votre problème, vous pourriez juste utiliser un fichier de l'extension que vous voulez pour stocker vos données. Juste créez votre fichier d'extension .CeQueVousVoulez et mettez y les données demandées.

Cependant, si l'accès à vos données par l'autre programme se fait en temps-réel , cela risque de ne pas faire le boulot, car l'OS ne voudra pas 2 processus utilisant le même fichier, et même s'il le faisait, cela corromperait très facilement le fichier !

Il est étrange par ailleur que Windows selon votre post vous donne accès aux zones mémoires de ces variables,le privilège d'acces a toutes les adresses mémoires n'étant réservées qu'au kernel et aux drivers systèmes, ne connaissant pas Falcon BMS , je ne sais pas sous quelle forme vous recevez ces variables et ne peut pas vous aider dans un autre design sans d'autres informations.

Cependant, vous pourriez utiliser les pipes offertes par l'api Win32 pour communiquer entre 2 processus que vous créez. Cependant cela ne marchera pas en cross-language avec Visual Basic car à ma connaissance, Visual Basic n'intègre pas l'API WIN32. Cela fonctionnera cependant en C.

De toute façon , utiliser les fichiers comme vous ditent serait TRES mauvais , les temps d'accès disques créeraient des latances.

Ma question devient donc : pourquoi voulez-vous faire du cross-language alors que C++ peut gérer une interface graphique avec Win32 ou la SQL voir même Qt ?
16/02/2017, 10h00
Bousk

Si tu veux stocker des données et les réutiliser depuis un autre programme, on appelle ça une base de données, un fichier de sauvegarde ou n'importe quoi qui peut être lu/écrit.
Une DLL ça fournit principalement des fonctions et objets à utiliser, des trucs en read-only.

Citation:

Je voudrais donc envoyer ces variables en temps reel dans une DLL pour les récupérer sur un autre programme sur lequel je pourrais avoir une interfaces graphique (bouton, affichage de texte)

Quel est l'intérêt de passer par une DLL ? Renvoie directement tes valeurs à ton autre programme. :calim2:
16/02/2017, 10h39
VRVI44

Citation:

Envoyé par Remilia

Bonjour. Non les DLLs ne sont pas faites pour stocker des donnés, mais des fonctions , rien a voir donc.

Par contre pour votre problème, vous pourriez juste utiliser un fichier de l'extension que vous voulez pour stocker vos données. Juste créez votre fichier d'extension .CeQueVousVoulez et mettez y les données demandées.

Donc pour mes données je peut par exemple les écrire dans un fichier .txt que mon autre programme va venir lire

Citation:

Envoyé par Remilia

Cependant, si l'accès à vos données par l'autre programme se fait en temps-réel , cela risque de ne pas faire le boulot, car l'OS ne voudra pas 2 processus utilisant le même fichier, et même s'il le faisait, cela corromperait très facilement le fichier !

Mais vue que les 2 programmes vont accéder en même temps au fichier, l'un va écrire dedans et l'autres le lire , ça ne va pas fonctionner

Citation:

Envoyé par Remilia

Il est étrange par ailleur que Windows selon votre post vous donne accès aux zones mémoires de ces variables,le privilège d'acces a toutes les adresses mémoires n'étant réservées qu'au kernel et aux drivers systèmes, ne connaissant pas Falcon BMS , je ne sais pas sous quelle forme vous recevez ces variables et ne peut pas vous aider dans un autre design sans d'autres informations.

Alors le développeur de Falcon BMS à répertorié toutes les adresses mémoires, ainsi que les valeurs récupérées dans ces adresses dans un fichier nommé flightdata.h
Cela été fait dans le but de faciliter la tâche aux "pitbuilders" (constructeur de cockpit)

Citation:

Envoyé par Remilia

Cependant, vous pourriez utiliser les pipes offertes par l'api Win32 pour communiquer entre 2 processus que vous créez. Cependant cela ne marchera pas en cross-language avec Visual Basic car à ma connaissance, Visual Basic n'intègre pas l'API WIN32. Cela fonctionnera cependant en C.

Qu'est ce que c'est les pipes ?
Si je programme tout en C le cross-langage peut fonctionne c'est ça ?

Citation:

Envoyé par Remilia

De toute façon , utiliser les fichiers comme vous ditent serait TRES mauvais , les temps d'accès disques créeraient des latances.

Il est vrais que moins il y aura de latence et mieux ça sera donc oui les accès disque vont ralentir l'écriture et la lecture dans le fichier

Citation:

Envoyé par Remilia

Ma question devient donc : pourquoi voulez-vous faire du cross-language alors que C++ peut gérer une interface graphique avec Win32 ou la SQL voir même Qt ?

Disons que lorsque j'ai voulu utiliser Qt creator ça ne fonctionnais pas
Et dans visuel studio 2015 j'ai des erreur à la création d'un application WindowsForm
Tandis que sous visualisation basic ça fonctionne parfaitement

Citation:

Envoyé par Bousk

Si tu veux stocker des données et les réutiliser depuis un autre programme, on appelle ça une base de données, un fichier de sauvegarde ou n'importe quoi qui peut être lu/écrit.
Une DLL ça fournit principalement des fonctions et objets à utiliser, des trucs en read-only.

Donc ça rejoins ce que disait Remilia, j'envoie les données dans un fichier texte par exemple

Citation:

Envoyé par Bousk

Quel est l'intérêt de passer par une DLL ? Renvoie directement tes valeurs à ton autre programme. :calim2:

Je pensais qu'une DLL pouvais servir de base de données
Je vais essayer de les envoyer à mon autre programme en passant par une base de donné
16/02/2017, 14h30
Remilia

Etes vous sûr que Falcon BMS n'est pas censé marcher sur microcontrolleur ? Car le programme , s'il marche sous windows, doit passer par des allocations mémoires, et ne PEUT prédire les addresses mémoires qui vont lui être passés.

Un fichier en écriture seul et un autre en lecture seule peut être une bonne idée, après le format doit permettre de calculer "Je veux telle donnée" -> je lit a partir de tant de caractères, les données devront donc avoir une taille en caractère fixée. Notez cependant le scénario suivant : process 1 écrit a l'emplacement X. process 2 veut lire a l'emplacement X. Sauf que la donnée est réécrite en même temps , et donc la valeur lue est fausse pour process 2.

Les pipes sont des objets mis a disposition par l'api Win32 qui permettent de communiquer entre différents processus, un peu comme un réseau. Cependant, Visual Basic ne supporte pas l'api Win32 et ne "comprendrait" pas ces informations .

Vous pourriez coder votre Gui en Qt sans Qt Creator par ailleur, j'imagine que vous avez notamment eu des erreurs d'edition des liens.

Une bonne idée , via ce que j'ai compris de votre problème, et si vous voulez toujours le faire dans différents processus est :

Le processus qui récupère les données les mets dans un buffer (en triant les données "inutiles" au GUI) et les envoient à intervalles très courts.
Le processus qui gère l'interface recoit ses données , et en bon petit "zombie" les affichent.

Il faudrait par contre un délimiteur pour que le processus GUI comprenne, par exemple /// est la fin des données de XXX et le début de YYY.
16/02/2017, 14h58
bacelar

@Remilia, @Bousk, bon les gars, c'est bien de déconseiller des trucs casse-gueule aux personnes, mais c'est pas une raison pour dire des mensonges. :weird:

Oui, une Dll peut stocker des variables, qu'elles peuvent être partagées dans plusieurs programmes, mais c'est un truc tellement casse-gueule, qu'il y a des dizaines de procédés plus simple pour faire du partage de données.

Je vais faire la supposition que le simulateur partage ces données en utilisant de la mémoire partagée, cf. les "extern" en fin de code :http://www.foinikas.org/ftp/public/F...light%20Data.h
Si c'est pas des branquignols, ce qu'ils vous offrent comme outils permettent de gérer la concurrence d'accès sur cette mémoire partagée.

Les développeurs ne semblent pas vouloir faire une stratégie de le boite noire.
Je pense donc qu'il faut bien potasser la documentation de leur SDK pour ne pas réinventer la roue ni résoudre de faux problèmes.

Au vue du code et de l'utilisation de la mémoire partagée pour accéder à des objets, je pense qu'ils ne fournissent qu'une API C++.

Attention, l'utilisation d'un même langage, le C++, ne garantit en rien la compatibilité entre des modules binaires.
Le C++ ne standardise pas l'ABI, chaque compilateur fait ce qu'il veut.
Pour garantir la compatibilité, il faut avoir le même compilateur AVEC les mêmes réglages AVEC les mêmes versions des librairies.
Si ce n'est pas le cas, vous êtes dans la même situation que les développeurs avec d'autres langages : bricoler des trucs pour que les modules binaires se comprennent.

Citation:

Envoyé par VRVI44

Bon déjà pour commencer je sais qu'il est possible de créer .DLL en c++ et les réutiliser dans un programme en C ou VB

Là, vous avez une vue un peu trop schématique d'une DLL.

Une DLL, c'est un module binaire, comme un exécutable. C'est tout !!!

Après, il y a différent type de Dll (assemblies .NET, ressources pour programmes, conteneur de composant COM/ActiveX, bibliothèques dynamiques de code ET de données, etc...)

Le code/compilateur appelant doit savoir quel type de Dll il utilise pour adapter son appel aux types de Dll.

Ce n'est pas le langage de création de la Dll qui limite ou pas son utilisation par un executable mais son type et la manière dont elle "exporte" son API.

Si c'est une API C++, c'est un peu le pire des choix pour l'interopérabilité (mais le plus "simple").

Citation:

Envoyé par VRVI44

mettre à jour en temps réel

Le temps réel, de manière strict, cela n'existe que sur les OS temps réels, Windows n'est pas un OS temps réel.
N'utilisez pas ce mot valise, utilisez des mots qui veulent dire concrètement quelques-choses. (Temps moyen de réponse, mécanisme de synchronisation, etc...).

Citation:

Envoyé par VRVI44

c'est si un programme peut mettre à jour en temps réel des valeurs dans une bibliothèque et que ces dernières sois réutilisées dans un programme d'un autre langage

C'est un peu le principe de la mémoire partagée, dont j'ai parlé pour les "extern" dans le code.
C'est piégeux, c'est pour cela que le SDK doit disposer des mécanismes de sécurité.
Malheureusement, cela doit être probablement fait en C++ dans le SDK, il faudra donc vraisemblablement réécrire, si ce n'est pas fourni dans le SDK, l'équivalent du code du SDK dans l'autre langage pour pourvoir utiliser aisément depuis le code source de l'exécutable : c'est un wrapper.

Citation:

Envoyé par VRVI44

pour les récupérer sur un autre programme sur lequel je pourrais avoir une interfaces graphique (bouton, affichage de texte)

Pourquoi le programme ne pourrait-il pas y accéder directement, sans passer par le "programme ConsoleWin32 en c++" ?

Citation:

Envoyé par Remilia

Bonjour. Non les DLLs ne sont pas faites pour stocker des donnés, mais des fonctions , rien a voir donc.

Non, cela n'exporte pas que des fonctions, des données aussi peuvent être exportées !!!

Le passage par des fichiers peut sembler attirant, mais vous avez à peu près les mêmes problèmes qu'avec la mémoire partagé.
Cela ne règle que le problème de la représentation des données qui peuvent varier d'un langage à un autre, mais c'est vraiment pas le plus complexe sur des données simples.
Donc voir les possibilités du SDK, puis la possibilité du mapping mémoire via un wrapper, le fichier c'est en ultime recours.

Citation:

Envoyé par Remilia

Il est étrange par ailleur que Windows selon votre post vous donne accès aux zones mémoires de ces variables,

Ma mémoire partagée :zoubi:

Citation:

Envoyé par Remilia

Visual Basic car à ma connaissance, Visual Basic n'intègre pas l'API WIN32.

WHAT!!!!!!!!!!!!!!!!!!!!!!!!!!!
https://support.microsoft.com/en-us/...32-bit-program
et pour n'importe quel machine de Win32 :
https://msdn.microsoft.com/fr-fr/lib...or=-2147217396
et ça c'est pour VB6, en VB.NET c'est encore plus simple : Le Framework .NET.

Citation:

Envoyé par Bousk

Si tu veux stocker des données et les réutiliser depuis un autre programme, on appelle ça une base de données

@Bousk, c'est un tantinet réducteur, juste un tantinet. :weird::aie::weird:

Citation:

Envoyé par Bousk

Quel est l'intérêt de passer par une DLL ? Renvoie directement tes valeurs à ton autre programme.

Pareil ;)

Citation:

Envoyé par VRVI44

Tandis que sous visualisation basic ça fonctionne parfaitement

"visualisation basic" ça n'existe pas, "Visual Basic" tu veux dire, non ?
Mais "Visual Basic", c'est pour du VB6, et ça fait près de 20 ans que c'est plus utilisé, à moins de travailler dans un musée.
Donc ça doit être plutôt "Visual Studio pour VB.NET".
Franchement, si t'es capable de faire ton travaille en VB.NET, c'est la même chose en C#, et il est "facile" de faire un wrapper C++/CLI qui sera en C++ mais facilement appelable depuis n'importe quel langage .NET : on n'en revient au wrapper cité ci-avant.

Donc, il reste donc la question primordiale :
Pourquoi passer par une Dll quand le programme partage déjà sa mémoire ???
16/02/2017, 15h02
bacelar

Citation:

Envoyé par Remilia

Etes vous sûr que Falcon BMS n'est pas censé marcher sur microcontrolleur ? Car le programme , s'il marche sous windows, doit passer par des allocations mémoires, et ne PEUT prédire les addresses mémoires qui vont lui être passés.
...

Là, vous tirez des plans sur la comète et vous enfilez les erreurs.
MÉMOIRE PARTAGÉE !!!