October 2011 - Wine-Devel - list.winehq.org

Re: Problems with drawing text in 1.3.29

by Marcus Meissner

On Wed, Oct 05, 2011 at 04:53:18PM +0100, Damian Dixon wrote: > Hi, > > I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because of > issues pulled the source from git last night and still have problems. > > I am having performance issues with DrawText (5 odd seconds to draw a simple > string) and the occasional X Error and crash. > > The X Error is consistent and is as follows: > > fixme:advapi:SetSecurityInfo stub > X Error of failed request: BadLength (poly request too large or internal > Xlib length error) > Major opcode of failed request: 151 (RENDER) > Minor opcode of failed request: 17 (RenderCreateGlyphSet) > Serial number of failed request: 41091 > Current serial number in output stream: 41571 > Process of pid=0023 has terminated > > > The crash less consistent but is dependent upon the amount of text I attempt > to draw. > > The last version I know this worked in was 1.1.39. > > I've a few things to still try out before I attempt to create an RBT. To get a backtrace and be able to dump some datastructures, run with WINEDEBUG=+synchronous wine foo.exe This will bring it into the debugger once the condition happens. CIao, MArcus

Oct. 5, 2011

Re: [PATCH 1/4 (resend)] audio: Load winmm only on demand

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > resend: Fix subject, to make buildbot happy. > > dlls/winealsa.drv/Makefile.in | 2 +- > dlls/winealsa.drv/midi.c | 21 ++++++++++++++++++++- > dlls/winecoreaudio.drv/Makefile.in | 2 +- > dlls/winecoreaudio.drv/coreaudio.c | 2 +- > dlls/winecoreaudio.drv/midi.c | 21 ++++++++++++++++++++- > dlls/wineoss.drv/Makefile.in | 2 +- > dlls/wineoss.drv/midi.c | 21 ++++++++++++++++++++- > 7 files changed, 64 insertions(+), 7 deletions(-) Making winmm a delayed import should work just as well, with no code changes. -- Alexandre Julliard julliard(a)winehq.org

Oct. 5, 2011

Re: Problems with drawing text in 1.3.29

by Frédéric Delanoy

On Wed, Oct 5, 2011 at 17:53, Damian Dixon <damian.dixon(a)gmail.com> wrote: > Hi, > I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because of > issues pulled the source from git last night and still have problems. > I am having performance issues with DrawText (5 odd seconds to draw a simple > string) and the occasional X Error and crash. > The X Error is consistent and is as follows: > > fixme:advapi:SetSecurityInfo stub > X Error of failed request: BadLength (poly request too large or internal > Xlib length error) > Major opcode of failed request: 151 (RENDER) > Minor opcode of failed request: 17 (RenderCreateGlyphSet) > Serial number of failed request: 41091 > Current serial number in output stream: 41571 > Process of pid=0023 has terminated > > The crash less consistent but is dependent upon the amount of text I attempt > to draw. > The last version I know this worked in was 1.1.39. 1.1.39 is quite old. Can you try regression testing that? At the least test with 1.2.x and other 1.3.x versions (you can probably find some earlier binary packages) Also, this should probably go to wine-users list, and not wine-devel

Oct. 5, 2011

Problems with drawing text in 1.3.29

by Damian Dixon

Hi, I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because of issues pulled the source from git last night and still have problems. I am having performance issues with DrawText (5 odd seconds to draw a simple string) and the occasional X Error and crash. The X Error is consistent and is as follows: fixme:advapi:SetSecurityInfo stub X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 151 (RENDER) Minor opcode of failed request: 17 (RenderCreateGlyphSet) Serial number of failed request: 41091 Current serial number in output stream: 41571 Process of pid=0023 has terminated The crash less consistent but is dependent upon the amount of text I attempt to draw. The last version I know this worked in was 1.1.39. I've a few things to still try out before I attempt to create an RBT. However I would like to know if anyone else is experiencing similar problems and f they have solved the problem. Thanks Damian

Oct. 5, 2011

[Question] Built-in indeo drivers

by Joerg-Cyril.Hoehle＠t-systems.com

Maxim Poliakovski wrote: >I volunteer myself to create an open-source Go ahead! Some apps still crash in Wine because their installers don't install them, and not every user is able to figure out from the fixme messages what's missing. OSS is not enough, your license must be compatible with Wine's. I don't know whether Indeo is covered by patents and whether that may cause trouble. Which Wine video codec is recommended for copy&paste? iccvid? Encoding only is like iccvid. Regards, Jörg Höhle

Oct. 5, 2011

[Question] Built-in indeo drivers

by Maxim

Hi crews, I want to propose a solution for the well-known problem with Indeo codecs. Details here: http://www.ligos.com/index.php/home/support/indeosupport/ There is a bunch of (old) games still using indeo in their cut scenes. For that reason the installation of the Intel DLLs is required. Unfortunately, old indeo codecs prior the version 5 contain bugs and their support has been discontinued for years. Moreover, Microsoft has disabled indeo in the latest OSes due to security issues. I volunteer myself to create an open-source bult-in replacement for indeo v3,4 and 5 based on my patches for ffmpeg. The code will be reworked in order to remove ffmpeg/libav library dependencies. Only decoding will be implemented. Encoding would require a huge amount of time and it doesn't worth it... Would be such a patch appreciated? Best regards Maxim Poliakovski

Oct. 5, 2011

Re: Vista/w2k8/w7 users, please test mmdevapi base render test

by Ricardo Filipe

