The next release of NSSM will be version 2.16 and it will include a feature which has been requested a number of times over the years, namely the ability to redirect the standard I/O streams which UNIX users know as stdin, stdout and stderr.

Surely getting an application to redirect its output would be easy. In fact I discovered:

• You have to explicitly pass the filehandles to CreateProcess().

• You have to explicitly tell CreateProcess() that the filehandles are inheritable when launching a child process.

• You have to explicitly tell CreateFile() that the filehandles are inheritable when opening them in the first place.

• Opening a file with FILE_APPEND_DATA semantics is not sufficient to append to a file. You have to explicitly seek to the end of the file.

• You can’t open two filehandles to the same path or there will be a race and one of them will lose data. You need to call DuplicateHandle() if both targets are the same. Determining that the user asked for both targets to be the same is an exercise for the reader. Vista offers GetFinalPathNameByHandle() but I couldn’t use that in NSSM because NSSM needs to work on older Windows versions.

• Trying to open a file with FILE_APPEND_DATA | FILE_WRITE_DATA and OPEN_ALWAYS will not result in opening a file for appending if it already exists or creating a new file if it didn’t. You have to try to open it for append and, if that fails with ERROR_FILE_NOT_FOUND, try again as a new file. Otherwise the file will be truncated.

On the plus side, the use of CreateFile() behind the scenes makes it entirely possible that you will be able to do clever stuff like open named pipes and connect IPC for different services together, or take input from a serial port.

Although reading to and writing from plain files is working and, as mentioned above, other I/O should in theory work just as well, the release won’t be coming just yet. I will also be including some rudimentary CPU affinity handling based on a contribution from Robert Middleton. I may even make good on my longstanding threat to remove the readable standard C stuff like declaring variables as unsigned long and replace them with ugly Win32-isms such as DWORD. I hate to do it but like it or not NSSM is a Windows application and probably should follow Windows coding conventions.

But not, under any circumstances, Hungarian notation.