Discussion :

[user8]

Bonjour tout le monde,

Je travaille actuellement sur une application chargeant une dll.
Cette Dll a besoin de différentes variables d'environnement pour fonctionner.
Ces variables ne sont pas définit dans mon windows.

Voila donc ce que je fais :
- Mon application se lance
- Mon application définit les variables via SetEnvironmentVariable
- Si je recupère mes variables via GetEnvironmentVariable je peux constater que tout est correct.
- Je charge ma dll via un loadlibrary

... mais cela ne fonctionne pas. Il semble que la Dll utilise l'environnement existant avant que je redéfinisse les variables.

Si je lance mon application via un batch qui set mes variables, cela fonctionne.


Savez-vous de quelle manière la dll recupère-t-elle l'environnement à utiliser ?
Existe-t-il un moyen pour lui dire d'utiliser l'environnement du process qui la charge?
CreateProcess permet de définir un environnement, n'y a t il pas le même fonctionnement pour une dll?

Merci d'avance pour votre aide.

[ShaiLeTroll]

SetEnvironmentVariable : Sets the contents of the specified environment variable for the current process.
On pourrait penser qu'une DLL charger par un processus partage ses variables d'environnement !

Que donne GetEnvironmentStrings ?

Ces variables d'environnement sont spécifiques à ton application ?
Un fichier conf (ini, cfg, xml ...) ou la BDR serait peut-être plus appropriés ?
Je crois n'avoir jamais utilisé les variables d'environnement à part dans les options de Delphi

