In the Windows version of the char* getStatus function (service_internal.c), the array

char lpszBuf[SHMEMSIZE];

is allocated on the stack, and then returned by casting lpszBuf to (char *). This may (and does) cause unexpected behavior (segmentation fault) because the stack memory for getStatus is automatically freed when the function returns. One solution is to allocate memory for lpszBuf dynamically using malloc (can be freed after each call to getStatus).

The standard stdio functions are shadowed by the fcgi_stdio functions in some but not all parts of the ZOO kernel. As tested on Windows, running a service (e.g. longProcess) with storeExecuteResponse=true and status=true may fail because the ExecuteResponse? is not written to the temporary <service>_final_<pid>.xml file via redirection of stdout. Putting #include "cgic.h" in service_internal.h resolved this problem.

Update: In some services it may be necessary to use standard stdio. For example, Visual C++ has a superset of wide character print functions, not redefined in fcgi_stdio.h, that take FILE* as a parameter (not FCGI_FILE*). This can easily be resolved by putting #define NO_FCGI_DEFINES at the beginning of the service source code.

The Windows-specific macro _zStrdup occurring in function char *strcasestr(...) (zoo_service_loader.c) does not exist. Presumably it should be replaced by zStrdup (defined in service.h)