What is the closest thing Windows has to fork

Question

I guess the question says it all   I want to fork on Windows  What is the most similar operation and how do I use it

User · Answer

as soon as you want to do file access or printf then io are refused    You cannot have your cake and eat it too    in msvcrt dll  printf   is based on the Console API  which in itself uses lpc to communicate with the console subsystem  csrss exe    Connection with csrss is initiated at process start-up  which means that any process that begins its execution  in the middle  will have that step skipped   Unless you have access to the source code of the operating system  then there is no point in trying to connect to csrss manually   Instead  you should create your own subsystem  and accordingly avoid the console functions in applications that use fork    once you have implemented your own subsystem  don t forget to also duplicate all of the parent s handles for the child process -     Also  you probably shouldn t use the Zw  functions unless you re in kernel mode  you should probably use the Nt  functions instead     This is incorrect   When accessed in user mode  there is absolutely no difference between Zw    Nt     these are merely two different  ntdll dll  exported names that refer to the same  relative  virtual address    ZwGetContextThread NtCurrentThread     amp context     obtaining the context of the current  running  thread by calling ZwGetContextThread is wrong  is likely to crash  and  due to the extra system call  is also not the fastest way to accomplishing the task

User · Answer

Cygwin has fully featured fork   on Windows  Thus if using Cygwin is acceptable for you  then the problem is solved in the case performance is not an issue   Otherwise you can take a look at how Cygwin implements fork    From a quite old Cygwin s architecture doc      5 6  Process Creation    The fork call in Cygwin is particularly interesting   because it does not map well on top of   the Win32 API  This makes it very   difficult to implement correctly    Currently  the Cygwin fork is a   non-copy-on-write implementation   similar to what was present in early   flavors of UNIX       The first thing that happens when a   parent process forks a child process   is that the parent initializes a space   in the Cygwin process table for the   child  It then creates a suspended   child process using the Win32   CreateProcess call  Next  the parent   process calls setjmp to save its own   context and sets a pointer to this in   a Cygwin shared memory area  shared   among all Cygwin tasks   It then fills   in the child s  data and  bss sections   by copying from its own address space   into the suspended child s address   space  After the child s address space   is initialized  the child is run while   the parent waits on a mutex  The child   discovers it has been forked and   longjumps using the saved jump buffer    The child then sets the mutex the   parent is waiting on and blocks on   another mutex  This is the signal for   the parent to copy its stack and heap   into the child  after which it   releases the mutex the child is   waiting on and returns from the fork   call  Finally  the child wakes from   blocking on the last mutex  recreates   any memory-mapped areas passed to it   via the shared area  and returns from   fork itself       While we have some ideas as to how to   speed up our fork implementation by   reducing the number of context   switches between the parent and child   process  fork will almost certainly   always be inefficient under Win32    Fortunately  in most circumstances the   spawn family of calls provided by   Cygwin can be substituted for a   fork exec pair with only a little   effort  These calls map cleanly on top   of the Win32 API  As a result  they   are much more efficient  Changing the   compiler s driver program to call   spawn instead of fork was a trivial   change and increased compilation   speeds by twenty to thirty percent in   our tests       However  spawn and exec present their   own set of difficulties  Because there   is no way to do an actual exec under   Win32  Cygwin has to invent its own   Process IDs  PIDs   As a result  when   a process performs multiple exec   calls  there will be multiple Windows   PIDs associated with a single Cygwin   PID  In some cases  stubs of each of   these Win32 processes may linger    waiting for their exec d Cygwin   process to exit    Sounds like a lot of work  doesn t it  And yes  it is slooooow   EDIT  the doc is outdated  please see this excellent answer for an update

User · Answer

People have tried to implement fork on Windows  This is the closest thing to it I can find   Taken from  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  amp  amp   haveLoadedFunctionsForFork    return -1          create forked process        ZwCreateProcess  amp hProcess  PROCESS ALL ACCESS   amp oa          NtCurrentProcess    TRUE  0  0  0           set the Eip for the child process to our child function        ZwGetContextThread NtCurrentThread     amp 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   amp mbi  sizeof mbi  0    else     ZwQueryVirtualMemory NtCurrentProcess     PVOID context Esp          MemoryBasicInformation   amp 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  amp hThread  THREAD ALL ACCESS   amp oa  hProcess           amp cid   amp context   amp stack  TRUE           copy exception table        ZwQueryInformationThread NtCurrentThread    ThreadBasicInformation           amp tbi  sizeof tbi  0       tib    PNT TIB tbi TebBaseAddress      ZwQueryInformationThread hThread  ThreadBasicInformation           amp tbi  sizeof tbi  0       ZwWriteVirtualMemory hProcess  tbi TebBaseAddress            amp tib- gt ExceptionList  sizeof tib- gt 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  amp  amp  ZwQuerySystemInformation  amp  amp  ZwQueryVirtualMemory  amp  amp          ZwCreateThread  amp  amp  ZwGetContextThread  amp  amp  ZwResumeThread  amp  amp          ZwQueryInformationThread  amp  amp  ZwWriteVirtualMemory  amp  amp  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  amp  amp  ZwQuerySystemInformation  amp  amp  ZwQueryVirtualMemory  amp  amp          ZwCreateThread  amp  amp  ZwGetContextThread  amp  amp  ZwResumeThread  amp  amp          ZwQueryInformationThread  amp  amp  ZwWriteVirtualMemory  amp  amp  ZwClose                return TRUE            else               ZwCreateProcess   NULL          ZwQuerySystemInformation   NULL          ZwQueryVirtualMemory   NULL          ZwCreateThread   NULL          ZwGetContextThread   NULL          ZwResumeThread   NULL          ZwQueryInformationThread   NULL          ZwWriteVirtualMemory   NULL          ZwClose   NULL            return FALSE

User · Answer

fork   semantics are necessary where the child needs access to the actual memory state of the parent as of the instant fork   is called   I have a piece of software which relies on the implicit mutex of memory copying as of the instant fork   is called  which makes threads impossible to use    This is emulated on modern  nix platforms via copy-on-write update-memory-table semantics    The closest that exists on Windows as a syscall is CreateProcess   The best that can be done is for the parent to freeze all other threads during the time that it is copying memory over to the new process s memory space  then thaw them   Neither the Cygwin frok  sic  class nor the Scilab code that Eric des Courtis posted does the thread-freezing  that I can see   Also  you probably shouldn t use the Zw  functions unless you re in kernel mode  you should probably use the Nt  functions instead  There s an extra branch that checks whether you re in kernel mode and  if not  performs all of the bounds checking and parameter verification that Nt  always do  Thus  it s very slightly less efficient to call them from user mode

User · Answer

The closest you say    Let me think    This must be fork   I guess     For details see Does Interix implement fork

User · Answer

I certainly don t know the details on this because I ve never done it it  but the native NT API has a capability to fork a process  the POSIX subsystem on Windows needs this capability - I m not sure if the POSIX subsystem is even supported anymore    A search for ZwCreateProcess   should get you some more details - for example this bit of information from Maxim Shatskih      The most important parameter here is SectionHandle  If this parameter   is NULL  the kernel will fork the current process  Otherwise  this   parameter must be a handle of the SEC IMAGE section object created on   the EXE file before calling ZwCreateProcess      Though note that Corinna Vinschen indicates that Cygwin found using ZwCreateProcess   still unreliable      Iker Arizmendi wrote         gt  Because the Cygwin project relied solely on Win32 APIs its fork  gt  implementation is non-COW and inefficient in those cases where a fork  gt  is not followed by exec   It s also rather complex  See here  section  gt  5 6  for details   gt     gt  http   www redhat com support wpapers cygnus cygnus cygwin architecture html       This document is rather old  10 years or so   While we re still using   Win32 calls to emulate fork  the method has changed noticably    Especially  we don t create the child process in the suspended state   anymore  unless specific datastructes need a special handling in the   parent before they get copied to the child   In the current 1 5 25   release the only case for a suspended child are open sockets in the   parent   The upcoming 1 7 0 release will not suspend at all       One reason not to use ZwCreateProcess was that up to the 1 5 25   release we re still supporting Windows 9x users   However  two   attempts to use ZwCreateProcess on NT-based systems failed for one   reason or another       It would be really nice if this stuff would be better or at all   documented  especially a couple of datastructures and how to connect a   process to a subsystem   While fork is not a Win32 concept  I don t   see that it would be a bad thing to make fork easier to implement