En général, c'est les programmes d'installation d'un produit comme InnoSetup, InstallShield ... qui définisse les variables d'environnement, ensuite le programme installé les utilisent (mais n'en ajoute pas à la volée)

[user8]

Tout d'abord, merci pour la réponse.

GetEnvironmentStrings me retourne la variable correctement définit.

Malheureusement, je n'ai pas le choix. Je dois utiliser les variables d'environnement. Je n'ai pas accés au contenu de la dll ce qui ne simplifie pas le problème. La dll a été développé en C++.

J'ai fait un test entre une application et une dll delphi, les variables sont correctement partagés.

Peut-etre existe-t-il en C++ la possiblité de récupérer les variables de windows plutot que celle du process en cours?

[ShaiLeTroll]

J'ai fait un test entre une application et une dll delphi, les variables sont correctement partagés.

Ah, intéressant !
Tu utilises une DLL fourni par un tiers, hum, c'est DLL avec exports ou c'est un objet COM ?
Faudrait contacter l'auteur si il a des détails à ce sujet, perso, je n'ai jamais vu ça, une API bien faite fourni les fonctions de configuration et ne suppose de variables existantes (où alors le SDK dipose d'une InstallSetup ...)

Je serais toi, je modifierais ces variables pour un programme d'installation de ton programme, cela évitera de perdre trop de temps à ce sujet !

Regarde la fonction BOOL SetEnvVariable(LPSTR szName, LPSTR szValue, CMO cmo);, j'ai ça dans le SDK fourni avec C++Builder 6, mais je ne l'ai pas trouvé dans les sources ???

[Paul TOTH]

Tout d'abord, merci pour la réponse.

GetEnvironmentStrings me retourne la variable correctement définit.

Malheureusement, je n'ai pas le choix. Je dois utiliser les variables d'environnement. Je n'ai pas accés au contenu de la dll ce qui ne simplifie pas le problème. La dll a été développé en C++.

J'ai fait un test entre une application et une dll delphi, les variables sont correctement partagés.

Peut-etre existe-t-il en C++ la possiblité de récupérer les variables de windows plutot que celle du process en cours?

ce serait surprenant...ne charges-tu pas la DLL en statique en plus du LoadLibrary ? elle serait alors déjà en mémoire...

[user8]

ShaiLeTroll : c'est Dll avec export. Cette dll ne fait qu'exporter des fonctions d'un .LIB. Il s'agit d'un "pont" entre delphi et une lib c++.

Paul TOTH : La dll n'est chargé qu'une fois et dynamiquement.

[ShaiLeTroll]

Cette dll ne fait qu'exporter des fonctions d'un .LIB. Il s'agit d'un "pont" entre delphi et une lib c++.

C'est étrange ce que tu dis là !
le fichier .LIB fourni avec une DLL ou issu de implib.exe (car C++Builder utilise un format différent), c'est en fait la liaison statique d'une DLL qui joue un peu le rôle d'un obj, en général, le fichier LIB ne contient rien de fondamentalement intéressant, en delphi, cela se remplace par une série de external !
le Fichier .LIB sert donc à importer les fonctions exportées d'une DLL, pas l'inverse !

Dans un fichier Lib, tu peux inclure des obj, que tu peux extraire avec tlib.exe
C'est peut-être à cela que tu fais allusion !
Je ne connais pas ce type de fichier .LIB !
Et dans ce cas, regarde si tu peux extraire les OBJ et les utiliser directement en Delphi : Liaison avec le fichier objet (Delphi)

[user8]

En faite par .lib, j'entend librairie static provenant de visual C++.

[user8]

Bon je pense avoir trouvé la cause de mon problème.

Mon application est en Delphi. Les fonctions getenvironmentvariable et setenvironmentvariable de l'API windows utilisent directement le block d'environnement du processus.
La Dll est en Visual C++. Hors, les fonctions putenv et getenv du C++ travaillent sur une copie du block d'environnement réalisée à l'initialisation du C-runtime.

_putenv and _wputenv affect only the environment that is local to the current process; you cannot use them to modify the command-level environment. That is, these functions operate only on data structures accessible to the run-time library and not on the environment segment created for a process by the operating system. When the current process terminates, the environment reverts to the level of the calling process (in most cases, the operating-system level). However, the modified environment can be passed to any new processes created by _spawn, _exec, or system, and these new processes get any new items added by _putenv and _wputenv.

Do not change an environment entry directly: instead, use _putenv or _wputenv to change it. In particular, direct freeing elements of the _environ[] global array might lead to invalid memory being addressed.

getenv and _putenv use the global variable _environ to access the environment table; _wgetenv and _wputenv use _wenviron. _putenv and _wputenv might change the value of _environ and _wenviron, thus invalidating the _envp argument to main and the _wenvp argument to wmain. Therefore, it is safer to use _environ or _wenviron to access the environment information. For more information about the relation of _putenv and _wputenv to global variables, see _environ, _wenviron.

L'utilisation d'un setenvironmentvariable avec un getenv ne peut donc pas fonctionner.

Donc maintenant:

- Soit, depuis Delphi, je peux accéder à la copie du block et faire l'équivalent d'un putenv. Mais je n'ai pas trouvé comment faire.
- Soit, je me fais une dll sous Visual C++ qui me permet d’exécuter des putenv. Mais c'est lourd.
- Soit la dll que j'utilise doit inclure des fonctionnalités de paramétrage et c'est elle qui va faire le putenv. Mais ça implique des changements coté dll.
Sinon si vous avez d'autres solutions je suis preneur.

[Paul TOTH]

mais si la DLL n'est pas encore chargée, comment pourrait-elle avoir une copie des variables d'environnement avant que tu ne les changes ?!

[user8]

je pense que le CRT_INIT (C_RunTime initialization) doit se faire dés qu'une dll C++ est chargée. Et dans toutes les dlls chargées en static, il doit y en avoir pas mal en C++ .

[Paul TOTH]

je pense que le CRT_INIT (C_RunTime initialization) doit se faire dés qu'une dll C++ est chargée. Et dans toutes les dlls chargées en static, il doit y en avoir pas mal en C++ .

dans ce cas tu dois pouvoir accéder à _putenv dans le runtime C++

[castorcharly]

C'est étrange ce que tu dis là !
le fichier .LIB fourni avec une DLL ou issu de implib.exe (car C++Builder utilise un format différent), c'est en fait la liaison statique d'une DLL qui joue un peu le rôle d'un obj, en général, le fichier LIB ne contient rien de fondamentalement intéressant, en delphi, cela se remplace par une série de external !
le Fichier .LIB sert donc à importer les fonctions exportées d'une DLL, pas l'inverse !

Dans un fichier Lib, tu peux inclure des obj, que tu peux extraire avec tlib.exe
C'est peut-être à cela que tu fais allusion !
Je ne connais pas ce type de fichier .LIB !
Et dans ce cas, regarde si tu peux extraire les OBJ et les utiliser directement en Delphi : Liaison avec le fichier objet (Delphi)

Bonjour,

Je suis confronté à un problème un peu semblable:
J'ai des fichiers .LIB qui sont utilisé en C++

Après qq. échange avec Paul Toth et lu ce qui se dit ici,
il est peut être possible, sous Delphi 2006, pour récupérer ces .LIB, de les "convertir" en .OBJ puis de les utiliser grâce à la directive $L.
C'est pas gagné, car déjà je ne pige pas bien les explications pour l'utilisation de TLIB. D'après ce que je comprends, c'est plutôt l'inverse, céer des .LIB à l'aide de .OBJ...

J'ai quand même tenté la synthaxe:
Tlib Z:\PARTAGE\cMs71.lib *ObcMs71.obj, cMs71.lst

et j'obtiens un message
Error: Bad header in input LIB

Avez vous une idée pour que j'avance ?

Merci