FreeLibrary qui ne rend pas la main :-(

Thierry

11/10/2004 à 17:07

Bonjour,

Aurélien REGAT-BARREL a écrit :

Là je m'avour vaincu : comment forcer Windows à décharger ce fouttu
module ? Je pense que c'est le DllMain -> DLL_PROCESS_DETACH buggé qui
empêche de décharger le module. Que faire dans un tel cas ?

Choper contre un mur le mec qu'a codé la DLL ?

--
« Always look at the bright side of the life... »

Thierry

11/10/2004 à 17:08

Bonjour,

Aurélien REGAT-BARREL a écrit :

Là je m'avour vaincu : comment forcer Windows à décharger ce fouttu
module ? Je pense que c'est le DllMain -> DLL_PROCESS_DETACH buggé qui
empêche de décharger le module. Que faire dans un tel cas ?

Choper contre un mur le mec qu'a codé la DLL ?
Le menacer de reveler a ses parents qu'il est informaticien et non pas
pianiste dans un bordel ?

--
« Always look at the bright side of the life... »

AMcD®

11/10/2004 à 17:58

Aurélien REGAT-BARREL wrote:

Là je m'avour vaincu : comment forcer Windows à décharger ce fouttu
module ? Je pense que c'est le DllMain -> DLL_PROCESS_DETACH buggé
qui empêche de décharger le module. Que faire dans un tel cas ?
Merci.

FreeLibrary() planter ? La DLL suspecte là, elle appelle pas d'autres DLLs ?
Parce que le problème pourrait venir de là... Regarde avec Dependency Walker
par exemple. Tu peux avoir pas mal de bazar si ta DLL appelle d'autres DLL
qui se libèrent mal lors de l'unloading de la tienne.

Sinon t'as testé de démapper toi-même la DLL de ton processus ? Une idée
comme ça, si tu vires le module de la liste du PEB ça devrait marcher non ?
Enfin, ça doit être du boulot, faut réinitialiser l'IAT aussi au passage
hein...

Un article mirifique qui peut t'aider :
http://arnold.mcdonald.free.fr/php/Index.php?p06 (regarde la figure 17)
:-).

Tant que j'y pense, t'as regardé ça :
http://www.winguides.com/registry/display.php?idf7 ?

Au fait, pourquoi tu recodes pas les fonctions de ta DLL ? Parce qu'utiliser
des fonctions d'une DLL foireuse, brrrr...

--
AMcD®

http://arnold.mcdonald.free.fr/

Vincent Burel

11/10/2004 à 21:07

"AMcD®" wrote in message
news:416aad8d$0$12178$

Aurélien REGAT-BARREL wrote:

> Là je m'avour vaincu : comment forcer Windows à décharger ce fouttu
> module ? Je pense que c'est le DllMain -> DLL_PROCESS_DETACH buggé
> qui empêche de décharger le module. Que faire dans un tel cas ?
> Merci.

FreeLibrary() planter ? La DLL suspecte là, elle appelle pas d'autres DLLs

?

Parce que le problème pourrait venir de là...

dans la DLLMain, effectivement (sur DLL_PROCESS_DETACH ou ATTACH) il est
déconseillé d'appeler des fonctions d'autre DLL pour éviter des deadlock (ou
appel récursive inter DLL). Mais les programmeurs amateurs s'entêtent à
faire
des appel d'API diverses dans la DLLMain, d'autant que parfois cela ne pose
aucun problème, donc le mec te croit pas quand tu lui dis que tout ce qu'il
fait dans le DLLmain peut poser des problème... Avec le temps le mec devient
professionnel du développement , Et puis un jour y'a un pépin, et le pépin
c'est un freeze alors ca spécule à mort sur Microsoft et les bugs, le
multitache et autres machin... ca coute des million en debugging, ca ruine
la boite, au bout d'un an y'a plus de trésorerie, il faut déposer le bilan,
les client paient plus, ca marche plus... ah ben mince alors :-)

Aurélien REGAT-BARREL

12/10/2004 à 10:12

> FreeLibrary() planter ? La DLL suspecte là, elle appelle pas d'autres DLLs

?

Parce que le problème pourrait venir de là... Regarde avec Dependency

Walker

par exemple. Tu peux avoir pas mal de bazar si ta DLL appelle d'autres DLL
qui se libèrent mal lors de l'unloading de la tienne.

