Bon, j'ai un programme en C, sans trucs hors norme.
Je compile avec gcc et les options -Wall -pedantic, aucun warning, aucune erreur.
 
Sous linux, le programme marche.
Sous windows, en double cliquant sur le programme, il marche.
Sous windows, en lancant le programme via command.com, il plante avec un 'le programme Toto a provoqué une erreur dans le module TOTO.EXE blablabla'.
 
Y'a une explication rationnelle ?

Kel windows un a noyau NT ou un noyau dos?precise stp

J'ai le même symptôme avec des programmes écrits en C et aussi avec ceux en Perl
 
Sur une machine NT 2000, il arrive que ça plante si je lance le programme en mode commande Ms-Dos.
 
Ca n'arrive pas systématiquement mais ça arrive. Par contre, sur le même OS à la maison, jamais je n'ai le moindre problème avec un prog Perl, les progs C compilés, pratiquement tout le temps.

aucun nt, je teste avec millenium.

C'est intéressant comme probleme ca! Il fait quoi ton programme?

Rien d'extraordinaire, il initialise pas mal de structures, et ca plante relativement vite. Seul truc notable, je fais plein de malloc et pas de free (vu que je vais virer les mallocs dans pas longtemps) mais ca m'étonnerais que ca joue, vu que si j'avais mis des free ca aurait planté avant.
 
Edit: ca aide probablement pas, mais je vois pas comment détailler sans filer tout le source, vu que tout s'imbrique.

Non ca doit pas venir des mallocs, sauf peut etre si tu ne vérifies pas si ils ont tous réussi

bon, en fait ca plante la dedans :

 
self n'est pas null, mais quand j'accède a l'attribut size, ca plante (fin pas a chaque fois que je passe dans cette methode, mais a chaque fois que j'y passe avec les mêmes parametres). Faut que je verifie si j'ai pas un cast malheureux, mais ca m'étonnerais, vu que ca marche sous linux, et sous win en passant par devc++ et en doublecliquant sur le fichier.

bon, ben j'ai trouvé la cause, même si j'ai pas compris pourquoi ca marchait du coup.
 
En fait le premier parametre de la méthode précédente était initialisé en cas de besoin :
 

 
le probleme, c'est que je mettais bien self->attributes a 0 dans le constructeur d'object, mais pas dans celui de string, ce qui fait que j'utilisait un truc non initialisé.
 
reste a comprendre pourquoi il était a 0 sous linux et en le lancant via l'explorer.

D'un autre côté c'est peut être la faute de Windows Meuh.
 
Ceci n'est pas un troll.

A la base y'a quand même une erreur que je me suis empressé de corriger. Maintenant ca explique pas pourquoi windows met la mémoire allouée a 0 quand on lance un programme a partir de la gui et la laisse dans un état non prévisible quand lance le même programme a partir de la ligne de commande.

 
Si le programme comporte une erreur, je préfere que l'OS ne me la corrige pas! Comment la repérer sinon?

 
certes, mais comment expliquer que le comportement est différent selon la manière de lancer le programme ?

Il faudrait se pencher du coté des parametres qu'on donne a CreateProcess. C'est a ce niveau la que ca doit différer

euh j'ai pas acces au sources de windows, moi... j'aurais du mal a voir ce qu'il appelle.

lol moi non plus!
Mais peut etre ca serait plus évident que l'on pense une fois qu'on aurait les parametres possibles sous les yeux!

Remarque, il suffit de désassembler command.com non?
 
edit : si je trouve une invocation a CreateProcess dans command.com je suis vraiment tres fort!!!

"The CreateProcess function creates a new process and its primary thread. The new process runs the specified executable file in the security context of the calling process"
 
Apparament command.com a moins de droits que explorer.
 
edit : mais je commence a me poser des questions moi, comment windows intercepte-il le lancement d'un programme a partir du command.com?

Heu... juste pour situer le contexte, je suis déja content que mon truc compile sous win, a la base c'était même pas prévu.  
 
Alors perdre mon temps a décompiler un interpréteur de commandes dos, on va oublier...

 
ben la mon probleme je pense pas que ce soit lié aux droits, mais plus que dans un cas malloc initialise la mémoire a 0, alors que dans l'autre cas non.

 
MDR j'aurais peut etre du lire le topic en entier, honte sur moi!
Ouais bon ben c'est pas la peine de chercher plus loin!

Ace17 a écrit a écrit :   MDR j'aurais peut etre du lire le topic en entier, honte sur moi! Ouais bon ben c'est pas la peine de chercher plus loin!

 
Ben si, la question est différente, mais n'a pas de réponse. C'est une erreur de supposer que malloc place la mémoire allouée a 0, mais ca n'explique pas pourquoi il le fait dans un cas et pas dans l'autre.
 
Ceci dit, la recherche de la solution est plus un defi inutile qu'autre chose, vu que le code mettant en avant cette différence est erroné.

Moi je pense que c'est tout betement que suivant les cas le programme n'est pas chargé au meme endroit; Coup de bol, dans un cas il est chargé dans un endroit qui contient des zeros, mais dans l'autre, il y a n'importe quoi.

Non-sens detecté !

MDR