hi joerg, i have some failures on my win7 machine with 5.1 sound: render.c:167: Returned periods: 10.0000 ms 3.0000 ms render.c:179: pwfx: 0075F060 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 6 render.c:183: rate: 48000 render.c:184: align: 24 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3f render.c:192: Alg: FLOAT render.c:308: Returned latency: 10.6666 ms render.c:405: Initialize (1, 44100x16x1) returns 00000000 unlike IsFormatSupport ed render.c:413: Test failed: Initialize(1, 44100x16x1) returns 00000000 render.c:381: IsSupported(1, 44100x16x2) render.c:405: Initialize (1, 48000x16x1) returns 00000000 unlike IsFormatSupport ed render.c:413: Test failed: Initialize(1, 48000x16x1) returns 00000000 render.c:381: IsSupported(1, 48000x16x2) render.c:405: Initialize (1, 96000x16x1) returns 00000000 unlike IsFormatSupport ed render.c:413: Test failed: Initialize(1, 96000x16x1) returns 00000000 render.c:381: IsSupported(1, 96000x16x2) render.c:381: IsSupported(0, 48000x 8x1) render.c:381: IsSupported(0, 48000x 8x2) render.c:381: IsSupported(0, 48000x16x1) render.c:381: IsSupported(0, 48000x16x2) render.c:895: Tests skipped: No capture device available: 80070490; skipping cap ture device in render session tests render: 671 tests executed (0 marked as todo, 3 failures), 1 skipped. anything else you require please ask. 2011/10/4 <Joerg-Cyril.Hoehle(a)t-systems.com> > Hi, > > please run on native machines my newest mmdevapi tests at > http://testbot.winehq.org/JobDetails.pl?Key=14691 > You'll find both patch and .exe there. > > I've split my former test in two. This is part one, without the GetPosition > tests. > WINETEST_DEBUG does not matter in part 1. > > wine mmdevapi_test.exe render > > I'd be pleased if you could test this with various configurations: > - with exclusive mode disabled in the MS control panel > - with non-standard settings in the MS control panel > - with 5:1 audio chosen (if possible) in the MS control panel > - audio entirely disabled > - sound card without capture (does "capture only" exist?) > > Please report any failures such that I can later submit this part one test, > given confidence that it's been tested with a variety of configurations. > > Thank you for testing, > Jörg Höhle > >

Oct. 5, 2011

Re: Vista/w2k8/w7 users, please test mmdevapi base render test

by Erik Inge Bolsø

Hi Jörg, on my W7 machine I get some failures. I'm using a semi-pro usb soundcard, Creative E-MU 0202 USB. It's set to use 24-bit, 48 kHz as standard in shared mode. In addition, I turned off the E-MU and connected my cheap C-Media USB headset and left it set to default settings (44100 hz, 16-bit). I get some failures both in exclusive and non-exclusive mode. (And how does the test handle multiple soundcards?) E-MU, Exclusive allowed: render.c:167: Returned periods: 10.0000 ms 3.0000 ms render.c:179: pwfx: 00751AA8 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 2 render.c:183: rate: 48000 render.c:184: align: 8 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3 render.c:192: Alg: FLOAT render.c:308: Returned latency: 10.6666 ms render.c:381: IsSupported(1, 44100x16x2) render.c:381: IsSupported(1, 48000x16x2) render.c:381: IsSupported(0, 48000x 8x2) render.c:381: IsSupported(0, 48000x16x2) render.c:887: Test failed: Initialize failed: 8889000f render.c:890: Test failed: GetService failed: 88890001 render.c:921: this is the last test seen before the exception render: unhandled exception c0000005 at 00409E1C E-MU, Exclusive disabled: render.c:167: Returned periods: 10.0000 ms 3.0000 ms render.c:179: pwfx: 00701AA8 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 2 render.c:183: rate: 48000 render.c:184: align: 8 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3 render.c:192: Alg: FLOAT render.c:308: Returned latency: 10.6666 ms render.c:413: Test failed: Initialize(1, 44100x16x2) returns 8889000e render.c:413: Test failed: Initialize(1, 48000x16x2) returns 8889000e render.c:381: IsSupported(0, 48000x 8x2) render.c:381: IsSupported(0, 48000x16x2) render.c:887: Test failed: Initialize failed: 8889000f render.c:890: Test failed: GetService failed: 88890001 render.c:921: this is the last test seen before the exception render: unhandled exception c0000005 at 00409E1C C-Media USB headphone, Exclusive enabled: render.c:167: Returned periods: 10.0000 ms 3.0000 ms render.c:179: pwfx: 00A81AA8 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 2 render.c:183: rate: 44100 render.c:184: align: 8 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3 render.c:192: Alg: FLOAT render.c:308: Returned latency: 11.6100 ms render.c:381: IsSupported(1, 44100x16x2) render.c:381: IsSupported(1, 48000x16x2) render.c:381: IsSupported(0, 44100x 8x2) render.c:381: IsSupported(0, 44100x16x2) render.c:1457: Test failed: Got wrong volume: 0.000000 render.c:1480: Test failed: Got wrong volume: 0.000000 render: 705 tests executed (0 marked as todo, 2 failures), 0 skipped. C-Media USB headphone, Exclusive disabled: render.c:167: Returned periods: 10.0000 ms 3.0000 ms render.c:179: pwfx: 009E1AA8 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 2 render.c:183: rate: 44100 render.c:184: align: 8 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3 render.c:192: Alg: FLOAT render.c:308: Returned latency: 11.6100 ms render.c:413: Test failed: Initialize(1, 44100x16x2) returns 8889000e render.c:413: Test failed: Initialize(1, 48000x16x2) returns 8889000e render.c:381: IsSupported(0, 44100x 8x2) render.c:381: IsSupported(0, 44100x16x2) render.c:1457: Test failed: Got wrong volume: 0.000000 render.c:1480: Test failed: Got wrong volume: 0.000000 render: 705 tests executed (0 marked as todo, 4 failures), 0 skipped. -- -erik http://useofwords.blogspot.com/

Oct. 5, 2011

Re: ws2_32: Patch to selectively bind to interfaces while still allowing broadcast packets (try 2)

by Erich Hoover

On Tue, Oct 4, 2011 at 3:30 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > On Tue, Oct 04, 2011 at 10:51:26AM -0600, Erich Hoover wrote: > > ... While this feature normally requires root > > privileges, it can also be enabled by giving wine-preloader the > > CAP_NET_RAW capability. ... > Frankly, no sane distributor will ever do this. I wouldn't expect them to. If a user wants this feature then they'd need to enable it themselves, just like for ICMP or for raw socket creation. Erich Hoover ehoover(a)mines.edu

Oct. 4, 2011

Re: ws2_32: Patch to selectively bind to interfaces while still allowing broadcast packets (try 2)

by Marcus Meissner

