Discussion :

[Clorish]

J'ai un systeme de Mise a jour de ma librairie basee sur le chargement d'une Dll de patch.

J'ai remarque que tant que le paquet contenant une classe qui a un moment ou un autre charge une Dll en memoire, bloque en acces la dll.
Je nepeut pas copier une nouvelle Dll a la place de l'ancienne tant que le paquet est ouvert, ce qui est assez embetant :/

Est ce normal ?

La dll est bien liberee et la classe detruite en fin de tache.
mais Windows refuse la suppression/Modification de la dll car eslle est sucsseptible d'etre encore utilisé.

[MD Software]

Est ce normal ?.

Je dirais, oui, c'est noraml, ou du moins ça paraît logique. Du coup, je ne vois pas comment tu peux faire.

Si tu fais un chargement dynamique de ta dll, tu as le même problème ?

[Clorish]

Si tu fais un chargement dynamique de ta dll, tu as le même problème ?

C'est par chargement dynimique .... (LoadLibrary)

[Mac LAK]

C'est par chargement dynimique .... (LoadLibrary)

Questions bêtes :
- Tes appels LoadLibrary/FreeLibrary sont-ils bien équilibrés ?
- Ton package, tu le charges également dynamiquement, par LoadPackage ? Si oui, penses-tu à équilibrer avec des UnloadPackage ?

[Clorish]

non le package n'est pas chargé dynamiquement car c'est un expert IDE.

Par contre la Dll normalement oui. Je fais en sorte de la liberer a la fin quand meme

[smyley]

mais si c'est un système de mise à jour pourquoi tu le sépares pas de ton projet ? par exemple un exe pour télécharger les mises à jours et un autre pour les installer, qui attend d'abord sagement que le premier se soit arrêter.

[Clorish]

Mouais j'ai resolu mon probleme comme ca mais la gestion via Dll est plus "propre" car demande moins de code.

en tout cas merci
Mais bon je ne compends toujours pas pkoi j'ai cette erreur :/

[Mac LAK]

Mais bon je ne compends toujours pas pkoi j'ai cette erreur :/

A priori, parceque ton paquet (qui a "monté" la DLL) n'est pas libéré, c'est pour ça que je te parlais de LoadPackage.

[Clorish]

A priori, parceque ton paquet (qui a "monté" la DLL) n'est pas libéré,

C'est justement ce qui m'embete ....

Le fait que FreeLibrary decremente le compteur, ce qui dans mon cas entraine la liberation de la Dll car je suis le seul appelant, je pensais que windows liberait le fichier Dll et permettait un acces a ce derner en suppression/ecriture.

Il semble logique de continuer a bloquer ce fichier pour eviter de rentre instable le programme car il est sense s'en resservir, mais d'un autre cote, il est aussi interessant de pouvoir liberer une Dll pour la remplacer et recharger la nouvelle ....

Je comprends eventuelement la philosaphie Windows a ce sujet, mais je le trouve extremement "bloquante" dans ses fonctionnalites :/

Fermer un programme pour le reouvrir et gerer la mise a jour des dlls via un exe secondaire je trouve ca un peut lourd par rapport au simple fait de dechargr une dll, remplacer et recharger la Dll :/

[Mac LAK]

Je comprends eventuelement la philosaphie Windows a ce sujet, mais je le trouve extremement "bloquante" dans ses fonctionnalites :/

C'est plutôt qu'il n'y a pas eu d'ordres de libération explicite, ça devrait passer sans problèmes soit avant de monter la DLL, soit en libérant le paquet... Windows n'est pas responsable des paquets Borland ! ;-)

Je t'encourage à aller voir du côté de la mise à jour "avant chargement", par présence (par exemple) de fichiers type "maDLL.dll.new" qui seraient échangés avec les "maDLL.dll" avant le chargement du paquet, et donc avant qu'ils soient verrouillés.

[Clorish]

C'est plutôt qu'il n'y a pas eu d'ordres de libération explicite

Aye .. c la que le bat blesse.
Moi j'explicite de dechargement de la Dll (FreeLibrary) alors ce que je ne comprends pas c'est que normalement elle est sensé etre libéré justement.

A moins que Borland fait le travail a moitié et decharge la bibliotheque mais pas completement .. il manquerais alors l'instruction qui signale a Windows que la Dll n'est plus utilisé.
Dans ce cas : Faiblesse du systeme de gestion Dll par Borland ? ou simple precaution ? A moins qu'il n'existe une option a cocher, ou une directive a mentionner .....

Quoi qu'il en soit, je n'arrive pas a voir l'utilité de ce genre d'operation :/

