On Wed, 22 May 2013 23:09:54 +0200 Irek Szczesniak wrote: > On Fri, May 17, 2013 at 4:43 PM, Irek Szczesniak <[email protected]> > wrote: > > On Fri, May 17, 2013 at 3:07 PM, David Korn <[email protected]> wrote: > >> Subject: Re: Re: [uwin-users] uwin-users Digest, Vol 98, Issue 5 > >> -------- > >> > >>> my guess is the uwin fork/exec code would run afoul of wine's emulation > >>> that itself probably uses fork/exec and stands on its head trying to hide > >>> that > >> > >> I don't know why this would be a problem assuming that the WINE > >> emulation of CreateProcess() doesn't randomly lay out the address space. > >> That means that two calls to CreateProcess() with the same arguments > >> should put shared libraries at the same address. > >> > >> UWIN uses only WIN32 calls so that if WINE implements WIN32 faithfully, > >> then in theory UWIN would work on WINE. > > > > Does posix.dll implement posix_spawn()? IMO a native posix_spawn() > > implementation would avoid the trouble of a fork(), exec() sequence
> Glenn? posix.dll provides spawnveg() with similar but limited semantics to posix_spawn() libast spawnvex() uses posix_spawn() or spawnveg() if possible however fork() is required by ksh -- well ksh can run on non-fork systems but its not nearly as efficient -- dgk can provide more details on that _______________________________________________ uwin-users mailing list [email protected] http://lists.research.att.com/mailman/listinfo/uwin-users
