The following clause in function outputResponse (zoo-kernel/service_internal.c, rev. 459, line 1998 ) causes unexpected behavior:

    if(lenv!=NULL){
      tmp0=(char*)malloc((strlen(lenv->value)+strlen(_("Unable to run the Service. The message returned back by the Service was the following: "+1)))*sizeof(char));
      sprintf(tmp0,_("Unable to run the Service. The message returned back by the Service was the following: %s"),lenv->value);
    }

The const char* argument to strlen is incremented by +1, whereas the intention is to allocate an additional byte. Line 1999 should presumably be written

     tmp0=(char*)malloc((strlen(lenv->value)+strlen(_("Unable to run the Service. The message returned back by the Service was the following: "))+1)*sizeof(char));

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).