On Tue, Oct 04, 2011 at 10:51:26AM -0600, Erich Hoover wrote: > Real Name: > Erich Hoover > > Description: > I know it's been quite a while, but I'm back with another solution > for Bug #7929. This patch uses SO_BINDTODEVICE in order to bind a > socket to a specific interface while still allowing broadcast packets > (a Linux-only feature). While this feature normally requires root > privileges, it can also be enabled by giving wine-preloader the > CAP_NET_RAW capability. Should insufficient permissions be available, > the patch outputs an appropriate error message notifying the user that > broadcast packets will not function properly. Frankly, no sane distributor will ever do this. Ciao, Marcus > Changelog: > ws2_32: Patch to selectively bind to interfaces while still > allowing broadcast packets. > From f4c904b9b21da7664eff33be918da71795db01af Mon Sep 17 00:00:00 2001 > From: Erich Hoover <ehoover(a)mines.edu> > Date: Tue, 4 Oct 2011 10:43:06 -0600 > Subject: ws2_32: Selectively bind UDP sockets to interfaces while still allowing broadcast packets. > > --- > dlls/ws2_32/socket.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 94 insertions(+), 0 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index f0313fc..174ec15 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -2101,6 +2101,94 @@ static int WINAPI WS2_WSARecvMsg( SOCKET s, LPWSAMSG msg, LPDWORD lpNumberOfByte > } > > /*********************************************************************** > + * interface_bind (INTERNAL) > + * > + * Bind the given socket exclusively to a specific interface. > + */ > +static int interface_bind( int fd, struct sockaddr *addr ) > +{ > + struct sockaddr_in *in_sock = (struct sockaddr_in *) addr; > + PIP_ADAPTER_INFO adapters = NULL, adapter; > + unsigned int sock_type = 0, optlen; > + int ret = FALSE; > + DWORD adap_size; > + > + if (in_sock->sin_addr.s_addr == htonl(WS_INADDR_ANY)) > + { > + /* Not binding to specific interface, use default route */ > + goto cleanup; > + } > + optlen = sizeof(sock_type); > + if (getsockopt(fd, SOL_SOCKET, SO_TYPE, &sock_type, &optlen) == -1 > + || sock_type != SOCK_DGRAM) > + { > + /* Not a UDP socket, interface-specific bind is irrelevant. */ > + goto cleanup; > + } > + /* Obtain the size of the IPv4 adapter list and allocate structure memory */ > + if (GetAdaptersInfo(NULL, &adap_size) != ERROR_BUFFER_OVERFLOW) > + { > + ERR("Failed to get the size of the adapter list, " > + "bound broadcast packets will not work on this socket.\n"); > + goto cleanup; > + } > + adapters = HeapAlloc(GetProcessHeap(), 0, adap_size); > + if (adapters == NULL) > + { > + ERR("Failed to allocate the adapter list, " > + "bound broadcast packets will not work on this socket.\n"); > + goto cleanup; > + } > + /* Obtain the IPv4 adapter list */ > + if (GetAdaptersInfo(adapters, &adap_size) != NO_ERROR) > + { > + ERR("Failed to obtain the adapter list, " > + "bound broadcast packets will not work on this socket.\n"); > + goto cleanup; > + } > + /* Search the IPv4 adapter list for the appropriate binding IP */ > + for (adapter = adapters; adapter != NULL; adapter = adapter->Next) > + { > + char *ip = adapter->IpAddressList.IpAddress.String; > + in_addr_t adapter_addr = (in_addr_t) inet_addr(ip); > + > + if (in_sock->sin_addr.s_addr == adapter_addr) > + { > +#ifdef SO_BINDTODEVICE > + struct ifreq ifr; > + > + memset(&ifr, 0, sizeof(ifr)); > + lstrcpynA(ifr.ifr_name, adapter->AdapterName, sizeof(ifr.ifr_name)); > + if (setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, (void*)&ifr, sizeof(ifr)) == 0) > + { > + /* Success! All packets sent on this socket will go through the > + * specified interface. */ > + TRACE("Bound to interface '%s' (corresponds to local address %s).\n", > + adapter->AdapterName, inet_ntoa(in_sock->sin_addr)); > + ret = TRUE; > + break; > + } > + > + /* If we are unable to bind to a specific interface then notify the > + * user that broadcast packets will not work for this socket. The > + * user can correct this by giving CAP_NET_RAW access to the > + * wine-preloader binary. */ > + ERR("SO_BINDTODEVICE failed (requires CAP_NET_RAW), " > + "broadcast packets will not work on this socket.\n"); > +#else /* SO_BINDTODEVICE */ > + WARN("SO_BINDTODEVICE is unsupported on this platform, " > + "broadcast packets will not work on this socket.\n"); > +#endif /* SO_BINDTODEVICE */ > + break; > + } > + } > + > +cleanup: > + HeapFree(GetProcessHeap(), 0, adapters); > + return ret; > +} > + > +/*********************************************************************** > * bind (WS2_32.2) > */ > int WINAPI WS_bind(SOCKET s, const struct WS_sockaddr* name, int namelen) > @@ -2151,6 +2239,12 @@ int WINAPI WS_bind(SOCKET s, const struct WS_sockaddr* name, int namelen) > "INADDR_ANY instead.\n"); > in4->sin_addr.s_addr = htonl(WS_INADDR_ANY); > } > + else if (interface_bind(fd, &uaddr.addr)) > + { > + /* Bound to a specific interface, change the binding > + * address so that broadcast packets work properly */ > + in4->sin_addr.s_addr = htonl(WS_INADDR_ANY); > + } > } > if (bind(fd, &uaddr.addr, uaddrlen) < 0) > { > -- > 1.7.1 > >

Oct. 4, 2011

Re: [1/4] cmd: Avoid checking handle type when already known in WCMD_ReadFile

by Eric Pouech

> I don't quite understand what you mean. WCMD_ReadFile is called > directly/indirectly in a lot of places, mostly around line-by-line > reads. > The question is not whether the compiler will inline this function > (you can't know that for sure, think -O0, different compilers, etc.), > but whether you want to check that every time. > > This function is_console_handle() could be inlined or not/fast, but > that's not the point. The point is why would one want to run that > function when not necessary, i.e. when callers already know the type. > It's just about finding/detecting the handle type once and only once > (per handle). > > the point is about passing twice the information to a given function the point is about adding unnecessary enums that clutter all the code the point is about thinking that you're only computing once a value, while you still need to compare the handle type (as you added it) to a given number A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Oct. 4, 2011

Re: [1/4] cmd: Avoid checking handle type when already known in WCMD_ReadFile

by Frédéric Delanoy

