On 10/14/2013 05:21, Dmitry Timoshkov wrote:
Nikolay Sivov wrote:
+FreeLibrary(mod);
Please add the tests for FreeLibrary return value.
Makes sense, thanks.
Nikolay Sivov wrote:
> +FreeLibrary(mod);
Please add the tests for FreeLibrary return value.
--
Dmitry.
Dmitry Timoshkov writes:
> @@ -979,6 +986,12 @@ NTSTATUS WINAPI NtWriteFile(HANDLE hFile, HANDLE hEvent,
> goto done;
> }
>
> +if (append_write)
> +{
> +offset_eof.QuadPart = (LONGLONG)-1; /* FILE_WRITE_TO_END_OF_FILE
> */
> +offset
Dmitry Timoshkov 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
julli...@winehq.org
Alexandre Julliard 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
Dmitry Timoshkov 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 valu
Alexandre Julliard 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
Hans Leidekker writes:
> @@ -129,11 +129,19 @@ static const RTL_OSVERSIONINFOEXW
> VersionData[NB_WINDOWS_VERSIONS] =
> 4, 0, 0, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field
> with a value! */
> },
> /* WINXP */
> +#ifdef _WIN64
> +{
> +sizeof(RTL_OSVE
Dmitry Timoshkov writes:
> Alexandre Julliard 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
Alexandre Julliard 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
Dmitry Timoshkov 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
julli...@winehq.org
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2356
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2339
Your paranoid andr
On Thu, 26 Sep 2013, Dmitry Timoshkov wrote:
[...]
> Obviously you need nothing to know about the test except that it works with
> a COM-port, so the only thing you'd need to investigate is the difference
> between VMs in COM-port setup,
There's none. All the VMs, wxppro, w7u, w7pro64, etc have th
Francois Gouget wrote:
> > > > This VM is broken,
> > >
> > > How so? That is: what should I do to fix it?
> >
> > Investigate, find the source of failures and fix it? Note, that all
> > other VMs pass this test just fine, moreover, this same w7pro64 VM
> > doesn't always fail.
>
> You obvious
On Thu, 26 Sep 2013, Dmitry Timoshkov wrote:
[...]
> > > This VM is broken,
> >
> > How so? That is: what should I do to fix it?
>
> Investigate, find the source of failures and fix it? Note, that all
> other VMs pass this test just fine, moreover, this same w7pro64 VM
> doesn't always fail.
Yo
Francois Gouget wrote:
> > > === w7pro64 (32 bit comm) ===
> > > comm.c:863: Test failed: WaitCommEvent failed with a timeout
> > > comm.c:875: recovering after WAIT_TIMEOUT...
> > > comm.c:886: Test failed: WaitCommEvent error 0
> > > comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY,
On Tue, 24 Sep 2013, Dmitry Timoshkov wrote:
> Marvin wrote:
>
> > === w7pro64 (32 bit comm) ===
> > comm.c:863: Test failed: WaitCommEvent failed with a timeout
> > comm.c:875: recovering after WAIT_TIMEOUT...
> > comm.c:886: Test failed: WaitCommEvent error 0
> > comm.c:888: Test failed: WaitC
Dmitry Timoshkov wrote:
> Marvin wrote:
>
> > === w7pro64 (32 bit comm) ===
> > comm.c:863: Test failed: WaitCommEvent failed with a timeout
> > comm.c:875: recovering after WAIT_TIMEOUT...
> > comm.c:886: Test failed: WaitCommEvent error 0
> > comm.c:888: Test failed: WaitCommEvent: expected E
Marvin wrote:
> === w7pro64 (32 bit comm) ===
> comm.c:863: Test failed: WaitCommEvent failed with a timeout
> comm.c:875: recovering after WAIT_TIMEOUT...
> comm.c:886: Test failed: WaitCommEvent error 0
> comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0
> comm.c:892: WaitCommE
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2267
Your paranoid andr
On 2013-09-18 11:31, Dmitry Timoshkov wrote:
> Thomas Faber wrote:
>> status = pNtWriteFile(hfile, 0, NULL, NULL, &iob, contents,
>> sizeof(contents), &offset, NULL);
>> ok(status == STATUS_PENDING || broken(status == STATUS_SUCCESS) /* see below
>> */, "expected STATUS_PENDING, got %#x\n", stat
Thomas Faber wrote:
> I noticed a couple of tests structured like this:
>
> status = pNtWriteFile(hfile, 0, NULL, NULL, &iob, contents,
> sizeof(contents), &offset, NULL);
> ok(status == STATUS_PENDING || broken(status == STATUS_SUCCESS) /* see
> below */, "expected STATUS_PENDING, got %#x\n", s
Hey Dmitry,
I noticed a couple of tests structured like this:
status = pNtWriteFile(hfile, 0, NULL, NULL, &iob, contents,
sizeof(contents), &offset, NULL);
ok(status == STATUS_PENDING || broken(status == STATUS_SUCCESS) /* see
below */, "expected STATUS_PENDING, got %#x\n", status);
ok(iob.Status
Nikolay Sivov wrote:
> > --- a/dlls/ntdll/tests/file.c
> > +++ b/dlls/ntdll/tests/file.c
> > @@ -1985,6 +1985,22 @@ static void test_read_write(void)
> >
> > bytes = 0xdeadbeef;
> > SetLastError(0xdeadbeef);
> > +ret = ReadFile
On 09/18/2013 10:53 AM, Dmitry Timoshkov wrote:
---
dlls/ntdll/tests/file.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c
index 120fdac..5ae605b 100644
--- a/dlls/ntdll/tests/file.c
+++ b/dlls
Dmitry Timoshkov writes:
> Nikolay Sivov wrote:
>
>> >> It looks like it belongs to kernel32/tests.
>> > Since actual access checks are done by ntdll APIs I believe that
>> > ntdll/tests
>> > is appropriate place, kernel32 file APIs are just wrappe
Francois Gouget wrote:
> That tree was a bit out of date causing the patch to fail to apply. I
> updated it and rediffed.
I'd appreciate if you could postpone sending this sort of patches
when they could conflict with other pending patches in that area.
Thanks.
--
Dmitry.
Nikolay Sivov wrote:
> >> It looks like it belongs to kernel32/tests.
> > Since actual access checks are done by ntdll APIs I believe that ntdll/tests
> > is appropriate place, kernel32 file APIs are just wrappers around the tested
> > functionality.
> >
Dmitry Timoshkov writes:
> This matches what NtWriteFile does.
>
> I assume that this patch is in 'pending' state because of a test failure
> caused
> by 2/2, if the reason is different - please let me know.
It would need some test cases for other file types.
--
Alexandre Julliard
julli...@wi
On 9/13/2013 12:16, Dmitry Timoshkov wrote:
Nikolay Sivov wrote:
It looks like it belongs to kernel32/tests.
Since actual access checks are done by ntdll APIs I believe that ntdll/tests
is appropriate place, kernel32 file APIs are just wrappers around the tested
functionality.
It doesn&#
Nikolay Sivov wrote:
> It looks like it belongs to kernel32/tests.
Since actual access checks are done by ntdll APIs I believe that ntdll/tests
is appropriate place, kernel32 file APIs are just wrappers around the tested
functionality.
--
Dmitry.
On 9/13/2013 11:20, Dmitry Timoshkov wrote:
This test passes under Wine and shows that ReadFile after
CreateFile(GENERIC_WRITE)
is really supposed to fail.
---
dlls/ntdll/tests/file.c | 82 +
1 file changed, 82 insertions(+)
It looks like it
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2144
Your paranoid andr
Marvin wrote:
> === wxppro (32 bit comm) ===
> comm.c:863: Test failed: WaitCommEvent failed with a timeout
> comm.c:875: recovering after WAIT_TIMEOUT...
> comm.c:886: Test failed: WaitCommEvent error 0
> comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0
> comm.c:892: WaitCommEv
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2127
Your paranoid andr
Nikolay Sivov writes:
> @@ -2776,8 +2776,7 @@ static NTSTATUS lookup_assembly(struct actctx_loader*
> acl,
> /* FIXME: add support for language specific lookup */
>
> nameW.Buffer = NULL;
> -if (!(buffer = RtlAllocateHeap( GetProcessHeap(), 0,
> -
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>> Why do you need that? It doesn't look to me like an improvement.
>
> IMO it simplifies the code and avoids using two different code paths
> for normal files.
At the cost of two extra seeks, plus introducing race conditions.
I don't thin
Alexandre Julliard wrote:
> Why do you need that? It doesn't look to me like an improvement.
IMO it simplifies the code and avoids using two different code paths
for normal files.
--
Dmitry.
Dmitry Timoshkov writes:
> ---
> dlls/ntdll/file.c | 31 +++
> 1 file changed, 15 insertions(+), 16 deletions(-)
Why do you need that? It doesn't look to me like an improvement.
--
Alexandre Julliard
julli...@winehq.org
Dmitry Timoshkov writes:
> @@ -961,16 +961,23 @@ NTSTATUS WINAPI NtWriteFile(HANDLE hFile, HANDLE hEvent,
>
> if (type == FD_TYPE_FILE)
> {
> +off_t off;
> +
> if (!(options & (FILE_SYNCHRONOUS_IO_ALERT |
> FILE_SYNCHRONOUS_IO_NONALERT)) && !offset)
> {
>
Dmitry Timoshkov writes:
> ---
> dlls/ntdll/file.c | 13 ++---
> dlls/ntdll/tests/file.c | 15 ---
> 2 files changed, 10 insertions(+), 18 deletions(-)
This is causing test failures all over the place.
--
Alexandre Julliard
julli...@winehq.org
Andrew Cook writes:
> This will be my last submission for this piece of code, i want to work
> on other things and it's been almost 2 weeks with zero comments on my
> previous submission.
It's clearly not ready, and you already know that since you've added
TODOs all over the place.
--
Alexandr
Alexandre Julliard wrote:
> > +if (offset && offset->QuadPart == (LONGLONG)-1 /*
> > FILE_WRITE_TO_END_OF_FILE */)
> > +offset->QuadPart = lseek( unix_handle, 0, SEEK_END );
> > +
>
> This looks very wrong, offset belongs to the caller.
Of course you are correct, thanks.
-
Dmitry Timoshkov writes:
> ---
> dlls/ntdll/file.c | 3 +++
> dlls/ntdll/tests/file.c | 15 ---
> 2 files changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c
> index 9420df5..9d5b02a 100644
> --- a/dlls/n
On 06/09/13 17:12, Frédéric Delanoy wrote:
> On Fri, Sep 6, 2013 at 5:41 AM, Andrew Cook wrote:
>> ---
>> dlls/ntdll/tests/Makefile.in | 1 +
>> dlls/ntdll/tests/job.c | 151
>> +++
>> include/winnt.h
On Fri, Sep 6, 2013 at 5:41 AM, Andrew Cook wrote:
> ---
> dlls/ntdll/tests/Makefile.in | 1 +
> dlls/ntdll/tests/job.c | 151
> +++
> include/winnt.h | 5 ++
> 3 files changed, 157 insertions(+)
> create m
Andrew Cook writes:
> diff --git a/dlls/ntdll/tests/Makefile.in b/dlls/ntdll/tests/Makefile.in
> index 10d6674..1903d10 100644
> --- a/dlls/ntdll/tests/Makefile.in
> +++ b/dlls/ntdll/tests/Makefile.in
> @@ -11,6 +11,7 @@ C_SRCS = \
> file.c \
> generat
Dmitry Timoshkov writes:
> diff --git a/dlls/ntdll/tests/file.c b/dlls/ntdll/tests/file.c
> index cde299c..c802432 100644
> --- a/dlls/ntdll/tests/file.c
> +++ b/dlls/ntdll/tests/file.c
> @@ -2124,11 +2124,8 @@ todo_wine
> iob.Information = -1;
> offset.Qu
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>> >> > Printing complete lsr value in the log may help with diagnosing
>> >> > test failures on Alexandre's machine.
>> >>
>> >> I don't see how, since TIOCSER_TEMT is the only defined bit. Do you
>> >> actually have a driver that returns
Alexandre Julliard wrote:
> >> > Printing complete lsr value in the log may help with diagnosing
> >> > test failures on Alexandre's machine.
> >>
> >> I don't see how, since TIOCSER_TEMT is the only defined bit. Do you
> >> actually have a driver that returns other status?
> >
> > I don't, but
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>> > Printing complete lsr value in the log may help with diagnosing
>> > test failures on Alexandre's machine.
>>
>> I don't see how, since TIOCSER_TEMT is the only defined bit. Do you
>> actually have a driver that returns other status?
>
Alexandre Julliard wrote:
> > Printing complete lsr value in the log may help with diagnosing
> > test failures on Alexandre's machine.
>
> I don't see how, since TIOCSER_TEMT is the only defined bit. Do you
> actually have a driver that returns other status?
I don't, but maybe yours does. The
Dmitry Timoshkov writes:
> Printing complete lsr value in the log may help with diagnosing
> test failures on Alexandre's machine.
I don't see how, since TIOCSER_TEMT is the only defined bit. Do you
actually have a driver that returns other status?
--
Alexandre Julliard
julli...@winehq.org
Dmitry Timoshkov writes:
> Dmitry Timoshkov wrote:
>
>> Printing complete lsr value in the log may help with diagnosing
>> test failures on Alexandre's machine.
>
> This patch is marked as 'Build failure' in the tracker, but I've checked it
> once again and compiles just fine here. What kind of
Dmitry Timoshkov wrote:
> Printing complete lsr value in the log may help with diagnosing
> test failures on Alexandre's machine.
This patch is marked as 'Build failure' in the tracker, but I've checked it
once again and compiles just fine here. What kind of build failure is that?
--
Dmitry.
Am Donnerstag, 29. August 2013, 10:47:46 schrieb Dmitry Timoshkov:
> Wolfgang Walter wrote:
> > I think that happens:
> >
> > * application writes data to com port.
> > * all is written, serial buffer is empty
> > * application calls WaitCommEvent()
> > * wait_on() is called
> > * wait_on() call
Dmitry Timoshkov wrote:
> Wolfgang Walter wrote:
>
> > I think that happens:
> >
> > * application writes data to com port.
> > * all is written, serial buffer is empty
> > * application calls WaitCommEvent()
> > * wait_on() is called
> > * wait_on() calls get_irq_info()
> > * get_irq_info()
Wolfgang Walter wrote:
> I think that happens:
>
> * application writes data to com port.
> * all is written, serial buffer is empty
> * application calls WaitCommEvent()
> * wait_on() is called
> * wait_on() calls get_irq_info()
> * get_irq_info() sets commio->irq_info->temt = 1
> * wait_on()
Hello Nikolay,
On 08/27/2013 12:16 PM, Nikolay Sivov wrote:
> +static OLEMISC get_olemisc_value(const WCHAR *str, int len)
> +{
> +int min, max;
> +
> +min = 0;
> +max = sizeof(olemisc_values)/sizeof(struct olemisc_entry) - 1;
> +
> +while (min <= max)
> +{
> +int n, c;
Hello Dimitry,
I think I now found the difference between my patches and yours and what makes
that one application fail (with or without [4/4] ntdll: Properly set flag
which indicates buffer empty state.)
My patch removes the attempt to flag EV_TXEMPTY only once.
In check_events() EV_TXEMPTY
; I assume it's a real hardware and not a VM? Is this with a real COM port,
> > or USB-serial cable? If the latter one what driver is it using?
>
> Looking at the failure messages above once again, I can say that WriteFile
> failure is definitely not caused by this patch. Does runn
> failure is definitely not caused by this patch. Does running the test
> > several
> > times cause the same failures? In any case it would be interesting to see
> > the +comm log with "ntdll: Add a trace for transmitter's buffer empty flag."
> > applied.
this with a real COM port,
>> or USB-serial cable? If the latter one what driver is it using?
>
> Looking at the failure messages above once again, I can say that WriteFile
> failure is definitely not caused by this patch. Does running the test several
> times cause the same fai
?
Looking at the failure messages above once again, I can say that WriteFile
failure is definitely not caused by this patch. Does running the test several
times cause the same failures? In any case it would be interesting to see
the +comm log with "ntdll: Add a trace for transmitter's buff
Alexandre Julliard wrote:
> It doesn't work here:
>
> ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p
> kernel32_test.exe.so comm.c && touch comm.ok
> comm.c:835: Test failed: WriteFile took 1 ms to write 17 Bytes at 150 Baud
> comm.c:848: Test failed: WaitCommEvent failed with
On Tuesday 27 August 2013 21:14:05 Alexandre Julliard wrote:
> Dmitry Timoshkov writes:
> > ---
> >
> > dlls/kernel32/tests/comm.c | 5 +
> > dlls/ntdll/serial.c| 13 +
> > 2 files changed, 6 insertions(+), 12 deletions(-)
>
> It
Dmitry Timoshkov writes:
> ---
> dlls/kernel32/tests/comm.c | 5 +
> dlls/ntdll/serial.c| 13 +
> 2 files changed, 6 insertions(+), 12 deletions(-)
It doesn't work here:
../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p
kernel32_t
Am Dienstag, 27. August 2013, 22:00:59 schrieben Sie:
> Wolfgang Walter wrote:
> > > Wolfgang Walter wrote:
> > > > I made similar changes so that several applications we use work. I
> > > > tested
> > > > your patches, all but one do work. I don't know why one does not,
> > > > though.
> > >
>
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26885
Your paranoid android
Andrew Cook wrote:
> On 27/08/13 22:02, Dmitry Timoshkov wrote:
> > Andrew Cook wrote:
> >> --- a/include/wine/server_protocol.h
> >> +++ b/include/wine/server_protocol.h
> >
> > And don't include autogenerated stuff in the patch.
> >
>
> Is there anything about this on the wiki? i wasn't sur
On 27/08/13 22:02, Dmitry Timoshkov wrote:
> Andrew Cook wrote:
>> --- a/include/wine/server_protocol.h
>> +++ b/include/wine/server_protocol.h
>
> And don't include autogenerated stuff in the patch.
>
Is there anything about this on the wiki? i wasn't sure how
autogenerated files are supposed
Andrew Cook wrote:
> +typedef struct _JOBOBJECT_ASSOCIATE_COMPLETION_PORT {
> + PVOID CompletionKey;
> + HANDLE CompletionPort;
> +} JOBOBJECT_ASSOCIATE_COMPLETION_PORT, *PJOBOBJECT_ASSOCIATE_COMPLETION_PORT;
This needs to go into its owm header.
> +static DWORD getProcess(PHANDLE handle) {
Hi Wolfgang,
Wolfgang Walter wrote:
> I made similar changes so that several applications we use work. I tested
> your
> patches, all but one do work. I don't know why one does not, though.
What patch doesn't work for you? Do you have a test case or a specific
scenario which doesn't work? Wha
ted by the OS.
---
dlls/ntdll/serial.c | 132 +++
1 file changed, 81 insertions(+), 51 deletions(-)
diff --git a/dlls/ntdll/serial.c b/dlls/ntdll/serial.c
index 5551b3c..c00b6a5 100644
--- a/dlls/ntdll/serial.c
+++ b/dlls/ntdll/serial.c
@@ -804,6 +804
Marvin wrote:
> === WVISTAX64 (32 bit comm) ===
> comm.c:835: Test failed: WriteFile took 16 ms to write 0 Bytes at 150 Baud
Failure is not caused by this patch, probably a VM is very slow.
--
Dmitry.
Nikolay Sivov writes:
> +static OLEMISC get_olemisc_value(const WCHAR *str, int len)
> +{
> +int min, max;
> +
> +min = 0;
> +max = ARRAY_SIZE(olemisc_values) - 1;
> +
> +while (min <= max)
> +{
> +int n, c;
> +
> +n = (min+max)/2;
> +
> +c = memcmp(ole
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26878
Your paranoid android
On 8/26/2013 19:04, Alexandre Julliard wrote:
Nikolay Sivov writes:
+while (min <= max)
+{
+int n, c;
+
+n = (min+max)/2;
+
+c = strncmpW(olemisc_values[n].name, str, len);
strncmp isn't enough.
Right, thanks.
Nikolay Sivov writes:
> +while (min <= max)
> +{
> +int n, c;
> +
> +n = (min+max)/2;
> +
> +c = strncmpW(olemisc_values[n].name, str, len);
strncmp isn't enough.
--
Alexandre Julliard
julli...@winehq.org
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>> > +if (type == FD_TYPE_FILE)
>> > +{
>> > +io_status->u.Status = status;
>> > +io_status->Information = total;
>> > +}
>>
>> I don't see why this would have to be specific to files.
>
> The
Alexandre Julliard wrote:
> > +if (type == FD_TYPE_FILE)
> > +{
> > +io_status->u.Status = status;
> > +io_status->Information = total;
> > +}
>
> I don't see why this would have to be specific to files.
There is a test for pipes which fails if th
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26790
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26789
Your paranoid android
Dmitry Timoshkov writes:
> @@ -748,6 +748,11 @@ err:
> }
> else
> {
> +if (type == FD_TYPE_FILE)
> +{
> +io_status->u.Status = status;
> +io_status->Information = total;
> +}
I don't see why this would have to be specific to files.
Andrey Turkin writes:
> ---
> dlls/ntdll/loader.c | 3 +++
> dlls/ntdll/ntdll.spec | 2 +-
> dlls/ntdll/sync.c | 16
> 3 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c
> index b3abad0
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26708
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26707
Your paranoid android
Marvin wrote:
> === WXPX64 (64 bit file) ===
> file.c:1791: Test failed: expected STATUS_SUCCESS, got 0
> file.c:1817: Test failed: expected STATUS_SUCCESS, got 0
> file.c:1844: Test failed: expected STATUS_END_OF_FILE, got 0xc011
> file.c:1855: Test failed: expected STATUS_END_OF_FILE, got 0
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26698
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26697
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=26661
Your paranoid android
Andrew Cook writes:
> diff --git a/dlls/ntdll/tests/Makefile.in b/dlls/ntdll/tests/Makefile.in
> index 10d6674..a44b880 100644
> --- a/dlls/ntdll/tests/Makefile.in
> +++ b/dlls/ntdll/tests/Makefile.in
> @@ -7,6 +7,7 @@ C_SRCS = \
> directory.c \
> en
Nikolay Sivov writes:
> On 8/2/2013 13:33, Alexandre Julliard wrote:
>> Nikolay Sivov writes:
>>
>>> @@ -1031,6 +1105,17 @@ static BOOL parse_window_class_elem(xmlbuf_t*
>>> xmlbuf, struct dll_redirect* dll)
>>> if (!(entity->u.class.name = xmlstrdupW(&content))) return
>>> FALSE;
>>>
On 8/2/2013 13:33, Alexandre Julliard wrote:
Nikolay Sivov writes:
@@ -1031,6 +1105,17 @@ static BOOL parse_window_class_elem(xmlbuf_t* xmlbuf,
struct dll_redirect* dll)
if (!(entity->u.class.name = xmlstrdupW(&content))) return FALSE;
+/* each class entry needs index, data an
Nikolay Sivov writes:
> @@ -1031,6 +1105,17 @@ static BOOL parse_window_class_elem(xmlbuf_t* xmlbuf,
> struct dll_redirect* dll)
>
> if (!(entity->u.class.name = xmlstrdupW(&content))) return FALSE;
>
> +/* each class entry needs index, data and string data */
> +acl->actctx->wn
On Mon, Jul 29, 2013 at 5:29 PM, Chris Moeller wrote:
>
>
You should add a FIXME() for the SystemNumaHighestNodeNumber case since you
are not implementing the full behavior.
QEMU may be able to emulate NUMA so that may be worth a look (although the
man page sucks on the topic). It's been a whi
From c0c3050e32d8d79596b6ec4dfc8a2a5b5ca76f8b Mon Sep 17 00:00:00 2001
From: Chris Moeller
Date: Mon, 29 Jul 2013 16:19:19 -0700
Subject: ntdll: Implement NtQuerySystemInformation class 0x37, used by
GetNumaHighestNodeNumber
---
dlls/ntdll/nt.c| 14 ++
include/winternl.h
Nikolay Sivov wrote:
> >> +#include "ddk/wdm.h"
> > Please don't do that, this breaks compilation with PSDK headers. If you need
> > some specific definitions, types or API prototypes - replicate them in the
> > test
> > itself.
> What breaks exactly? The fact that PSDK doesn't have DDK headers
On 7/16/2013 09:47, Dmitry Timoshkov wrote:
Nikolay Sivov wrote:
+#include "ddk/wdm.h"
Please don't do that, this breaks compilation with PSDK headers. If you need
some specific definitions, types or API prototypes - replicate them in the test
itself.
What breaks exactly? The fact that PSDK d
1 - 100 of 1294 matches
Mail list logo
