Version 0 of the 'Freiburg' project port to windows

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

using the Microsoft SFU (Service For Unix) technology
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