nan, pas de pb du côté des mutex ou autres...
je crois que j'ai trouvé le soucis.
Je suis obligé d'utiliser l'API et les types de Microsoft pour faire la prog de la carte son sans que cela me prenne 2 mois.
Le soucis, c'est que leur doc sur le sujet est assez légère.
Alors voila les 2 soucis que j'avais, ainsi que les 2 solutions:
1. Le programme fonctionne avec le debugger de Visual C++ mais pas quand je lance l'exe.
Visiblement, leur debugger a la con initialise un certain nombre de variables si cela n'a pas été fait à l'init. Or il y avait un champs dans le recoin d'une structure definie par microsoft que je n'avais pas initialisé, because je pensais qu'il ne fallait pas.
Comme le debugger le faisait à ma place, je n'avais pas le soucis en debug, et ca plantait lamentablement en lancant l'exe.
2. Une fois le pg apparement fini, il reste un process zombie que je n'arrive pas à killer.
Dans ses fonctions systeme, winNT verrouille des zones de mémoire, et ne les dévérouille que lorsqu'on le demande explicitement. Donc si le programme plante avant que cette liberation ait été demandée (genre on arrete le debugger brutalement, on on a une exception...), ces zones de mémoires ne sont pas libérés.
C'est tres con parce que si le pg a planté, on n'a justement plus la main dessus et donc on ne peut plus unlocker ces zones.
C'est de plus assez etonnant que cette liberation ne soit pas automatique en fin de processus, comme cela peut l'être pour des zones allouées dynamiquement avec un new ou un malloc et que l'on oublierais malencontreusement de désallouer.
Peut être (et même sans doute) y a-t-il une solution pour éviter cela, mais dans l'immédiat je ne vois pas...
Seule solution a mon pb: faire un programme qui ne plante pas!
