end of ms windows support, and how to bring it back.

[Luka <luka@MIT.EDU>]

as discussed at last week's meeting, we're desupporting walkthru
build for ms windows.  this message summarizes why that is, how
we're doing it, and how to bring it back if we want to.

the existing windows implementation was poor in that it relied on
basically a hardwired framework to pull just some small subset of
the code into a msdev build tree and stitch it together, with no
regard for the plugin framework.  that means that reasonable changes
within the plugin framework on the unix side may still likely break
the windows support.  maintaining such a setup is unreasonable.

additionally, the code built under ms tools rather than gnu tools
requires a huge number of #def hacks throughout the entire codebase
largely due to the horrible state of "posix compliance" in ms
libraries.  simply redoing the port using cygwin/gnu tools in place
of msdev stuff should eliminate the need for much of this pollution,
since it is dealt with in the libraries and headers as it should be.

finally, it should be noted that the implementation done this
way was exceedingly bulky and confusing.  i am constantly distracted
by pieces of it as i go through files, and the various large and
scattered chunks of the source tree dedicated to it are sure to slow
spin-up time for new developers.

so to summarize why we're desupporting this implementation of
walkthru for windows:
 - no one is currently interested in actively maintaining it.
 - building is nontrivial, and regression thereby intractable.
 - the whole framework design is very questionable.
 - presence of the windows support code is expected to be a
   continued drain on resources and hazard to maintainability,
   even while dormant.

now, how we're doing the desupport.  i've applied the following tag
to the walkthru module as it currently stands today:

  mswindows_desupport_2003-05-06_tag

henceforth (that tag above having been applied now), anyone is free
to remove code that is specifically present just for windows support
at will, leaving no trace.  (cvs keeps the history of ages past.
your job is just to keep the current codebase tidy!)

later, if someone wants to play with windows stuff, you can do a cvs
checkout using -r and that tag name, and you will get exactly what was
in the repository mainline today.  it will contain all the gory windows
support code just described, and may be handy if you want to either:
 - resurrect the same framework to build for windows.
 - refer to what specific windows compatibility hacks were done, to
   guide you in a fresh implementation of windows support.

note that my recommendation, if you intend to make firewalk work on
windows again, is that you go at it from scratch, building exclusively
under gnu tools (not ms dev studio tools), and probably discover that
it largely just works and you have no need for much of the old code
at all.

-pl