Quelle est la chose la plus proche de windows contient fork()?

Je suppose que la question dit tout.

Je veux fourche sur windows. Ce qui est le plus semblable opération et comment l'utiliser.

InformationsquelleAutor rlbond | 2009-06-12
  1. 78

    Cygwin a complet fork() sur Windows. Ainsi, si l'utilisation de Cygwin qui est acceptable pour vous, alors le problème est résolu dans le cas de la performance n'est pas un problème.

    Sinon, vous pouvez prendre un coup d'oeil à la façon dont Cygwin implémente fork(). À partir d'un très vieux Cygwin l'architecture doc:

    5.6. Processus De Création
    La fourche d'appel dans Cygwin est particulièrement intéressant
    parce qu'il n'a pas la carte bien sur le dessus de
    l'API Win32. Cela le rend très
    difficile à mettre en œuvre correctement.
    Actuellement, la Cygwin fourche est un
    non-copy-on-write mise en œuvre
    similaire à ce qui était présent au début de l'
    saveurs de UNIX.

    La première chose qui arrive quand une
    processus parent fourches d'un processus enfant
    c'est que le parent initialise un espace
    dans le Cygwin table de processus pour l'
    enfant. Il crée ensuite une suspension
    processus enfant à l'aide de la Win32
    CreateProcess appel. Ensuite, le parent
    traiter les appels setjmp pour enregistrer ses propres
    contexte et définit un pointeur vers cette
    un Cygwin zone de mémoire partagée (shared
    parmi tous Cygwin tâches). Il remplit ensuite
    dans l'enfant .les données et les .sev sections
    en copiant à partir de son propre espace d'adressage
    dans la suspension adresse de l'enfant
    de l'espace. Après l'adresse de l'enfant de l'espace
    est initialisé, l'enfant est exécutée alors que
    le parent attend sur un mutex. L'enfant
    découvre qu'elle a été fourchue et
    longjumps en utilisant le même saut de la mémoire tampon.
    Ensuite, l'enfant définit le mutex l'
    le parent est en attente et bloque sur
    un autre mutex. C'est le signal pour
    le parent pour copier sa pile et le tas
    dans l'enfant, après quoi il
    libère le mutex l'enfant est
    d'attente et renvoie de la fourche
    appel. Enfin, l'enfant se réveille à partir de
    le blocage sur le dernier mutex, recrée
    à la mémoire correspond à des zones passé
    via la zone partagée, et les revenus de l'
    fourche elle-même.

    Alors que nous avons quelques idées sur la façon de
    la vitesse de notre fourchette de mise en œuvre par
    la réduction du nombre de contexte
    bascule entre le parent et l'enfant
    processus, la fourche sera presque certainement
    toujours être inefficace sous Win32.
    Heureusement, dans la plupart des circonstances de la
    frayer la famille d'appels fournies par
    Cygwin peut être remplacée par une
    fork/exec paire avec seulement un peu de
    des efforts. Ces appels à la carte proprement sur le dessus
    de l'API Win32. En conséquence, ils
    sont beaucoup plus efficaces. La modification de la
    compilateur pilote du programme à appeler
    spawn au lieu de fourche a été une mince
    changement et l'augmentation de la compilation
    la vitesse de vingt à trente pour cent dans
    nos tests.

    Cependant, la réapparition et exec présenter leurs
    un certain nombre de difficultés. Parce qu'il n'y
    n'est pas une façon de faire une réelle exec sous
    Win32, Cygwin doit inventer ses propres
    Id De Processus (Pid). Par conséquent, lorsque
    un processus effectue plusieurs exec
    les appels, il y aura plusieurs Fenêtres
    Le pid associé à une seule Cygwin
    PID. Dans certains cas, les mégots de chacun de
    ces processus Win32 peut subsister,
    en attendant leur exec avais Cygwin
    processus de sortie.

    Ressemble à beaucoup de travail, n'est-ce pas? Et oui, c'est slooooow.

    EDIT: la doc est obsolète, veuillez voir cette excellente réponse pour une mise à jour

    • C'est une bonne réponse si vous voulez écrire un Cygwin application sur windows. Mais en général ce n'est pas la meilleure chose à faire. Fondamentalement, les *nix et Windows de processus et de threads modèles sont très différentes. La fonction CreateProcess() et CreateThread() sont généralement équivalent Api
    • Les développeurs doivent garder à l'esprit que ce n'est pas pris en charge mécanisme, et autant que je me souvienne c'est en effet enclin à casser à chaque fois que certains autres processus sur le système à l'aide de l'injection de code.
    • La mise en œuvre différente lien n'est plus valide.
    • Édité à laisser les autres répondre à des liens qu'
    • En fait, vous avez ne devriez pas le faire, même si vous essayez d'écrire un "cygwin app". Il tente d'imiter Unix est fork pourtant, il l'accomplit avec une qui fuit la solution et vous devez être prêt à des situations inattendues.
    InformationsquelleAutor Laurynas Biveinis
  2. 57

    Certes, je ne connais pas les détails, sur ce point, car je ne l'ai jamais fait, mais le natif NT API a une capacité à fourche d'un processus (le sous-système POSIX sur Windows besoin de cette capacité - je ne suis pas sûr si le sous-système POSIX est encore supportée).

    Une recherche pour ZwCreateProcess() devrait vous obtenir un peu plus de détails - par exemple ce bit d'information de Maxim Shatskih:

    Le paramètre le plus important ici est SectionHandle. Si ce paramètre
    est NULL, le noyau de la fourche le processus actuel. Sinon, cette
    paramètre doit être une poignée d'indicateurs sec_image section de l'objet créé sur
    le fichier EXE avant d'appeler ZwCreateProcess().

    Mais notez qu' Corinna Vinschen indique que Cygwin trouvé à l'aide de ZwCreateProcess() encore peu fiables:

    Iker Arizmendi a écrit:

    > Because the Cygwin project relied solely on Win32 APIs its fork
