The file service_internal.c contains the definition of the new function readServiceFile, which calls getServiceFromFile; getServiceFromFile is defined in service_conf.tab.c and declared extern in service_internal.h.

Since WPS service implementations must be linked with service_internal.obj, I suggest moving the definition of readServiceFile to zoo_service_loader.c to avoid "unresolved external symbol" type linker errors. To complete this task, remove the declaration

extern int getServiceFromFile(maps*,const char*,service**);

from service_internal.h and put it in zoo_service_loader.c. Also put the declaration

extern int readServiceFile(maps* conf, char* file,service** service,char *name);

in zcfg2yaml.c

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.