Cette dll utilise uniquement kernel32 et une dll interface d'un driver
firewire. Elle fait partie d'un SDK qui permet de piloter une caméra
scientifique.

Sinon t'as testé de démapper toi-même la DLL de ton processus ? Une idée
comme ça, si tu vires le module de la liste du PEB ça devrait marcher non

?

Enfin, ça doit être du boulot, faut réinitialiser l'IAT aussi au passage
hein...

Moui, beaucoup trop de boulot pour un truc qui est censé fonctionner depuis
une semaine...:-/
Si j'avais le temps je tenterais plus simple, vu que déjà j'appelle les
fonctions critiques de cette dll depuis un thread que je kill s'il est
planté, ben faire la même chose pour le FreeLibrary.
Si le plantage vient du DllMain->DLL_THREAD_DETACH, ça pourrait résoudre mon
probleme. Mais ça me parrait trop beau.

Un article mirifique qui peut t'aider :
http://arnold.mcdonald.free.fr/php/Index.php?p06 (regarde la figure 17)
:-).

En dehors des heures de boulot j'y jetterais un oeil, ainsi qu'au reste ;-)

Tant que j'y pense, t'as regardé ça :
http://www.winguides.com/registry/display.php?idf7 ?

Ca concerne que Explorer il me semble, et je me méfie de ce genre de softs
qui soit disant optimizent. Dans le meilleur des cas ça ralentit le système
(ah c'est malin de faire décharger toutes les dll, comme ça chaque création
de nvx process est bien long, même si on vient de l'exécuter 2 sec avant),
dans le pire ça le fait planter:
http://support.microsoft.com/?id6480

Au fait, pourquoi tu recodes pas les fonctions de ta DLL ? Parce

qu'utiliser

des fonctions d'une DLL foireuse, brrrr...

Ben oui mais c'est tout ce que j'ai pour piloter ma caméra. Mais d'un point
de vue des codeurs allemand, la dll n'a pas de bug, c'est moi qui l'utilise
mal... (Enfin, je les ai pas encore contacté, mais c'est ce qui m'attend).
Merci.

--
Aurélien REGAT-BARREL

> FreeLibrary() planter ? La DLL suspecte là, elle appelle pas d'autres DLLs

?

Parce que le problème pourrait venir de là... Regarde avec Dependency

Walker

par exemple. Tu peux avoir pas mal de bazar si ta DLL appelle d'autres DLL
qui se libèrent mal lors de l'unloading de la tienne.

Cette dll utilise uniquement kernel32 et une dll interface d'un driver
firewire. Elle fait partie d'un SDK qui permet de piloter une caméra
scientifique.

Sinon t'as testé de démapper toi-même la DLL de ton processus ? Une idée
comme ça, si tu vires le module de la liste du PEB ça devrait marcher non

?

Enfin, ça doit être du boulot, faut réinitialiser l'IAT aussi au passage
hein...

Moui, beaucoup trop de boulot pour un truc qui est censé fonctionner depuis
une semaine...:-/
Si j'avais le temps je tenterais plus simple, vu que déjà j'appelle les
fonctions critiques de cette dll depuis un thread que je kill s'il est
planté, ben faire la même chose pour le FreeLibrary.
Si le plantage vient du DllMain->DLL_THREAD_DETACH, ça pourrait résoudre mon
probleme. Mais ça me parrait trop beau.

Un article mirifique qui peut t'aider :
http://arnold.mcdonald.free.fr/php/Index.php?p06 (regarde la figure 17)
:-).

En dehors des heures de boulot j'y jetterais un oeil, ainsi qu'au reste ;-)

Tant que j'y pense, t'as regardé ça :
http://www.winguides.com/registry/display.php?idf7 ?