Quand au test de presence d'une version New ne me plait pas trop en fait ....
Surtout que le principe d'une Dl c'est d'etre partagée .. donc si un autre logiciel l'utilise, je ne pourrait pas plus la renomer que maintenant ... ce qui m'oblige a l'utiliser telle quelle, et donc a conserver N versions de Dlls en attendant que tous les logiciels l'ai libérée (utilisation reseau .... donc un reboot ne suffit pas a reinitialiser tous les logs qui manipule la Dll)

Bref ... c kk

[Mac LAK]

Aye .. c la que le bat blesse.
Moi j'explicite de dechargement de la Dll (FreeLibrary) alors ce que je ne comprends pas c'est que normalement elle est sensé etre libéré justement.

Essaie de faire passer ton paquet/programme à Dependancy Walker : si ta DLL est "montrée" dans la hiérarchie des dépendances, t'es mort : il y a un lien "en dur"... Si ta DLL est réellement chargée à 100% de manière dynamique, DW est incapable de te la montrer comme étant une dépendance !!

A moins que Borland fait le travail a moitié et decharge la bibliotheque mais pas completement .. il manquerais alors l'instruction qui signale a Windows que la Dll n'est plus utilisé.

Non, je ne pense pas que ce soit ça : FreeLibrary fait partie de l'API Win32, pas de Borland. Par contre, si la mémoire est verrouillée et/ou non swappable, ça peut être une raison de cette interdiction...
Que fait ta DLL exactement, comme traitements ? Ne serait-elle pas utilisée par un autre paquet, ou même par un exécutable (l'IDE Delphi ?) ? Verrouille-t-elle des ressources globales ? Quel est le résultat d'exécution de FreeLibrary ?
Egalement, n'aurais-tu pas ouvert la DLL pour en extraire des ressources, et ces ressources (y compris les VERSIONINFO) sont-elles bien libérées avant ta tentative de remplacement ?
Je n'ai pas plus de pistes pour l'instant...

Dans ce cas : Faiblesse du systeme de gestion Dll par Borland ? ou simple precaution ? A moins qu'il n'existe une option a cocher, ou une directive a mentionner .....

Je suis loin d'être une bête en gestion des paquets, je n'en utilise quasiment jamais (je préfère les DLL pour les exécutions, ou les sources directs pour la compilation)... Faudrait peut-être poser la question sur les newsgroups Borland, en tout cas je n'ai pas d'autre réponse pour toi sous le coude, désolé.
En tout cas, je pense que c'est lié au fait que ce soit un paquet qui requiert la DLL, j'ai déjà fait ça avec des DLL chargées dynamiquement, et je n'ai jamais eu d'interdiction de verrouillage par Windows.

Quoi qu'il en soit, je n'arrive pas a voir l'utilité de ce genre d'operation :/

Augmentation des performances globales du système, tout simplement.

Quand au test de presence d'une version New ne me plait pas trop en fait ....
<snip>

Effectivement, si elle est sur réseau, c'est beaucoup plus gênant... Mais ça peut être l'explication de ton verrouillage aussi, car la mise à jour de fichiers sur un réseau est loin d'être simple !! Forum "Développement Windows" si tu penses que c'est ça qui en est la cause...

[Clorish]

Oui ... ben je crois que je vais attendre d'en savoir un peu plus en attendant la gestion par exe me suffira :p

en tout cas merci pour ces explication qui m'aide a concevoir les rouages de windows de maniere plus large.

Pour ma part, c'est pas les idees qui me manques mais bien souvent une incertitude quand a la gestion reele de Windows (memoire, fichiers, Dlls, etc ..)
Si j'en savais un peu plus sur ces mecanismes, j'aurais moins de propblemes et surtout je pourrais savoir si la plupart de mes idees sont correctes car reposent sur des bases fiables ou si au contraire elle se reposent sur des suppositions erronees

[Mac LAK]

Pour ma part, c'est pas les idees qui me manques mais bien souvent une incertitude quand a la gestion reele de Windows (memoire, fichiers, Dlls, etc ..)
Si j'en savais un peu plus sur ces mecanismes, j'aurais moins de propblemes et surtout je pourrais savoir si la plupart de mes idees sont correctes car reposent sur des bases fiables ou si au contraire elle se reposent sur des suppositions erronees

Tu sais, la seule manière, c'est d'éplucher MSDN et d'aller tripatouiller le bas niveau aussi souvent que possible... Malheureusement, ce n'est pas toujours trivial en Delphi, et Visual C++ reste le maître incontesté pour ce genre de trucs...
Un autre truc qui aide bien à "dégrossir" le sujet, c'est d'examiner les sources de la RTL Delphi : il y a pas mal de trucs intéressants dedans...

[Clorish]

Oki merci

En ce qui concerne les sources .. j'ai mon nez fourré dedans 12h/24 mais j'ai encore du mal :/