Bonjour,
 
bon, désolé si ma question est stupide au cas où, mais j'aurai voulu savoir un truc et de toute facon c'est comme ca qu'on progresse en posant des questions.  
 
J'ai fait un programme C sous dev-cpp (et visual C++) qui m'affiche comme erreur qu'il ne reconnait pas la fonction fork(). Est-ce que c'est parce que la librairie unistd.h n'est pas reconnue sous windows et ne marche que sous unix? Ou sinon comment je peux l'ajouter? Et sinon, sous windows, comment on crée des processus?  
 
Merci beaucoup pour les réponses.

tu veux pas plutôt installe une distrib GNU/Linux ?

Désolé je vois pas le rapport lol.

fork() est un appel système (un truc qui fait l'interface entre le noyau et les applications) décrit par Posix. Or windows n'est pas compatible Posix.
Tu peux utiliser Cygwin ou SFU http://www.microsoft.com/windowsse [...] fault.mspx pour assurer une compatibilité Posix. Le deux ont plutot bonne presse.
Pour le second on m'avait dit que son besoin pour Microsoft s'était fait sentir pour certains appels d'offre où une compatibilité Posix était requise. J'ignore en revanche comment il s'intégre à Windows, retour bienvenus.

ben que tu essais de faire tes devoirs de C/Unix sous windows ...

Merci Manatane.  
Taz, relis bien les questions avant de répondre stp, merci...

ben oui, je lis bien et je comprends que tu essaies de faire de la programmation Unix.

Taz est comique lol...

Ben unistd.h c'est le header qui définit un peu tout ce qui est fondamentale à Posix (ce n'est pas ANSI) et comme Unix==Posix et que Windows!=Posix ben on peut facilement en déduire que tu veux faire de la programmation Unix sur un système incompatible
http://www.opengroup.org/onlinepub [...] std.h.html

Merci de la précision Manatane, au moins ta réponse à toi a le mérite d'etre claire, pas comme certains qui se la jouent des qu'ils parlent à un débutant...

je me la joue pas. Seulement dans ton premier message tu constates toi même que ton programme posix ne fonctionne pas sous Windows. Je te dis donc d'installer un système GNU/Linux conforme POSIX.

oui mais lui il demande une solution pour windows, alors ton linux tu oublies quoi. C'est pas ce qu'il veut!

C'est bon les gars. On vient de m'avertir que le Taz est un beau specimen sur ce forum : toujours a faire le mac et a se foutre de la gueule des moins à l'aise en programmation. N'aggrave pas ton cas petit, tu sais, c'est toujours plus facile de faire le beau derrière l'écran de son ordi, mais devant les gens, quelque chose me dit que tu dois t'écraser vite fait...
 
Sinon, merci à tous pour les réponses qui m'ont aidées à mieux capter. Merci.

ben on te dis mal.

On peut reprocher à Taz d'être parfois lapidaire (j'en connais d'autres), mais il est techniquement juste et son expertise est reconnue. Il faut savoir prendre l'information comme elle vient et chercher un peu par soi-même, approfondir... On est pas là pour tout faire tomber tout cuit dans le bec. En principe, on donne des pistes, et les gens progressent d'eux-même...
 
Pour répondre à ta question initiale, il y a peut être une solution portable dans la glib.
 
http://developer.gnome.org/doc/API/glib/
 

pour la version 2.x :
 
http://developer.gnome.org/doc/API [...] esses.html
 
Les fonctions sont un peu barbares, mais c'est exactement ce qu'il faut.

Pour windows, la fonction qui permet de cree des processus est  CreateProcess(..) . Je te laisse regarder la doc, elle est un peu longue.  
Arretez svp avec le combat linux/windows. Si le gars veux faire son application sous windows, c'est son choix, allez pas lui dire de changer d'os ou de faire ça sous linux...  

 
Absolument rien à voir. Le gars voulait utiliser la fonction fork(), qui est une fonction POSIX, d'où les réponses.

Non le gars voulait créer un process sous Windows et demandait si on peut le faire avec fork().
La réponse est non, il faut utiliser createProcess.

Dis moi Taz, quand tu te trompes en achetant une cheville qui n’est pas adaptée à ton mur, tu changes de cheville ou tu rachètes un nouvel appartement ?

exactement, je change de cheville !
 
c'est pas la peine de faire du POSIX sur du pas POSIX.
CQFD

Je me permet de rajouter une petite chose :
 
Sous Unix, pour effectuer 2 taches simultanéments, on a tendence à creer 2 process via la fonction fork().
Sous windows, l'approche est différente : on va créer 2 threads dans 1 seul processus.
La différence entre les 2 est qu'il y a une cloison forte qui sépare 2 processus distincts (pas de partage de mémoire systématique, par ex) alors que 2 threads d'un meme processus partagent leur espace data (tas).
A noter qu'Unix permet de créer des threads.
 
Tout ca pour dire que je pense qu'il te faut plutot créer 2 threads (on va dire, en créer un de plus, car tu en as forcément 1 qui est créé par le main() de ton programme), plutôt que regarder du côté des processus.
La fonction est CreateThread(). Regardes dans la MSDN sur le site de Microsoft. Il y a des exemples simples pour bien comprendre.

...

http://www.microsoft.com/france/te [...] eads0.mspx

> Sous Unix, pour effectuer 2 taches simultanéments, on a tendence à creer 2 process via la fonction fork().
- ...dans les années 80 du siècle dernier, où il n y avait pas de thread...
 
> Sous windows, l'approche est différente : on va créer 2 threads dans 1 seul processus.
- ...sauf quand on a besoin de cloisonner les données...
 
Bonjour les bugs et les failles, avec de telles idées reçues.

mauvaise réponse. le choix thread/processus se pose toujours aujourd'hui selon ce qu'on veut faire.

> mauvaise réponse....
 
c est bien ce que je dis:
> - ...sauf quand on a besoin de cloisonner les données...  
 
et j insiste:
> Bonjour les bugs et les failles, avec de telles idées reçues.
idée reçue en question: process = thread

1 an et demi plus tard...
Intéressant en tout cas ce topic, pour des gens qui comme moi sont plus habitués au pinguin qu'à Windob.

C'est bon aussi de relire de vieux truc...

Sauf que les Windows basé sur un noyau NT sont POSIX

 
C'est gentil de fêter la journée du patrimoine, Pelle d'or du jour !