Manuel Leclerc wrote:
> Le 13/01/2012 09:53, JKB a écrit :
>
> > Tu as la description complète du problème dans la KB de
> > (je te l'accorde, il faut un peu chercher parce qu'ils ne
> > pas être fier du problème).
> >
> > Pour faire simple : une DLL n'est pas mappée dans un espace de
> > processus sous Windows mais dans un espace commun aux processus
> > l'utilisent (ils n'ont _rien_ compris au fonctionnement de base
> > la mémoire virtuelle. Passons ! Pour branlibranla, la mémoire
> > virtuelle, même sur l'architecture moisie du x86, c'est un truc
> > permet d'avoir une zone de mémoire physique mappée sur plusieurs
> > zones de mémoire virtuelle dans des espaces mémoire différents).
> > La conséquence de ce choix (de ce bug ? de cette fonctionnalité
> > est que la mémoire allouée dans une DLL n'est pas allouée sur
> > processus utilisant cette DLL, mais sur le 'tas' de la DLL. Ce
> > fait que lorsque tu fermes le programme utilisant la DLL sans
> > libérer explicitement ce qui a été alloué par la DLL en
> > as une belle fuite mémoire. Depuis je ne sais plus quelle
> > Visual C++, la libcrt contient une rustine qui piste les
> > de mémoire dans les DLL pour les libérer explicitement à la fin
> > l'exécution d'un processus.
> >
> > Un autre truc amusant avec cette façon de faire, c'est qu'un
> > processus peut marcher sur les données d'un autre processus au
> > travers de l'utilisation d'un pointeur hasardeux en mémoire
> > qu'il a été alloué dans la mémoire d'une DLL.
> >
> > Donc, lorsqu'on doit écrire une DLL sous Windows, on évite
> > que possible d'utiliser de la mémorie dynamique avec allocation
> > _dans_ la DLL.
>
> En simplifiant un peu, mon métier consiste à coder des DLLs, et ça
> fait un paquet d'années. Donc ton message m'inquiète au plus haut
> point, car je n'y comprends strictement rien. Tu serais bien
> aimable de m'aider à trouver la référence vers l'article de KB
> dont tu parles.
>
Comme je trouvais ça hautement bizarre, j'ai cherché un peu sur le
et trouvé ceci:
A Dynamic-Link Library (DLL) can contain global data or local data.
Manuel Leclerc <manuel.leclerc@alussinan.org> wrote:
> Le 13/01/2012 09:53, JKB a écrit :
>
> > Tu as la description complète du problème dans la KB de
> > (je te l'accorde, il faut un peu chercher parce qu'ils ne
> > pas être fier du problème).
> >
> > Pour faire simple : une DLL n'est pas mappée dans un espace de
> > processus sous Windows mais dans un espace commun aux processus
> > l'utilisent (ils n'ont _rien_ compris au fonctionnement de base
> > la mémoire virtuelle. Passons ! Pour branlibranla, la mémoire
> > virtuelle, même sur l'architecture moisie du x86, c'est un truc
> > permet d'avoir une zone de mémoire physique mappée sur plusieurs
> > zones de mémoire virtuelle dans des espaces mémoire différents).
> > La conséquence de ce choix (de ce bug ? de cette fonctionnalité
> > est que la mémoire allouée dans une DLL n'est pas allouée sur
> > processus utilisant cette DLL, mais sur le 'tas' de la DLL. Ce
> > fait que lorsque tu fermes le programme utilisant la DLL sans
> > libérer explicitement ce qui a été alloué par la DLL en
> > as une belle fuite mémoire. Depuis je ne sais plus quelle
> > Visual C++, la libcrt contient une rustine qui piste les
> > de mémoire dans les DLL pour les libérer explicitement à la fin
> > l'exécution d'un processus.
> >
> > Un autre truc amusant avec cette façon de faire, c'est qu'un
> > processus peut marcher sur les données d'un autre processus au
> > travers de l'utilisation d'un pointeur hasardeux en mémoire
> > qu'il a été alloué dans la mémoire d'une DLL.
> >
> > Donc, lorsqu'on doit écrire une DLL sous Windows, on évite
> > que possible d'utiliser de la mémorie dynamique avec allocation
> > _dans_ la DLL.
>
> En simplifiant un peu, mon métier consiste à coder des DLLs, et ça
> fait un paquet d'années. Donc ton message m'inquiète au plus haut
> point, car je n'y comprends strictement rien. Tu serais bien
> aimable de m'aider à trouver la référence vers l'article de KB
> dont tu parles.
>
Comme je trouvais ça hautement bizarre, j'ai cherché un peu sur le
et trouvé ceci:
A Dynamic-Link Library (DLL) can contain global data or local data.
Manuel Leclerc wrote:
> Le 13/01/2012 09:53, JKB a écrit :
>
> > Tu as la description complète du problème dans la KB de
> > (je te l'accorde, il faut un peu chercher parce qu'ils ne
> > pas être fier du problème).
> >
> > Pour faire simple : une DLL n'est pas mappée dans un espace de
> > processus sous Windows mais dans un espace commun aux processus
> > l'utilisent (ils n'ont _rien_ compris au fonctionnement de base
> > la mémoire virtuelle. Passons ! Pour branlibranla, la mémoire
> > virtuelle, même sur l'architecture moisie du x86, c'est un truc
> > permet d'avoir une zone de mémoire physique mappée sur plusieurs
> > zones de mémoire virtuelle dans des espaces mémoire différents).
> > La conséquence de ce choix (de ce bug ? de cette fonctionnalité
> > est que la mémoire allouée dans une DLL n'est pas allouée sur
> > processus utilisant cette DLL, mais sur le 'tas' de la DLL. Ce
> > fait que lorsque tu fermes le programme utilisant la DLL sans
> > libérer explicitement ce qui a été alloué par la DLL en
> > as une belle fuite mémoire. Depuis je ne sais plus quelle
> > Visual C++, la libcrt contient une rustine qui piste les
> > de mémoire dans les DLL pour les libérer explicitement à la fin
> > l'exécution d'un processus.
> >
> > Un autre truc amusant avec cette façon de faire, c'est qu'un
> > processus peut marcher sur les données d'un autre processus au
> > travers de l'utilisation d'un pointeur hasardeux en mémoire
> > qu'il a été alloué dans la mémoire d'une DLL.
> >
> > Donc, lorsqu'on doit écrire une DLL sous Windows, on évite
> > que possible d'utiliser de la mémorie dynamique avec allocation
> > _dans_ la DLL.
>
> En simplifiant un peu, mon métier consiste à coder des DLLs, et ça
> fait un paquet d'années. Donc ton message m'inquiète au plus haut
> point, car je n'y comprends strictement rien. Tu serais bien
> aimable de m'aider à trouver la référence vers l'article de KB
> dont tu parles.
>
Comme je trouvais ça hautement bizarre, j'ai cherché un peu sur le
et trouvé ceci:
A Dynamic-Link Library (DLL) can contain global data or local data.
Le Tue, 17 Jan 2012 22:25:58 +0000 (UTC),
(Michel Talon) a écrit :Manuel Leclerc wrote:
> Le 13/01/2012 09:53, JKB a écrit :
>
> > Tu as la description complète du problème dans la KB de
Microsoft> > (je te l'accorde, il faut un peu chercher parce qu'ils ne
doivent> > pas être fier du problème).
> >
> > Pour faire simple : une DLL n'est pas mappée dans un espace de
> > processus sous Windows mais dans un espace commun aux processus
qui> > l'utilisent (ils n'ont _rien_ compris au fonctionnement de base
de> > la mémoire virtuelle. Passons ! Pour branlibranla, la mémoire
> > virtuelle, même sur l'architecture moisie du x86, c'est un truc
qui> > permet d'avoir une zone de mémoire physique mappée sur plusieurs
> > zones de mémoire virtuelle dans des espaces mémoire différents).
> > La conséquence de ce choix (de ce bug ? de cette fonctionnalité
?)> > est que la mémoire allouée dans une DLL n'est pas allouée sur
le tas du> > processus utilisant cette DLL, mais sur le 'tas' de la DLL. Ce
qui> > fait que lorsque tu fermes le programme utilisant la DLL sans
> > libérer explicitement ce qui a été alloué par la DLL en
question, tu> > as une belle fuite mémoire. Depuis je ne sais plus quelle
version de> > Visual C++, la libcrt contient une rustine qui piste les
allocations> > de mémoire dans les DLL pour les libérer explicitement à la fin
de> > l'exécution d'un processus.
> >
> > Un autre truc amusant avec cette façon de faire, c'est qu'un
> > processus peut marcher sur les données d'un autre processus au
> > travers de l'utilisation d'un pointeur hasardeux en mémoire
pour peu> > qu'il a été alloué dans la mémoire d'une DLL.
> >
> > Donc, lorsqu'on doit écrire une DLL sous Windows, on évite
autant> > que possible d'utiliser de la mémorie dynamique avec allocation
> > _dans_ la DLL.
>
> En simplifiant un peu, mon métier consiste à coder des DLLs, et ça
> fait un paquet d'années. Donc ton message m'inquiète au plus haut
> point, car je n'y comprends strictement rien. Tu serais bien
> aimable de m'aider à trouver la référence vers l'article de KB
> dont tu parles.
>Comme je trouvais ça hautement bizarre, j'ai cherché un peu sur le
webet trouvé ceci:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682594(v=vs.8
5).aspxA Dynamic-Link Library (DLL) can contain global data or local data.
Je pense que <http://msdn.microsoft.com/en-US/library/ms235460.aspx>
est plus
proche de ce que raconte JKB, modulo le mappage de la DLL. Ceci-dit,
je ne vois
pas trace de ladite rustine. M'enfin comme je code pas non plus des
DLLs sous Windows...
Le Tue, 17 Jan 2012 22:25:58 +0000 (UTC), talon@lpthe.jussieu.fr
(Michel Talon) a écrit :
Manuel Leclerc <manuel.leclerc@alussinan.org> wrote:
> Le 13/01/2012 09:53, JKB a écrit :
>
> > Tu as la description complète du problème dans la KB de
Microsoft
> > (je te l'accorde, il faut un peu chercher parce qu'ils ne
doivent
> > pas être fier du problème).
> >
> > Pour faire simple : une DLL n'est pas mappée dans un espace de
> > processus sous Windows mais dans un espace commun aux processus
qui
> > l'utilisent (ils n'ont _rien_ compris au fonctionnement de base
de
> > la mémoire virtuelle. Passons ! Pour branlibranla, la mémoire
> > virtuelle, même sur l'architecture moisie du x86, c'est un truc
qui
> > permet d'avoir une zone de mémoire physique mappée sur plusieurs
> > zones de mémoire virtuelle dans des espaces mémoire différents).
> > La conséquence de ce choix (de ce bug ? de cette fonctionnalité
?)
> > est que la mémoire allouée dans une DLL n'est pas allouée sur
le tas du
> > processus utilisant cette DLL, mais sur le 'tas' de la DLL. Ce
qui
> > fait que lorsque tu fermes le programme utilisant la DLL sans
> > libérer explicitement ce qui a été alloué par la DLL en
question, tu
> > as une belle fuite mémoire. Depuis je ne sais plus quelle
version de
> > Visual C++, la libcrt contient une rustine qui piste les
allocations
> > de mémoire dans les DLL pour les libérer explicitement à la fin
de
> > l'exécution d'un processus.
> >
> > Un autre truc amusant avec cette façon de faire, c'est qu'un
> > processus peut marcher sur les données d'un autre processus au
> > travers de l'utilisation d'un pointeur hasardeux en mémoire
pour peu
> > qu'il a été alloué dans la mémoire d'une DLL.
> >
> > Donc, lorsqu'on doit écrire une DLL sous Windows, on évite
autant
> > que possible d'utiliser de la mémorie dynamique avec allocation
> > _dans_ la DLL.
>
> En simplifiant un peu, mon métier consiste à coder des DLLs, et ça
> fait un paquet d'années. Donc ton message m'inquiète au plus haut
> point, car je n'y comprends strictement rien. Tu serais bien
> aimable de m'aider à trouver la référence vers l'article de KB
> dont tu parles.
>
Comme je trouvais ça hautement bizarre, j'ai cherché un peu sur le
web
et trouvé ceci:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682594(v=vs.8
5).aspx
A Dynamic-Link Library (DLL) can contain global data or local data.
Je pense que <http://msdn.microsoft.com/en-US/library/ms235460.aspx>
est plus
proche de ce que raconte JKB, modulo le mappage de la DLL. Ceci-dit,
je ne vois
pas trace de ladite rustine. M'enfin comme je code pas non plus des
DLLs sous Windows...
Le Tue, 17 Jan 2012 22:25:58 +0000 (UTC),
(Michel Talon) a écrit :Manuel Leclerc wrote:
> Le 13/01/2012 09:53, JKB a écrit :
>
> > Tu as la description complète du problème dans la KB de
Microsoft> > (je te l'accorde, il faut un peu chercher parce qu'ils ne
doivent> > pas être fier du problème).
> >
> > Pour faire simple : une DLL n'est pas mappée dans un espace de
> > processus sous Windows mais dans un espace commun aux processus
qui> > l'utilisent (ils n'ont _rien_ compris au fonctionnement de base
de> > la mémoire virtuelle. Passons ! Pour branlibranla, la mémoire
> > virtuelle, même sur l'architecture moisie du x86, c'est un truc
qui> > permet d'avoir une zone de mémoire physique mappée sur plusieurs
> > zones de mémoire virtuelle dans des espaces mémoire différents).
> > La conséquence de ce choix (de ce bug ? de cette fonctionnalité
?)> > est que la mémoire allouée dans une DLL n'est pas allouée sur
le tas du> > processus utilisant cette DLL, mais sur le 'tas' de la DLL. Ce
qui> > fait que lorsque tu fermes le programme utilisant la DLL sans
> > libérer explicitement ce qui a été alloué par la DLL en
question, tu> > as une belle fuite mémoire. Depuis je ne sais plus quelle
version de> > Visual C++, la libcrt contient une rustine qui piste les
allocations> > de mémoire dans les DLL pour les libérer explicitement à la fin
de> > l'exécution d'un processus.
> >
> > Un autre truc amusant avec cette façon de faire, c'est qu'un
> > processus peut marcher sur les données d'un autre processus au
> > travers de l'utilisation d'un pointeur hasardeux en mémoire
pour peu> > qu'il a été alloué dans la mémoire d'une DLL.
> >
> > Donc, lorsqu'on doit écrire une DLL sous Windows, on évite
autant> > que possible d'utiliser de la mémorie dynamique avec allocation
> > _dans_ la DLL.
>
> En simplifiant un peu, mon métier consiste à coder des DLLs, et ça
> fait un paquet d'années. Donc ton message m'inquiète au plus haut
> point, car je n'y comprends strictement rien. Tu serais bien
> aimable de m'aider à trouver la référence vers l'article de KB
> dont tu parles.
>Comme je trouvais ça hautement bizarre, j'ai cherché un peu sur le
webet trouvé ceci:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682594(v=vs.8
5).aspxA Dynamic-Link Library (DLL) can contain global data or local data.
Je pense que <http://msdn.microsoft.com/en-US/library/ms235460.aspx>
est plus
proche de ce que raconte JKB, modulo le mappage de la DLL. Ceci-dit,
je ne vois
pas trace de ladite rustine. M'enfin comme je code pas non plus des
DLLs sous Windows...
Le Wed, 18 Jan 2012 00:25:37 +0100,
Toxico Nimbus écrivait :
Je pense que <http://msdn.microsoft.com/en-US/library/ms235460.aspx>
est plus proche de ce que raconte JKB, modulo le mappage de la DLL.
Ceci-dit, je ne vois pas trace de ladite rustine. M'enfin comme je
code pas non plus des DLLs sous Windows...
La rustine est dans le changelog de la libcrt.dll de je ne sais plus
quelle version de Visual C++. C'est assez ancien.
Le Wed, 18 Jan 2012 00:25:37 +0100,
Toxico Nimbus <toxn@free.fr> écrivait :
Je pense que <http://msdn.microsoft.com/en-US/library/ms235460.aspx>
est plus proche de ce que raconte JKB, modulo le mappage de la DLL.
Ceci-dit, je ne vois pas trace de ladite rustine. M'enfin comme je
code pas non plus des DLLs sous Windows...
La rustine est dans le changelog de la libcrt.dll de je ne sais plus
quelle version de Visual C++. C'est assez ancien.
Le Wed, 18 Jan 2012 00:25:37 +0100,
Toxico Nimbus écrivait :
Je pense que <http://msdn.microsoft.com/en-US/library/ms235460.aspx>
est plus proche de ce que raconte JKB, modulo le mappage de la DLL.
Ceci-dit, je ne vois pas trace de ladite rustine. M'enfin comme je
code pas non plus des DLLs sous Windows...
La rustine est dans le changelog de la libcrt.dll de je ne sais plus
quelle version de Visual C++. C'est assez ancien.
Le 18/01/2012 08:21, JKB a écrit :Le Wed, 18 Jan 2012 00:25:37 +0100,
Toxico Nimbus écrivait :
Je pense que <http://msdn.microsoft.com/en-US/library/ms235460.aspx>
est plus proche de ce que raconte JKB, modulo le mappage de la DLL.
Ceci-dit, je ne vois pas trace de ladite rustine. M'enfin comme je
code pas non plus des DLLs sous Windows...
La rustine est dans le changelog de la libcrt.dll de je ne sais plus
quelle version de Visual C++. C'est assez ancien.
Heu... quand on utilise des CRTs différentes au sein d'un même process
il ne faut pas faire libérer par l'une ce qui a été allouée par une
autre, ça me paraît assez logique et normal.
Je ne vois pas le moindre foutu rapport avec la gestion de la mémoire
virtuelle par le kernel, ou avec le mappage des DLLs, ou avec une soit
disant fuite mémoire à la fin d'un processus, ou avec ton histoire
de corruption de la mémoire d'un autre processus.
Si c'est de cette page dont tu parlais, je crois que tu racontes
n'importe quoi ; ça me rassure.
Le 18/01/2012 08:21, JKB a écrit :
Le Wed, 18 Jan 2012 00:25:37 +0100,
Toxico Nimbus <toxn@free.fr> écrivait :
Je pense que <http://msdn.microsoft.com/en-US/library/ms235460.aspx>
est plus proche de ce que raconte JKB, modulo le mappage de la DLL.
Ceci-dit, je ne vois pas trace de ladite rustine. M'enfin comme je
code pas non plus des DLLs sous Windows...
La rustine est dans le changelog de la libcrt.dll de je ne sais plus
quelle version de Visual C++. C'est assez ancien.
Heu... quand on utilise des CRTs différentes au sein d'un même process
il ne faut pas faire libérer par l'une ce qui a été allouée par une
autre, ça me paraît assez logique et normal.
Je ne vois pas le moindre foutu rapport avec la gestion de la mémoire
virtuelle par le kernel, ou avec le mappage des DLLs, ou avec une soit
disant fuite mémoire à la fin d'un processus, ou avec ton histoire
de corruption de la mémoire d'un autre processus.
Si c'est de cette page dont tu parlais, je crois que tu racontes
n'importe quoi ; ça me rassure.
Le 18/01/2012 08:21, JKB a écrit :Le Wed, 18 Jan 2012 00:25:37 +0100,
Toxico Nimbus écrivait :
Je pense que <http://msdn.microsoft.com/en-US/library/ms235460.aspx>
est plus proche de ce que raconte JKB, modulo le mappage de la DLL.
Ceci-dit, je ne vois pas trace de ladite rustine. M'enfin comme je
code pas non plus des DLLs sous Windows...
La rustine est dans le changelog de la libcrt.dll de je ne sais plus
quelle version de Visual C++. C'est assez ancien.
Heu... quand on utilise des CRTs différentes au sein d'un même process
il ne faut pas faire libérer par l'une ce qui a été allouée par une
autre, ça me paraît assez logique et normal.
Je ne vois pas le moindre foutu rapport avec la gestion de la mémoire
virtuelle par le kernel, ou avec le mappage des DLLs, ou avec une soit
disant fuite mémoire à la fin d'un processus, ou avec ton histoire
de corruption de la mémoire d'un autre processus.
Si c'est de cette page dont tu parlais, je crois que tu racontes
n'importe quoi ; ça me rassure.
Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Le 18/01/2012 11:02, JKB a écrit :Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
Et avec la complicité de la CNAM, aujourd'hui, pas possible de passer
par un logiciel non homologué ! Déjà qu'avant, avoir un lecteur vital
sous linux était très très difficile, mais alors maintenant c'est mort
de chez mort ...
On est piégé comme des cons, avec des base de données proprio sur des
logiciels homologués buggués à mort avec des plantages de biblio microsoft !
Le 18/01/2012 11:02, JKB a écrit :
Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
Et avec la complicité de la CNAM, aujourd'hui, pas possible de passer
par un logiciel non homologué ! Déjà qu'avant, avoir un lecteur vital
sous linux était très très difficile, mais alors maintenant c'est mort
de chez mort ...
On est piégé comme des cons, avec des base de données proprio sur des
logiciels homologués buggués à mort avec des plantages de biblio microsoft !
Le 18/01/2012 11:02, JKB a écrit :Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
Et avec la complicité de la CNAM, aujourd'hui, pas possible de passer
par un logiciel non homologué ! Déjà qu'avant, avoir un lecteur vital
sous linux était très très difficile, mais alors maintenant c'est mort
de chez mort ...
On est piégé comme des cons, avec des base de données proprio sur des
logiciels homologués buggués à mort avec des plantages de biblio microsoft !
Le 18/01/2012 11:02, JKB a écrit :Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
Le 18/01/2012 11:02, JKB a écrit :
Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
Le 18/01/2012 11:02, JKB a écrit :Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
Et quand j'ouvre deux softimage, que dans un je lance un rendu d'une
image, pendant que dans l autre je continue a modelisé un objet et que
tout ca se passe sans aucun lag, tu ne penses pas que c'est du
multitache ?
Pour pouvoir faire ça, c'est parce que tes processus laissent la main à ton
système. Ce sont tes applications qui sont programmées pour permettre à ton
système d'être multitâche.
Et quand j'ouvre deux softimage, que dans un je lance un rendu d'une
image, pendant que dans l autre je continue a modelisé un objet et que
tout ca se passe sans aucun lag, tu ne penses pas que c'est du
multitache ?
Pour pouvoir faire ça, c'est parce que tes processus laissent la main à ton
système. Ce sont tes applications qui sont programmées pour permettre à ton
système d'être multitâche.
Et quand j'ouvre deux softimage, que dans un je lance un rendu d'une
image, pendant que dans l autre je continue a modelisé un objet et que
tout ca se passe sans aucun lag, tu ne penses pas que c'est du
multitache ?
Pour pouvoir faire ça, c'est parce que tes processus laissent la main à ton
système. Ce sont tes applications qui sont programmées pour permettre à ton
système d'être multitâche.
Le 29/01/2012 18:56, PP a écrit :Le 18/01/2012 11:02, JKB a écrit :Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
J'attends toujours la référence qui pourrait me convaincre que JKB a
fait autre chose que de raconter n'importe quoi.
Mais pourquoi considères tu qu'un plantage dans une bibliothèque est lié
à cette bibliothèque, et non à ces appelants ?
Le 29/01/2012 18:56, PP a écrit :
Le 18/01/2012 11:02, JKB a écrit :
Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
J'attends toujours la référence qui pourrait me convaincre que JKB a
fait autre chose que de raconter n'importe quoi.
Mais pourquoi considères tu qu'un plantage dans une bibliothèque est lié
à cette bibliothèque, et non à ces appelants ?
Le 29/01/2012 18:56, PP a écrit :Le 18/01/2012 11:02, JKB a écrit :Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
J'attends toujours la référence qui pourrait me convaincre que JKB a
fait autre chose que de raconter n'importe quoi.
Mais pourquoi considères tu qu'un plantage dans une bibliothèque est lié
à cette bibliothèque, et non à ces appelants ?
Le 29/01/2012 18:56, PP a écrit :Le 18/01/2012 11:02, JKB a écrit :Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
J'attends toujours la référence qui pourrait me convaincre que JKB a
fait autre chose que de raconter n'importe quoi.
Le 29/01/2012 18:56, PP a écrit :
Le 18/01/2012 11:02, JKB a écrit :
Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
J'attends toujours la référence qui pourrait me convaincre que JKB a
fait autre chose que de raconter n'importe quoi.
Le 29/01/2012 18:56, PP a écrit :Le 18/01/2012 11:02, JKB a écrit :Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
J'attends toujours la référence qui pourrait me convaincre que JKB a
fait autre chose que de raconter n'importe quoi.