spectras :
suffit de les ouvrir avant.
)
TerminateThread((HANDLE *) threadId, 0);
Godzil :
hehe Create* et WaitFor(Single|Multiple)Object powaaaa
Bref, je préfère Windows pour programmer, et même si vous me prouvez que Linux est mieux, je trollerai pour le casser (et puis je suis comme ça, je trouve que le fork/exec est plus lourd que CreateProcess) Edit: et moins fiable en plus: CreateProcess retourne immédiatement une erreur si la ligne de commande est mauvaise, ou immédiatement une bonne nouvelle si ça marche. Sous nunux, si la ligne de commande est mauvaise, le père n'a aucun moyen de le savoir, puisque le fils retourne une erreur tout de suite ou une bonne nouvelle A LA FIN du programme...Sauf que CreateProcess est une fonction EXTREMEMENT lente. Le ration CreateProcess / fork est de l'ordre de 200 ou 500 un truc comme ça en terme de temps utilisé.
Mais surtout, un truc que je ne supporte pas sous Linux, c'est qu'un fils doit toujours se terminer avant le père. Bonne chance pour lancer deux ou trois démons et terminer le prog ensuite... On n'a pas ce genre de problème sous Windows...
(mais bon, uniquement quand le système n'est plus très stable).
Et comme je l'ai dit, fork+exec n'apporte au père aucune confirmation que son fils s'est bien lancé, sauf si le fils est prévu pour communiquer avec le père (bonne chance pour simplement lancer un démon)C'est marrant ça a jamais causé de problème particulier, d'autant qu'il est très simple pour le père de savoir si ça a marché ou non vu que le noyau informe le père en temps réel de ce qui arrive au fils.
Et puis, je ne suis pas sur qu'on puisse ouvrir librement un processus système de Windows avec l'accès PROCESS_DUP_HANDLE... Quand je vois qu'il FAUT être le système pour utiliser CreateProcessAsUser...En théorie non c'est pas possible. En pratique, as-tu déjà été vérifier la totalité des opérations que tu peux interdire aux autres processus de faire au tien ? As-tu la moindre idée des vulnérabilités que tu peux créer juste en oubliant d'aller interdire, par exemple, le DuplicateHandle ? De fait, il est arrivé que des développeurs de services systèmes de windows oublient d'aller interdire le DuplicateHandle. Et toi dans tes progs, est-ce que tu penses systématiquement à le faire ?
(LogonUser ne suffit pas...)Pour avoir développé ma propre GINA et travaillé avec l'authentification dans Active Directory (eh oui on a tous nos periodes sombres
) j'ai un bon aperçu du fonctionnement de la sécurité sous windows.
Je ne pense pas, car Fork copie toutes les variables. Au mieux, CreateProcess copie tous les Handles, mais il faut toujours passer leurs numéro au fils, soit par la ligne de commande soit par un tube qu'on aurait mis à la place de stdin. (stdin, stdout et stderr peuvent être récupérés sans problème par le fils avec GetStdHandle)Si tu as besoin de faire ça c'est que tu fais du multiprocessus. Pour ce type d'utilisation, fork() est bien plus appropriée puisqu'elle crée duplique le processus (mais je te confirme qu'il n'existe pas d'équivalent de fork() sous windows. Le code typique d'un serveur, par exemple, est
while() {
accepteruneconnection();
pid = fork();
if (pid == 0) { gérer la connexion(); exit(0); }
fermerlaconnexion(); }
Mais surtout, un truc que je ne supporte pas sous Linux, c'est qu'un fils doit toujours se terminer avant le père. Bonne chance pour lancer deux ou trois démons et terminer le prog ensuite...C'est complètement faux.
Et puis, un truc que j'ai du mal à comprendre, c'est POURQUOI pratiquement tous les Unix Users s'amusent à tuer les processus de la façon la plus sanglante possible? Quelqu'un de mon école (un troisième année en plus) est allé jusqu'à nous reprocher de ne pas terminer une session par kill -9 -1 (envoie SIGKILL à tous)Je ne connais personne qui fasse ça
. De plus ça n'envoie pas le signal à tous les processus mais que aux tiens, ce qui est une nuance importante.
#include <stdio.h>
#include <unistd.h>
int main (int argc , char **argv) {
int i;
switch(fork()) {
case -1:
printf("Erreur a duplication du processus\n");
exit(-1);
break;
case 0:
printf("Demarrage du fils\n");
execv(argv[0], &argv[1]);
break;
default:
printf("le rocessus pere ne fait rien");
break;
}
}
Oui, mais c'est sale et ça laisse des processus à l'état zombie... Il me semble que l'état zombie cause des leaks, non? En plus, ton prog surcharge le système jusqu'à ce qu'une erreur veuille bien se produire, là...- non ça ne laisse pas les processus à l'état de zombie. Quand le père d'un processus meure, tous ses fils sont adoptés par le processus init, qui détruit tous les zombies
spectras: donc, un serveur crée un nouveau processus par client. C'est uniquement pour la stabilité? Car on peut très bien faire un serveur avec un thread par client, et même un serveur avec un thread pour tous, c'est plus économique...C'est plus fiable (puisqu'un plantage ne tue pas le serveur), c'est plus sûr (puisqu'un client ne peut pas interagir avec d'autres clients, vu qu'ils sont dans des espaces d'adressages distincts), et c'est tout aussi efficace, l'appel fork() étant extrèmement rapide (plus rapide que CreateThread sous windows, parce que beginthread doit initialiser des choses supplémentaires dans les librairies alors que fork() n'a rien à toucher).
Pour duplicatehandle, je dois t'avouer que je ne touche jamais à la DACL de mes programmes. En plus, il n'y a de sécurité que sous les windows de type NT, et j'ai un vieux 98se sur un de mes PC, sur lequel j'ai tendance à faire tourner mes programmes... Et puis, je n'écris pas de service système windows. Si on n'a pas "pensé à interdire PROCESS_DUP_HANDLE", c'est que le programmeur a choisi quoi interdire, et non quoi autoriser. Pour moi, ça, c'est une erreur encore plus grosse, pour un service système windows..C'est sûr, bien géré c'est pas un problème. Mais ça ajoute un point d'entrée vers ton processus, ça ajoute une possibilité de se tromper.
Au fait, je comprends qu'il puisse être intéressant de piquer un handle à un processus pour accéder à ses objets, mais à quoi sert-il d'insérer un handle dans un autre processus? Il faut ensuite obliger cet autre process à l'utiliser pour que ça serve à quelque chose...Ben en fait à ce que j'avais compris en regardant comment ça marchait à l'époque où ces failles avaient été trouvées, ça utilisait le fait que les handles alloués étaient prévisibles et que le service n'interdisait pas le DuplicateHandle. De fait on pouvait alors lui coller un handle de notre choix en lieu et place de celui qu'il aurait dû accéder.
Il faut bien qu'il copie tout le segment de données, puisque modifier une donnée dans un process ne la modifie pas dans l'autre.c'était vrai à l'époque de l'amstrad et de l'IBM PC.
Et il est bien obligé de toucher aux libsQue nenni, le noyau n'est absolument pas au courant de l'existence d'un concept appelé "bibliothèque partagée" (qui est de toutes façon un concept applicatif totalement en dehors des fonctions d'un noyau) et le fork() n'est pas concerné par ces sordides affaires de linkage dynamique.
si l'une d'elles maintient un compteur pour savoir combien de process lui sont reliésSTOP! ceci supposerait que bibliothèque soit une entité extérieure consciente de la présence de processus multiples. Tout faux. Une bibliothèque est un bout de code qui est chargé et lié au programme dans son espace d'adressage et est donc totalement indépendent de tout autre programme qui se trouverait utiliser le même bout de code.
il faut qu'elle soit notifiée de la création d'un nouveau process...Ben elle est au courant quand elle est initialisée. Il n'y a pas de notion de "nouveau" processus. La bibliothèque est un élément intégrant d'UN programme dans UN processus.
Sauf si les libs dynamiques Linux n'ont jamais de code d'initialisation... ou n'ont jamais de mémoire partagée...attends... un bibliothèque ? de la mémoire partagée ? on doit pas parler de la même chose. Jusqu'à preuve du contraire l'espace d'adressage est un des composants définissant un processus, et la mémoire partagée est un élément du processus.
Celles de Windows ont DllMain() et peuvent avoir de la mem partagée...Voir ci-dessus. Le DllMain est une aberration quand il s'agit de processus (threads pourquoi pas). C'est un bout de code s'exécutant magiquement sans que le programme appelant ait rien demandé. Par ailleurs je ne vois pas plus le rapport avec "il faut qu'elle soit notifiée de la création d'un nouveau process...". Sous windows, quand ta bibliothèque est chargée, DllMain est appelé pour qu'elle s'initialise (et pareil avant de la fermer d'ailleurs). Je vois pas le rapport avec de la communication interprocessus.
Pour la copie: Si j'ai bien compris, la page mémoire n'est copiée que la première fois qu'un process tente d'écrire dedans? C'est plus économique en effet...
DllMain permet d'initialiser la librairie au démarrage, par exemple en allouant de la mémoire pour le processus courant, ou ses threads.Voilà jusque là pas de pb, même si le choix est disctuable et que de très nombreuses DLL préfèrent ne rien faire là et avoir une fonction d'iniitalisation distincte (sinon en cas d'erreur l'utilisateur se mange une vilaine boite de dialoge comme que le programme ne peut pas être exécuté c'est pas top)
Bien sur, si sous Linux, DllMain et compagnie n'existent pas, si une lib Linux n'est que du code qui ne gère pas d'initialisation ni de mémoire partagée, le problème ne se pose plus...Pour ce qui est de la mémoire partagée, c'est totalement indépendant des bibliothèques (et c'est d'ailleurs ce qui est expliqué dans ton lien : ils montrent comment faire pour mettre en oeuvre de la mémoire partagée entre un ensemble de processus non déterminé à l'avance, cet ensemble se trouvant être l'ensemble de programmes utilisant une dll).
une librairie peut garder en mémoire le nombre de processus l'utilisant, ou mémoriser tous les pid des processus auxquels elle est reliée, etcJe ne vois pas pourquoi une bibliothèque ferait ça, puisque par définition elle rend un service en fournissant un ensemble de fonctions, et faire interagir des processus différents depuis un morceau de code ne faisant pas partie du programme principal est TRES peu recommandé.
spectras
: D'ailleurs ils n'auraient aucun moyen de se distinguer l'un de l'autre si fork() ne renvoyait pas une valeur différente à chaque processus.