2011/10/4 Juan Lang <juan.lang(a)gmail.com>: >> OK but the purpose is to avoid checking the handle type for every line >> read. Granted, one could use '((DWORD_PTR)h) & 3 == 3' instead of >> GetConsoleMode or similar function. >> (there's currently code like "BOOL is_console = GetConsoleMode(...); >> ...; while WCMD_fgets(..., is_console)" and the handle type shouldn't >> change between lines/iterations, so why bother recomputing it every >> time?) > > You're probably not. The compiler will probably inline this function, > or at least its return value, since it knows it's guaranteed not to > change. Please don't do the compiler's work for it: IMHO, it's more > readable to make an inline function to determine whether the handle is > a console handle. I don't quite understand what you mean. WCMD_ReadFile is called directly/indirectly in a lot of places, mostly around line-by-line reads. The question is not whether the compiler will inline this function (you can't know that for sure, think -O0, different compilers, etc.), but whether you want to check that every time. This function is_console_handle() could be inlined or not/fast, but that's not the point. The point is why would one want to run that function when not necessary, i.e. when callers already know the type. It's just about finding/detecting the handle type once and only once (per handle).

Oct. 4, 2011

Re: kernel32: Implement GetVolumePathName.

by Charles Davis

On Oct 4, 2011, at 11:56 AM, Erich Hoover wrote: > On Tue, Oct 4, 2011 at 11:36 AM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> On Oct 4, 2011, at 9:32 AM, Erich Hoover wrote: >>> This patch implements GetVolumePathName by using the full folder >>> path and working backward until stat() returns a different device. >> Surely there's a better way. Can't you do a statfs(2)/statvfs(2) (for example) to find out the FS root? (I know that works on the BSDs and Mac OS, because their statfs/statvfs structures all have a field for that--f_mntonname.) Then you can map that path back to a Wine path, and return that. Of course, that won't work for fake drives (see below). > > I doubt it, the function needs to return the mount point along the > given path (see MSDN). In the case of cross-device symbolic links > your suggestion will not return the current path. Ah, you're right. MSDN says that GetVolumePathName() returns the volume containing the target of the symlink... unless of course, the path is a remote one. (Same for mounted volumes.) But that isn't a common case, nor is it one that Wine even supports yet :). > >> At the very least, you should be caching this information, like I did when I added case-insensitive lookup support to Wine (see commit 4e44e153c5c78339f17baeabe22f2015cfc8737c). Because you call stat(2) on every single directory in a pathname (especially in the common case of the file being on the root device), calculating this from scratch is extremely expensive. > > I'm not sure this function is used enough to justify caching the > results, as this is the first time I've noticed the FIXME on the > console. If someone thinks that is the case then I can always make > that a "part 2" patch. OK. > >> And what about drive C? On Wine, that's not a device at all. It's a folder usually somewhere on the root device. In general, I don't see anything in your patch that accounts for fake drives like C:--the common case, I might add! > > If you pass it just the path to "C:\" then it will spit back "C:\", > since it only encounters the one filesystem. If you pass something > like "C:\windows\system32\" then it will spit back "C:\" unless the > "windows" or "system32" folders are symbolic links to a folder on > another drive. Ah, I read your patch wrong. Never mind. Chip

Oct. 4, 2011

Re: [1/4] cmd: Avoid checking handle type when already known in WCMD_ReadFile

by Juan Lang

> OK but the purpose is to avoid checking the handle type for every line > read. Granted, one could use '((DWORD_PTR)h) & 3 == 3' instead of > GetConsoleMode or similar function. > (there's currently code like "BOOL is_console = GetConsoleMode(...); > ...; while WCMD_fgets(..., is_console)" and the handle type shouldn't > change between lines/iterations, so why bother recomputing it every > time?) You're probably not. The compiler will probably inline this function, or at least its return value, since it knows it's guaranteed not to change. Please don't do the compiler's work for it: IMHO, it's more readable to make an inline function to determine whether the handle is a console handle. --Juan

Oct. 4, 2011

Re: kernel32: Implement GetVolumePathName.

by Erich Hoover

On Tue, Oct 4, 2011 at 11:36 AM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > On Oct 4, 2011, at 9:32 AM, Erich Hoover wrote: > > This patch implements GetVolumePathName by using the full folder > > path and working backward until stat() returns a different device. > Surely there's a better way. Can't you do a statfs(2)/statvfs(2) (for example) to find out the FS root? (I know that works on the BSDs and Mac OS, because their statfs/statvfs structures all have a field for that--f_mntonname.) Then you can map that path back to a Wine path, and return that. Of course, that won't work for fake drives (see below). I doubt it, the function needs to return the mount point along the given path (see MSDN). In the case of cross-device symbolic links your suggestion will not return the current path. > At the very least, you should be caching this information, like I did when I added case-insensitive lookup support to Wine (see commit 4e44e153c5c78339f17baeabe22f2015cfc8737c). Because you call stat(2) on every single directory in a pathname (especially in the common case of the file being on the root device), calculating this from scratch is extremely expensive. I'm not sure this function is used enough to justify caching the results, as this is the first time I've noticed the FIXME on the console. If someone thinks that is the case then I can always make that a "part 2" patch. > And what about drive C? On Wine, that's not a device at all. It's a folder usually somewhere on the root device. In general, I don't see anything in your patch that accounts for fake drives like C:--the common case, I might add! If you pass it just the path to "C:\" then it will spit back "C:\", since it only encounters the one filesystem. If you pass something like "C:\windows\system32\" then it will spit back "C:\" unless the "windows" or "system32" folders are symbolic links to a folder on another drive. Erich Hoover ehoover(a)mines.edu

Oct. 4, 2011

Re: [2/2] gdi32/tests: fix MSVC build in bitmap.c

by Marvin

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=14695 Your paranoid android. === WNT4WSSP6 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 00416287 === W2KPROSP4 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 00416287 === WXPPROSP3 (32 bit bitmap) === bitmap: unhandled exception 80000003 at 7C90120E === W2K3R2SESP2 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 7C83F11C === WVISTAADM (32 bit bitmap) === bitmap: unhandled exception c0000005 at 7749653F === W2K8SE (32 bit bitmap) === bitmap: unhandled exception c0000005 at 00000000 === W7PRO (32 bit bitmap) === bitmap: unhandled exception c0000005 at 772D5A15 === W7PROX64 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 00000000 === TEST64_W7SP1 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 77593CDB === W7PROX64 (64 bit bitmap) === Timeout === TEST64_W7SP1 (64 bit bitmap) === Timeout

Oct. 4, 2011

Re: kernel32: Implement GetVolumePathName.

by Charles Davis

On Oct 4, 2011, at 9:32 AM, Erich Hoover wrote: > This patch implements GetVolumePathName by using the full folder > path and working backward until stat() returns a different device. Surely there's a better way. Can't you do a statfs(2)/statvfs(2) (for example) to find out the FS root? (I know that works on the BSDs and Mac OS, because their statfs/statvfs structures all have a field for that--f_mntonname.) Then you can map that path back to a Wine path, and return that. Of course, that won't work for fake drives (see below). At the very least, you should be caching this information, like I did when I added case-insensitive lookup support to Wine (see commit 4e44e153c5c78339f17baeabe22f2015cfc8737c). Because you call stat(2) on every single directory in a pathname (especially in the common case of the file being on the root device), calculating this from scratch is extremely expensive. And what about drive C? On Wine, that's not a device at all. It's a folder usually somewhere on the root device. In general, I don't see anything in your patch that accounts for fake drives like C:--the common case, I might add! Chip

Oct. 4, 2011

Re: kernel32: Implement GetVolumePathName.

by Dan Kegel

On Tue, Oct 4, 2011 at 8:58 AM, Erich Hoover <compholio(a)gmail.com> wrote: >> Fails test here? >> ... >> >> 3 RtlDosPathNameToNtPathName_U+0x35c(dos_path="C:\windows\system32", >> ntpath=0x32fbb4, file_part=(nil), cd=(nil)) [dlls/ntdll/path.c:394] >> 4 GetVolumePathNameW+0x107(filename="C:\windows\system32", >> volumepathname="?Ir\sandbox\slave\(", buflen=0x14) >> [dlls/kernel32/volume.c:1767] > > That test succeeds on my box... That is also a particularly odd place for it > to segfault, I really don't see how RtlDosPathNameToNtPathName_U could > possibly screw up with that pathname. Might be an unrelated flakiness. I'll run it in a loop here and see if I can get it to happen again. - Dan

Oct. 4, 2011

Re: kernel32: Implement GetVolumePathName.

by Erich Hoover

On Tue, Oct 4, 2011 at 9:46 AM, Dan Kegel <dank(a)kegel.com> wrote: > Fails test here? > ... 3 RtlDosPathNameToNtPathName_U+0x35c(dos_path="C:\windows\system32", > ntpath=0x32fbb4, file_part=(nil), cd=(nil)) [dlls/ntdll/path.c:394] > 4 GetVolumePathNameW+0x107(filename="C:\windows\system32", > volumepathname="?Ir\sandbox\slave\(", buflen=0x14) > [dlls/kernel32/volume.c:1767] > ... > That test succeeds on my box... That is also a particularly odd place for it to segfault, I really don't see how RtlDosPathNameToNtPathName_U could possibly screw up with that pathname. Erich Hoover ehoover(a)mines.edu

Oct. 4, 2011

re: kernel32: Implement GetVolumePathName.

by Dan Kegel

Fails test here? ../../../tools/runtest -q -P wine -M ntdll.dll -T ../../.. -p ntdll_test.exe.so file.c && touch file.ok Unhandled exception: page fault on read access to 0x00212b18 in 32-bit code (0x7bc47995). Backtrace: =>0 HEAP_CreateFreeBlock+0xbb(subheap=0x110014, ptr=0x122b48, size=0xeffd0) [dlls/ntdll/heap.c:583] 1 HEAP_ShrinkBlock+0x42(subheap=0x110014, pArena=0x122b08, size=0x38) [dlls/ntdll/heap.c:685] 2 RtlAllocateHeap+0x2a8(heap=0x110000, flags=0x2, size=0x38) [dlls/ntdll/heap.c:1699] 3 RtlDosPathNameToNtPathName_U+0x35c(dos_path="C:\windows\system32", ntpath=0x32fbb4, file_part=(nil), cd=(nil)) [dlls/ntdll/path.c:394] 4 GetVolumePathNameW+0x107(filename="C:\windows\system32", volumepathname="?Ir\sandbox\slave\(", buflen=0x14) [dlls/kernel32/volume.c:1767] 5 test_file_name_information+0x179() [dlls/ntdll/tests/file.c:1304] 6 func_file+0x374() [dlls/ntdll/tests/file.c:1726] 7 run_test+0x9e(name="file.c") [include/wine/test.h:556] 8 main+0x23a(argc=<?>, argv=0x1103c8) [include/wine/test.h:624] 0x7bc47995 HEAP_CreateFreeBlock+0xbb [dlls/ntdll/heap.c:583] in ntdll: movl 0x0(%eax),%eax 583 (*(DWORD *)((char *)ptr + size) & ARENA_FLAG_FREE))

