to port 'freiburg' to windows I try 3 different approach's:

   1. using the Microsoft SFU (Service For Unix) technology
   2. using cygwin/mingw

just the solution first .. 3. (native port) with '-mno-cygwin' flag was the
best solution ...  the reason follow:

'''the build environment'''
the original code is on a LINUX file system
every build target uses NFS to get the sources local
   * (+) sources always up to date
the local build is done by sym-linking the sources into a local file system
   * (+) build is done local -> more speed, no special nfs build problems

'''1'st try: SFU''
SFU is a full UNIX OS as WINDOWS subsystem: (link)
just the list of collected experiences:
   * (-) very new -> less software was already ported (no tcl, libtool, ...)
   * (-) needs it 'own' build target -> every software needs changes in the
     autoconf (eg ..) part -> non trivial
   * (-) it is an full OS -> no 'standalone' application possible ->
      always need the full SFU installation even if your application is very
      small -> bad
   * (-) no mixed integration between windows and SFU -> no easy integration
      into windows tools
   * (-) a couple of non-trivial bugs -> not very good tested -> small community
      -> expensive usability
   * (-) performance issues -> was slower than expected
   * (-) in fact I spend significant more time solving system issues and porting
      new tools to SFU as I spend on the goal -> this was very very bad
   * (+) good support with direct contact to the developers
   * (+) build system close to unix (no libtool !!) -> need its own 'Makefile'
   * (+) no 'dll' issues -> no changes to unix 'so' build system
   * (+) very less code changes

'''2'nt try: cygwin/mingw''
cygwin uses a 'native' port of the unix environment to windows -> no subsystem

native cygwin:
   * (-) uses 'dll' -> new build system
   * (-) libtool is available but creates a lot of of very mystic files -> bad
   * (-) always link to the cygwin library
   * (+) close to unix build system
   * (+) no path issues (you always in the 'cygwin' world

native mingw:
   * (-) uses 'dll' -> new build system
   * (-) no libtool -> need its own 'Makefile'
   * (-) many path issues -> mingw gcc uses windows-path-system and the build environment
     uses cygwin path system -> very very bad, special mingw does not support sym-linked
     files -> out of business for me

cygwin+mingw: (using the '-mno-cygwin')
   * (-) uses 'dll' -> new build system
   * (-) no libtool -> need its own 'Makefile'
   * (+) no patsies -> mingw is fully integrated into cygwin world
      -> understand sym-linked files -> very very good

'''native port issues'''
   * (-) very hard to get any documentation other than online form MS
   * (+) I hand an old VC++6.0 compiler with MSDN-CD -> got libC doku -> ok
   * (+) free microsoft SDK has winsock2 docu -> ok
   * (+) winsock2 is BSD socket + some extra stuff -> good

my macros for cross platform socket solution:

    #if defined(IS_POSIX)
    #   define SHUTDOWN_BOTH SHUT_RDWR
    #   define SOCKET_ERROR -1
    #   define INVALID_SOCKET -1
    #   define WIN32_WSA(x)   x
    #   define WIN32_socket(x)   x
    #   include <sys/ioctl.h>
    #   include <errno.h>
    #elif defined(IS_WIN32)
    #   define SHUTDOWN_BOTH SD_BOTH
    #   define WIN32_WSA(x)   WSA##x
    #   define WIN32_socket(x)   x##socket
    #endif

   * (+) all native porting issues are reduced to get a solution for:
    * mkstemp
    * gettimeofday
    * sprintf(buf,"%p",ptr) // MS does not add '0x' to the pointer -> bad