This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |