- wine-devel - winehq.org

D3DXCreatePolygon
by paulo lesgaz 26 Oct '11

26 Oct '11

Hello, any problem with my D3DXCreatePolygon patch? Thanks in advance. David

2 1

Re: Wine's configure script when cross-compiling
by Roger Cruz 26 Oct '11

26 Oct '11

Hi Dan, So far that autoconf script has been a nightmare. It doesn't include string.h (where strerror.h is defined) directly BUT I did include unistd.h in order to get autoconf to find getpagesize(). I'm building under the Android development which uses GCC for cross-compiling for ARM. I decided to continue making progress on my project by taking autoconf's output (config.h) and hand tweaking the #define HAVE_xxx functions that I know the cross-compile environment provide. I get a lot farther now but a new error arises, for which I have no clues yet on how to fix. make[1]: Entering directory `/development/rcruz/sandbox/wine-builds/winearm3/dlls/acledit' arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/acledit -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o main.o /home/rcruz/sandbox/wine-dev-branch/dlls/acledit/main.c /home/rcruz/sandbox/wine-builds/wine32-dev/tools/winegcc/winegcc -b arm-linux-androideabi -B/home/rcruz/sandbox/wine-builds/wine32-dev/tools/winebuild --sysroot=../.. -fasynchronous-unwind-tables -shared /home/rcruz/sandbox/wine-dev-branch/dlls/acledit/acledit.spec main.o -o acledit.dll.so ../../libs/port/libwine_port.a ../../dlls/winecrt0/libwinecrt0.a(dll_entry.o): In function `__wine_spec_dll_entry': /home/rcruz/sandbox/wine-dev-branch/dlls/winecrt0/dll_entry.c:42: undefined reference to `_fini' /home/rcruz/sandbox/wine-dev-branch/dlls/winecrt0/dll_entry.c:37: undefined reference to `_init' /home/rcruz/sandbox/tools/toolchain9/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: acledit.dll.so: hidden symbol `_init' isn't defined /home/rcruz/sandbox/tools/toolchain9/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status winegcc: arm-linux-androideabi-gcc failed make[1]: *** [acledit.dll.so] Error 2 make[1]: Leaving directory `/development/rcruz/sandbox/wine-builds/winearm3/dlls/acledit' ________________________________ From: Dan Kegel <dank(a)kegel.com> To: wine-devel(a)winehq.org Cc: roger_r_cruz(a)yahoo.com Sent: Wednesday, October 26, 2011 12:49 AM Subject: re: Wine's configure script when cross-compiling Welcome to the wonderful world of autoconf! > The code that generates conftest.c does not provide for an argument to strerror. Why doesn't it? And how does the configure script succeed when compiling for x86? If I recall correctly: Because conftest.c doesn't include the .h file that declares strerror(), and C doesn't have typesafe linkage, checking for the presence of a function by linking to it with a totally bogus call with no arguments should work fine. It's not clear why the compiler is complaining - did it somehow see a .h file that declared strerror()? What compiler are you using?

1 0

re: Wine's configure script when cross-compiling
by Dan Kegel 26 Oct '11

26 Oct '11

Welcome to the wonderful world of autoconf! > The code that generates conftest.c does not provide for an argument to strerror. Why doesn't it? And how does the configure script succeed when compiling for x86? If I recall correctly: Because conftest.c doesn't include the .h file that declares strerror(), and C doesn't have typesafe linkage, checking for the presence of a function by linking to it with a totally bogus call with no arguments should work fine. It's not clear why the compiler is complaining - did it somehow see a .h file that declared strerror()? What compiler are you using?

1 0

Wine's configure script when cross-compiling
by Roger Cruz 26 Oct '11

26 Oct '11

I'm still attempting to cross-compile Wine to ARM and I'm running into many compile errors right off the bat. I have tracked these down to the lack of HAVE_xxx in the config.h file generated from configure script. Many of the functions being checked from this list fail when they are compiled by ac_fn_c_check_func () for ac_func in \ _finite \ _isnan \ _pclose \ _popen \ ... snprintf \ spawnvp \ statfs \ statvfs \ strcasecmp \ strdup \ strerror \ One example of a failure is strerror which does not compile because it is missing one argument conftest.c:165: error: too few arguments to function 'strerror' The code that generates conftest.c does not provide for an argument to strerror. Why doesn't it? And how does the configure script succeed when compiling for x86? int main () { return $2 (); ; return 0; } Thanks in advance Roger R. Cruz

1 0

Regression testing breakthrough
by Damjan Jovanovic 25 Oct '11

25 Oct '11

Hi Since the beginning, I've had issues with regression testing. Despite the fact it's very useful, it takes forever, it's easy to make a mistake (especially during "reverse regression testing"), users find it too long and technical, and only a small minority of regressions are ever bisected. And several patches need backporting to allow older versions of Wine to compile and run on today's make, gcc, and libraries - this is the case even for the 1.0.x releases from less than 3 years ago! The problem is of course compilation. "configure" takes at least 40 seconds, without any way to speed it up on multi-core CPUs. "make" takes > 5 minutes, and it's only taking longer as Wine gets bigger. Compilation is fundamentally complex and technical to users. But what if we had precompiled binaries, and regression testing consisted of just running different versions of Wine? Wine binaries take up about 122 MB and take over 5 minutes to compile. There's now 35770 commits between 36def4af0ca85a1d0e66b5207056775bcb3b09ff (Release 1.0) and "origin". That's about 4.4 terrabytes of storage and over 4 months of compilation, if each of those versions had to be compiled and installed into its own prefix, way beyond what most users are willing or able to store or do. Most patches however end up affecting only a few binary files in the end, and compiling successive versions allows "make" to be very quick. So I've written a tool that compiles Wine and adds each commit's binaries into a Git repository. It knows how to compile old versions of Wine (currently as far back as 1.0). It knows that commits affecting only ANNOUNCE, .gitignore, and files in dll/ or programs/ ending with .c and such don't need to go through the endlessly slow "configure", only "make". It is stateless: if interrupted, it can resume from the last successful commit. It works around bugs in GNU make (you won't believe how many there are...). This tool compiled all 35000 or so commits from Wine 1.0 to around 4th October 2011 in only 7 days, generating a Git repository of Wine binaries that's only 26 gigabytes in size. Regression testing with binaries is a pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 step regression in just 20 minutes, and most of that time was spent running the application and dealing with 2 X-server crashes. I haven't figured out how to make the binaries available to users. Few users can clone a 26 gigabyte repository, and even fewer places can serve that much to multiple users. Maybe Git can compress it further? The other idea I had is that users should be able to regression test through a GUI tool. Maybe the GUI tool can just download and run the +/- 122 MB binary snapshots for specific commits, instead of having the entire binary repository locally? Any other ideas? Would you like to see this tool? Can I send an attachment with it? Thank you Damjan Jovanovic

12 22

Re: [PATCH] kernel32: Output message to stderr in UTF-8
by Alex Henrie 25 Oct '11

25 Oct '11

Hello, Last week I submitted a patch to make kernel32 output an error message in UTF-8 rather than the current codepage. This fixed a bug in which the command "wine /." would produce a garbled error message in languages other than English. However, thinking about this some more, I'm not sure that my patch fixes the bug correctly. I made WideCharToMultiByte use CP_UTF8 instead of CP_ACP, but reading more about the codepage setting, I think I should have used either CP_UNIXCP or CP_OEMCP. Could anyone help clarify which should be used? -Alex

2 1

Re: [PATCH 2/5] d3d8/tests: Add a small test for multisampled CopyRects().
by Francois Gouget 25 Oct '11

25 Oct '11

commit fd1afd24f4af20646ce0f3a7ac2064e8e49b1e7d Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Wed Oct 19 22:03:11 2011 +0200 d3d8/tests: Add a small test for multisampled CopyRects(). This commit causes the d3d8:visual to crash on my desktop (Debian Testing, 9600GT, 285.05.09-1 proprietary driver): wine: Unhandled stack overflow at address 0x7e3ab8bf (thread 0009), starting debugger... err:seh:setup_exception_record stack overflow 1100 bytes in thread 0009 eip 7ef8952b esp 00240ee4 stack 0x240000-0x241000-0x340000 The call that causes the crash is: hr = IDirect3DDevice8_CopyRects(device, rt, NULL, 0, readback, NULL); The stack trace seems to point towards an out of hand recursion problem that eventually causes a stack overrun: Backtrace: =>0 0x7e3a7a32 d3dfmt_get_conv+0x12(surface=0x161728, need_alpha_ck=0x1, use_texturing=0x1, format=0x242074, convert=0x24210c) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:4372] in wined3d (0x00242018) 1 0x7e3b05ee surface_load_texture+0xcd(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5953] in wined3d (0x00242128) 2 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242258) 3 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242388) 4 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242498) 5 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x002425c8) 6 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x002426f8) 7 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242808) 8 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242938) 9 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242a68) 10 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242b78) 11 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242ca8) 12 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242dd8) 13 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242ee8) 14 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00243018) 15 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00243148) 16 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00243258) 17 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00243388) 18 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x002434b8) 19 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x002435c8) [...] -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

1 0

D3DXCreatePolygon
by David Adam 25 Oct '11

25 Oct '11

Any problem with my D3DXCreatePolygon patch? Thanks in advance. David

1 0

Re: riched20: do not return incorrect values from ME_CharFromPoint[Cursor]
by Alexandre Julliard 24 Oct '11

24 Oct '11

Thomas Faber <thfabba(a)gmx.de> writes: > Windows's version of GetTextExtentExPointW, which is called in that function, > returns a value of 1 in this case (Wine's does not, which would appear to be > a bug), leading to the "i<len" assertion failure if there is no text in the > control. > The patch fixes riched20 to correctly handle either behavior by > adding a fast path for cx <= 0 (the function obviously needs to return 0 in > the cx == 0 case too, so it can skip the calculation). You should not be adding workarounds for Wine bugs, the bugs need to be fixed instead. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: riched20: explicitly cast WPARAM to character types
by Michael Stefaniuc 24 Oct '11

24 Oct '11

On 10/22/2011 10:38 PM, Thomas Faber wrote: > This makes the use of casts more consistent and shows the conversion > from WPARAM to CHAR/WCHAR is intentional for WM_CHAR/EM_SETPASSWORDCHAR. > Also fixes two MSVC warnings. To make it consistent remove the WCHAR cast 3 lines above. Casts are *not* there to show a conversion is intentional. They tell the compiler to STFU and to the human reader they mean "*WARNING* doing something odd here". So don't cry wolf when there's no wolf in sight. No clue anyway why MSVC even warns, integer to integer conversions are allowed. If you still want to get rid of those warnings the fix would be to change the type of charCode to WCHAR. To correctly unmarshal the WCHAR out of the WPARAM when passing it to ME_Char() use LOWORD(). bye michael

3 2

Re: [PATCH 4/5] wined3d: Refuse to create a D3D10 wined3d device if it is not supported by the GPU.
by Henri Verbeet 24 Oct '11

24 Oct '11

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (wined3d->dxVersion >= 10 && (shader_caps.VertexShaderVersion < WINED3DVS_VERSION(4,0) > + || shader_caps.PixelShaderVersion < WINED3DPS_VERSION(4,0))) This should probably be handled in dxgi_device_init().

1 0

Re: [PATCH 2/5] d3d9: Limit VS/PS reported version.
by Henri Verbeet 24 Oct '11

24 Oct '11

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (pCaps->VertexShaderVersion > D3DVS_VERSION(3,0)) > + pCaps->VertexShaderVersion = D3DVS_VERSION(3,0); > + if (pCaps->PixelShaderVersion > D3DPS_VERSION(3,0)) > + pCaps->PixelShaderVersion = D3DPS_VERSION(3,0); > + This should probably go into filter_caps().

1 0

Re: [PATCH 1/5] d3d8: Limit VS/PS reported version.
by Henri Verbeet 24 Oct '11

24 Oct '11

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (pCaps->VertexShaderVersion > D3DVS_VERSION(1,1)) > + pCaps->VertexShaderVersion = D3DVS_VERSION(1,1); > + if (pCaps->PixelShaderVersion > D3DPS_VERSION(1,4)) > + pCaps->PixelShaderVersion = D3DPS_VERSION(1,4); > + fixup_caps() should already do this.

1 0

Re: [PATCH 5/7] msxml3: Make positions returned by ISAXLocator compatible with msxml6
by Nikolay Sivov 24 Oct '11

24 Oct '11

On 10/24/2011 14:55, Piotr Caban wrote: > --- > dlls/msxml3/factory.c | 8 ++++- > dlls/msxml3/msxml_private.h | 1 + > dlls/msxml3/saxreader.c | 62 > +++++++++++++++++++++++++++++++++++++++--- > 3 files changed, 64 insertions(+), 7 deletions(-) > > > > static ClassFactory saxreadcf = { {&ClassFactoryVtbl }, SAXXMLReader_create }; > +static ClassFactory saxread6cf = { {&ClassFactoryVtbl }, SAXXMLReader6_create }; > static ClassFactory httpreqcf = { {&ClassFactoryVtbl }, XMLHTTPRequest_create }; Such version dependent behaviour is handled currently with additional argument of MSXML_VERSION enum type. It's better to do it the same way in SAX too, to be consistent.

1 0

Re: [1/2] d3dx9: Implemented non-equal declaration support in CloneMesh.
by Matteo Bruni 24 Oct '11

24 Oct '11

