Win32 process spawning, POpen and Hugs, revisited

[Graham Klyne]

I didn't (yet) receive Simon's original message, but I did look in the 
archive [1], where the source code attachment shows up as a "non-text" .obj 
file.  So my comment may be based on incomplete information.

Is "forkProcess" in the sense of a Unix fork?  If so, this is something 
that is difficult to do cleanly on Windows -- normally, it requires the 
full Cygwin emulating environment, which as far as I'm concerned is a 
killer for deploying applications.  Theoretically, Windows NT kernel does 
have a facility to "clone" an entire process, complete with address space 
contents, but, as far as I'm aware this functionality is not exposed by the 
Win32 API.

(This is a shame, because the Unix fork model is extraordinarily elegant, 
and simplifies a whole raft of process-creation issues, but Windows is what 
we have to live with.)

#g
--

[1] http://www.haskell.org//pipermail/libraries/2004-March/001832.html


At 07:40 17/03/04 -0500, David Roundy wrote:
>On Wed, Mar 17, 2004 at 12:01:11PM -0000, Simon Marlow wrote:
> >
> > On a related note, I recently implemented a System.Process library on
> > Unix.  Source code attached.  The Windows implementation should be
> > relatively straightforward.  Porting it to Hugs will require
> > System.Posix.forkProcess, but I don't see any great difficulties there.
>
>...
>
> > I think this is a good platform-independent abstraction for process
> > management.  What do others think?
>
>Looks pretty good to me.  I'm currently using doing all my forking in C,
>since that seems the "easiest" way to go about it, particularly since I
>need to do it on both windows and POSIX systems (which I accomplish via
>#ifdefs).  But this is all very nasty code that I'd like to get rid of (or
>more likely, nest in another layer of #ifdefs to deal with old versions of
>ghc...).
>
>The only thing I'd like to check on that I can't tell about is whether
>passing stdin and stdout to runProcess will behave "correctly".  Some
>programs (e.g. gpg) can figure out how to get control of the tty by
>themselves (to ask for passwords in the case of gpg), but others (some
>versions of vi) will fail if their stdin and stdout correspond to a tty.
>It would be nice to be able to run "user-interactive" commands such as text
>editors in a safe and consistent manner.  I'm not clear from your code
>whether there will be a problem with passing stdin and stdout to
>runProcess.  If the process closes stdin, will it be closed for me? If the
>process changes the buffering of stdin, will that change it for me?
>Enquiring minds want to know! :)
>--
>David Roundy
>http://www.abridgegame.org
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact