to port 'freiburg' to windows I try 3 different approach's:
- using the Microsoft SFU (Service For Unix) technology
- using cygwin/mingw
- 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 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
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