Ca concerne que Explorer il me semble, et je me méfie de ce genre de softs
qui soit disant optimizent. Dans le meilleur des cas ça ralentit le système
(ah c'est malin de faire décharger toutes les dll, comme ça chaque création
de nvx process est bien long, même si on vient de l'exécuter 2 sec avant),
dans le pire ça le fait planter:
http://support.microsoft.com/?id6480

Au fait, pourquoi tu recodes pas les fonctions de ta DLL ? Parce

qu'utiliser

des fonctions d'une DLL foireuse, brrrr...

Ben oui mais c'est tout ce que j'ai pour piloter ma caméra. Mais d'un point
de vue des codeurs allemand, la dll n'a pas de bug, c'est moi qui l'utilise
mal... (Enfin, je les ai pas encore contacté, mais c'est ce qui m'attend).
Merci.

--
Aurélien REGAT-BARREL

Vous avez filtré cet utilisateur ! Consultez son message

> FreeLibrary() planter ? La DLL suspecte là, elle appelle pas d'autres DLLs

?

Parce que le problème pourrait venir de là... Regarde avec Dependency

Walker

par exemple. Tu peux avoir pas mal de bazar si ta DLL appelle d'autres DLL
qui se libèrent mal lors de l'unloading de la tienne.

Cette dll utilise uniquement kernel32 et une dll interface d'un driver
firewire. Elle fait partie d'un SDK qui permet de piloter une caméra
scientifique.

Sinon t'as testé de démapper toi-même la DLL de ton processus ? Une idée
comme ça, si tu vires le module de la liste du PEB ça devrait marcher non

?

Enfin, ça doit être du boulot, faut réinitialiser l'IAT aussi au passage
hein...

Moui, beaucoup trop de boulot pour un truc qui est censé fonctionner depuis
une semaine...:-/
Si j'avais le temps je tenterais plus simple, vu que déjà j'appelle les
fonctions critiques de cette dll depuis un thread que je kill s'il est
planté, ben faire la même chose pour le FreeLibrary.
Si le plantage vient du DllMain->DLL_THREAD_DETACH, ça pourrait résoudre mon
probleme. Mais ça me parrait trop beau.

Un article mirifique qui peut t'aider :
http://arnold.mcdonald.free.fr/php/Index.php?p06 (regarde la figure 17)
:-).

En dehors des heures de boulot j'y jetterais un oeil, ainsi qu'au reste ;-)

Tant que j'y pense, t'as regardé ça :
http://www.winguides.com/registry/display.php?idf7 ?

Ca concerne que Explorer il me semble, et je me méfie de ce genre de softs
qui soit disant optimizent. Dans le meilleur des cas ça ralentit le système
(ah c'est malin de faire décharger toutes les dll, comme ça chaque création
de nvx process est bien long, même si on vient de l'exécuter 2 sec avant),
dans le pire ça le fait planter:
http://support.microsoft.com/?id6480

Au fait, pourquoi tu recodes pas les fonctions de ta DLL ? Parce

qu'utiliser

des fonctions d'une DLL foireuse, brrrr...

Ben oui mais c'est tout ce que j'ai pour piloter ma caméra. Mais d'un point
de vue des codeurs allemand, la dll n'a pas de bug, c'est moi qui l'utilise
mal... (Enfin, je les ai pas encore contacté, mais c'est ce qui m'attend).
Merci.

--
Aurélien REGAT-BARREL

Aurélien REGAT-BARREL

12/10/2004 à 10:33

> dans la DLLMain, effectivement (sur DLL_PROCESS_DETACH ou ATTACH) il est
déconseillé d'appeler des fonctions d'autre DLL pour éviter des deadlock

(ou

appel récursive inter DLL). Mais les programmeurs amateurs s'entêtent à
faire

Le probleme c'est que ces mecs développent aussi des drivers. J'ai vu ce que
ça donnait sur une autre caméra. Tu transmets un buffer ainsi que sa taille,
mais visiblement la taille ils s'en fouttent, vu que si elle est pas bonne
t'es récompensé avec un écran bleau...
Là c'est emmerdant car c'est une fonction interne à la dll qui plante,
fonction qui permet de couper la liaison (CloseCamera). Comme juste avant
elle a planté dans mon thread kamikaze, moi j'ai tué le thread et je dit bye
bye à la dll via FreeLibrary. Mais le mec a du faire un truc genre "si la
connexion n'a pas été fermée, le faire" et hop, il appelle la même fonction,
et moi, ben je l'ai où je pense.
Du coup actuellement je ne fais plus le FreeLibrary, et à la place du
LoadLibrary je tente d'abord un GetModuleHandle. Etrangement, ça a l'air de
bien marcher au 2° coup malgré le plantage précédent, je vais essayer
aujourd'hui de voir si en cas de plantage, je peux arriver à faire un reset
via un nouveau OpenCamera suivi d'un CloseCamera qui pourrait alors
fonctionner. Ca serait presque propre...

des appel d'API diverses dans la DLLMain, d'autant que parfois cela ne

pose

aucun problème, donc le mec te croit pas quand tu lui dis que tout ce

qu'il

fait dans le DLLmain peut poser des problème... Avec le temps le mec

devient

professionnel du développement , Et puis un jour y'a un pépin, et le pépin
c'est un freeze alors ca spécule à mort sur Microsoft et les bugs, le
multitache et autres machin... ca coute des million en debugging, ca ruine
la boite, au bout d'un an y'a plus de trésorerie, il faut déposer le

bilan,

les client paient plus, ca marche plus... ah ben mince alors :-)

Moui. Mais ici je soupçonne plutôt un manque de budget pour le département
info de la boite. Car la majorité des caméras sont utilisées avec le
logiciel fourni, et très peu programment le leur. Pourtant au prix que ça
coûte on pourrait demander un truc correct, surtout que même le soft fourni
est franchement limite. On a déjà envoyé un rapport de bogue y'a 1 mois, pas
de réponse. Pour info, un des bogues concerne l'enregistrement dans un
fichier ASCII de valeurs 16 bits. Attention, la question qui tue, combien
faut-il prévoir de chiffres pour stocker en ASCII des nombres de 16 bits ?
Ben voilà, il en manque un.

--
Aurélien REGAT-BARREL

> dans la DLLMain, effectivement (sur DLL_PROCESS_DETACH ou ATTACH) il est
déconseillé d'appeler des fonctions d'autre DLL pour éviter des deadlock

(ou

appel récursive inter DLL). Mais les programmeurs amateurs s'entêtent à
faire

Le probleme c'est que ces mecs développent aussi des drivers. J'ai vu ce que
ça donnait sur une autre caméra. Tu transmets un buffer ainsi que sa taille,
mais visiblement la taille ils s'en fouttent, vu que si elle est pas bonne
t'es récompensé avec un écran bleau...
Là c'est emmerdant car c'est une fonction interne à la dll qui plante,
fonction qui permet de couper la liaison (CloseCamera). Comme juste avant
elle a planté dans mon thread kamikaze, moi j'ai tué le thread et je dit bye
bye à la dll via FreeLibrary. Mais le mec a du faire un truc genre "si la
connexion n'a pas été fermée, le faire" et hop, il appelle la même fonction,
et moi, ben je l'ai où je pense.
Du coup actuellement je ne fais plus le FreeLibrary, et à la place du
LoadLibrary je tente d'abord un GetModuleHandle. Etrangement, ça a l'air de
bien marcher au 2° coup malgré le plantage précédent, je vais essayer
aujourd'hui de voir si en cas de plantage, je peux arriver à faire un reset
via un nouveau OpenCamera suivi d'un CloseCamera qui pourrait alors
fonctionner. Ca serait presque propre...

des appel d'API diverses dans la DLLMain, d'autant que parfois cela ne

pose

aucun problème, donc le mec te croit pas quand tu lui dis que tout ce

qu'il

fait dans le DLLmain peut poser des problème... Avec le temps le mec

devient

professionnel du développement , Et puis un jour y'a un pépin, et le pépin
c'est un freeze alors ca spécule à mort sur Microsoft et les bugs, le
multitache et autres machin... ca coute des million en debugging, ca ruine
la boite, au bout d'un an y'a plus de trésorerie, il faut déposer le

bilan,

les client paient plus, ca marche plus... ah ben mince alors :-)

Moui. Mais ici je soupçonne plutôt un manque de budget pour le département
info de la boite. Car la majorité des caméras sont utilisées avec le
logiciel fourni, et très peu programment le leur. Pourtant au prix que ça
coûte on pourrait demander un truc correct, surtout que même le soft fourni
est franchement limite. On a déjà envoyé un rapport de bogue y'a 1 mois, pas
de réponse. Pour info, un des bogues concerne l'enregistrement dans un
fichier ASCII de valeurs 16 bits. Attention, la question qui tue, combien
faut-il prévoir de chiffres pour stocker en ASCII des nombres de 16 bits ?
Ben voilà, il en manque un.

--
Aurélien REGAT-BARREL

Vous avez filtré cet utilisateur ! Consultez son message

> dans la DLLMain, effectivement (sur DLL_PROCESS_DETACH ou ATTACH) il est
déconseillé d'appeler des fonctions d'autre DLL pour éviter des deadlock

(ou

appel récursive inter DLL). Mais les programmeurs amateurs s'entêtent à
faire

Le probleme c'est que ces mecs développent aussi des drivers. J'ai vu ce que
ça donnait sur une autre caméra. Tu transmets un buffer ainsi que sa taille,
mais visiblement la taille ils s'en fouttent, vu que si elle est pas bonne
t'es récompensé avec un écran bleau...
Là c'est emmerdant car c'est une fonction interne à la dll qui plante,
fonction qui permet de couper la liaison (CloseCamera). Comme juste avant
elle a planté dans mon thread kamikaze, moi j'ai tué le thread et je dit bye
bye à la dll via FreeLibrary. Mais le mec a du faire un truc genre "si la
connexion n'a pas été fermée, le faire" et hop, il appelle la même fonction,
et moi, ben je l'ai où je pense.
Du coup actuellement je ne fais plus le FreeLibrary, et à la place du
LoadLibrary je tente d'abord un GetModuleHandle. Etrangement, ça a l'air de
bien marcher au 2° coup malgré le plantage précédent, je vais essayer
aujourd'hui de voir si en cas de plantage, je peux arriver à faire un reset
via un nouveau OpenCamera suivi d'un CloseCamera qui pourrait alors
fonctionner. Ca serait presque propre...

des appel d'API diverses dans la DLLMain, d'autant que parfois cela ne

pose

aucun problème, donc le mec te croit pas quand tu lui dis que tout ce

qu'il

fait dans le DLLmain peut poser des problème... Avec le temps le mec

devient

professionnel du développement , Et puis un jour y'a un pépin, et le pépin
c'est un freeze alors ca spécule à mort sur Microsoft et les bugs, le
multitache et autres machin... ca coute des million en debugging, ca ruine
la boite, au bout d'un an y'a plus de trésorerie, il faut déposer le

bilan,

les client paient plus, ca marche plus... ah ben mince alors :-)

Moui. Mais ici je soupçonne plutôt un manque de budget pour le département
info de la boite. Car la majorité des caméras sont utilisées avec le
logiciel fourni, et très peu programment le leur. Pourtant au prix que ça
coûte on pourrait demander un truc correct, surtout que même le soft fourni
est franchement limite. On a déjà envoyé un rapport de bogue y'a 1 mois, pas
de réponse. Pour info, un des bogues concerne l'enregistrement dans un
fichier ASCII de valeurs 16 bits. Attention, la question qui tue, combien
faut-il prévoir de chiffres pour stocker en ASCII des nombres de 16 bits ?
Ben voilà, il en manque un.

--
Aurélien REGAT-BARREL

Vincent Burel

12/10/2004 à 11:10

"Aurélien REGAT-BARREL" wrote in message
news:416b9552$0$23254$

> dans la DLLMain, effectivement (sur DLL_PROCESS_DETACH ou ATTACH) il est
> déconseillé d'appeler des fonctions d'autre DLL pour éviter des deadlock
(ou
> appel récursive inter DLL). Mais les programmeurs amateurs s'entêtent à
> faire
Le probleme c'est que ces mecs développent aussi des drivers. J'ai vu ce

que

ça donnait sur une autre caméra. Tu transmets un buffer ainsi que sa

taille,

mais visiblement la taille ils s'en fouttent, vu que si elle est pas bonne
t'es récompensé avec un écran bleau...

et oui, note que c'est un bleu qui n'est pas sans intéret artistique. Ceci
dit, c'est de plus en plus souvent que l'industrie fournit du matos buggé,
doté de drivers buggé et d'interface soft buggé, fait par des développeurs
souvent externes à l'entreprise, payés au lance pierre, ou contre un ou deux
exemplaires gratuit du produit (ne riez pas, pas mal d'entreprises
relativement importantes travaillent comme ça).

Pour info, un des bogues concerne l'enregistrement dans un
fichier ASCII de valeurs 16 bits. Attention, la question qui tue, combien
faut-il prévoir de chiffres pour stocker en ASCII des nombres de 16 bits ?
Ben voilà, il en manque un.

ha ouai, mais le développeur qui sait lire à déjà complètement disparu,
regarde le seul qui lit un peu les doc ici , ca doit être AMcD :-) Et la
tendance actuelle c'est le développeur qui sait compter... qui est en train
de disparaitre petit à petit. Vivement que le développeur qui passe son
temps à blablater disparaisse... oups c'est moi ! :-).

AMcD®

12/10/2004 à 12:58

Vincent Burel wrote:

ha ouai, mais le développeur qui sait lire à déjà complètement
disparu,