Oct. 4, 2011

Re: [1/4] cmd: Avoid checking handle type when already known in WCMD_ReadFile

by Frédéric Delanoy

2011/10/4 Eric Pouech <eric.pouech(a)orange.fr>: > > > Le 4 octobre 2011 13:40, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a > écrit : >> >> 2011/10/4 Dan Kegel <dank(a)kegel.com>: >> > + * handle_type: type of hIn handle >> > + * 0 if file, 1 if console, anything else if unknown >> > (autodetect) >> > >> > I suspect you want an enum for that. >> >> Well I thought about that, but found it a bit overkill for such a >> limited set of possible values. >> Also, if I used sthg like >> >> enum CMD_HANDLE_TYPE { >> CMD_HT_FILE = 0, >> CMD_HT_CONSOLE = 1, >> CMD_HT_UNKNOWN = 2 >> } >> > again, this is not needed (passing all thoses CMD_HT bits) > > static inline BOOL is_console_handle(HANDLE h) {return ((DWORD_PTR)h) & 3 == > 3;} > will test every handle and tell whether it's a console or a regular (file, > pipe...) handle > > Eric Pouech OK but the purpose is to avoid checking the handle type for every line read. Granted, one could use '((DWORD_PTR)h) & 3 == 3' instead of GetConsoleMode or similar function. (there's currently code like "BOOL is_console = GetConsoleMode(...); ...; while WCMD_fgets(..., is_console)" and the handle type shouldn't change between lines/iterations, so why bother recomputing it every time?)

