Updated AnonymouPipeServerUnix to create handles with appropriate handles of anonymous pipe setup to support inheritance into child processes
Updated AnonymousPipeClientUnix to load client handles with inheritability (this is kind unclear behavior still)
Updated all the anonymous pipe server stream unit tests that launch child processes to specify handle inheritability
As of latest implementation of handle inheritance, unit test T111 passes now and accepted file has been added to source control
Updated all the anonymous pipes created by Process class to use updated method signature for MonoIO.CreatePipe(), these calls all set Inheritability to false, even though i believe they are technically being inherited anyway, beacuse STDIN / STDOUT / STDERR had special handling for inheritability during process creation, so ultimately the values used here are still irrelevant?
Updated MonoIO.CreatePipe() and MonoIO.GetPipeHandle() to accept boolean arguments indicating whether inheritance is allowed
Started real implementation of WapiSecurityAttributes in File handles, which at this point really means taking as much as possible of the existing (unimplemented skeleton code) and hooking it into the wapi infrastructure. THe only thing being used is the bInheritable field of the security attributes right now. The rest is only preserved under an assumption that somebody smarter than me had a reason for adding it.
attempted to include a little documentation about how other WapiSecurityAttribute fields are going to work (even though it's unused)
implemented some framework / uility methods for dealing with security attributes in wapi handles
updated file handle deletion event handler file_close() with code to free memory allocated for security attributes (at least the part of the memory we are using right now)
built out handling in file_close() to free a WapiSecurityAttributes structure when freeing (if it's present)
Moved ves_icall_System_IO_MonoIO_PollFD and ves_icall_System_IO_MonoIO_GetPipeHandle to metadata/file-io.c to be a little more consistent with the location other icalls are defined
built out code in CreatePipe() to initialize a WapiSecurityAttributes structure if needed
rewrote CreatePipe() icall-def to omit parameter list (because new arguments were added and this is easier and more robust way to set it up)
created new GetPipeHandle() to do a lookup or create of a pipe handle (was previously implemented in ves_icall_system_IO-MonoIO_GetPipeHandle)
updated wapi_pipehandle_initialize to deal with handle WapiSecurityAttributes
rewrote handle closing / inheritance code in CreateProcess(), original implementation closed everything, and temporary implementation clsoed nothing, finally we have a solution that is actually doing robust behavior, all handles will be closed, unless they are flagged (in the WAPI handle layer) as inheritable, in which case the handle will be left open instead.