Hi Michael, + for (i = 0; declaration1[i].Stream != 0xff; i++) + { + if (memcmp(&declaration1[i], &declaration2[i], sizeof(*declaration1))) Doesn't that loop need to stop at the first end marker of either declaration? I.e. may the first vertex declaration be longer than the second one?

2 2

winealsa: 6 Channel Audio
by Jonathan McCrohan 24 Oct '11

24 Oct '11

Hi, Using foobar2000 (Wine 1.3.31) to output 6 channel audio via WASAPI, I get an error in foobar2000, and the following Wine errors in the terminal: fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels However, when using a patched version of Wine with hardcoded support for 6 channel audio, foobar2000 6 channel audio works correctly (patch attached). While this works, it is just a hack and doesn't fix the underlying issue; the additional 9,994 audio channels. This also merely just changes the error message from 2s channel to 6 channels: fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 6 channels Would someone with a better knowledge of Wine and/or ALSA be able to assist me in tracking down the source of this bug? Thanks, Jonathan

3 4

Patch resend etiquette
by Erich Hoover 24 Oct '11

24 Oct '11

How long should one wait to resend patches marked as "New" on the patch list? It seems that once they've gone "far enough" down on the list that there's no chance they'll be looked at. Thanks in advance for your advice. Erich Hoover ehoover(a)mines.edu

3 3

Re: vbscript: Fixed local variable count calculation
by Marvin 24 Oct '11

24 Oct '11

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=15088 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

re: winmm: Avoid casting return value of Heap(Re)Alloc calls.
by Dan Kegel 23 Oct '11

23 Oct '11

Doesn't build here: ccache gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_WINMM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O0 -Werror -Wno-unused-but-set-variable -Wno-unused-but-set-parameter -o lolvldrv.o lolvldrv.c lolvldrv.c: In function 'MMDRV_InitPerType': lolvldrv.c:406:13: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] lolvldrv.c:411:13: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] cc1: all warnings being treated as errors make[1]: Leaving directory `/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winmm' make[1]: *** [lolvldrv.o] Error 1 make: *** [dlls/winmm] Error 2 http://buildbot.kegel.com/builders/runtests-default/builds/874

5 8

Re: [3/6] dinput: SetActionMap saving simple configurations to an .ini file
by Vitaliy Margolen 23 Oct '11

23 Oct '11

Few nit picks. On 10/22/2011 02:53 PM, Lucas Fialho Zawacki wrote: > +static void _write_private_profile_intW(const char *format, WCHAR* section, WCHAR* key, int value, WCHAR* file) > +{ > + WCHAR* value_str = heap_printfW(format, value); Here and everywhere else you not checking if memory allocation succeeded. > + WCHAR path[] = { > + '%','C','o','m','m','o','n','P','r','o','g','r','a','m','F','i','l','e','s','%','\\', > + 'D','i','r','e','c','t','X','\\', > + 'D','i','r','e','c','t','I','n','p','u','t','\\', > + 'U','s','e','r',' ','M','a','p','s','\0'}; Missing static const qualifiers. Also the above directory does not exists and you not explicitly creating it. > + guid_strA = debugstr_guid(&lpdiaf->guidActionMap); > + guid_size = MultiByteToWideChar(CP_ACP, 0, guid_strA, -1, NULL, 0); I'm not sure debug function is ok to be used in the regular code. Also, if need it as unicode why not print it as unicode from the beginning? > + IDirectInputDevice_GetDeviceInfo(&This->IDirectInputDevice8W_iface, &didevi); You should use IDirectInputDevice8W_from_impl() function instead of directly accessing internals. > + memcpy(username, find_data.cFileName, (end - find_data.cFileName + 1) * sizeof(WCHAR)); No checking for big enough buffer. Assuming that file names are in specified format. Also I'm not exactly sure why do you need a mapping user name anyway? Wine does not support multiple users. The user currently running Wine would be the one created all the files. All this seems to be redundant. Vitaliy.

1 0

Compilation error when cross-compiling Wine to ARM.
by Roger Cruz 23 Oct '11

23 Oct '11

I'm attempting to cross-compile Wine for ARM and during the compilation of the first file, I get the following error about some strings.h routines not being portable. I have tracked this down to the redefinitions for these routines in include/port.h. How do I get around this issue? Is there a certain #define that needs to be enabled to allow me to use the native strings.h without redefinition (namely this #define NO_LIBWINE_PORT). What is the purpose of having these redefined? Any insight would be most welcome. gcc -c -I/home/rcruz/sandbox/dev-branch/tools -I. -I/home/rcruz/sandbox/dev-branch/include -I../include -D__WINESRC__ -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o makedep.o /home/rcruz/sandbox/dev-branch/tools/makedep.c In file included from /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/stdlib.h:42, from /home/rcruz/sandbox/dev-branch/tools/makedep.c:29: /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:49: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ffs_is_not_portable' /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'strcasecmp_is_not_portable' /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'strncasecmp_is_not_portable' Regards, Roger R. Cruz

3 3

Re: riched20: do not return incorrect values from ME_CharFromPoint[Cursor]
by Thomas Faber 23 Oct '11

23 Oct '11

Hi, On 2011-10-22 22:45, Thomas Faber wrote: > Windows's version of GetTextExtentExPointW, which is called in that function, > returns a value of 1 in this case (Wine's does not, which would appear to be > a bug), leading to the "i<len" assertion failure if there is no text in the > control. this description isn't 100% complete (the fix is correct nonetheless). With the help of the corresponding gdi32 tests [1], I can describe it better: The nAvailWidth in a zero-width richedit control will be -2 (as borders are subtracted by the format rect, resulting in an invalid rect, as previously demonstrated), which will be passed as max_extent to GetTextExtentExPointW. Wine's version would return 0 as expected, while Windows's would interpret this as a large unsigned number and return the length of the text (1 in my test case, mIRC). This eventually led to the i<len assertion failing, as i was set to len exactly. I hope this clears up any doubts. Wine's riched20 now works nicely as a replacement for its counterpart. :) Best regards and have a nice Sunday. Tom [1] http://www.winehq.org/pipermail/wine-patches/2011-October/108186.html