Ou disparaît peu à peu pour les derniers... Personellement, ça fait un bail
que j'ai pas mis un pied dans une fac, un IUT, etc., mais tout de même, je
me demande bien ce qu'on y apprend aujourd'hui ! J'installe/teste des tas de
softs, commerciaux, shareware, freeware, etc. 'tain, ça plante de tous les
côtés ! Et des bugs comme pour Aurélien hein, Windows n'est absolument pas
en cause, c'est ces logiciels qui sont codés par des buses, point à la ligne
!

Moi qui ait l'habitude d'ouvrir mon museau, je le clame haut et fort, la
nouvelle génération de codeurs là, celle qui a 10 ans de moins que nous,
elle vaut pas un rond pour la grande majorité. Élevée au C++, aux grandes
théories, au GNU et cie, mais sur des bases foireuses. Jamais vu autant de
bugs depuis 2 ans environ, et dès qu'un driver foire t'es mort ! C'est
devenu n'importe quoi.

regarde le seul qui lit un peu les doc ici , ca doit être
AMcD :-)

C'est pour cela que je disparaît moi ausi à mon tour. Je n'appartiens pas à
la même planète que mes "collègues". Moi, quand j'entends "qu'est-ce que tu
t'emmerdes à vérif comme un fou, si ça marche pas y aura du support client",
c'est mon poing qui me démange. Mais bon, c'est comme ça.

Et la tendance actuelle c'est le développeur qui sait
compter...

La tendance actuelle c'est le n'importe quoi et une génération de codeurs
minables. Quand je vois ce que moi je faisais à 16 ans et que je compare à
un gars de 23 ans qui sort d'une école je suis effaré ! On a guelé sur Kro
pendant des années, loué le Open Source, mais oublié d'inculquer la base aux
gens. L'Open Source ! Ha en voilà une idée géniale tiens ! Comme si c'était
la panacée. J'en rencontre des morveux (Linuxiens à 100% bien évidemment)
qui te sortent que leur soft est fiable puisqu'en Open Source ! Ben voyons !
Dans leur esprit, le code est accessible, donc, dans leur esprit, quelqu'un
va venir vérifier si il y a un bug. Leur esprit vit dans un monde parfait
mais irréel. Personne viendra vérifier ton code dans la pratique. Et dans le
monde parfait, tu le vérifie avant de toute façons.

Sérieux, je ne sais pas comment ont été formé ces djeunz, mais c'est assez
terrible. Regarde les drivers. Qui code encore des drivers en France ? Qui
sait seulement ? 100 personnes ? 50 ? Moins ? Faudrait demander à GG, mais
je pense qu'il n'y a même plus de support DDK en français... Bilan ? Du
tierce-partie, de l'import d'on ne sait-où et, au final, des problèmes comme
notre ami. On a monté la tête aux gens contre Kro, en pratique, les
étudiants (ceux intéressés par la prog tout du moins) se sont tournés vers
Linux, où tout est gratuit, disponible (etc., etc.). Moi, je veux bien, mais
ça fait de piètres codeurs au final.

Tiens dernier gag en date. Un gars rencontré sur le net qui se disait
hacker. Un gros cador d'après lui, genre qui poste en plein d'endroits, un
peu "connu". Le gars savait même pas programmer en assembleur... Ha ils sont
beaux les hackers modernes !

--
AMcD® - Radoteur

http://arnold.mcdonald.free.fr/

Vincent Burel wrote:

ha ouai, mais le développeur qui sait lire à déjà complètement
disparu,

Ou disparaît peu à peu pour les derniers... Personellement, ça fait un bail
que j'ai pas mis un pied dans une fac, un IUT, etc., mais tout de même, je
me demande bien ce qu'on y apprend aujourd'hui ! J'installe/teste des tas de
softs, commerciaux, shareware, freeware, etc. 'tain, ça plante de tous les
côtés ! Et des bugs comme pour Aurélien hein, Windows n'est absolument pas
en cause, c'est ces logiciels qui sont codés par des buses, point à la ligne
!

Moi qui ait l'habitude d'ouvrir mon museau, je le clame haut et fort, la
nouvelle génération de codeurs là, celle qui a 10 ans de moins que nous,
elle vaut pas un rond pour la grande majorité. Élevée au C++, aux grandes
théories, au GNU et cie, mais sur des bases foireuses. Jamais vu autant de
bugs depuis 2 ans environ, et dès qu'un driver foire t'es mort ! C'est
devenu n'importe quoi.

regarde le seul qui lit un peu les doc ici , ca doit être
AMcD :-)

C'est pour cela que je disparaît moi ausi à mon tour. Je n'appartiens pas à
la même planète que mes "collègues". Moi, quand j'entends "qu'est-ce que tu
t'emmerdes à vérif comme un fou, si ça marche pas y aura du support client",
c'est mon poing qui me démange. Mais bon, c'est comme ça.

Et la tendance actuelle c'est le développeur qui sait
compter...

La tendance actuelle c'est le n'importe quoi et une génération de codeurs
minables. Quand je vois ce que moi je faisais à 16 ans et que je compare à
un gars de 23 ans qui sort d'une école je suis effaré ! On a guelé sur Kro
pendant des années, loué le Open Source, mais oublié d'inculquer la base aux
gens. L'Open Source ! Ha en voilà une idée géniale tiens ! Comme si c'était
la panacée. J'en rencontre des morveux (Linuxiens à 100% bien évidemment)
qui te sortent que leur soft est fiable puisqu'en Open Source ! Ben voyons !
Dans leur esprit, le code est accessible, donc, dans leur esprit, quelqu'un
va venir vérifier si il y a un bug. Leur esprit vit dans un monde parfait
mais irréel. Personne viendra vérifier ton code dans la pratique. Et dans le
monde parfait, tu le vérifie avant de toute façons.

Sérieux, je ne sais pas comment ont été formé ces djeunz, mais c'est assez
terrible. Regarde les drivers. Qui code encore des drivers en France ? Qui
sait seulement ? 100 personnes ? 50 ? Moins ? Faudrait demander à GG, mais
je pense qu'il n'y a même plus de support DDK en français... Bilan ? Du
tierce-partie, de l'import d'on ne sait-où et, au final, des problèmes comme
notre ami. On a monté la tête aux gens contre Kro, en pratique, les
étudiants (ceux intéressés par la prog tout du moins) se sont tournés vers
Linux, où tout est gratuit, disponible (etc., etc.). Moi, je veux bien, mais
ça fait de piètres codeurs au final.

Tiens dernier gag en date. Un gars rencontré sur le net qui se disait
hacker. Un gros cador d'après lui, genre qui poste en plein d'endroits, un
peu "connu". Le gars savait même pas programmer en assembleur... Ha ils sont
beaux les hackers modernes !

--
AMcD® - Radoteur

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

Vincent Burel wrote:

ha ouai, mais le développeur qui sait lire à déjà complètement
disparu,

Ou disparaît peu à peu pour les derniers... Personellement, ça fait un bail
que j'ai pas mis un pied dans une fac, un IUT, etc., mais tout de même, je
me demande bien ce qu'on y apprend aujourd'hui ! J'installe/teste des tas de
softs, commerciaux, shareware, freeware, etc. 'tain, ça plante de tous les
côtés ! Et des bugs comme pour Aurélien hein, Windows n'est absolument pas
en cause, c'est ces logiciels qui sont codés par des buses, point à la ligne
!

Moi qui ait l'habitude d'ouvrir mon museau, je le clame haut et fort, la
nouvelle génération de codeurs là, celle qui a 10 ans de moins que nous,
elle vaut pas un rond pour la grande majorité. Élevée au C++, aux grandes
théories, au GNU et cie, mais sur des bases foireuses. Jamais vu autant de
bugs depuis 2 ans environ, et dès qu'un driver foire t'es mort ! C'est
devenu n'importe quoi.

regarde le seul qui lit un peu les doc ici , ca doit être
AMcD :-)

C'est pour cela que je disparaît moi ausi à mon tour. Je n'appartiens pas à
la même planète que mes "collègues". Moi, quand j'entends "qu'est-ce que tu
t'emmerdes à vérif comme un fou, si ça marche pas y aura du support client",
c'est mon poing qui me démange. Mais bon, c'est comme ça.

Et la tendance actuelle c'est le développeur qui sait
compter...

