Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Dmitry Timoshkov dmitry@baikal.ru writes:
dlls/ntdll/file.c | 3 ++- dlls/ntdll/tests/file.c | 5 +++-- 2 files changed, 5 insertions(+), 3 deletions(-)
I don't see the point. Do you actually have an app that depends on this?
Alexandre Julliard julliard@winehq.org wrote:
I don't see the point. Do you actually have an app that depends on this?
When I started to work on this I had an app that has one of the reasons to require running under Vista+ was the difference in overlapped IO behavior. On the other hand the tests clearly show that up-to-date Windows versions (including Windows XP) always return STATUS_PENDING for asynchronous read and write on disk files. Is there another way to remove all those todo_wine statements from the tests?
Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
I don't see the point. Do you actually have an app that depends on this?
When I started to work on this I had an app that has one of the reasons to require running under Vista+ was the difference in overlapped IO behavior. On the other hand the tests clearly show that up-to-date Windows versions (including Windows XP) always return STATUS_PENDING for asynchronous read and write on disk files. Is there another way to remove all those todo_wine statements from the tests?
The tests also show that returning success is allowed for other file types, so I don't see a need to add complexity to treat files differently, unless there's a demonstrated need.
Alexandre Julliard julliard@winehq.org wrote:
I don't see the point. Do you actually have an app that depends on this?
When I started to work on this I had an app that has one of the reasons to require running under Vista+ was the difference in overlapped IO behavior. On the other hand the tests clearly show that up-to-date Windows versions (including Windows XP) always return STATUS_PENDING for asynchronous read and write on disk files. Is there another way to remove all those todo_wine statements from the tests?
The tests also show that returning success is allowed for other file types, so I don't see a need to add complexity to treat files differently, unless there's a demonstrated need.
Do you propose to leave NtWriteFile/NtReadFile in the state when they return STATUS_SUCCESS for overlapped writes and reads? But that's clearly not how Windows implements this accordingto the tests, and that would require changing all the tests to accept both values so that they pass under Wine.
Dmitry Timoshkov dmitry@baikal.ru writes:
Do you propose to leave NtWriteFile/NtReadFile in the state when they return STATUS_SUCCESS for overlapped writes and reads? But that's clearly not how Windows implements this accordingto the tests, and that would require changing all the tests to accept both values so that they pass under Wine.
Well, the tests fail mostly because you have decided that this behavior is broken. I'm not convinced.
Alexandre Julliard julliard@winehq.org wrote:
Do you propose to leave NtWriteFile/NtReadFile in the state when they return STATUS_SUCCESS for overlapped writes and reads? But that's clearly not how Windows implements this accordingto the tests, and that would require changing all the tests to accept both values so that they pass under Wine.
Well, the tests fail mostly because you have decided that this behavior is broken. I'm not convinced.
The tests show that this is how fully up to date Windows versions starting from XP behave, isn't that convincing enough? If not, what else do you need to see?
Dmitry Timoshkov dmitry@baikal.ru writes:
The tests show that this is how fully up to date Windows versions starting from XP behave, isn't that convincing enough? If not, what else do you need to see?
An application that breaks because of this.
-
Alexandre Julliard -
Dmitry Timoshkov