1 0

Re: 80245: riched20/tests: test format rect adaption to window size and behavior with zero-sized windows
by Dan Kegel 22 Oct '11

22 Oct '11

Fails to build here... On Oct 22, 2011 1:48 PM, <buildbot(a)kegel.com> wrote: This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/898 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed shell_2 Errors: editor.c: In function 'test_format_rect': editor.c:6369:5: error: passing argument 4 of 'SendMessageA' makes integer from pointer without a cast [-Werror] make[1]: *** [editor.o] Error 1 make: *** [dlls/riched20/tests] Error 2 make: *** Waiting for unfinished jobs.... _______________________________________________ wine-tests-results mailing list wine-tests-results(a)winehq.org http://www.winehq.org/mailman/listinfo/wine-tests-results

2 1

Re: msctf: increase buffer to have room for full key
by Austin English 22 Oct '11

22 Oct '11

On Fri, Oct 21, 2011 at 20:26, Aric Stewart <aric(a)codeweavers.com> wrote: > > found by Dan Kegel with Valgrind. > Fixes bug 25826 And Clang :). -- -Austin

1 0

Re: [PATCH 1/5] wined3d: Move the cursor in wined3d_device_set_cursor_position().
by Stefan Dösinger 21 Oct '11

21 Oct '11

Hi, Does this address Alexandre's need for a software cursor, or is this unrelated? In the tests I recommend to test a bigger cursor in addition to the 32x32 cursor to see what happens in situations where Windows falls back to a software cursor. Stefan On Thursday 20 October 2011 12:42:55 Henri Verbeet wrote: > --- > dlls/wined3d/device.c | 8 +++++++- > 1 files changed, 7 insertions(+), 1 deletions(-) > > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 67e50b5..6f43715 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -5251,10 +5251,16 @@ void CDECL > wined3d_device_set_cursor_position(struct wined3d_device *device, > device->xScreenSpace = x_screen_space; > device->yScreenSpace = y_screen_space; > > - /* switch to the software cursor if position diverges from the > hardware one */ if (device->hardwareCursor) > { > POINT pt; > + > + GetCursorPos( &pt ); > + if (x_screen_space == pt.x && y_screen_space == pt.y) > + return; > + SetCursorPos( x_screen_space, y_screen_space ); > + > + /* Switch to the software cursor if position diverges from the > hardware one. */ GetCursorPos( &pt ); > if (x_screen_space != pt.x || y_screen_space != pt.y) > {

2 1

Re: [PATCH 2/2] vbscript: Added remaining week day constants implementations
by Marvin 21 Oct '11

21 Oct '11

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=15047 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/2] vbscript: Added vbSunday constant implementation
by Marvin 21 Oct '11

21 Oct '11

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=15046 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: dpnet/tests: Avoid casting return value of HeapAlloc calls
by Marvin 21 Oct '11

21 Oct '11

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=15042 Your paranoid android. === WNT4WSSP6 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c0000005 at 004013BF === W2KPROSP4 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c0000005 at 004013BF

3 2

Re: 80186: [PATCH 2/2] dinput: Restore checks for DirectX 3 buffer size.
by Dan Kegel 21 Oct '11

21 Oct '11

