REF: WIN32 port of mud++ v0.15
SUBJECT: proposed process model for port

Foundation:
The UN*X versions of mud++ v0.15 use the following model:
 
    --------------             ---------------------------
    | Session 1  |             |     Session 2           |
    | ---------- |             | ----------   ---------- |
    | | Proc a |-|------------>| | Proc n |-->| Proc p | |
    | ---------- |             | ----------   ---------- |
    --------------             ---------------------------
(if this is wrong, please feel free to correct me.)
1) Under Session 1 the administrator issues the "mud++" command and 
Proc a is started.

2) The mud then fork()s, creating Proc n, which
is temporarily located in Session 1.  Proc a exit()s and Proc n
setsid()s which creates Session 2 separate from Session 1.

3) Whenever a reboot() is needed, Proc n writes a file with all the
pertinent socket information in it, fork()s Proc p and exec()s the
"mud++" again.  Then Proc n exit()s.

4) Proc p starts again at step (2) with the same purpose as a Proc a.

(I am supposing that when Proc p exit()s that Session 2 dies.)



I think that under WIN32 I will have to approach this differently.
Certainly I could do the equivalent of a fork()+exec() combination,
but the new process would NOT inherit open file pointers, stack, etc...

Under WIN32 threads are well defined and supported.  Probably one process
with two threads is called for here.  The main(starting) thread would be
the opening thread.  Then there would be the daemon (or game loop) thread.
A reboot() would save the tab file just as the UN*X version, but then it
would only exit() the thread. (Threads must begin with a call to a 
function under WIN32 which would affect the way the main loop code)

Follows is pseudocode for this implementation:
-----------------------------------------------------------
main()
{
  ....(setup code, call winsock initialization etc...)
  while (!DONE)
    newThread(*daemonThread);
  ... (shutdown code, close winsock etc...)
}

....

daemonThread()
{
  while(!REBOOT && !DONE )
  {
  ... (main game loop including checking for tab file, etc )...
  ... (load files, reconnect sockets) ...
  }
  if (!DONE)
    writeTabFile(); // let the next daemon thread know the status
}

----------------------------------------------------------------------


This method would not be to hard to emulate in the UN*X versions:

---------------------------------------------------------
UN*Xmain()
{
    ....(setup code, call socket initialization etc...)
  fork()
  if (parent)
    exit();
  setsid();
  UN*Xdaemon();
  if (DONE)
  {
  ... (shutdown code, close sockets etc...)
  }
  exit();
}

UN*Xdaemon()
{
  while(!REBOOT && !DONE )
  {
  ... (main game loop including checking for tab file, etc )...
  ... (load files, reconnect sockets) ...
  }
  if (!DONE)
  {
    writeTabFile(); // let the next daemon know the status
    fork();
    exec(mud++);
  }
}
-------------------------------------------------------------------