User · Answer

There is no easy way to emulate fork   on Windows   I suggest you to use threads instead

User · Answer

Your best options are CreateProcess   or CreateThread    There is more information on porting here

User · Answer

Prior to Microsoft introducing their new  Linux subsystem for Windows  option  CreateProcess   was the closest thing Windows has to fork    but Windows requires you to specify an executable to run in that process   The UNIX process creation is quite different to Windows  Its fork   call basically duplicates the current process almost in total  each in their own address space  and continues running them separately  While the processes themselves are different  they are still running the same program  See here for a good overview of the fork exec model   Going back the other way  the equivalent of the Windows CreateProcess   is the fork   exec   pair of functions in UNIX   If you were porting software to Windows and you don t mind a translation layer  Cygwin provided the capability that you want but it was rather kludgey   Of course  with the new Linux subsystem  the closest thing Windows has to fork   is actually fork    -

User · Answer

Well  windows doesn t really have anything quite like it  Especially since fork can be used to conceptually create a thread or a process in  nix   So  I d have to say   CreateProcess   CreateProcessEx    and  CreateThread    I ve heard that for C applications   beginthreadex   is better

User · Answer

If you only care about creating a subprocess and waiting for it  perhaps  spawn  API s in process h are sufficient  Here s more information about that   https   docs microsoft com en-us cpp c-runtime-library process-and-environment-control https   en wikipedia org wiki Process h

User · Answer

The following document provides some information on porting code from UNIX to Win32  https   msdn microsoft com en-us library y23kc048 aspx  Among other things  it indicates that the process model is quite different between the two systems and recommends consideration of CreateProcess and CreateThread where fork  -like behavior is required

User · Answer

As other answers have mentioned  NT  the kernel underlying modern versions of Windows  has an equivalent of Unix fork    That s not the problem  The problem is that cloning a process s entire state is not generally a sane thing to do  This is as true in the Unix world as it is in Windows  but in the Unix world  fork   is used all the time  and libraries are designed to deal with it  Windows libraries aren t  For example  the system DLLs kernel32 dll and user32 dll maintain a private connection to the Win32 server process csrss exe  After a fork  there are two processes on the client end of that connection  which is going to cause problems  The child process should inform csrss exe of its existence and make a new connection     but there s no interface to do that  because these libraries weren t designed with fork   in mind  So you have two choices  One is to forbid the use of kernel32 and user32 and other libraries that aren t designed to be forked     including any libraries that link directly or indirectly to kernel32 or user32  which is virtually all of them  This means that you can t interact with the Windows desktop at all  and are stuck in your own separate Unixy world  This is the approach taken by the various Unix subsystems for NT  The other option is to resort to some sort of horrible hack to try to get unaware libraries to work with fork    That s what Cygwin does  It creates a new process  lets it initialize  including registering itself with csrss exe   then copies most of the dynamic state over from the old process and hopes for the best  It amazes me that this ever works  It certainly doesn t work reliably     even if it doesn t randomly fail due to an address space conflict  any library you re using may be silently left in a broken state  The claim of the current accepted answer that Cygwin has a  quot fully-featured fork   quot  is    dubious  Summary  In an Interix-like environment  you can fork by calling fork    Otherwise  please try to wean yourself from the desire to do it  Even if you re targeting Cygwin  don t use fork   unless you absolutely have to

[c++] What is the closest thing Windows has to fork()?

Examples related to c++

Examples related to c

Examples related to windows

Examples related to fork