(from CSR: mostly code-quality issues)

1. Filesystem interface.  There are more kinds of pathname in
   Windowsland than in Unix: most obviously, there's the issue of
   backslashes as directory separators, but also, what should be done
   with the drive letter (device, probably)?  UNC paths?

     [ 2006-01-11: traditional-style DOS/Win32 paths are handled
       mostly correctly; there may still be a problem in the
       implementation of :WILD-INFERIORS, and in escaping
       metacharacters.  UNC paths, paths starting with "//./" and
       similar things with magical meanings are as-yet unsupported. ]

2. FFI/Alien.  At the moment, there's a horrible piece of
   almost-duplicated code implementing alien-funcall-stdcall for the
   STDCALL calling convention of Win32, while the normal alien-funcall
   implements CDECL (IIUC).  Reducing the duplication, providing a
   better interface, and implementing the fast-stdcall convention are
   all goals.

     [ 2006-01-11: Luis Oliveira has something which looks promising
       here. ]

3. Unix/Win32 mismatches and divergences.  At the moment, much of the
   Win32 support is implemented with reader conditionals in the
   SB-UNIX package and unix.lisp.  Although this works reasonably well
   (with a bit of help from MSCVRT.DLL, IIUC) it is likely to make
   maintenance harder; as such, it may make sense to identify the
   various code paths calling SB-UNIX functions, and seeing if they
   are implementable in win32, have a close analogue, or are
   completely different, and maybe defining functionality in parallel
   accordingly.

4. The build system.  Making the system build (assuming installation
   of Make, gcc, bash, and so on) using the current or near-enough
   build scripts would be good.
   ** updating make-config.sh to handle new information; [done]
   ** integrating grovel-headers; [kind of done]
   ** is win32 really the name for the object format on win32? [COFF/PE-COFF]
   ** be able to run our own test suite.

5. External-format support.  This is actually necessary for proper
   operation, because CVS pulls down text files with CRLF endings, so
   the ~<Newline> format directive fails to work.

6. Various LISP_FEATURE_WIN32 ifdefs litter some of the runtime files,
   particularly interrupt.c.  Is it possible to abstract the
   operations required?