Hi Vitaliy, could you check on win64? I had a test failure there with your patch. - Dan On Thu, Oct 20, 2011 at 7:49 AM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default-x86_64 while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default-x86_64/builds/769 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine dinput_test.exe.so device.c > device.c:117: Test failed: GetDeviceData() should have failed: 80040207 > device.c:120: Test failed: GetDeviceData() should have failed: 80040207 > device.c:117: Test failed: GetDeviceData() should have failed: 80040207 > device.c:120: Test failed: GetDeviceData() should have failed: 80040207 > device.c:117: Test failed: GetDeviceData() should have failed: 80040207 > device.c:120: Test failed: GetDeviceData() should have failed: 80040207 > device.c:117: Test failed: GetDeviceData() should have failed: 80040207 > device.c:120: Test failed: GetDeviceData() should have failed: 80040207 > make: *** [device.ok] Error 8 > >

3 5

Anyone wants to ban spammer on forum
by Vitaliy Margolen 20 Oct '11

20 Oct '11

So any admins actually watching and want to bad roberbdib3a on forum? Also why aren't every moderator has these rights to block spammers, since we have only one forum. - Vitaliy

10 19

Re: 80200: wininet: add a stub for ShowClientAuthCerts
by Dan Kegel 20 Oct '11

20 Oct '11

Fails to build here? On Thu, Oct 20, 2011 at 3:52 PM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/804 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > internet.c: In function 'ShowClientAuthCerts': > internet.c:4391:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] > make[1]: *** [internet.o] Error 1 > make: *** [dlls/wininet] Error 2 > make: *** Waiting for unfinished jobs.... > >

1 0

Re: attrib: Use FormatMessageW() for better internationalization support.
by Alexandre Julliard 20 Oct '11

20 Oct '11

Francois Gouget <fgouget(a)free.fr> writes: > @@ -72,10 +72,12 @@ static int ATTRIB_wprintf(const WCHAR *format, ...) { > } > > va_start(parms, format); > - len = vsnprintfW(output_bufW, MAX_WRITECONSOLE_SIZE/sizeof(WCHAR), format, parms); > + SetLastError(NO_ERROR); > + len = FormatMessageW(FORMAT_MESSAGE_FROM_STRING, format, 0, 0, output_bufW, > + MAX_WRITECONSOLE_SIZE/sizeof(*output_bufW), &parms); You have to use __ms_va_list with FormatMessage for it to work properly on 64-bit. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: vbscript: Added Global_isNull implementation
by Marvin 20 Oct '11

20 Oct '11

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=15023 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: Regression testing breakthrough
by Hin-Tak Leung 20 Oct '11

20 Oct '11

