[Pachi] Pachi windows build

Jukka Jylänki jujjyl at gmail.com
Sun Jan 1 20:09:13 CET 2012

>Hi All,

>I've been trying to build Pachi on windows using MinGW, but have had
>some issues.

>I've managed to solve a lot of the initial issues, but there are some
>particular problems that are hard to fix, notably:
>* MinGW doesn't implement an inet_ntop function, although there is one
>  on later versions of windows.
>* There is no nanosleep function on windows.

>inet_ntop isn't a very complex piece of code, from what I gather, so
>it could theoretically be replaced with a custom written function,
>which would then work on both linux and windows, but I haven't yet seen
>an implementation that I was sure was open source and could be used.
>Does anybody have any bright ideas, or have any code handy to use for

>Nanosleep might have to be replaced for this to work on windows. Does
>anybody know if there are any, more portable functions that could be
>used instead?

>Help, comments and suggestions welcome.


Hi Paul, nice to read someone also trying a Windows build. I joined
the list today, to see if there's anyone working on a Visual Studio
build. I tried to push the pachi sources through VS2010 today, but
there seems to be several headers, and more demandingly, C99 features
in use that don't trivially map to the VC10 C compiler.

There does exist InetNtop in Winsock, see here
. The reason the naming is different is (as I understand it) that
Windows libraries want to always provide both Ascii and Unicode
variants, so therefore they don't match the Unix equivalents. Also,
apparently there's inet_ntop as-is in ws2tcpip.h, perhaps this helps
, but not in all versions(?).

As for nanosleep, there is no equivalent, and it's not possible to
implement one on windows (in an ideal form). This is because Windows
does not allow sleeping a thread for such small time slices like
nanoseconds. There's the Sleep function
which is given a millisecond value, but it does not guarantee any
precision, and in practice can have a large granularity, something
like 2ms-15ms.

I have seen some people abuse the Winsock select() call
to wait on a selector that is never triggered, and setting the desired
sleep amount as the timeout parameter, which takes in
nanosecond-precise values. Their assumption is that since you can pass
in nanosecond-precise values, then select() would also sleep for
nanosecond-precise times, but that is not accurate.

It is possible to implement manual nanosecond-level-waits by
busy-spin-waiting on a NOP loop and counting time manually with
QueryPerformanceCounter & QueryPerformanceFrequency system calls, see
. The QueryPerformanceCounter is the highest-precision timer available
on Windows (boils down to RDTSC, but implements consistency by not
varying the frequency by power saver modes which lower the CPU bus
speeds etc.) Although, since a thread can be pre-empted at any given
time, such a spinwait sleep loop cannot guarantee to sleep exactly the
desired time, and of course this will just waste system CPU resources.

Searching through the codebase, I see there's two calls to sleep,
time_sleep(u->stats_delay); where stats_delay is set to 10ms by
default, and time_sleep(TREE_BUSYWAIT_INTERVAL); where
TREE_BUSYWAIT_INTERVAL == 100ms. Since the times are this high, I
assume the actual times they get to sleep is not critical, and
therefore the Sleep() system call is probably most appropriate.


More information about the Pachi mailing list