From: Reid Thompson <reid.thompson@...>
Date: 2009-06-10T23:54:54+09:00
Subject: Re: inheriting socket in child process on Windows

On Wed, 2009-06-10 at 23:50 +0900, knutaf@gmail.com wrote:
> On Jun 10, 7:41 am, Robert Klemme <shortcut...@googlemail.com> wrote:
> > 2009/6/10  <knu...@gmail.com>:
> >
> > > True, I did realize after I posted that perhaps my way isn't the "most
> > > obvious." In any case, I'd very much like to avoid requiring cygwin
> > > for this to work. Plus, with cygwin, I would guess my original Linux
> > > approach would probably work without modification.
> >
> > I don't understand the "plus".  Why is that an additional reason to
> > not want to work with cygwin?
> 
> You caught me. That was bad wording on my part. s/Plus//.
> 
> > > Finally, after testing it out briefly, I don't think fork will work in
> > > my situation. I didn't give enough context originally,
> >
> > Aha!
> >
> > > but I'm
> > > spawning the new child process in order for it to be the same process
> > > as the parent, but having picked up any code changes that have been
> > > made. A "live reboot", if you will. Fork doesn't seem to re-interpret
> > > the source.
> >
> > fork() just copies the process - with all open file descriptors etc.
> > My understanding of Windows internals is limited but I do believe that
> > there is no direct equivalent function. It may be that the pattern
> > does not work on "plain" Windows.
> >
> > Kind regards
> >
> > robert
> >
> > --
> > remember.guy do |as, often| as.you_can - without endhttp://blog.rubybestpractices.com/
> 
> You're right. In fact, calling fork() on plain Windows throws a "not
> supported by this platform" exception.
> 

see CreateProcess(...)  for the closest win equivalent

http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx