bonjour,
voila, jai un programme qui charge une dll, et qui appele une de ses api
allouant de la memoire et fait plein de travaux.
ex:
unsigned char *data;
api(&data);
seulement voila, je voudrais que mon programme puisse desallouser la memoire
allouer par la dll, mais un simple delete [] data; ne marche pas , hors je
ne voudrais pas que ma dll le desalloue elle pour d'autre raison de
traitement.
(l'allocation de la memoire dans la dll se fait pas new , et je ne peux pas
allouer la memoire avant l'appel de l'api car c'est elle qui sait combien il
faut allouer et qui m'initialise le contenu de la mémoire, et cet api peut
desallouer aussi la memoire en cas d'erreur)
je voudrais savoir si ya une api win qui permet de desallouer la memoire ?
sinon jai pensé a fournir un pointeur de fonction a l'appel de l'api pour
que celle-ci se charge de l'allocation (afin d'avoir une adresse accessible
par mon exe pour le delete)
je cherche un moyen qui soit propre
merci d'avance
--
-----
http://dark.freezee.org/
- Dark Update v1.0
- Dark Emule v0.44b r4
- Dark 3D-X (le desktop 3d pour windows) (en cours)
> > En quoi est-ce "crade" exactement selon toi? > > C'est la seule solution valable si tu manipule des objets qui font
de
> l'alloccation en interne et que tu les passe par valeur entre
modules.
En fait, je ne trouve pas *la résolution* crade, mais le fait de
devoir
le faire : cela est généralement dû à un mauvais cloisonnement
entre les
modules. Mais c'est plus une impression qu'un argumentaire.
Je dirais plutôt que c'est la conception des DLLs au départ qui est foireuse, de ne pas avoir prévu ce problème :-)
Quand à dire que c'est un mauvais cloisonnement entre modules, je ne suis pas d'accord : ca me semble parfaitement sain et naturel de passer un std::string par valeur en paramètre d'une fonction par exemple....
De plus, j'ai tendance à préférer les modules :
- soit avec des interfaces simples (fonction C avec des arguments à
la
Win32) - soit avec des structure complexes, mais à condition d'avoir un
runtime
qui les marshale (COM, DCOM, CORBA, ...).
Mouais... Si on travaille dans un seul processus, est-ce bien la peine de sortir cette artillerie lourde? Ceci-dit, cela pose la quesiton suivante : est-ce bien toujours justifié de sauscisonner 1 application en N dLLs, et ne serait-il pas plus simple le plus souvent d'avoir un seul module?
--> dans ce style d'interfaces, on n'a pas ce problème.
Pas de problème en COM (ou en Corba)? Avec la gestion manuelle des AddRef/Release? On ne doit pas avoir la même expérience :-)
De plus, pour le déploiement des dll de la libc et la libc++, c'est problématique si les postes client ne sont pas complètement
contrôlés,
ou si le déploiement est complèxe (là c'est du vécu : chat
échaudé
craint l'eau froide).
Effectivement, il faut le savoir. Mais bon, déployer 1 ou 2 DLLs dans le même répertoire que l'application, il y a nettement pire comme contrainte non?
Arnaud MVP - VC
Olivier Huet wrote:
>
> En quoi est-ce "crade" exactement selon toi?
>
> C'est la seule solution valable si tu manipule des objets qui font
de
> l'alloccation en interne et que tu les passe par valeur entre
modules.
En fait, je ne trouve pas *la résolution* crade, mais le fait de
devoir
le faire : cela est généralement dû à un mauvais cloisonnement
entre les
modules. Mais c'est plus une impression qu'un argumentaire.
Je dirais plutôt que c'est la conception des DLLs au départ qui est
foireuse, de ne pas avoir prévu ce problème :-)
Quand à dire que c'est un mauvais cloisonnement entre modules, je ne
suis pas d'accord : ca me semble parfaitement sain et naturel de passer
un std::string par valeur en paramètre d'une fonction par exemple....
De plus, j'ai tendance à préférer les modules :
- soit avec des interfaces simples (fonction C avec des arguments à
la
Win32)
- soit avec des structure complexes, mais à condition d'avoir un
runtime
qui les marshale (COM, DCOM, CORBA, ...).
Mouais... Si on travaille dans un seul processus, est-ce bien la peine
de sortir cette artillerie lourde? Ceci-dit, cela pose la quesiton
suivante : est-ce bien toujours justifié de sauscisonner 1 application
en N dLLs, et ne serait-il pas plus simple le plus souvent d'avoir un
seul module?
--> dans ce style d'interfaces, on n'a pas ce problème.
Pas de problème en COM (ou en Corba)? Avec la gestion manuelle des
AddRef/Release? On ne doit pas avoir la même expérience :-)
De plus, pour le déploiement des dll de la libc et la libc++, c'est
problématique si les postes client ne sont pas complètement
contrôlés,
ou si le déploiement est complèxe (là c'est du vécu : chat
échaudé
craint l'eau froide).
Effectivement, il faut le savoir. Mais bon, déployer 1 ou 2 DLLs dans
le même répertoire que l'application, il y a nettement pire comme
contrainte non?
> > En quoi est-ce "crade" exactement selon toi? > > C'est la seule solution valable si tu manipule des objets qui font
de
> l'alloccation en interne et que tu les passe par valeur entre
modules.
En fait, je ne trouve pas *la résolution* crade, mais le fait de
devoir
le faire : cela est généralement dû à un mauvais cloisonnement
entre les
modules. Mais c'est plus une impression qu'un argumentaire.
Je dirais plutôt que c'est la conception des DLLs au départ qui est foireuse, de ne pas avoir prévu ce problème :-)
Quand à dire que c'est un mauvais cloisonnement entre modules, je ne suis pas d'accord : ca me semble parfaitement sain et naturel de passer un std::string par valeur en paramètre d'une fonction par exemple....
De plus, j'ai tendance à préférer les modules :
- soit avec des interfaces simples (fonction C avec des arguments à
la
Win32) - soit avec des structure complexes, mais à condition d'avoir un
runtime
qui les marshale (COM, DCOM, CORBA, ...).
Mouais... Si on travaille dans un seul processus, est-ce bien la peine de sortir cette artillerie lourde? Ceci-dit, cela pose la quesiton suivante : est-ce bien toujours justifié de sauscisonner 1 application en N dLLs, et ne serait-il pas plus simple le plus souvent d'avoir un seul module?
--> dans ce style d'interfaces, on n'a pas ce problème.
Pas de problème en COM (ou en Corba)? Avec la gestion manuelle des AddRef/Release? On ne doit pas avoir la même expérience :-)
De plus, pour le déploiement des dll de la libc et la libc++, c'est problématique si les postes client ne sont pas complètement
contrôlés,
ou si le déploiement est complèxe (là c'est du vécu : chat
échaudé
craint l'eau froide).
Effectivement, il faut le savoir. Mais bon, déployer 1 ou 2 DLLs dans le même répertoire que l'application, il y a nettement pire comme contrainte non?
Arnaud MVP - VC
dark poulpo
merci :)
jai deja resolu tout ce probleme, mais pour info ce n'etait pas aussi simple que ca.
jai deja un manageur de plugin qui soccupe de charger/decharger/trier les plugin par categorie de plugin, priorité,... un manageur de data bien precis qui appelle le manageur de plugin pour savoir quelle plugin est bon un manageur n de ... qui appelle aussi la manageur de plugin
et jai peut etre aussi a integrer un manageur de memoire pour gerer les fuites, la fragmentation, ...
mon probleme actuel est comment passer mon manageur de data a un plugin de categorie x (message dans un autre post)
-- ----- http://dark.freezee.org/ - Dark Update v1.0 - Dark Emule v0.44b r4 - Dark 3D-X (le desktop 3d pour windows) (en cours)
merci :)
jai deja resolu tout ce probleme, mais pour info ce n'etait pas aussi
simple que ca.
jai deja un manageur de plugin qui soccupe de charger/decharger/trier les
plugin par categorie de plugin, priorité,...
un manageur de data bien precis qui appelle le manageur de plugin pour
savoir quelle plugin est bon
un manageur n de ... qui appelle aussi la manageur de plugin
et jai peut etre aussi a integrer un manageur de memoire pour gerer les
fuites, la fragmentation, ...
mon probleme actuel est comment passer mon manageur de data a un plugin de
categorie x (message dans un autre post)
--
-----
http://dark.freezee.org/
- Dark Update v1.0
- Dark Emule v0.44b r4
- Dark 3D-X (le desktop 3d pour windows) (en cours)
jai deja resolu tout ce probleme, mais pour info ce n'etait pas aussi simple que ca.
jai deja un manageur de plugin qui soccupe de charger/decharger/trier les plugin par categorie de plugin, priorité,... un manageur de data bien precis qui appelle le manageur de plugin pour savoir quelle plugin est bon un manageur n de ... qui appelle aussi la manageur de plugin
et jai peut etre aussi a integrer un manageur de memoire pour gerer les fuites, la fragmentation, ...
mon probleme actuel est comment passer mon manageur de data a un plugin de categorie x (message dans un autre post)
-- ----- http://dark.freezee.org/ - Dark Update v1.0 - Dark Emule v0.44b r4 - Dark 3D-X (le desktop 3d pour windows) (en cours)
Vincent Burel
"dark poulpo" wrote in message news:41f74eb5$0$28954$
merci :)
jai deja resolu tout ce probleme, mais pour info ce n'etait pas aussi simple que ca.
c'est pas forcément simple, par contre c'est primordiale.
mon probleme actuel est comment passer mon manageur de data a un plugin de categorie x (message dans un autre post)
si vous voulez que votre plug-in agisse sur le manager, il vaut mieux se mettre en place un mechanisme de callback (une fonction) avec un protocole à soi (tout simple)... Si vous voulez que votre plug-in utilise des fonction du manager directement, alors vous pouvez passer un jeu de fonction sous la forme d'une structure de donnée ou d'une lpVtbl (tableau de fonction). dans ce cas les prototype de ces fonctions devront être définis avec leur convention d'appel... généralement on utilise __stdcall (car compatible avec tous les langage)...
VB
PS : si ca continue ce newsgroup vous enverra une facture : -)
"dark poulpo" <qsdqd@sss.ss> wrote in message
news:41f74eb5$0$28954$8fcfb975@news.wanadoo.fr...
merci :)
jai deja resolu tout ce probleme, mais pour info ce n'etait pas aussi
simple que ca.
c'est pas forcément simple, par contre c'est primordiale.
mon probleme actuel est comment passer mon manageur de data a un plugin de
categorie x (message dans un autre post)
si vous voulez que votre plug-in agisse sur le manager, il vaut mieux se
mettre en place un mechanisme de callback (une fonction) avec un protocole à
soi (tout simple)... Si vous voulez que votre plug-in utilise des fonction
du manager directement, alors vous pouvez passer un jeu de fonction sous la
forme d'une structure de donnée ou d'une lpVtbl (tableau de fonction). dans
ce cas les prototype de ces fonctions devront être définis avec leur
convention d'appel... généralement on utilise __stdcall (car compatible avec
tous les langage)...
VB
PS : si ca continue ce newsgroup vous enverra une facture : -)
"dark poulpo" wrote in message news:41f74eb5$0$28954$
merci :)
jai deja resolu tout ce probleme, mais pour info ce n'etait pas aussi simple que ca.
c'est pas forcément simple, par contre c'est primordiale.
mon probleme actuel est comment passer mon manageur de data a un plugin de categorie x (message dans un autre post)
si vous voulez que votre plug-in agisse sur le manager, il vaut mieux se mettre en place un mechanisme de callback (une fonction) avec un protocole à soi (tout simple)... Si vous voulez que votre plug-in utilise des fonction du manager directement, alors vous pouvez passer un jeu de fonction sous la forme d'une structure de donnée ou d'une lpVtbl (tableau de fonction). dans ce cas les prototype de ces fonctions devront être définis avec leur convention d'appel... généralement on utilise __stdcall (car compatible avec tous les langage)...
VB
PS : si ca continue ce newsgroup vous enverra une facture : -)
Vincent Burel
"Vincent Burel" wrote in message news:41f748f4$0$19440$
PS : l'essentiel des programmeur du dimanche
je voulais dire que l'essentiel des programmeurs du dimanche s'arrètent dès qu'il y a 3 données à gérer, ou bien un tantinet d'organisation de soucec à opérer... c'est dommage... et pour l'avoir été (programmeur du dimanche - status que je regrette d'ailleurs) j'ajoute que ce sont souvent eux qui ont le temps d'avoir des idées originales...
VB
"Vincent Burel" <vincent.burel@spam-wanadoo.fr> wrote in message
news:41f748f4$0$19440$8fcfb975@news.wanadoo.fr...
PS : l'essentiel des programmeur du dimanche
je voulais dire que l'essentiel des programmeurs du dimanche s'arrètent dès
qu'il y a 3 données à gérer, ou bien un tantinet d'organisation de soucec à
opérer... c'est dommage... et pour l'avoir été (programmeur du dimanche -
status que je regrette d'ailleurs) j'ajoute que ce sont souvent eux qui ont
le temps d'avoir des idées originales...
"Vincent Burel" wrote in message news:41f748f4$0$19440$
PS : l'essentiel des programmeur du dimanche
je voulais dire que l'essentiel des programmeurs du dimanche s'arrètent dès qu'il y a 3 données à gérer, ou bien un tantinet d'organisation de soucec à opérer... c'est dommage... et pour l'avoir été (programmeur du dimanche - status que je regrette d'ailleurs) j'ajoute que ce sont souvent eux qui ont le temps d'avoir des idées originales...
VB
dark poulpo
> je voulais dire que l'essentiel des programmeurs du dimanche s'arrètent
dès
qu'il y a 3 données à gérer, ou bien un tantinet d'organisation de soucec
à
opérer... c'est dommage... et pour l'avoir été (programmeur du dimanche - status que je regrette d'ailleurs) j'ajoute que ce sont souvent eux qui
ont
le temps d'avoir des idées originales...
je comprend que tu le regrettes, quand tu perds ce status, tu n'a malheuresement plus le temps d'apprendre a ta guise et d'approfondir. ca devient industriel.je dirais meme que ce peu te degouter de programmer pour toi. :-((((
> je voulais dire que l'essentiel des programmeurs du dimanche s'arrètent
dès
qu'il y a 3 données à gérer, ou bien un tantinet d'organisation de soucec
à
opérer... c'est dommage... et pour l'avoir été (programmeur du dimanche -
status que je regrette d'ailleurs) j'ajoute que ce sont souvent eux qui
ont
le temps d'avoir des idées originales...
je comprend que tu le regrettes, quand tu perds ce status, tu n'a
malheuresement plus le temps d'apprendre a ta guise et d'approfondir. ca
devient industriel.je dirais meme que ce peu te degouter de programmer pour
toi. :-((((
> je voulais dire que l'essentiel des programmeurs du dimanche s'arrètent
dès
qu'il y a 3 données à gérer, ou bien un tantinet d'organisation de soucec
à
opérer... c'est dommage... et pour l'avoir été (programmeur du dimanche - status que je regrette d'ailleurs) j'ajoute que ce sont souvent eux qui
ont
le temps d'avoir des idées originales...
je comprend que tu le regrettes, quand tu perds ce status, tu n'a malheuresement plus le temps d'apprendre a ta guise et d'approfondir. ca devient industriel.je dirais meme que ce peu te degouter de programmer pour toi. :-((((
Olivier Huet
Bonjour,
a écrit :
Je dirais plutôt que c'est la conception des DLLs au départ qui est foireuse, de ne pas avoir prévu ce problème :-)
oui peut être :-) Je crois bien que l'on retrouve le même genre de problème avec les .so des OS Unix like, mais je connais peu la question sur ces os.
Quand à dire que c'est un mauvais cloisonnement entre modules, je ne suis pas d'accord : ca me semble parfaitement sain et naturel de passer un std::string par valeur en paramètre d'une fonction par exemple....
En effet là je ne vais pas dire le contraire, mais le fait est que pour faire ça, il faut justement que std::string soit identique dans les deux modules, et donc, on en reviens à ce que tu as précisé aussi : mettre ici aussi les libc et libc++ en dll...
qui les marshale (COM, DCOM, CORBA, ...).
Mouais... Si on travaille dans un seul processus, est-ce bien la peine de sortir cette artillerie lourde?
COM dans un seul process, permet justement d'éviter de se poser ces problèmes de type des arguments, mais effectivement, cela en rajoute potentiellement une multitude.
DCOM et CORBA, en effet pour du multiprocessus et multimachines : cela dit en passant, n'utilisez *pas* CORBA, ou du moins pas Visibroker, c'est vraiment plein de bugs... (là je dénonce et c'est méchant mais c'est tout de même bien vrai)
> Ceci-dit, cela pose la quesiton
suivante : est-ce bien toujours justifié de sauscisonner 1 application en N dLLs, et ne serait-il pas plus simple le plus souvent d'avoir un seul module?
Vaste débat : quelques arguments +/- bons AMHA : pour le cloisonnement
- il permet souvent plus facilement de travailler en équipe (chacun son module)
- il permet souvent de développer progressivement : on fait une brique de base que l'on ne touche ensuite plus, puis ensuite des modules dessus.
- est indispensable pour gérer ce que veux faire le posteur initial : sorte de plugins
- dès qu'un projet grossit, il devient quasi indispensable : pourquoi ne pas le prévoir dès le début ?
Et il y en a probablement d'autres, mais en effet, pour un projet moyennement gros, avec peu de personnes, le module unique est probablement beaucoup mieux. Après, c'est peut-être bien un sorte de mode ou de religion.
--> dans ce style d'interfaces, on n'a pas ce problème.
Pas de problème en COM (ou en Corba)? Avec la gestion manuelle des AddRef/Release? On ne doit pas avoir la même expérience :-)
Et les SmartPointers ? :-) non je sais bien que ça ne résouds pas tout (cycles, qui fait le premier addref etc etc.).
Mais Je parlais ici des transmissions d'arguments qui sont alors beaucoup plus propres et précises.
Et en effet, viennent ensuite des problèmes variés. Pour COM, je ne mettrais personnellement pas les addref/release en premier mais plutôt les dialogues entre threads dans différents modèle d'appartement : c'est tout de même le top dans le genre bizareries :-)
Effectivement, il faut le savoir. Mais bon, déployer 1 ou 2 DLLs dans le même répertoire que l'application, il y a nettement pire comme contrainte non?
Oui. En environement serveur par exemple, aucun problèmes, mais pour des applis déployées sur des clients finaux par internet avec des ActiveX etc., c'est embêtant : de quoi incendier les gens qui ont provoqué la nécessité de compiler en mode libc en dll :-) (non je déconne, d'une part c'est de l'histoire ancienne, et je n'incendie pas : pas de menaces :-) )
Olivier Huet
Bonjour,
adebaene@club-internet.fr a écrit :
Je dirais plutôt que c'est la conception des DLLs au départ qui est
foireuse, de ne pas avoir prévu ce problème :-)
oui peut être :-) Je crois bien que l'on retrouve le même genre de
problème avec les .so des OS Unix like, mais je connais peu la question
sur ces os.
Quand à dire que c'est un mauvais cloisonnement entre modules, je ne
suis pas d'accord : ca me semble parfaitement sain et naturel de passer
un std::string par valeur en paramètre d'une fonction par exemple....
En effet là je ne vais pas dire le contraire, mais le fait est que pour
faire ça, il faut justement que std::string soit identique dans les deux
modules, et donc, on en reviens à ce que tu as précisé aussi : mettre
ici aussi les libc et libc++ en dll...
qui les marshale (COM, DCOM, CORBA, ...).
Mouais... Si on travaille dans un seul processus, est-ce bien la peine
de sortir cette artillerie lourde?
COM dans un seul process, permet justement d'éviter de se poser ces
problèmes de type des arguments, mais effectivement, cela en rajoute
potentiellement une multitude.
DCOM et CORBA, en effet pour du multiprocessus et multimachines : cela
dit en passant, n'utilisez *pas* CORBA, ou du moins pas Visibroker,
c'est vraiment plein de bugs... (là je dénonce et c'est méchant mais
c'est tout de même bien vrai)
> Ceci-dit, cela pose la quesiton
suivante : est-ce bien toujours justifié de sauscisonner 1 application
en N dLLs, et ne serait-il pas plus simple le plus souvent d'avoir un
seul module?
Vaste débat : quelques arguments +/- bons AMHA : pour le cloisonnement
- il permet souvent plus facilement de travailler en équipe (chacun son
module)
- il permet souvent de développer progressivement : on fait une brique
de base que l'on ne touche ensuite plus, puis ensuite des modules dessus.
- est indispensable pour gérer ce que veux faire le posteur initial :
sorte de plugins
- dès qu'un projet grossit, il devient quasi indispensable : pourquoi ne
pas le prévoir dès le début ?
Et il y en a probablement d'autres, mais en effet, pour un projet
moyennement gros, avec peu de personnes, le module unique est
probablement beaucoup mieux. Après, c'est peut-être bien un sorte de
mode ou de religion.
--> dans ce style d'interfaces, on n'a pas ce problème.
Pas de problème en COM (ou en Corba)? Avec la gestion manuelle des
AddRef/Release? On ne doit pas avoir la même expérience :-)
Et les SmartPointers ? :-) non je sais bien que ça ne résouds pas tout
(cycles, qui fait le premier addref etc etc.).
Mais Je parlais ici des transmissions d'arguments qui sont alors
beaucoup plus propres et précises.
Et en effet, viennent ensuite des problèmes variés. Pour COM, je ne
mettrais personnellement pas les addref/release en premier mais plutôt
les dialogues entre threads dans différents modèle d'appartement : c'est
tout de même le top dans le genre bizareries :-)
Effectivement, il faut le savoir. Mais bon, déployer 1 ou 2 DLLs dans
le même répertoire que l'application, il y a nettement pire comme
contrainte non?
Oui. En environement serveur par exemple, aucun problèmes, mais pour des
applis déployées sur des clients finaux par internet avec des ActiveX
etc., c'est embêtant : de quoi incendier les gens qui ont provoqué la
nécessité de compiler en mode libc en dll :-) (non je déconne, d'une
part c'est de l'histoire ancienne, et je n'incendie pas : pas de menaces
:-) )
Je dirais plutôt que c'est la conception des DLLs au départ qui est foireuse, de ne pas avoir prévu ce problème :-)
oui peut être :-) Je crois bien que l'on retrouve le même genre de problème avec les .so des OS Unix like, mais je connais peu la question sur ces os.
Quand à dire que c'est un mauvais cloisonnement entre modules, je ne suis pas d'accord : ca me semble parfaitement sain et naturel de passer un std::string par valeur en paramètre d'une fonction par exemple....
En effet là je ne vais pas dire le contraire, mais le fait est que pour faire ça, il faut justement que std::string soit identique dans les deux modules, et donc, on en reviens à ce que tu as précisé aussi : mettre ici aussi les libc et libc++ en dll...
qui les marshale (COM, DCOM, CORBA, ...).
Mouais... Si on travaille dans un seul processus, est-ce bien la peine de sortir cette artillerie lourde?
COM dans un seul process, permet justement d'éviter de se poser ces problèmes de type des arguments, mais effectivement, cela en rajoute potentiellement une multitude.
DCOM et CORBA, en effet pour du multiprocessus et multimachines : cela dit en passant, n'utilisez *pas* CORBA, ou du moins pas Visibroker, c'est vraiment plein de bugs... (là je dénonce et c'est méchant mais c'est tout de même bien vrai)
> Ceci-dit, cela pose la quesiton
suivante : est-ce bien toujours justifié de sauscisonner 1 application en N dLLs, et ne serait-il pas plus simple le plus souvent d'avoir un seul module?
Vaste débat : quelques arguments +/- bons AMHA : pour le cloisonnement
- il permet souvent plus facilement de travailler en équipe (chacun son module)
- il permet souvent de développer progressivement : on fait une brique de base que l'on ne touche ensuite plus, puis ensuite des modules dessus.
- est indispensable pour gérer ce que veux faire le posteur initial : sorte de plugins
- dès qu'un projet grossit, il devient quasi indispensable : pourquoi ne pas le prévoir dès le début ?
Et il y en a probablement d'autres, mais en effet, pour un projet moyennement gros, avec peu de personnes, le module unique est probablement beaucoup mieux. Après, c'est peut-être bien un sorte de mode ou de religion.
--> dans ce style d'interfaces, on n'a pas ce problème.
Pas de problème en COM (ou en Corba)? Avec la gestion manuelle des AddRef/Release? On ne doit pas avoir la même expérience :-)
Et les SmartPointers ? :-) non je sais bien que ça ne résouds pas tout (cycles, qui fait le premier addref etc etc.).
Mais Je parlais ici des transmissions d'arguments qui sont alors beaucoup plus propres et précises.
Et en effet, viennent ensuite des problèmes variés. Pour COM, je ne mettrais personnellement pas les addref/release en premier mais plutôt les dialogues entre threads dans différents modèle d'appartement : c'est tout de même le top dans le genre bizareries :-)
Effectivement, il faut le savoir. Mais bon, déployer 1 ou 2 DLLs dans le même répertoire que l'application, il y a nettement pire comme contrainte non?
Oui. En environement serveur par exemple, aucun problèmes, mais pour des applis déployées sur des clients finaux par internet avec des ActiveX etc., c'est embêtant : de quoi incendier les gens qui ont provoqué la nécessité de compiler en mode libc en dll :-) (non je déconne, d'une part c'est de l'histoire ancienne, et je n'incendie pas : pas de menaces :-) )
