Re: [AppDB] How to deal with hardware/driver dependent test result?
On Tue, Aug 27, 2013 at 8:57 PM, Felix Yan wrote: > Hi, > > I'm maintaining Spore 1.0, and it works correctly in wine for over a year on > Nvidia video card with closed-source nvidia driver - but I do noticed with > Intel cards with open source drivers, the game is nearly not playable - > missing texture and more problems. > > Today comes in a new test result that mark the game as "Garbage", while the > description is exactly what happened on my laptop with Intel chip. What > should I do about this? To proceed with the test result and change the game > to "Garbage" stage, or reject with "Nvidia cards works fine"? I don't think > either is fine, so I come to the list for help. > > Thanks! > > Regards, > Felix Yan It's a valid report. Submitting more up to date results with Nvidia so users know it works there would be helpful (as well as a note in the HowTo section, for example). -- -Austin
Re: kernel32/tests: Remove a useless trace.
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=26897 Your paranoid android. === WVISTAX64 (64 bit comm) === comm.c:835: Test failed: WriteFile took 16 ms to write 0 Bytes at 150 Baud comm.c:1445: test_AbortWaitCts timeout 500 handle 003C comm.c:1412: Changing CommMask on the fly for handle 003C after timeout 500
[AppDB] How to deal with hardware/driver dependent test result?
Hi, I'm maintaining Spore 1.0, and it works correctly in wine for over a year on Nvidia video card with closed-source nvidia driver - but I do noticed with Intel cards with open source drivers, the game is nearly not playable - missing texture and more problems. Today comes in a new test result that mark the game as "Garbage", while the description is exactly what happened on my laptop with Intel chip. What should I do about this? To proceed with the test result and change the game to "Garbage" stage, or reject with "Nvidia cards works fine"? I don't think either is fine, so I come to the list for help. Thanks! Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [4/4] ntdll: Properly set flag which indicates buffer empty state.
Dmitry Timoshkov wrote: > 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 a timeout > > comm.c:859: Test failed: WaitCommEvent error 997 > > comm.c:860: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 > > comm.c:865: Test failed: WaitCommEvent used 1000 ms for waiting > > comm.c:1895: Tests skipped: interactive tests (set WINETEST_INTERACTIVE=1) > > make: *** [comm.ok] Error 5 > > 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 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. And current logic of setting the empty buffer flag is really broken, it always sets the flag to a not zero value if ioctl(TIOCOUTQ) succeeds. -- Dmitry.
Re: RFC: Mark dylib/mach-o on Mac OS X
On Aug 27, 2013, at 3:08 PM, André Hentschel wrote:
> Hi,
> at [1] i noticed that dylibs are printed as PEs.
> This intents to fix that, but i have no Mac, could someone please review/test?
>
> [1]
> http://test.winehq.org/data/8ef3a142263e6db11f1514f77b3de84c8b08d7a0/mac_fg-snow-macdrv/advapi32:cred.html
I generally agree with Ken's comments. In addition:
>
> diff --git a/dlls/dbghelp/module.c b/dlls/dbghelp/module.c
> index 6bea436..41fa7e6 100644
> --- a/dlls/dbghelp/module.c
> +++ b/dlls/dbghelp/module.c
> @@ -33,6 +33,7 @@
> WINE_DEFAULT_DEBUG_CHANNEL(dbghelp);
>
> const WCHARS_ElfW[] = {'<','e','l','f','>','\0'};
> +const WCHARS_MachoW[] = {'<','m','a','c','h','o','>','\0'};
Personally, I'd prefer:
const WCHARS_MachOW[] = {'<','m','a','c','h','-','o','>','\0'};
> diff --git a/programs/winedbg/info.c b/programs/winedbg/info.c
> index c0b86ba..c2c7c08 100644
> --- a/programs/winedbg/info.c
> +++ b/programs/winedbg/info.c
> @@ -253,8 +258,11 @@ void info_win32_module(DWORD64 base)
> break;
> }
> if (j < im.num_used) continue;
> -if (strstr(im.mi[i].ModuleName, ".so") ||
> strchr(im.mi[i].ModuleName, '<'))
> +if (strstr(im.mi[i].ModuleName, ".so") ||
> strstr(im.mi[i].ModuleName, "") ||
> +strstr(im.mi[i].ModuleName, ""))
The 'wine' binary (the module whose name is "") is a Mach-O file,
too, on Mac OS.
Chip
Re: [4/4] ntdll: Properly set flag which indicates buffer empty state.
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 a timeout > comm.c:859: Test failed: WaitCommEvent error 997 > comm.c:860: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 > comm.c:865: Test failed: WaitCommEvent used 1000 ms for waiting > comm.c:1895: Tests skipped: interactive tests (set WINETEST_INTERACTIVE=1) > make: *** [comm.ok] Error 5 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? -- Dmitry.
Re: msvcr90/tests: Add more ARM forwards and use them in tests
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=26894 Your paranoid android. === WXPX64 (32 bit msvcr90) === No test summary line found
Re: RFC: Mark dylib/mach-o on Mac OS X
Hi,
On Aug 27, 2013, at 4:08 PM, André Hentschel wrote:
> @@ -94,6 +95,9 @@ static void module_fill_module(const WCHAR* in, WCHAR* out,
> size_t size)
> if (len > 3 && !strcmpiW(&out[len - 3], S_DotSoW) &&
> (l = match_ext(out, len - 3)))
> strcpyW(&out[len - l - 3], S_ElfW);
> +else if (len > 6 && !strcmpiW(&out[len - 6], S_DotDylibW) &&
> +(l = match_ext(out, len - 6)))
> +strcpyW(&out[len - l - 6], S_MachoW);
This isn't sufficient. Even though the native dynamic library extension is
.dylib on Mac OS X, Wine actually still uses .so as the extension for its
libraries. For example, kernel32.dll.so.
So, you have to change the earlier branch matching S_DotSoW, too. Probably, it
should just use "#ifdef __APPLE__" to pick the tag to apply, as
module_get_type_by_name() does in a similar situation.
You do still need the test for .dylib for platform libraries.
> +dbg_printf("MACH-O\t");
I think it should be "Mach-O", not "MACH-O".
> +dbg_printf("MACH-O\t");
Same here.
I believe you missed a check for "" in symbols_info_cb() in symbol.c. I'm
not sure under what circumstances that would be important, though.
-Ken
Re: [4/4] ntdll: Properly set flag which indicates buffer empty state.
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 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 a timeout > comm.c:859: Test failed: WaitCommEvent error 997 > comm.c:860: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 > comm.c:865: Test failed: WaitCommEvent used 1000 ms for waiting > comm.c:1895: Tests skipped: interactive tests (set WINETEST_INTERACTIVE=1) > make: *** [comm.ok] Error 5 I think TIMEOUT (1s) in kernel32/tests/comm.c is too short and the test for < 900, too. Here it tooks often 1100 milliseconds and more (with vanilla 1.6). And I checked the actual git-tree: the test fails here, too (but not always). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Recht Abteilungsleiter IT Leopoldstraße 15 80802 München
RFC: Mark dylib/mach-o on Mac OS X
Hi,
at [1] i noticed that dylibs are printed as PEs.
This intents to fix that, but i have no Mac, could someone please review/test?
[1]
http://test.winehq.org/data/8ef3a142263e6db11f1514f77b3de84c8b08d7a0/mac_fg-snow-macdrv/advapi32:cred.html
diff --git a/dlls/dbghelp/module.c b/dlls/dbghelp/module.c
index 6bea436..41fa7e6 100644
--- a/dlls/dbghelp/module.c
+++ b/dlls/dbghelp/module.c
@@ -33,6 +33,7 @@
WINE_DEFAULT_DEBUG_CHANNEL(dbghelp);
const WCHARS_ElfW[] = {'<','e','l','f','>','\0'};
+const WCHARS_MachoW[] = {'<','m','a','c','h','o','>','\0'};
const WCHARS_WineLoaderW[] =
{'<','w','i','n','e','-','l','o','a','d','e','r','>','\0'};
static const WCHAR S_DotSoW[] = {'.','s','o','\0'};
static const WCHAR S_DotDylibW[]= {'.','d','y','l','i','b','\0'};
@@ -94,6 +95,9 @@ static void module_fill_module(const WCHAR* in, WCHAR* out,
size_t size)
if (len > 3 && !strcmpiW(&out[len - 3], S_DotSoW) &&
(l = match_ext(out, len - 3)))
strcpyW(&out[len - l - 3], S_ElfW);
+else if (len > 6 && !strcmpiW(&out[len - 6], S_DotDylibW) &&
+(l = match_ext(out, len - 6)))
+strcpyW(&out[len - l - 6], S_MachoW);
}
while ((*out = tolowerW(*out))) out++;
}
diff --git a/programs/winedbg/info.c b/programs/winedbg/info.c
index c0b86ba..c2c7c08 100644
--- a/programs/winedbg/info.c
+++ b/programs/winedbg/info.c
@@ -244,6 +244,11 @@ void info_win32_module(DWORD64 base)
}
}
}
+else if (strstr(im.mi[i].ModuleName, ""))
+{
+dbg_printf("MACH-O\t");
+module_print_info(&im.mi[i], FALSE);
+}
else
{
/* check module is not embedded in another module */
@@ -253,8 +258,11 @@ void info_win32_module(DWORD64 base)
break;
}
if (j < im.num_used) continue;
-if (strstr(im.mi[i].ModuleName, ".so") ||
strchr(im.mi[i].ModuleName, '<'))
+if (strstr(im.mi[i].ModuleName, ".so") ||
strstr(im.mi[i].ModuleName, "") ||
+strstr(im.mi[i].ModuleName, ""))
dbg_printf("ELF\t");
+else if (strstr(im.mi[i].ModuleName, ".dylib") ||
strstr(im.mi[i].ModuleName, ""))
+dbg_printf("MACH-O\t");
else
dbg_printf("PE\t");
module_print_info(&im.mi[i], FALSE);
Re: [4/4] ntdll: Properly set flag which indicates buffer empty state.
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_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 a timeout comm.c:859: Test failed: WaitCommEvent error 997 comm.c:860: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:865: Test failed: WaitCommEvent used 1000 ms for waiting comm.c:1895: Tests skipped: interactive tests (set WINETEST_INTERACTIVE=1) make: *** [comm.ok] Error 5 -- Alexandre Julliard julli...@winehq.org
Re: [1/4] ntdll: Ignore ioctl(TIOCGICOUNT) failures.
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. > > > > > > What patch doesn't work for you? > > > > I tested all your patches together (indivually they will not really work > > here). > > Yeah, the patches need to be tested after applying all of them. They were > broken into smaller parts in order to make regression test easier in case of > a regression. If I don't know what doesn't work I can't make any > improvement. Yes, that's clear. I'll have a closer look what's the main difference. The problematic application uses asynchronous IO. I wrote my patch 2009 (and earlier version 2008) so I have to rethink about it. I remember that TX_TXEMPTY detection was a problem, then. It could get lost. The reason I moved the output buffer empty detection from get_irq_info() into check_events() was simply because I thought handling input queue in check_events() but ouput queue in get_irq_info() seems odd. I also think that it's better to detect that get_irq_info() basicly does not work with drivers not supporting TIOCGICOUNT and it is good to have that information in the callers of get_irq_info(). So I return STATUS_NOT_IMPLEMENTED and handle the situation in the caller. And then it is better to move empty sending queue handling out of get_irq_info(). I handle the TIOCSERGETLSR wrong, as I see now (I should & with TIOCSER_TEMT). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Abteilungsleiter IT Leopoldstraße 15 80802 München
Retiring winetestbot
Folks, I am writing to announce that we will be retiring the original Wine Test Bot, written by the late Ge van Geldorp, as of August 31, 2013. We will switch over to the new test bot that Francois has been working on at that time. On September 1, we'll panic and fix everything that is broken ). I want to thank Ge's family, notably his brother Arno, for keeping the servers running these years since Ge passed away. It's also important to note how incredible a contribution the Wine Test Bot has proven to be for the Wine project; Wine owes an incredible debt to Ge, and I hope we can all collectively work to remember the great gift he gave us and the world. Cheers, Jeremy
Re: Does auto-apt work to get wine dependencies in source code?
--Sorry about the HTML in the earlier message. >> Was thinking of running some tests but the list of dependencies on the >> website seems outdated, apt-get build-dep does not work. >Is that with the ubuntu-wine ppa enabled? There are two answers to that question, surprisingly. (1) bitbox In the instructions it looks like the wine ppa repository can be installed the Debian way. But I did that and here's the result. E: You must put some 'source' URIs in your sources.list So, I had to add the wine-ppa by manually adding to the sources.list. (2) non bitbox This morning a new version of the i386 photo function was added, and now the depencencies install. Conclusion: This afternoon I was able to update all dependencies and compile without a problem using (with modifications above) the bitbox instructions. Compiled only. Did not install because I needed symlinks, but at least I know where I am and what I have to do. Susan
Re: ntdll: Implement job objects
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. === W2KPROSP4 (32 bit job) === job: unhandled exception c005 at
Re: ntdll: Implement job objects
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 sure how > autogenerated files are supposed to be handled. http://wiki.winehq.org/SubmittingPatches#head-84da92180d7e348c42aa38456e4159769d12b11a "Do not include diffs for files that are automatically generated..." -- Dmitry.
Re: ntdll: Implement job objects
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 to be handled.
Re: ntdll: Implement job objects
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) {
> + STARTUPINFO startup = {};
> +PROCESS_INFORMATION info = {};
> +
> + if(!CreateProcessA(NULL, GetCommandLine(), NULL, NULL, FALSE, 0, NULL,
> NULL, &startup, &info)) {
> +ok(FALSE, "CreateProcess: %x\n", GetLastError());
> + return 0;
> +}
> +
> + CloseHandle(info.hThread);
> +*handle = info.hProcess;
> +
> + return info.dwProcessId;
> +};
Indentation is completely messed up in the tests, please set tab size to 8
and even better avoid tabs at all. ';' at the end of function looks funny.
> +typedef struct _JOBOBJECT_ASSOCIATE_COMPLETION_PORT {
> + PVOID CompletionKey;
> + HANDLE CompletionPort;
> +} JOBOBJECT_ASSOCIATE_COMPLETION_PORT, *PJOBOBJECT_ASSOCIATE_COMPLETION_PORT;
Same as above.
> +static NTSTATUS (WINAPI *pNtCreateJobObject)( PHANDLE handle, ACCESS_MASK
> access, const OBJECT_ATTRIBUTES *attr );
> +static NTSTATUS (WINAPI *pNtSetInformationJobObject)( HANDLE handle,
> JOBOBJECTINFOCLASS klass, PVOID info, ULONG len );
> +static NTSTATUS (WINAPI *pNtAssignProcessToJobObject)( HANDLE job, HANDLE
> process );
> +static NTSTATUS (WINAPI *pNtIsProcessInJob)( HANDLE process, HANDLE job );
> +static NTSTATUS (WINAPI *pNtTerminateJobObject)( HANDLE job, NTSTATUS status
> );
Please move it to the beginning of the file.
> --- a/include/wine/server_protocol.h
> +++ b/include/wine/server_protocol.h
And don't include autogenerated stuff in the patch.
--
Dmitry.
Re: [1/4] ntdll: Ignore ioctl(TIOCGICOUNT) failures.
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? What hardware and driver are you using? -- Dmitry.
Re: [1/4] ntdll: Ignore ioctl(TIOCGICOUNT) failures.
Hello,
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.
I attached my patch, maybe it is usefull to you.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Abteilungsleiter IT
Leopoldstraße 15
80802 München>From de0a36a35e36c3d5033fbf7c6593768a8f676844 Mon Sep 17 00:00:00 2001
From: Wolfgang Walter
Date: Mon, 28 Sep 2009 15:52:32 +0200
Subject: [PATCH] improve handling of usb2serial adapters
wine does not handle most usb2serial adapters very well.
wine decides at compile time if it expects serial interfaces
to support TIOCGICOUNT and TIOCSERGETLSR.
On linux a lot of device drivers of serial use2serial-adapters
don't suport those ioctls.
This patch tries to handle those devices as if
TIOCGICOUNT and TIOCSERGETLSR were not supported 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,7 @@ typedef struct async_commio
*/
static NTSTATUS get_irq_info(int fd, serial_irq_info *irq_info)
{
+NTSTATUS status = STATUS_NOT_IMPLEMENTED;
#ifdef TIOCGICOUNT
struct serial_icounter_struct einfo;
if (!ioctl(fd, TIOCGICOUNT, &einfo))
@@ -815,47 +816,29 @@ static NTSTATUS get_irq_info(int fd, serial_irq_info *irq_info)
irq_info->parity = einfo.parity;
irq_info->brk = einfo.brk;
irq_info->buf_overrun = einfo.buf_overrun;
+return STATUS_SUCCESS;
}
-else
-{
-TRACE("TIOCGICOUNT err %s\n", strerror(errno));
-memset(irq_info,0, sizeof(serial_irq_info));
-return FILE_GetNtStatus();
-}
-#else
-memset(irq_info,0, sizeof(serial_irq_info));
-return STATUS_NOT_IMPLEMENTED;
-#endif
-irq_info->temt = 0;
-/* Generate a single TX_TXEMPTY event when the TX Buffer turns empty*/
-#ifdef TIOCSERGETLSR /* prefer to log the state TIOCSERGETLSR */
-if (ioctl(fd, TIOCSERGETLSR, &irq_info->temt))
-{
-TRACE("TIOCSERGETLSR err %s\n", strerror(errno));
-return FILE_GetNtStatus();
-}
-#elif defined(TIOCOUTQ) /* otherwise we log when the out queue gets empty */
-if (ioctl(fd, TIOCOUTQ, &irq_info->temt))
-{
-TRACE("TIOCOUTQ err %s\n", strerror(errno));
-return FILE_GetNtStatus();
-}
-else
-{
-if (irq_info->temt == 0)
-irq_info->temt = 1;
-}
+TRACE("TIOCGICOUNT err %s\n", strerror(errno));
+/* EINVAL means: TIOCGICOUNT is not supported by serial driver
+ * in this case behave as if TIOCGICOUNT is not defined by OS
+ */
+if (errno != EINVAL)
+status = FILE_GetNtStatus();
#endif
-return STATUS_SUCCESS;
+memset(irq_info,0, sizeof(serial_irq_info));
+return status;
}
-static DWORD check_events(int fd, DWORD mask,
+static NTSTATUS check_events(int fd, DWORD mask,
const serial_irq_info *new,
const serial_irq_info *old,
- DWORD new_mstat, DWORD old_mstat)
+ DWORD new_mstat, DWORD old_mstat, DWORD *ret)
{
-DWORD ret = 0, queue;
+DWORD queue;
+NTSTATUS status = STATUS_SUCCESS;
+
+*ret = 0;
TRACE("mask 0x%08x\n", mask);
TRACE("old->rx 0x%08x vs. new->rx 0x%08x\n", old->rx, new->rx);
@@ -866,28 +849,67 @@ static DWORD check_events(int fd, DWORD mask,
TRACE("old->brk 0x%08x vs. new->brk 0x%08x\n", old->brk, new->brk);
TRACE("old->buf_overrun 0x%08x vs. new->buf_overrun 0x%08x\n", old->buf_overrun, new->buf_overrun);
-if (old->brk != new->brk) ret |= EV_BREAK;
-if ((old_mstat & MS_CTS_ON ) != (new_mstat & MS_CTS_ON )) ret |= EV_CTS;
-if ((old_mstat & MS_DSR_ON ) != (new_mstat & MS_DSR_ON )) ret |= EV_DSR;
-if ((old_mstat & MS_RING_ON) != (new_mstat & MS_RING_ON)) ret |= EV_RING;
-if ((old_mstat & MS_RLSD_ON) != (new_mstat & MS_RLSD_ON)) ret |= EV_RLSD;
-if (old->frame != new->frame || old->overrun != new->overrun || old->parity != new->parity) ret |= EV_ERR;
+if (old->brk != new->brk) *ret |= EV_BREAK;
+if ((old_mstat & MS_CTS_ON ) != (new_mstat & MS_CTS_ON )) *ret |= EV_CTS;
+if ((old_mstat & MS_DSR_ON ) != (new_mstat & MS_DSR_ON )) *ret |= EV_DSR;
+if ((old_mstat & MS_RING_ON) != (new_mstat & MS_RING_ON)) *ret |= EV_RING;
+if ((old_mstat & MS_RLSD_ON) != (new_mstat & MS_RLSD_ON)) *ret |= EV_RLSD;
+if (old->frame != new->frame || old->overrun != new->overrun || old->parity != new->parity) *ret |= EV_ERR;
if (mask & EV_RXCHAR)
{
queue = 0;
#ifdef TIOCINQ
if (ioctl(fd, TIOCINQ, &queue))
- WARN("TIOCINQ returned error\n");
+{
+if (errno != EINVAL)
+{
+
Re: [4/4] ntdll: Properly set flag which indicates buffer empty state.
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.
Re: ntdll: Store all 'comClass' attributes (try2)
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(olemisc_values[n].name, str, min(len,
> olemisc_values[n].len)*sizeof(WCHAR));
> +if (!c)
> +{
> +if (olemisc_values[n].len < len)
> +c = -1;
> +else if (olemisc_values[n].len > len)
> +c = 1;
> +}
Actually, memcmp is not a good choice for comparing Unicode strings. It
doesn't make a difference for ASCII-only strings, but it would still be
cleaner to do it right. strncmpW is preferable (as long as you use it
correctly...)
--
Alexandre Julliard
julli...@winehq.org
Re: [4/4] ntdll: Properly set flag which indicates buffer empty state.
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. === WVISTAX64 (32 bit comm) === comm.c:835: Test failed: WriteFile took 16 ms to write 0 Bytes at 150 Baud comm.c:1443: test_AbortWaitCts timeout 500 handle 00B4 comm.c:1410: Changing CommMask on the fly for handle 00B4 after timeout 500