Oct. 4, 2011

Re: [1/4] cmd: Avoid checking handle type when already known in WCMD_ReadFile

by Eric Pouech

Le 4 octobre 2011 13:40, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : > 2011/10/4 Dan Kegel <dank(a)kegel.com>: > > + * handle_type: type of hIn handle > > + * 0 if file, 1 if console, anything else if unknown > (autodetect) > > > > I suspect you want an enum for that. > > Well I thought about that, but found it a bit overkill for such a > limited set of possible values. > Also, if I used sthg like > > enum CMD_HANDLE_TYPE { > CMD_HT_FILE = 0, > CMD_HT_CONSOLE = 1, > CMD_HT_UNKNOWN = 2 > } > > again, this is not needed (passing all thoses CMD_HT bits) static inline BOOL is_console_handle(HANDLE h) {return ((DWORD_PTR)h) & 3 == 3;} will test every handle and tell whether it's a console or a regular (file, pipe...) handle A+ > -- > -- > Eric Pouech >

Oct. 4, 2011

Re: Vista/w2k8/w7 users, please test mmdevapi base render test

by Henri Verbeet

On 4 October 2011 14:11, Paul Chitescu <paulc(a)voip.null.ro> wrote: > On Tuesday 04 October 2011 02:40:49 pm Joerg-Cyril.Hoehle(a)t-systems.com wrote: >> [...] >> - sound card without capture (does "capture only" exist?) >> [...] > > Yes, there are at least some webcams with built-in USB microphone. > There are also e.g. USB table microphones.

Oct. 4, 2011

Re: Regression by author list?

by Reece Dunn

On 4 October 2011 13:29, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Hi > > Where do we find that list of regressions by author, that was in > Alexandre's keynote at Wineconf? http://source.winehq.org/regressions - Reece

Oct. 4, 2011

Regression by author list?

by Damjan Jovanovic

Hi Where do we find that list of regressions by author, that was in Alexandre's keynote at Wineconf? Thank you Damjan Jovanovic

Oct. 4, 2011

Re: Vista/w2k8/w7 users, please test mmdevapi base render test

by Paul Chitescu

On Tuesday 04 October 2011 02:40:49 pm Joerg-Cyril.Hoehle(a)t-systems.com wrote: > [...] > - sound card without capture (does "capture only" exist?) > [...] Yes, there are at least some webcams with built-in USB microphone. Paul

Oct. 4, 2011

Re: [1/4] cmd: Avoid checking handle type when already known in WCMD_ReadFile

by Dan Kegel

2011/10/4 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > Well I thought about that, but found it a bit overkill for such a > limited set of possible values. > Also, if I used sthg like > > enum CMD_HANDLE_TYPE { > CMD_HT_FILE = 0, > CMD_HT_CONSOLE = 1, > CMD_HT_UNKNOWN = 2 > } > > , I'd have to add error checking for unknown parameters passed to > WCMD_ReadFile, or never check for CMD_HT_UNKNOWN, and just use it as > default value. > So TBH I don't think an enum is really necessary (especially since > it's just a corner case; all "similar" functions use a BOOL > is_console_handle, covering cases 0 and 1. I wouldn't want to change > those) It's not overkill, and you don't have to add error checking, the compiler will or should do that as long as you make all the types that enum. Really, the annoying part is the magic opencoded constants. Those will set off alarm bells in anyone reviewing the code.

Oct. 4, 2011

Re: [1/4] cmd: Avoid checking handle type when already known in WCMD_ReadFile

by Frédéric Delanoy

2011/10/4 Dan Kegel <dank(a)kegel.com>: > + * handle_type: type of hIn handle > + * 0 if file, 1 if console, anything else if unknown (autodetect) > > I suspect you want an enum for that. Well I thought about that, but found it a bit overkill for such a limited set of possible values. Also, if I used sthg like enum CMD_HANDLE_TYPE { CMD_HT_FILE = 0, CMD_HT_CONSOLE = 1, CMD_HT_UNKNOWN = 2 } , I'd have to add error checking for unknown parameters passed to WCMD_ReadFile, or never check for CMD_HT_UNKNOWN, and just use it as default value. So TBH I don't think an enum is really necessary (especially since it's just a corner case; all "similar" functions use a BOOL is_console_handle, covering cases 0 and 1. I wouldn't want to change those)

Oct. 4, 2011

Vista/w2k8/w7 users, please test mmdevapi base render test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, please run on native machines my newest mmdevapi tests at http://testbot.winehq.org/JobDetails.pl?Key=14691 You'll find both patch and .exe there. I've split my former test in two. This is part one, without the GetPosition tests. WINETEST_DEBUG does not matter in part 1. wine mmdevapi_test.exe render I'd be pleased if you could test this with various configurations: - with exclusive mode disabled in the MS control panel - with non-standard settings in the MS control panel - with 5:1 audio chosen (if possible) in the MS control panel - audio entirely disabled - sound card without capture (does "capture only" exist?) Please report any failures such that I can later submit this part one test, given confidence that it's been tested with a variety of configurations. Thank you for testing, Jörg Höhle

Oct. 4, 2011

Re: unable to compile wine from latest git

by Vijay Kiran Kamuju

On Tue, Oct 4, 2011 at 3:52 AM, Austin English <austinenglish(a)gmail.com> wrote: > On Mon, Oct 3, 2011 at 12:24, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: >> Hi, >> >> This is on fedora 15. I have just downloaded the fresh git, and >> attempting the my first build on this system. > > Please bottom-post on wine mailing lists. > >> The source code is downloaded to a usb drive which is FAT32 formatted. > > Looking at $TOPDIR/Makefile: > __builddeps__: dlls/libd3dcompiler.def > dlls/libd3dcompiler.def: dlls/d3dcompiler_43/libd3dcompiler.def > $(RM) $@ && $(LN_S) d3dcompiler_43/libd3dcompiler.def $@ > > LN_S is `ln -s`, which will fail on a fat32 file system. > > You need to build on a file system that supports symlinks (ext3/4, > xfs, nfs, etc.). > > -- > -Austin > Well, if you see configure script. There is an alternative for "ln -s", and it is "cp -p" which is is used for MSYS and DJPP based builds. I modified the configure and it worked I will try to send that patch for review may be by evening. ----- Vijay