> implementation is non-COW and inefficient in those cases where a fork
> is not followed by exec.  It's also rather complex. See here (section
> 5.6) for details:
>  
> http://www.redhat.com/support/wpapers/cygnus/cygnus_cygwin/architecture.html

    Ce document est assez vieille, 10 ans ou plus. Alors que nous sommes toujours à l'aide de
    Win32 appels pour émuler la fourche, la méthode a changé sensiblement.
    En particulier, nous ne créons pas le processus de l'enfant dans l'état suspendu
    de plus, à moins que certaines datastructes besoin d'un traitement spécial dans le
    parent avant d'avoir copié à l'enfant. Dans le courant 1.5.25
    relâchez le seul cas d'un sursis à l'enfant sont les sockets dans le
    parent. La prochaine version 1.7.0 ne suspendra pas du tout.

    Une raison de ne pas utiliser ZwCreateProcess était que, jusqu'à la 1.5.25
    libération nous sommes toujours à la prise en charge de Windows 9x utilisateurs. Cependant, deux
    les tentatives d'utilisation de ZwCreateProcess sur les systèmes basés sur NT a échoué pour une
    raison ou une autre.

    Ce serait vraiment gentil si ce genre de choses serait mieux ou pas du tout
    documenté, en particulier un couple de structures de données et comment connecter un
    processus à un sous-système. Tandis que la fourche n'est pas un Win32 concept, je n'ai pas
    voir que ce serait une mauvaise chose pour faire de fourche plus facile à mettre en œuvre.

    • C'est la mauvaise réponse. La fonction CreateProcess() et CreateThread() sont les équivalents.
    • Interix est disponible dans Windows Vista Entreprise/intégrale en tant que "sous-système pour les Applications UNIX": en.wikipedia.org/wiki/Interix
    • cela peut être une mauvaise réponse, mais la fonction CreateProcess()/CreateThread() pourrait bien être mauvais, trop. Cela dépend si l'on est à la recherche de la Win32 façon de faire les choses " ou "en tant que proche de fork() de la sémantique que possible". La fonction CreateProcess() se comporte de manière très différente que fork(), qui est la raison cygwin besoin de faire beaucoup de travail pour le soutenir.
    • Le lien est mort à la de 2013, est-il un miroir ou de l'archive quelque part?
    • J'ai essayé de corriger les liens et copier le texte dans la réponse (donc l'avenir de liens cassés ne sont pas un problème). Cependant, cette réponse est de il y a assez longtemps que je ne suis pas certain à 100% de la citation que j'ai trouvé aujourd'hui est ce que je faisais référence en 2009.
    • Bavure: Merci! Toujours bon pour des fins d'archivage.
    • Si les gens veulent "fork immédiate exec", alors peut-être CreateProcess est un candidat. Mais fork sans exec est souvent souhaitable et c'est ce que les pilotes de demander un réel fork.

    InformationsquelleAutor Michael Burr
  3. 35

    Bien, windows n'a pas vraiment quelque chose de semblable. Surtout depuis que la fourche peut être utilisé pour conceptuellement créer un thread ou un processus sous *nix.

    Donc, je dirais:

    CreateProcess()/CreateProcessEx()

    et

    CreateThread() (J'ai entendu dire que pour des applications C, _beginthreadex() est mieux).

    InformationsquelleAutor Evan Teran
  4. 15

    Les gens ont essayé de mettre en œuvre la fourche sur Windows. C'est la chose la plus proche d'elle que je peut trouver:

    Prises à partir de: http://doxygen.scilab.org/5.3/d0/d8f/forkWindows_8c_source.html#l00216

    static BOOL haveLoadedFunctionsForFork(void);
int fork(void) 
{
HANDLE hProcess = 0, hThread = 0;
OBJECT_ATTRIBUTES oa = { sizeof(oa) };
MEMORY_BASIC_INFORMATION mbi;
CLIENT_ID cid;
USER_STACK stack;
PNT_TIB tib;
THREAD_BASIC_INFORMATION tbi;
CONTEXT context = {
CONTEXT_FULL | 
CONTEXT_DEBUG_REGISTERS | 
CONTEXT_FLOATING_POINT
};
if (setjmp(jenv) != 0) return 0; /* return as a child */
/* check whether the entry points are 
initilized and get them if necessary */
if (!ZwCreateProcess && !haveLoadedFunctionsForFork()) return -1;
/* create forked process */
ZwCreateProcess(&hProcess, PROCESS_ALL_ACCESS, &oa,
NtCurrentProcess(), TRUE, 0, 0, 0);
/* set the Eip for the child process to our child function */
ZwGetContextThread(NtCurrentThread(), &context);
/* In x64 the Eip and Esp are not present, 
their x64 counterparts are Rip and Rsp respectively. */
#if _WIN64
context.Rip = (ULONG)child_entry;
#else
context.Eip = (ULONG)child_entry;
#endif
#if _WIN64
ZwQueryVirtualMemory(NtCurrentProcess(), (PVOID)context.Rsp,
MemoryBasicInformation, &mbi, sizeof mbi, 0);
#else
ZwQueryVirtualMemory(NtCurrentProcess(), (PVOID)context.Esp,
MemoryBasicInformation, &mbi, sizeof mbi, 0);
#endif
stack.FixedStackBase = 0;
stack.FixedStackLimit = 0;
stack.ExpandableStackBase = (PCHAR)mbi.BaseAddress + mbi.RegionSize;
stack.ExpandableStackLimit = mbi.BaseAddress;
stack.ExpandableStackBottom = mbi.AllocationBase;
/* create thread using the modified context and stack */
ZwCreateThread(&hThread, THREAD_ALL_ACCESS, &oa, hProcess,
&cid, &context, &stack, TRUE);
/* copy exception table */
ZwQueryInformationThread(NtCurrentThread(), ThreadBasicInformation,
&tbi, sizeof tbi, 0);
tib = (PNT_TIB)tbi.TebBaseAddress;
ZwQueryInformationThread(hThread, ThreadBasicInformation,
&tbi, sizeof tbi, 0);
ZwWriteVirtualMemory(hProcess, tbi.TebBaseAddress, 
&tib->ExceptionList, sizeof tib->ExceptionList, 0);
/* start (resume really) the child */
ZwResumeThread(hThread, 0);
/* clean up */
ZwClose(hThread);
ZwClose(hProcess);
/* exit with child's pid */
return (int)cid.UniqueProcess;
}
static BOOL haveLoadedFunctionsForFork(void)
{
HANDLE ntdll = GetModuleHandle("ntdll");
if (ntdll == NULL) return FALSE;
if (ZwCreateProcess && ZwQuerySystemInformation && ZwQueryVirtualMemory &&
ZwCreateThread && ZwGetContextThread && ZwResumeThread &&
ZwQueryInformationThread && ZwWriteVirtualMemory && ZwClose)
{
return TRUE;
}
ZwCreateProcess = (ZwCreateProcess_t) GetProcAddress(ntdll,
"ZwCreateProcess");
ZwQuerySystemInformation = (ZwQuerySystemInformation_t)
GetProcAddress(ntdll, "ZwQuerySystemInformation");
ZwQueryVirtualMemory = (ZwQueryVirtualMemory_t)
GetProcAddress(ntdll, "ZwQueryVirtualMemory");
ZwCreateThread = (ZwCreateThread_t)
GetProcAddress(ntdll, "ZwCreateThread");
ZwGetContextThread = (ZwGetContextThread_t)
GetProcAddress(ntdll, "ZwGetContextThread");
ZwResumeThread = (ZwResumeThread_t)
GetProcAddress(ntdll, "ZwResumeThread");
ZwQueryInformationThread = (ZwQueryInformationThread_t)
GetProcAddress(ntdll, "ZwQueryInformationThread");
ZwWriteVirtualMemory = (ZwWriteVirtualMemory_t)
GetProcAddress(ntdll, "ZwWriteVirtualMemory");
ZwClose = (ZwClose_t) GetProcAddress(ntdll, "ZwClose");
if (ZwCreateProcess && ZwQuerySystemInformation && ZwQueryVirtualMemory &&
ZwCreateThread && ZwGetContextThread && ZwResumeThread &&
ZwQueryInformationThread && ZwWriteVirtualMemory && ZwClose)
{
return TRUE;
}
else
{
ZwCreateProcess = NULL;
ZwQuerySystemInformation = NULL;
ZwQueryVirtualMemory = NULL;
ZwCreateThread = NULL;
ZwGetContextThread = NULL;
ZwResumeThread = NULL;
ZwQueryInformationThread = NULL;
ZwWriteVirtualMemory = NULL;
ZwClose = NULL;
}
return FALSE;
}
    • Notez que la plupart de la vérification des erreurs manque, par exemple, ZwCreateThread retourne un NTSTATUS valeur qui peut être vérifiée à l'aide de l'RÉUSSI et ÉCHOUÉ macros.
    • Ce qui se passe si les fork plante, ça plante le programme, ou le fil juste crash? Si il bloque le programme, puis ce n'est pas vraiment un fork. Juste par curiosité, parce que je suis à la recherche d'une vraie solution, et espérons que cela pourrait être une bonne alternative.
    • Je tiens à noter, il y a un bug dans le code fourni. haveLoadedFunctionsForFork est une fonction globale dans la tête, mais une fonction statique dans le fichier c. Ils doivent être global. Et actuellement, la fourche se bloque, l'ajout de la vérification des erreurs maintenant.
    • Le site est mort et je ne sais pas comment je peux compiler l'exemple de mon propre système. Je suppose que je suis absent de certains en-têtes ou y compris les mauvaises suis-je? (l'exemple n'est pas de leur montrer.)
    InformationsquelleAutor Eric des Courtis
  5. 6

    Avant Microsoft a présenté sa nouvelle "sous-système Linux pour Windows" option, CreateProcess() était la chose la plus proche de Windows contient fork(), mais Windows vous demande de spécifier un fichier exécutable à exécuter dans ce processus.

    La création des processus UNIX est très différent de Windows. Son fork() appel essentiellement duplique le processus actuel de près de au total, chacun dans leur propre espace d'adressage, et continue de courir séparément. Alors que les processus eux-mêmes sont différents, ils ont toujours la même programme. Voir ici pour avoir un bon aperçu de la fork/exec modèle.

    Aller de l'autre côté, l'équivalent de la Windows CreateProcess() est le fork()/exec() paire de fonctions UNIX.

    Si vous étiez le portage de logiciels pour Windows et vous n'avez pas l'esprit d'une couche de traduction, Cygwin fourni la capacité que vous voulez, mais il était plutôt kludgey.

    Bien sûr, avec la nouvelle Sous-système Linux, la chose la plus proche de Windows contient fork() est fait fork() 🙂

    • Donc, compte tenu de WSL, puis-je utiliser fork en moyenne, les non-WSL application?
    InformationsquelleAutor paxdiablo
  6. 6

    Le document suivant fournit de l'information sur le portage de code à partir d'UNIX pour Win32:
    https://msdn.microsoft.com/en-us/library/y23kc048.aspx

    Entre autres choses, il indique que le modèle de processus est assez différente entre les deux systèmes et recommande l'examen de la fonction CreateProcess et CreateThread où fork()-comme le comportement est nécessaire.

    InformationsquelleAutor Brandon E Taylor
  7. 3

    fork() sémantique est nécessaire que lorsque l'enfant a besoin d'accéder à la mémoire réelle de l'état de la mère comme de l'instant fork() est appelée. J'ai un morceau de logiciel qui repose sur l'implicite mutex de la mémoire de la copie de l'instant fork() est appelée, ce qui rend les threads impossible à utiliser. (C'est émulé sur moderne *nix, via des plates-formes de copie sur écriture/mise à jour d'une mémoire de la table de la sémantique.)

    Le plus proche de ce qui existe sur Windows comme un syscall est la fonction CreateProcess. Le mieux qu'on puisse faire est pour le parent de geler tous les autres threads pendant le temps qu'il est la copie de la mémoire sur le nouveau processus de l'espace de mémoire, puis de les décongeler. Ni le Cygwin frok [sic] de la classe, ni le code Scilab qu'Eric des Courtis posté le fil de gel, que je peux voir.

    Aussi, vous ne devriez pas utiliser le Zw* fonctions, sauf si vous êtes en mode noyau, vous devriez probablement utiliser le Nt* fonctions à la place. Il ya un supplément de branche qui vérifie si vous êtes en mode noyau et, si non, effectue toutes les vérifications de limites et les paramètres de vérification que le Nt* toujours faire. Ainsi, il est très légèrement moins efficace à les appeler depuis le mode utilisateur.

    • Des informations très intéressantes concernant Zw* les symboles exportés, je vous remercie.
    • Notez que le Zw* fonctions à partir de l'espace utilisateur encore la carte de Nt* fonctions dans l'espace noyau, pour la sécurité. Ou au moins qu'ils le devraient.
    InformationsquelleAutor sjcaged
  8. 3

    "dès que vous voulez faire de l'accès aux fichiers ou printf puis io sont refusé"

    • Vous ne pouvez pas avoir votre gâteau et le manger aussi... dans msvcrt.dll, printf() est basé sur la Console API, qui lui-même utilise lpc pour communiquer avec la console de sous-système (csrss.exe). Connexion avec csrss est initiée au processus de démarrage, ce qui signifie que tous les processus qui commence son exécution "dans le milieu" qui sera mis à l'étape sauté. Sauf si vous avez accès au code source du système d'exploitation, alors il est inutile d'essayer de se connecter à csrss manuellement. Au lieu de cela, vous devez créer votre propre sous-système, et par conséquent d'éviter les fonctions de la console dans les applications qui utilisent fork().

    • une fois que vous avez mis en place votre propre sous-système, n'oubliez pas de dupliquer tous les parents de poignées pour le processus de l'enfant;-)

    "Aussi, vous ne devriez pas utiliser le Zw* fonctions, sauf si vous êtes en mode noyau, vous devriez probablement utiliser le Nt* fonctions à la place."

    • C'est incorrect. Lors de l'accès en mode utilisateur, il n'y a absolument aucune différence entre Zw*** Nt***; ce ne sont que deux (ntdll.dll) exporté des noms qui font référence à la même (relative) d'adressage virtuel.

    ZwGetContextThread(NtCurrentThread(), &le contexte);

    • obtenir le contexte de l'actuelle (en cours) thread en appelant ZwGetContextThread est mauvais, est susceptible de se bloquer, et (dû à l'apport de l'appel système) n'est pas le moyen le plus rapide pour accomplir la tâche.
    • Cela ne semble pas répondre à la question principale, mais de répondre à quelques autres réponses différentes, et serait probablement mieux répondre directement à chaque pour plus de clarté et pour le rendre plus facile à suivre ce qui se passe.
    • vous semblez être en qui printf toujours écrit sur la console.
    InformationsquelleAutor user3502619
  9. 2

    Vos meilleures options sont La fonction CreateProcess() ou CreateThread(). Il n'y a plus d'informations sur le portage de ici.

    InformationsquelleAutor John T
  10. 2

    Il n'est pas facile à imiter fork() sur Windows.

    Je vous suggère d'utiliser des threads au lieu.

    • Eh bien, dans l'équité, de la mise en œuvre de fork était exactement ce que CygWin n'. Mais, si jamais vous lisez sur comment ils l'ont fait, yor "pas facile" est une brute misunderstatement 🙂
    InformationsquelleAutor VVS
  11. 2

    Le plus proche de vous dire... Laissez-moi réfléchir... Cela doit être fork (), je suppose 🙂

    Pour les détails, voir Ne Interix mettre en œuvre fork()?

    InformationsquelleAutor Piotr Dobrogost
  12. 1

    Si vous ne se soucient que de la création d'un sous-processus et l'attente, peut-être _spawn* API dans le processus.h sont suffisantes. Voici plus d'informations à ce sujet:

    https://docs.microsoft.com/en-us/cpp/c-runtime-library/process-and-environment-control
    https://en.wikipedia.org/wiki/Process.h

    InformationsquelleAutor solstice333