Updated 2004-09-19 09:16:44

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

  1. using the Microsoft SFU (Service For Unix) technology
  2. using cygwin/mingw
  3. native port with 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: Interix

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

3'nt try: native port with cygwin/mingw

cygwin+mingw: (using the '-mno-cygwin')

  • (-) uses 'dll' -> new build system
  • (-) no libtool -> need its own 'Makefile'
  • (+) no path issues -> 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 had 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 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

  • (+) 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

RHS For the pointer issue, would using the following help?
 sprintf(buf,"0x%x", (unsigned int) ptr);

I choose
 sprintf(buf,"0x%p", ptr); // to avoid format warnings