La tendance actuelle c'est le n'importe quoi et une génération de codeurs
minables. Quand je vois ce que moi je faisais à 16 ans et que je compare à
un gars de 23 ans qui sort d'une école je suis effaré ! On a guelé sur Kro
pendant des années, loué le Open Source, mais oublié d'inculquer la base aux
gens. L'Open Source ! Ha en voilà une idée géniale tiens ! Comme si c'était
la panacée. J'en rencontre des morveux (Linuxiens à 100% bien évidemment)
qui te sortent que leur soft est fiable puisqu'en Open Source ! Ben voyons !
Dans leur esprit, le code est accessible, donc, dans leur esprit, quelqu'un
va venir vérifier si il y a un bug. Leur esprit vit dans un monde parfait
mais irréel. Personne viendra vérifier ton code dans la pratique. Et dans le
monde parfait, tu le vérifie avant de toute façons.

Sérieux, je ne sais pas comment ont été formé ces djeunz, mais c'est assez
terrible. Regarde les drivers. Qui code encore des drivers en France ? Qui
sait seulement ? 100 personnes ? 50 ? Moins ? Faudrait demander à GG, mais
je pense qu'il n'y a même plus de support DDK en français... Bilan ? Du
tierce-partie, de l'import d'on ne sait-où et, au final, des problèmes comme
notre ami. On a monté la tête aux gens contre Kro, en pratique, les
étudiants (ceux intéressés par la prog tout du moins) se sont tournés vers
Linux, où tout est gratuit, disponible (etc., etc.). Moi, je veux bien, mais
ça fait de piètres codeurs au final.

Tiens dernier gag en date. Un gars rencontré sur le net qui se disait
hacker. Un gros cador d'après lui, genre qui poste en plein d'endroits, un
peu "connu". Le gars savait même pas programmer en assembleur... Ha ils sont
beaux les hackers modernes !

--
AMcD® - Radoteur

http://arnold.mcdonald.free.fr/

AMcD®

12/10/2004 à 13:13

Aurélien REGAT-BARREL wrote:

http://www.winguides.com/registry/display.php?idf7 ?

Ca concerne que Explorer il me semble, et je me méfie de ce genre de
softs qui soit disant optimizent.

C'est pas un soft, c'est une clé dans la base de registres.

Dans le meilleur des cas ça
ralentit le système (ah c'est malin de faire décharger toutes les
dll, comme ça chaque création de nvx process est bien long, même si
on vient de l'exécuter 2 sec avant), dans le pire ça le fait planter:
http://support.microsoft.com/?id6480

Ton lien ne marche pas, mais bon, pourquoi veux-tu que ça plante ? Chaque
appel de DLL voit incrémenter un compteur d'utilisation de celle-ci. Elle
n'est réellement déchargée de la mémoire que si le compteur passe à zéro.
Quand à ralentir la création d'un process, j'en doute, quand même. Tu sais,
importer une DLL c'est juste la mapper dans l'espace de ton processus et
remplir l'IAT avec les bonnes adresses des fonctions importées. Cela doit se
compter en micro-secondes...

Si tu peux filer le lien exact, j'aimerai ben le lire.

A+

--
AMcD®

http://arnold.mcdonald.free.fr/

Vincent Burel

12/10/2004 à 13:37

"AMcD®" wrote in message
news:416bb8cd$0$9077$

Vincent Burel wrote:

> ha ouai, mais le développeur qui sait lire à déjà complètement
> disparu,

Ou disparaît peu à peu pour les derniers... Personellement, ça fait un

bail

que j'ai pas mis un pied dans une fac, un IUT, etc., mais tout de même, je
me demande bien ce qu'on y apprend aujourd'hui ! J'installe/teste des tas

de

softs, commerciaux, shareware, freeware, etc. 'tain, ça plante de tous les
côtés ! Et des bugs comme pour Aurélien hein, Windows n'est absolument pas
en cause, c'est ces logiciels qui sont codés par des buses, point à la

ligne

!

ha ! ;-) L'informatique à son Cabrel ! C'était mieux avant ! :-)

Je te l'ai déjà dit, on ne fait plus de soft qui marche , pour la bonne et
simple raison qu'un soft qui marche c'est une boite qui fermet et des
chomeurs en plus. Alors qu'un soft qui marche pas c'est de la maintenance
sur plusieurs années, c'est de la mise à jour payante, c'est une hotline,
c'est du boulot quoi ! On le dit jamais assez, mais l'incompétance bien
employé, ca génère de la richesse ! Le sdéveloppeurs sont formé pour le
monde actuel , pas pour le tiens. Un soft qui marche ! :-) tu te rend compte
de l'ineptie ! :-)

VB

FreeLibrary qui ne rend pas la main :-(

10 réponses

Veuillez sélectionner un problème