I have two suggestions - - git clone has a "--depth" option which does a shallow clone (i.e. with some history removed). - you can use "git-archive" to export arbitrary commits out as a tar ball dynamically; there is no need to have store a tar ball permanently. That said, I am doubtful about the usefulness of this in a linux environment, because the system libraries (in the general sense - libjpeg, etc) varies between different linux distros. --- On Wed, 19/10/11, Joel Holdsworth <joel(a)airwebreathe.org.uk> wrote: Alternatively, have you considered doing a .tar.gz of every build snapshot, and placing that on a server somewhere? e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? Then one could write a simple wine regression bisect tool that implements similar semantics to git bisect, but would essentially wrap wget. Then in your server you could have an index file which is a list of the sha commit ids. This would save the user having to clone a 26Gb repository when most of the commits will be irrelevant. Extra bonus points for doing a better job of compressing the small deltas between binaries*, rather than compressing full wine builds. Joel * Are binaries deterministic like this? or do they tend to be completely scrambled? On 18 October 2011 at 09:45 Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Hi > > Since the beginning, I've had issues with regression testing. Despite the > fact it's very useful, it takes forever, it's easy to make a mistake > (especially during "reverse regression testing"), users find it too long and > technical, and only a small minority of regressions are ever bisected. And > several patches need backporting to allow older versions of Wine to compile > and run on today's make, gcc, and libraries - this is the case even for the > 1.0.x releases from less than 3 years ago! > > The problem is of course compilation. "configure" takes at least 40 seconds, > without any way to speed it up on multi-core CPUs. "make" takes > 5 minutes, > and it's only taking longer as Wine gets bigger. Compilation is > fundamentally complex and technical to users. > > But what if we had precompiled binaries, and regression testing consisted of > just running different versions of Wine? > > Wine binaries take up about 122 MB and take over 5 minutes to compile. > There's now 35770 commits between 36def4af0ca85a1d0e66b5207056775bcb3b09ff > (Release 1.0) and "origin". That's about 4.4 terrabytes of storage and over > 4 months of compilation, if each of those versions had to be compiled and > installed into its own prefix, way beyond what most users are willing or > able to store or do. Most patches however end up affecting only a few binary > files in the end, and compiling successive versions allows "make" to be very > quick. > > So I've written a tool that compiles Wine and adds each commit's binaries > into a Git repository. It knows how to compile old versions of Wine > (currently as far back as 1.0). It knows that commits affecting only > ANNOUNCE, .gitignore, and files in dll/ or programs/ ending with .c and such > don't need to go through the endlessly slow "configure", only "make". It is > stateless: if interrupted, it can resume from the last successful commit. It > works around bugs in GNU make (you won't believe how many there are...). > > This tool compiled all 35000 or so commits from Wine 1.0 to around 4th > October 2011 in only 7 days, generating a Git repository of Wine binaries > that's only 26 gigabytes in size. Regression testing with binaries is a > pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 > step regression in just 20 minutes, and most of that time was spent running > the application and dealing with 2 X-server crashes. > > I haven't figured out how to make the binaries available to users. Few users > can clone a 26 gigabyte repository, and even fewer places can serve that > much to multiple users. Maybe Git can compress it further? The other idea I > had is that users should be able to regression test through a GUI tool. > Maybe the GUI tool can just download and run the +/- 122 MB binary snapshots > for specific commits, instead of having the entire binary repository > locally? > > Any other ideas? Would you like to see this tool? Can I send an attachment > with it? > > Thank you > Damjan Jovanovic

1 0

Re: Bug 28791: ensure that dashes value is not 0 for PS_USERSTYLE linestyles
by Alexandre Julliard 19 Oct '11

19 Oct '11

damian dixon <damian.dixon(a)gmail.com> writes: > diff --git a/dlls/winex11.drv/pen.c b/dlls/winex11.drv/pen.c > index b677515..71b1bea 100644 > --- a/dlls/winex11.drv/pen.c > +++ b/dlls/winex11.drv/pen.c > @@ -108,7 +108,7 @@ HPEN X11DRV_SelectPen( PHYSDEV dev, HPEN hpen ) > case PS_USERSTYLE: > physDev->pen.dash_len = min(elp->elpNumEntries, MAX_DASHLEN); > for(i = 0; i < physDev->pen.dash_len ; i++) > - physDev->pen.dashes[i] = min(elp->elpStyleEntry[i], 255); > + physDev->pen.dashes[i] = min(elp->elpStyleEntry[i], 255) ? min(elp->elpStyleEntry[i], 255) : 1; Removing 0 entries (and merging the adjacent entries) would probably be more correct. It could also use some test cases. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 2/2] vbscript: Added Global_IsEmpty implementation
by Marvin 19 Oct '11

19 Oct '11

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=15011 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Fix Bug 23124 with an "ln -s"
by Ken Sharp 19 Oct '11

19 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=23124 Could someone tell me if the attached patch would actually work? It does compile and works correctly with LANG=en_PH.utf-8 but I'm don't know that: 1. Using an "ln -s" is acceptable, nor if it will work given some file systems may be unable to use soft links. 2. I have correctly edited configure, configure.ac and LINGUAS, or even if I need to edit both. Thanks all, Ken

2 1

Re: vbscript: Added Global_IsEmpty implementation
by Marvin 19 Oct '11

19 Oct '11

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=15010 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: vbscript: Added Global_IsEmpty implementation
by Marvin 19 Oct '11

19 Oct '11

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=15010 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: 80141: vbscript: Added Global_IsEmpty implementation
by Dan Kegel 19 Oct '11

19 Oct '11

Hi Jacek, build failed here... did you forget #include <assert.h> ? On Wed, Oct 19, 2011 at 9:56 AM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/715 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > global.c: In function 'Global_IsEmpty': > global.c:281:5: error: implicit declaration of function 'assert' [-Werror=implicit-function-declaration] > make[1]: *** [global.o] Error 1 > make: *** [dlls/vbscript] Error 2 > make: *** Waiting for unfinished jobs.... > >

2 1

Re: 80135: [PATCH 05/10] gdi32: Implement SetPixel.
by Dan Kegel 19 Oct '11

19 Oct '11

Patches 5-7 failed on WINEDEBUG=warn+heap here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so palette.c && touch palette.ok ... palette.c:104: Test failed: getColor=00280000 Might be flaky; patch 8 passed. patches 9 and 10 aren't done testing yet. On Wed, Oct 19, 2011 at 6:18 AM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-heaptest while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-heaptest/builds/673 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine gdi32_test.exe.so palette.c > palette.c:104: Test failed: getColor=00280000 > make: *** [palette.ok] Error 1 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: A TLS packet with unexpected length was received. > >

2 3

Re: [PATCH 1/2] gdi32: Add a string table resource for the translation.
by Alexandre Julliard 19 Oct '11

