krnl386.exe16: Do not reassign default handles after they got closed.
sebastian at fds-team.de
Wed Apr 6 02:57:33 CDT 2016
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.
More information about the wine-devel