dlls/kernel subdir (also splitting 16bit APIs in a separate file)
- implemented ntdll.Nt{Lock|Unlock}File, and made use of those for the
kernel32 equivalent
- implemented a few information classes in NtQueryInformationFile and
NtSetInformationFile (still lots of missing classes)
- enhanced the get_file_info server request in order to implement
correctly NtQueryInformationFile (change time & file alloc size)
- rewrote registry loading to comply with latest changes
handles as wineserver handles
- console input handle object is no longer waitable (input record
synchronisation is now implemented as a simple semaphore), and removed
FD_TYPE_CONSOLE from fd types in wineserver
- console handles now always have their two lower bit set so one can
distinguish a console handle from a kernel object handle
- implemented some undocumented kernel32 console related APIs
(CloseConsoleHandle, GetConsoleInputWaitHandle, OpenConsoleW,
VerifyConsoleIoHandle, DuplicateConsoleHandle)
- allowed a few kernel32 APIs to take console pseudo-handles
(FlushFileBuffer, GetFileType, WaitFor*Object*)
- simplified the console inheritance at process creation
- in console tests, no longer create a console if one already exists
Adapt the DeleteFileA error code checks to take into account variations
between Win9x and NT.
Test DeleteFile(NULL).
Add tests for DeleteFileW.
On NT, calling _lclose on an already closed handle will cause memory
corruption and thus sometimes crash -> removed the relevant test.
Skip the Unicode tests when on Win9x.
- Fix behaviour if files are on different Wine drives
- delete source if copy successful
- try rename() - files may be on the same Unix file system.
- Try copy/delete if rename() fails: files may be on the same DOS
drive, but on different Unix file systems.
WSAGetOverlappedResult().
Fixed shutdown() to work correctly for overlapped sockets (do not
actually do a shutdown() system call as long as there are pending
overlapped requests).
Also added correct error reporting when trying to read or write on a
shut down connection, also for ReadFile()/WriteFile() calls.
- calling the "call_completion" method unconditionally in finish_async
(introduced by me) was wrong, because the thread may never be in an
alertable wait state -> call it only if user completion function is present.
- We need two constant "ops" objects, one with and one without call_completion
method (the event field may NOT be used to determine whether the completion
must be called or not).