19 Oct '11

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > @@ -1,7 +1,7 @@ > EXTRADEFS = -D_GDI32_ > MODULE = gdi32.dll > IMPORTLIB = gdi32 > -IMPORTS = advapi32 > +IMPORTS = advapi32 user32 You don't want to import user32 from gdi32. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)
by Henri Verbeet 19 Oct '11

19 Oct '11

On 18 October 2011 12:43, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Changes: Check for dynamic texture support, moved the format-specific tests to > this patch. > That's not really what I meant with "make this part of the test in patch 3/7". The point is that test_lockrect_offset() is about the offset calculation, not so much about what valid rectangles for block based formats are. And it probably wouldn't hurt to run test_partial_block_lock() on the other formats like e.g. ATI2N anyway.

2 5

Re: [PATCH] kernel32: Output message to stderr in UTF-8
by Dmitry Timoshkov 19 Oct '11

19 Oct '11

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > - WideCharToMultiByte( CP_ACP, 0, msgW, -1, msg, sizeof(msg), NULL, NULL ); > + WideCharToMultiByte( CP_UTF8, 0, msgW, -1, msg, sizeof(msg), NULL, NULL ); > MESSAGE( "wine: %s", msg ); Try CP_UNIXCP intead. -- Dmitry.

1 0

Re: 80121: aclocal.m4: fix compiles on systems that don't support ln -s
by Austin English 18 Oct '11

18 Oct '11

On Tue, Oct 18, 2011 at 16:34, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/678 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > make[1]: *** [avifile.dll16.so] Error 2 > make: *** [dlls/avifile.dll16] Error 2 > make: *** Waiting for unfinished jobs.... Hm, worked here, though trying it again with plain make rather than make -jX, fails. Needs more investigation. Please don't commit. -- -Austin

1 0

Odd valgrind warning on ubuntu 11.10 related to set_wm_hints
by Dan Kegel 18 Oct '11

18 Oct '11

I've added a suppression for this already to http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-sup… It looks benign, but it's annoying because the suppression it needs is so wide. I wonder if the gcc bug on ubuntu 11.10 is why there's no useful backtrace there... Syscall param writev(vector[...]) points to uninitialised byte(s) at writev (writev.c:51) by 0x40004: ??? Address 0x4598748 is 160 bytes inside a block of size 16,384 alloc'd at calloc (vg_replace_malloc.c:467) by XOpenDisplay (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0) by x11drv_init_thread_data (x11drv_main.c:689) by thread_init_display (x11drv.h:580) by X11DRV_create_win_data (window.c:2030) by X11DRV_WindowPosChanging (window.c:2429) by set_window_pos (winpos.c:1951) by USER_SetWindowPos (winpos.c:2077) by SetWindowPos (winpos.c:2151) by show_window (winpos.c:1088) by ShowWindow (winpos.c:1186) by WIN_CreateWindowEx (win.c:1498) by CreateWindowExA (win.c:1550) by init (comboex.c:505) by func_comboex (comboex.c:598) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at set_wm_hints (window.c:1128)

1 0

Re: registry keys of serial ports
by Uwe Bonnes 18 Oct '11

18 Oct '11

Hello, while hunting down why a drop down box didn't offer me the serial port I configured, I stumbled across Stefans proposal from Summer 09. The patch still applied cleanly, and after setting up hal and the hal development library, the progarm worked as expected. What is the status of that proposal? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: po: Update English (US) translation
by Alexandre Julliard 18 Oct '11

18 Oct '11

Ken Sharp <kennybobs(a)o2.co.uk> writes: > From 68519bf26da3d912bf92febc13a34ec00cfd7cc4 Mon Sep 17 00:00:00 2001 > From: Ken Sharp <kennybobs(a)o2.co.uk> > Date: Sat, 15 Oct 2011 03:50:43 +0100 > Subject: [PATCH] po: Update English (US) translation There's no translation to update, the rc files are already en_US. If the strings need changing they have to be changed in the rc files. -- Alexandre Julliard julliard(a)winehq.org

4 10

Re: mshtml: Added IHTMLDocument2::elementFromPoint implementation
by Marvin 18 Oct '11

18 Oct '11

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=14979 Your paranoid android. === TEST64_W7SP1 (32 bit htmldoc) === htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer htmldoc.c:4446: Test failed: tag = L"BODY" === TEST64_W7SP1 (64 bit htmldoc) === htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer htmldoc.c:4446: Test failed: tag = L"BODY"

2 1

Re: vbscript: Added support for hex literals not ending with '&'
by Marvin 18 Oct '11

18 Oct '11

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=14970 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel