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

Antw.: signal_arc.c failing to cross-compile
by André Hentschel Oct. 28, 2011

Oct. 28, 2011

Thats not a problem of cross compiling to ARM, but of android. Android is not Linux, not fully. Maybe i can find a solution, but only maybe. BTW all the problems you will find are Android specific. Gesendet mit meinem HTC ----- Reply message ----- Von: "Roger Cruz" <roger_r_cruz(a)yahoo.com> An: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> Betreff: signal_arc.c failing to cross-compile Datum: Fr., Okt. 28, 2011 06:46 Hi Andre et al, Wondering if any of you know how to get around this? The compiler is barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. Thanks in advance, Roger R. Cruz arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -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 signal_arm.o /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: expected declaration specifiers or '...' before 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'restore_context': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: 'sigcontext' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: (Each undeclared identifier is reported only once /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for each function it appears in.) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: expected ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'segv_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'SIGCONTEXT' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'context' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: ISO C90 forbids mixed declarations and code /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: implicit declaration of function 'setup_exception_record' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'trap_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: implicit declaration of function 'save_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'fpe_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: implicit declaration of function 'save_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: implicit declaration of function 'restore_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'int_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'abrt_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'usr1_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too many arguments to function 'restore_context' make[1]: *** [signal_arm.o] Error 1

2 1

Re: ntdll: Make the VirtualProtect tests pass under Wine. Resend.
by Alexandre Julliard Oct. 28, 2011

Oct. 28, 2011

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Updated to current git. > --- > dlls/kernel32/tests/virtual.c | 16 ---------------- > dlls/ntdll/virtual.c | 3 +++ > 2 files changed, 3 insertions(+), 16 deletions(-) This completely breaks Wine here. There are several places where we use WRITECOPY for protections, they would have to be fixed first. -- Alexandre Julliard julliard(a)winehq.org

1 0

signal_arc.c failing to cross-compile
by Roger Cruz Oct. 28, 2011

Oct. 28, 2011

Hi Andre et al, Wondering if any of you know how to get around this? The compiler is barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. Thanks in advance, Roger R. Cruz arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -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 signal_arm.o /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: expected declaration specifiers or '...' before 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'restore_context': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: 'sigcontext' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: (Each undeclared identifier is reported only once /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for each function it appears in.) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: expected ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'segv_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'SIGCONTEXT' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'context' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: ISO C90 forbids mixed declarations and code /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: implicit declaration of function 'setup_exception_record' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'trap_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: implicit declaration of function 'save_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'fpe_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: implicit declaration of function 'save_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: implicit declaration of function 'restore_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'int_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'abrt_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'usr1_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too many arguments to function 'restore_context' make[1]: *** [signal_arm.o] Error 1

2 1

Re: winscard/tests: Add the tests file
by Marvin Oct. 26, 2011

Oct. 26, 2011

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=15123 Your paranoid android. === W2KPROSP4 (32 bit winscard) === winscard.c:53: Test failed: SCardIsValidContext expected SCARD_E_INVALID_HANDLE, received 00000006 winscard.c:64: Test failed: SCardReleaseContext expected SCARD_E_INVALID_HANDLE, received 00000006

2 1

re: [PATCH 1/3] widl: teach widl how to automatically create class factories (resend)
by Dan Kegel Oct. 26, 2011

Oct. 26, 2011

Hi Bernhard, build fails here: widl.o: In function `write_dlldata': /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/tools/widl/widl.c:423: undefined reference to `write_dlldata_list' widl.o: In function `main': /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/tools/widl/widl.c:781: undefined reference to `write_dlldata_list' http://winehq.org:8010/builders/runtests-default/builds/106 Also, patch 2/3 doesn't apply: error: patch failed: Make.rules.in:20 error: Make.rules.in: patch does not apply http://winehq.org:8010/builders/runtests-default/builds/107

2 2

Re: [PATCH 2/2] d3dx9/test: Fix typo.
by Marvin Oct. 26, 2011

Oct. 26, 2011

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=15120 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h
by Jacek Caban Oct. 26, 2011

Oct. 26, 2011

Hi Michael, On 10/26/11 00:30, Michael Stefaniuc wrote: > --- > include/d3d9caps.h | 182 ++++++++++++++++++++++++++-------------------------- > 1 files changed, 91 insertions(+), 91 deletions(-) > > diff --git a/include/d3d9caps.h b/include/d3d9caps.h > index 8ed6598..64dba21 100644 > --- a/include/d3d9caps.h > +++ b/include/d3d9caps.h > @@ -29,13 +29,13 @@ > #define D3DCURSORCAPS_LOWRES 2 > > > -#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L > -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L > -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L > -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L > -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L > -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L > -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L > +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 > +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 > +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 > +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 > +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 > +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 > +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040 > mingw-w64 project imports some of our headers, including most of d3d headers. They would probably prefer to keep them with 'l' modifier since that's the right thing to do. Given that it's mostly harmless for Wine, could we please consider not changing it? Thanks, Jacek

5 7

Re: [PATCH 1/2] d3dx9: Improve argument check in D3DXFindShaderComment().
by Marvin Oct. 26, 2011

Oct. 26, 2011

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=15119 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

winealsa: 6 Channel Audio
by Joerg-Cyril.Hoehle＠t-systems.com Oct. 26, 2011

Oct. 26, 2011

Hi, Andrew Eikum wrote: > > A configuration option (in winecfg/control panel) [...] > My reaction to this is "urrrrrrrghhhhhhh". >Tucking stuff away in the registry makes it a pain to screw >up their config, which means they'll probably turn to submitting bug >reports with the default config first, which is exactly what I want. Interesting wish. Somehow understandable, however ... Currently I see the winecfg as the only viable solution to the issue that we (at least I) don't know how to get the best default parameters. E.g. dmix prefers 48000Hz but this is settable somewhere in /etc/alsa or /usr/share/alsa PA seems to use 44100 on my system (and I'm wondering whether PA may end up using dmix as back-end, involving some resampling from 44100 to 48000?!?) All of them will happily accept any rate and resample. I don't know how to get hw:0's preferred rate short of disabling resampling, which will cause compatibility trouble (perhaps open hw:0 twice, once without resampling to investigate the bare bones, then with resampling which is what Wine needs for its operations). >GetMixFormat(). For example, >it should really be a per-device (and therefore per-backend) setting. Huh? it's already dependent on This->pcm_handle, hence the backend. IMHO we need enumeration tests to verify that GetMixFormat exists for every mmdevapi device. Conceptually IMHO, GetMix is all about a mixer. I don't believe MS provides N mixers, rather than one for each of "Default Voice output channel" and "Multimedia output" and perhaps "Comm output" -- should these be different. That's 1-3. OTOH, it's possible that it supplies on-demand mixing services for every mmdevapi backend, e.g. the poor built-in speaker, on-board audio and distinct 5:1 PCI card. Can an app open any device in shared (=mixer) mode, even when it's not one of the default devices? It's quite logical that there's a control panel in Windows Vista-7. Their users must be able to define which is their default (preferred) voice, multimedia and comm output card, and possibly how their 5/7:1 speakers are positioned. Ideally, Wine should detect whether ALSA has a distinct (and working) "surround" or "5.1" output device, use that and detect (or map) its speaker configuration. >Apparently ALSA is capable of handling up to 10,000 channels The message means nothing more than that dmix will accept upto 10000 channels and map that somehow to the underlying device. Not unlike that systematic test performed by a German guy IIRC about channel mapping on MS, where 1-6 channels were also accepted and distributed somehow to the existing speakers. Regards, Jörg Höhle

1 0

D3DXCreatePolygon
by paulo lesgaz Oct. 26, 2011

Oct. 26, 2011

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

2 1

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

Oct. 26, 2011

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 Oct. 25, 2011

Oct. 25, 2011

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 Oct. 25, 2011

Oct. 25, 2011

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 Oct. 25, 2011

Oct. 25, 2011

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 Oct. 25, 2011

Oct. 25, 2011

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 Oct. 25, 2011

Oct. 25, 2011

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 Oct. 25, 2011

Oct. 25, 2011

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 Oct. 24, 2011

Oct. 24, 2011

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 Oct. 24, 2011

Oct. 24, 2011

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 Oct. 24, 2011

Oct. 24, 2011

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 Oct. 24, 2011

Oct. 24, 2011

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 Oct. 24, 2011

Oct. 24, 2011

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 Oct. 24, 2011

Oct. 24, 2011

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 Oct. 24, 2011

Oct. 24, 2011

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 Oct. 24, 2011

Oct. 24, 2011

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