On Jan 21 12:50, Thomas Wolff wrote:
> Am 21.01.2018 um 11:56 schrieb Marco Atzeri:
> > On 21/01/2018 16:32, Jay K wrote:
> > >
> > > I have some desire to discuss fork.
> > > I know it is an old and difficult topic.
> > >
> > > I found this:
> > >
> > > "Cygwin fork and RtlCloneUserProcess"
> > > https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/afdf1b68-1f3e-47f5-94cf-51e397afe073/cygwin-fork-and-rtlcloneuserprocess?forum=windowsgeneraldevelopmentissues
> > >
> > > NT has had fork since v1.
> > > The Posix subsystem used it.
> >
> > If you look at the several Corinna's tentatives of having any info
> > on the Microsoft forum the problem is the lack of official documentation
> > of the details.
> >
> > Without details no solution can be implemented that is guaranteed
> > to work on all existing and hopefully future version of Windows.
> >
> > Cygwin can only use official external API and not hidden internal one.
> There was this mail from Microsoft, offering support in case Windows 10
> would raise console problems with cygwin:
> https://cygwin.com/ml/cygwin/2015-04/msg00623.html
> While this was particularly about the console, maybe this offer could be
> used for a request to provide official documentation of that system call, so
> it could then be used?
BTDT.
There already was an internal discussion between us Cygwin devs and
Microsoft devs back in 2012 to handle various aspects of a POSIX fork
implementation(*), which was fairly detailed. This was triggered by
Windows 8 previews breaking fork on Cygwin due to a change in ASLR
behaviour. We also asked for some minor provisions in the official
Win32 API(**) but the discussion petered out during the Windows 8
release with no further reply from the Microsoft side.
Corinna
(*) E.g., when using RtlCloneUserProcess everything done on the
kernel/ntdll level appears to work (reading/writing to file handles,
shared memory is available, etc), but simple higher-level stuff like
Windows console handles become non-functional.
(**) E.g., telling CreateProcess that, right now, we don't want ASLR,
regardless of the executables dynamicbase flag, or allowing the
parent to tell the created child exactly where to load DLLs.
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat