krnl386.exe16: Do not reassign default handles after they got closed.

[Sebastian Lackner]

On 06.04.2016 05:50, Alexandre Julliard wrote:
> Sebastian Lackner <sebastian at fds-team.de> writes:
> 
>> @@ -363,7 +363,7 @@ HFILE16 WINAPI _lclose16( HFILE16 hFile )
>>      }
>>      TRACE("%d (handle32=%p)\n", hFile, dos_handles[hFile] );
>>      CloseHandle( dos_handles[hFile] );
>> -    dos_handles[hFile] = 0;
>> +    dos_handles[hFile] = (hFile < 5) ? INVALID_HANDLE_VALUE : 0;
> 
> This will cause functions that take default handles to not return the
> correct errors. Is that really how it's supposed to work? What bug is
> this for?
> 

As far as I remember it basically solves two bugs at once:

* First of all, apps interpret a returned HFILE of 0 from file APIs as failure.
  This can happen when apps call _lclose(0) before, or when FILE_InitProcessDosHandles
  does not properly initialize them. The second case, failure to
  initialize dos_handles[*] during init, will be fixed in a separate patch.

* I also remember that Michael ran various tests to verify the return value
  of _lclose(*), and it showed that Windows returns 0 when trying to close
  such handle multiple times. I am aware that we still call CloseHandle() on
  INVALID_HANDLE_VALUE in Wine, but this is probably well-defined enough to
  avoid additional checks.

@ Michael: Could you please double-check that my statements above are correct?
If you still have your tests, please also attach them for further review.

Regards,
Sebastian