Oct. 4, 2011

Re: unable to compile wine from latest git

by Austin English

On Mon, Oct 3, 2011 at 12:24, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Hi, > > This is on fedora 15. I have just downloaded the fresh git, and > attempting the my first build on this system. Please bottom-post on wine mailing lists. > The source code is downloaded to a usb drive which is FAT32 formatted. Looking at $TOPDIR/Makefile: __builddeps__: dlls/libd3dcompiler.def dlls/libd3dcompiler.def: dlls/d3dcompiler_43/libd3dcompiler.def $(RM) $@ && $(LN_S) d3dcompiler_43/libd3dcompiler.def $@ LN_S is `ln -s`, which will fail on a fat32 file system. You need to build on a file system that supports symlinks (ext3/4, xfs, nfs, etc.). -- -Austin

Oct. 4, 2011

re: [1/3] kernel32/tests: Test K32GetProcessImageFileNameA() and improve the QueryFullProcessImageNameA() tests.

by Dan Kegel

Build fails here with -Werror: process.c: In function ‘test_GetProcessImageFileNameA’: process.c:1646: error: unused variable ‘image’ You seem to have two copies of that variable, one shadowing the other?

Oct. 4, 2011

Re: unable to compile wine from latest git

by Vijay Kiran Kamuju

Hi, This is on fedora 15. I have just downloaded the fresh git, and attempting the my first build on this system. The source code is downloaded to a usb drive which is FAT32 formatted. The hardware is a Compaq laptop with core duo processor and 2 G RAM. Do you need any more details. Thanks, Vijay On Mon, Oct 3, 2011 at 8:17 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Mon, Oct 3, 2011 at 05:03, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: >> Hi, >> >> I just downloaded the git and tried compile it. >> >> I just issued `make` command after doing `./configure` >> >> But it gave the below errors: >> make[1]: Leaving directory `/media/PENDRIVE/devel/repo/wine/tools/wrc' > > What type of file system is that on? > > -- > -Austin >

Oct. 3, 2011

Re: unable to compile wine from latest git

by Austin English

On Mon, Oct 3, 2011 at 05:03, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Hi, > > I just downloaded the git and tried compile it. > > I just issued `make` command after doing `./configure` > > But it gave the below errors: > make[1]: Leaving directory `/media/PENDRIVE/devel/repo/wine/tools/wrc' What type of file system is that on? -- -Austin

Oct. 3, 2011

Re: unable to compile wine from latest git

by Vijay Kiran Kamuju

On Mon, Oct 3, 2011 at 2:15 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > On Mon, Oct 3, 2011 at 09:03, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: >> Hi, >> >> I just downloaded the git and tried compile it. >> >> I just issued `make` command after doing `./configure` >> ... >> Since the build of wine has changed a bit, i am unable to understand >> how to fix this issue. > > Try make distclean && ./configure && make depend && make > It did not work, same error > Try this too: > git clean -fd > I did it and then I tried 'make' still the same error. Now doing the distclean and recompling. Still the same can this be a file system issue. (i do not think it is) I can see that there is libd3dcompiler.def file.... > Taken from: http://wine.1045685.n5.nabble.com/Latest-Git-Fails-tools-install-td1838892.… > -------- Vijay

Oct. 3, 2011

Re: unable to compile wine from latest git

by Bruno Jesus

On Mon, Oct 3, 2011 at 09:03, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Hi, > > I just downloaded the git and tried compile it. > > I just issued `make` command after doing `./configure` > ... > Since the build of wine has changed a bit, i am unable to understand > how to fix this issue. Try make distclean && ./configure && make depend && make Try this too: git clean -fd Taken from: http://wine.1045685.n5.nabble.com/Latest-Git-Fails-tools-install-td1838892.…

Oct. 3, 2011

unable to compile wine from latest git

by Vijay Kiran Kamuju

Hi, I just downloaded the git and tried compile it. I just issued `make` command after doing `./configure` But it gave the below errors: make[1]: Leaving directory `/media/PENDRIVE/devel/repo/wine/tools/wrc' make[1]: Entering directory `/media/PENDRIVE/devel/repo/wine/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/media/PENDRIVE/devel/repo/wine/include' make[1]: Entering directory `/media/PENDRIVE/devel/repo/wine/dlls/adsiid' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/media/PENDRIVE/devel/repo/wine/dlls/adsiid' rm -f dlls/libd3dcompiler.def && cp -p d3dcompiler_43/libd3dcompiler.def dlls/libd3dcompiler.def cp: cannot stat `d3dcompiler_43/libd3dcompiler.def': No such file or directory make: *** [dlls/libd3dcompiler.def] Error 1 Since the build of wine has changed a bit, i am unable to understand how to fix this issue. Thanks, Vijay

Oct. 3, 2011

Re: [1/4] winscard: implementation

by André Hentschel

Am 03.10.2011 09:31, schrieb Vincent Hardy: > First submitted on wine-devel and modified following comments from Marcus Meissner (MAX_ATR_SIZE / bytecount). > OK, some notes: "winscard: implementation" is a very bad name for a patch, especially for 4. Splitting the patches is a good idea, but you need to split it different (you are adding dead code). In the first patch you might want to add the configure.ac and library loading stuff together with only the things needed for e.g. SCardListReadersA (why no SCardListReadersW?) and then e.g. a patch for every new function. I didn't looked at the code, but i want to remember you to read http://wiki.winehq.org/SubmittingPatches -- Best Regards, André Hentschel

Oct. 3, 2011

Re: Alexandre's keynote

by Maarten Lankhorst

Hey JWhite, On 10/02/2011 12:10 AM, Jeremy White wrote: > Thanks to Jon Parshall's hard work, we have Alexandre's keynote available here: > > http://www.youtube.com/watch?v=2rdDvMonTnQ > > Remember to have your libation at hand so you can play the game... <grin> > > Cheers, > > Jeremy > > Nice work, is there a pdf available too? :) ~Maarten

Oct. 3, 2011

Re: Alexandre's keynote

by Marcus Meissner

On Sat, Oct 01, 2011 at 05:10:31PM -0500, Jeremy White wrote: > Thanks to Jon Parshall's hard work, we have Alexandre's keynote > available here: > > http://www.youtube.com/watch?v=2rdDvMonTnQ > > Remember to have your libation at hand so you can play the game... <grin> Thanks for doing that :) Interesting new regression by git commit overview and fortunately I just have 1 yet. ;) Ciao, Marcus

Oct. 3, 2011

Re: Alexandre's keynote

by Francois Gouget

On Sun, 2 Oct 2011, Francois Gouget wrote: [...] > And here are the WineConf photos: > http://fgouget.free.fr/tmp/201110-WineConf/ > > Currently from the keynote and presentations. Now with the group photo and some improved developper presentation photos. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ E-Voting: It's not the people who vote that count. It's the people who count the votes.

Oct. 2, 2011

Re: Alexandre's keynote

by Erich Hoover

On Sun, Oct 2, 2011 at 9:05 AM, Austin English <austinenglish(a)gmail.com> wrote: > ... > take a sip of your favorite beverage ;). Did you guys find a resolution for Bug #27162? Erich Hoover ehoover(a)mines.edu

Oct. 2, 2011

Re: Alexandre's keynote

by Austin English

On Sat, Oct 1, 2011 at 17:10, Jeremy White <jwhite(a)codeweavers.com> wrote: > Remember to have your libation at hand so you can play the game... <grin> For those following along at home, anytime you hear: 'DIB Engine' 'regression' 'lines of code' take a sip of your favorite beverage ;). -- -Austin

Oct. 2, 2011

Re: Alexandre's keynote

by Francois Gouget

On Sat, 1 Oct 2011, Jeremy White wrote: > Thanks to Jon Parshall's hard work, we have Alexandre's keynote available > here: > > http://www.youtube.com/watch?v=2rdDvMonTnQ And here are the WineConf photos: http://fgouget.free.fr/tmp/201110-WineConf/ Currently from the keynote and presentations. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.

Oct. 2, 2011

Alexandre's keynote

by Jeremy White

Thanks to Jon Parshall's hard work, we have Alexandre's keynote available here: http://www.youtube.com/watch?v=2rdDvMonTnQ Remember to have your libation at hand so you can play the game... <grin> Cheers, Jeremy

Oct. 1, 2011

Re: [po]updated korean resource(2011-09-30)

by Francois Gouget

On Fri, 30 Sep 2011, Hwang YunSong(황윤성) wrote: [...] > #: winecfg.rc:88 > -#, fuzzy > msgid "(None)" > -msgstr "없음" > +msgstr "(없음)" I think you're missing a closing parenthesis here. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ question = ( to ) ? be : ! be; -- Wm. Shakespeare

Oct. 1, 2011

Script for bisecting conformance test failures

by Francois Gouget

Would something like this be useful to include in Wine? If that's deemed interesting I can clean it up and submit it. I'm posting it here early in case it's useful for WineConf. It's a tool which you can use with git bisect to find the patch that causes a regression in a conformance test. It's used like this: git bisect start <bad> <good> git bisect run ./tools/testbisect dlls/gdi32/tests bitmap Come back a bit later and you have the bad patch. It can also be used with flaky tests by specifying the number of times to run a test. So if a test fails in 30% of the time you could only consider that it works if it succeeds 10 times in a row. You can even grep for a specific error if the test has other errors you don't care about. Finally you can also use it without git just to figure out if a test is flaky or not. For instance: $ ./tools/testbisect dlls/random/tests flaky 100 100 Failed 42 time(s) in 100 run(s) -> definitely flaky -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?

Oct. 1, 2011

Re: [PATCH 2/2] cmd: Handle truncation for console reads

by Frédéric Delanoy

2011/10/1 Dan Kegel <dank(a)kegel.com>: > What's motivating this change? Are you quite sure you know how > ReadConsole behaves? > > I bet one could write a test for this that used SendInput to > send keystrokes to be read by ReadConsole, and > verify the end of line and end of buffer behavior... Motivation for this change is a verification/fix of the current truncation reporting/handling. I checked with debugger and various parameters (including changing noChars/MAXSTRING) and it's how it currently behaves. Error messages for truncation are already done in wcmdmain.c around line 1840 /* Handle truncated input - issue warning */ if (strlenW(extraSpace) == MAXSTRING -1) { WCMD_output_asis(WCMD_LoadMessage(WCMD_TRUNCATEDLINE)); WCMD_output_asis(extraSpace); WCMD_output_asis(newline); } Now cmd just outputs a warning but continues on truncated input (don't know if windows does the same)

Oct. 1, 2011

Re: [PATCH 1/2] cmd: Improve WCMD_fgets documentation

by Frédéric Delanoy

2011/10/1 Dan Kegel <dank(a)kegel.com>: > + * We can't use the native f* functions because of the filename > syntax differences > + * between DOS and Unix. > > That doesn't belong in a function comment; it's > an implementation detail that belongs, at most, > inside the function. Yeah true. I simply copied it over from previous doc. Might move it/delete part of it

Oct. 1, 2011

re: [PATCH 2/2] cmd: Handle truncation for console reads

by Dan Kegel

What's motivating this change? Are you quite sure you know how ReadConsole behaves? I bet one could write a test for this that used SendInput to send keystrokes to be read by ReadConsole, and verify the end of line and end of buffer behavior...

Oct. 1, 2011

re: [PATCH 1/2] cmd: Improve WCMD_fgets documentation

by Dan Kegel

+ * We can't use the native f* functions because of the filename syntax differences + * between DOS and Unix. That doesn't belong in a function comment; it's an implementation detail that belongs, at most, inside the function.

Oct. 1, 2011

Re: Favorite bug: deadlock preventing backtraces?

by Dan Kegel

On Fri, Sep 30, 2011 at 1:29 AM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > On 09/29/2011 06:00 AM, Dan Kegel wrote: >> On one of my boxes, if I run winmm/midi.ok in a loop, it will >> eventually deadlock/crash >> ( http://bugs.winehq.org/show_bug.cgi?id=28388 ): > > I'm wondering if it's because of the lock in virtual_handle_stack_fault, what if you remove that? :P I did write a nice script to do a btall automatically when the lockup happens. With git, on my e8400, with WINEDEBUG=warn+heap, I get roughly 4 lockups per 100 runs. Under the same conditions, but without the lock in virtual_handle_stack_fault, I get ... roughly 4 lockups per 100 runs. And the stacks look the same.

Oct. 1, 2011