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

Configuration warning
by Taeksang Yoo Jan. 16, 2011

Jan. 16, 2011

configure: WARNING: OpenCL/opencl.h: present but cannot be compiled configure: WARNING: OpenCL/opencl.h: check for missing prerequisite headers? configure: WARNING: OpenCL/opencl.h: see the Autoconf documentation configure: WARNING: OpenCL/opencl.h: section "Present But Cannot Be Compiled" configure: WARNING: OpenCL/opencl.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## Hello Wine developers. While compiling wine 1.3.11 on Mac OS X 10.6.6 using F3-bgmusic.patch and wine-1.3.11-xinput2.patch I got this error. If you need to know anything else please let me know; I reported the error as requested. Taeksang Yoo

2 1

semi-updated valgrind results
by Austin English Jan. 16, 2011

Jan. 16, 2011

I ran the tests with Valgrind for wine 1.3.11 on Debian Squeeze. I haven't yet updated the suppressions file (I'd appreciate feedback on what to add :p), so the logs are a bit noisy... But, if you're curious, see http://austinenglish.com/logs/valgrind/ I haven't yet setup the tests on that machine to run daily, I may do so eventually, especially if it proves useful :-). -- -Austin

2 2

tests/amstream.c doesn't test anything
by Joerg-Cyril.Hoehle＠t-systems.com Jan. 15, 2011

Jan. 15, 2011

Hi, please take a look at test.winehq.org http://test.winehq.org/data/tests/amstream:amstream.html It appears that almost all native machines perform 0 tests on amstream. As no skip is flagged, results appear all green. The only exception are Wylda's XP machines. They execute 16 tests but fail one of them. Can we conclude that the amstream tests are in a bad shape, despite green colour? Or that some amstream components are optional and should be installed on more test bots? (Note that the amstream.dll is present, otherwise the message would be different) Most Wine machines also execute 0 tests, except Nicolas Le Cam's (nlc) amstream.c:163: Test marked todo: IDirectDrawMediaStream_CreateSample returned: 80004001 What's different about these machines? Should I take this to bugzilla? I know next to nothing about amstream. It is about streaming to audio or a DirectDraw surface. http://msdn.microsoft.com/en-us/library/dd390909%28v=VS.85%29.aspx Regards, Jörg Höhle

4 3

re: Fail to use USB-Key/USB-Shield with wine USB patch
by Dan Kegel Jan. 15, 2011

Jan. 15, 2011

Qian wrote: > My usbkey is also called G&D USB-Shield, it is required by > ICBC persional internet banking while online trading. > Unfortunately, ICBC website is IE-only, ActiveX and VBscript are required. > ... In fact, we don't have to login ICBC for testing the usbkey, > because there is a tool called Token Administration Utility, Thanks for the nice summary and the links. Hopefully someone will have time to look into the problem. I fear that the fact that it installs several drivers makes it unlikely it will be able to work in wine, but who knows. Also, even if the USB problems are worked out, there might be a bunch of crypto features that still need to be implemented/fixed. - Dan p.s. It looks like the software your bank uses is described here: http://www.aeteurope.com/aet/aet-europe/_www/en/pub/products/safesign/safes… (And it looks like they have a Linux version of their software, including the Token Administration Utility, but that won't help you.) They mention that they conform to the "windows smart card infrastructure" described in http://msdn.microsoft.com/en-us/library/bb905527.aspx The "base csp" described there is at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e8095fd5-c7e5-4… but won't install on non-licensed versions of windows, like wine.

1 0

Testbot not accepting patch
by Travis Athougies Jan. 15, 2011

Jan. 15, 2011

Hi there, I've been trying to submit this patch to the testbot, and it keeps refusing it with the error "Unrecognized file typea" (that's not a typo, that's the exact error). The testbot has also refused to accept the patch when I sent it in on wine-patches (the error on the patch status page is apply failure). As far as I can tell, the patch looks good, it was generated by git format-patch from the latest git and I did not touch it after that, so it should apply, but it doesn't. Can you look into this? Thanks, Travis. -- Travis Athougies

7 8

64bit debugging or 32/64bit wine coexistence?
by Geoff Hart Jan. 15, 2011

Jan. 15, 2011

I'm on Fedora 14, using 64bit Wine 1.3.10, to do Winelib development. Seems to work fine, except, I ran into winedbg problems, like: http://www.winehq.org/pipermail/wine-devel/2010-September/086933.html I saw Eric's response: http://www.winehq.org/pipermail/wine-devel/2010-October/087241.html but I presume it will take sometime for that to trickle into Fedora's repos. So, I thought I'd try using 32bit development, in the mean time. However: ghart(a)32 ~ $ winegcc -m32 crash.c -o crash32 /usr/bin/ld: Relocatable linking with relocations from format elf64-x86-64 (/usr/lib64/wine/libwinecrt0.a(exe_entry.o)) to format elf32-i386 (crash32.6JRMXE.o) is not supported winebuild: /usr/bin/ld failed with status 1 winegcc: winebuild failed I presumed this was because I needed to use WINEARCH=win32, so I tried: ghart(a)32 ~ $ rm -fr ~/.win32 ghart(a)32 ~ $ WINEPREFIX=~/.win32 WINEARCH=win32 winecfg wine: created the configuration directory '/vhe/emu/users/ghart/.win32' wine: cannot find L"C:\\windows\\system32\\wineboot.exe" err:process:start_wineboot failed to start wineboot, err 2 Ends up with an incomplete ~/.win32. In contrast: ghart(a)32 ~ $ rm -fr ~/.win64 ghart(a)32 ~ $ WINEPREFIX=~/.win64 WINEARCH= winecfg wine: created the configuration directory '/vhe/emu/users/ghart/.win64' Could not load wine-gecko. HTML rendering will be disabled. fixme:system:SetProcessDPIAware stub! fixme:iphlpapi:NotifyAddrChange (Handle 0x63be914, overlapped 0x63be918): stub wine: configuration in '/vhe/emu/users/ghart/.win64' has been updated. seems to function properly. ghart(a)32 ~ $ locate wineboot /usr/bin/wineboot /usr/lib/wine/fakedlls/wineboot.exe /usr/lib64/wine/wineboot.exe.so /usr/lib64/wine/fakedlls/wineboot.exe I wondered why no /usr/lib/wine/wineboot.exe.so ghart(a)32 ~ $ ls /usr/lib/wine/wine*.so /usr/lib/wine/winebrowser.exe.so /usr/lib/wine/winemapi.dll.so /usr/lib/wine/winecfg.exe.so /usr/lib/wine/winemenubuilder.exe.so /usr/lib/wine/wineconsole.exe.so /usr/lib/wine/winemine.exe.so /usr/lib/wine/winecoreaudio.drv.so /usr/lib/wine/winepath.exe.so /usr/lib/wine/wined3d.dll.so /usr/lib/wine/wineps16.drv16.so /usr/lib/wine/winedbg.exe.so /usr/lib/wine/wineps.drv.so /usr/lib/wine/winedevice.exe.so /usr/lib/wine/winepulse.drv.so /usr/lib/wine/winefile.exe.so /usr/lib/wine/winevdm.exe.so /usr/lib/wine/winegstreamer.dll.so /usr/lib/wine/winex11.drv.so /usr/lib/wine/winejoystick.drv.so I then wondered if this is some Fedora packaging issue: root(a)mspl001 ~ # yum install wine.i686 Loaded plugins: auto-update-debuginfo, presto, refresh-packagekit Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package wine.i686 0:1.3.10-1.fc14 set to be installed --> Processing Dependency: wine-wow(x86-32) = 1.3.10-1.fc14 for package: wine-1.3.10-1.fc14.i686 --> Running transaction check ---> Package wine-wow.i686 0:1.3.10-1.fc14 set to be installed --> Processing Conflict: wine-1.3.10-1.fc14.x86_64 conflicts wine-wow(x86-32) = 1.3.10-1.fc14 --> Finished Dependency Resolution Error: wine conflicts with wine-wow To me this suggests that wine.i686 is exclusively for 32bit, which I'm hesitant use (I'd like to have both 32 and 64 bit compilations at least, even if debugging is limited to 32bit). I googled around quite a bit, and saw others mention problems similar to mine, but didn't spot any resolution. Can anyone suggest a solution for either the 64bit winedbg or 32bit winegcc usage? thanks, Geoff

2 1

Re: [01/10] msvcr90/tests: Avoid casting away const and avoid potential overflows in comparison functions.
by Marcus Meissner Jan. 15, 2011

Jan. 15, 2011

On Sat, Jan 15, 2011 at 02:27:49AM -0600, Andrew Nguyen wrote: > --- > dlls/msvcr90/tests/msvcr90.c | 27 +++++++++++++++++++++------ > 1 files changed, 21 insertions(+), 6 deletions(-) > > > diff --git a/dlls/msvcr90/tests/msvcr90.c b/dlls/msvcr90/tests/msvcr90.c > index 24a6517..9c07d64 100644 > --- a/dlls/msvcr90/tests/msvcr90.c > +++ b/dlls/msvcr90/tests/msvcr90.c > @@ -446,25 +446,40 @@ static void test_wcsncat_s(void) > } > > -static __cdecl int strcomparefunc(void *context, const void *a, const void*b) > +static __cdecl int strcomparefunc(void *context, const void *a, const void *b) > { > + const char *p = a, *q = b; > + > ok (a != b, "must never get the same pointer\n"); > ++*(int *) context; > - return lstrcmpA(*(char**)a,*(char**)b); > + > + return lstrcmpA(p, q); As testbot wrote, this change is wrong. :) should be const char *p = *a, *q = *b; I guess. Ciao, Marcus

2 1

Re: [02/10] ntdll/tests: Avoid casting away const and avoid potential overflows in comparison functions.
by Marvin Jan. 15, 2011

Jan. 15, 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=8309 Your paranoid android. === WNT4WSSP6 (32 bit string) === string.c:1229: Test failed: badly sorted, strarr[0] is World string.c:1230: Test failed: badly sorted, strarr[1] is ! string.c:1231: Test failed: badly sorted, strarr[2] is Hopefully string.c:1232: Test failed: badly sorted, strarr[3] is . string.c:1233: Test failed: badly sorted, strarr[4] is Hello string.c:1235: Test failed: badly sorted, strarr[6] is Sorted === W2KPROSP4 (32 bit string) === string.c:1229: Test failed: badly sorted, strarr[0] is World string.c:1230: Test failed: badly sorted, strarr[1] is ! string.c:1231: Test failed: badly sorted, strarr[2] is Hopefully string.c:1232: Test failed: badly sorted, strarr[3] is . string.c:1233: Test failed: badly sorted, strarr[4] is Hello string.c:1235: Test failed: badly sorted, strarr[6] is Sorted === WXPPROSP3 (32 bit string) === string.c:1229: Test failed: badly sorted, strarr[0] is World string.c:1230: Test failed: badly sorted, strarr[1] is ! string.c:1231: Test failed: badly sorted, strarr[2] is Hopefully string.c:1232: Test failed: badly sorted, strarr[3] is . string.c:1233: Test failed: badly sorted, strarr[4] is Hello string.c:1235: Test failed: badly sorted, strarr[6] is Sorted === W2K3R2SESP2 (32 bit string) === string.c:1229: Test failed: badly sorted, strarr[0] is World string.c:1230: Test failed: badly sorted, strarr[1] is ! string.c:1231: Test failed: badly sorted, strarr[2] is Hopefully string.c:1232: Test failed: badly sorted, strarr[3] is . string.c:1233: Test failed: badly sorted, strarr[4] is Hello string.c:1235: Test failed: badly sorted, strarr[6] is Sorted === WVISTAADM (32 bit string) === string.c:1229: Test failed: badly sorted, strarr[0] is World string.c:1230: Test failed: badly sorted, strarr[1] is ! string.c:1231: Test failed: badly sorted, strarr[2] is Hopefully string.c:1232: Test failed: badly sorted, strarr[3] is . string.c:1233: Test failed: badly sorted, strarr[4] is Hello string.c:1235: Test failed: badly sorted, strarr[6] is Sorted === W2K8SE (32 bit string) === string.c:1229: Test failed: badly sorted, strarr[0] is World string.c:1230: Test failed: badly sorted, strarr[1] is ! string.c:1231: Test failed: badly sorted, strarr[2] is Hopefully string.c:1232: Test failed: badly sorted, strarr[3] is . string.c:1233: Test failed: badly sorted, strarr[4] is Hello string.c:1235: Test failed: badly sorted, strarr[6] is Sorted === W7PRO (32 bit string) === string.c:1229: Test failed: badly sorted, strarr[0] is World string.c:1230: Test failed: badly sorted, strarr[1] is ! string.c:1231: Test failed: badly sorted, strarr[2] is Hopefully string.c:1232: Test failed: badly sorted, strarr[3] is . string.c:1233: Test failed: badly sorted, strarr[4] is Hello string.c:1235: Test failed: badly sorted, strarr[6] is Sorted === W7PROX64 (32 bit string) === string.c:1229: Test failed: badly sorted, strarr[0] is World string.c:1230: Test failed: badly sorted, strarr[1] is ! string.c:1231: Test failed: badly sorted, strarr[2] is Hopefully string.c:1232: Test failed: badly sorted, strarr[3] is . string.c:1233: Test failed: badly sorted, strarr[4] is Hello string.c:1235: Test failed: badly sorted, strarr[6] is Sorted === W7PROX64 (64 bit string) === string.c:1229: Test failed: badly sorted, strarr[0] is Hello string.c:1230: Test failed: badly sorted, strarr[1] is ! string.c:1231: Test failed: badly sorted, strarr[2] is Wine string.c:1232: Test failed: badly sorted, strarr[3] is World string.c:1233: Test failed: badly sorted, strarr[4] is Hopefully string.c:1234: Test failed: badly sorted, strarr[5] is Sorted string.c:1235: Test failed: badly sorted, strarr[6] is .

1 0

Re: [01/10] msvcr90/tests: Avoid casting away const and avoid potential overflows in comparison functions.
by Marvin Jan. 15, 2011

Jan. 15, 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=8308 Your paranoid android. === WXPPROSP3 (32 bit msvcr90) === msvcr90.c:585: Test failed: badly sorted, strarr[1] is World msvcr90.c:586: Test failed: badly sorted, strarr[2] is Hopefully msvcr90.c:587: Test failed: badly sorted, strarr[3] is Sorted msvcr90.c:588: Test failed: badly sorted, strarr[4] is Hello msvcr90.c:589: Test failed: badly sorted, strarr[5] is . msvcr90.c:590: Test failed: badly sorted, strarr[6] is Wine === W2K3R2SESP2 (32 bit msvcr90) === msvcr90.c:585: Test failed: badly sorted, strarr[1] is World msvcr90.c:586: Test failed: badly sorted, strarr[2] is Hopefully msvcr90.c:587: Test failed: badly sorted, strarr[3] is Sorted msvcr90.c:588: Test failed: badly sorted, strarr[4] is Hello msvcr90.c:589: Test failed: badly sorted, strarr[5] is . msvcr90.c:590: Test failed: badly sorted, strarr[6] is Wine === WVISTAADM (32 bit msvcr90) === msvcr90.c:585: Test failed: badly sorted, strarr[1] is World msvcr90.c:586: Test failed: badly sorted, strarr[2] is Hopefully msvcr90.c:587: Test failed: badly sorted, strarr[3] is Sorted msvcr90.c:588: Test failed: badly sorted, strarr[4] is Hello msvcr90.c:589: Test failed: badly sorted, strarr[5] is . msvcr90.c:590: Test failed: badly sorted, strarr[6] is Wine === W2K8SE (32 bit msvcr90) === msvcr90.c:585: Test failed: badly sorted, strarr[1] is World msvcr90.c:586: Test failed: badly sorted, strarr[2] is Hopefully msvcr90.c:587: Test failed: badly sorted, strarr[3] is Sorted msvcr90.c:588: Test failed: badly sorted, strarr[4] is Hello msvcr90.c:589: Test failed: badly sorted, strarr[5] is . msvcr90.c:590: Test failed: badly sorted, strarr[6] is Wine === W7PRO (32 bit msvcr90) === msvcr90.c:585: Test failed: badly sorted, strarr[1] is World msvcr90.c:586: Test failed: badly sorted, strarr[2] is Hopefully msvcr90.c:587: Test failed: badly sorted, strarr[3] is Sorted msvcr90.c:588: Test failed: badly sorted, strarr[4] is Hello msvcr90.c:589: Test failed: badly sorted, strarr[5] is . msvcr90.c:590: Test failed: badly sorted, strarr[6] is Wine === W7PROX64 (32 bit msvcr90) === msvcr90.c:585: Test failed: badly sorted, strarr[1] is World msvcr90.c:586: Test failed: badly sorted, strarr[2] is Hopefully msvcr90.c:587: Test failed: badly sorted, strarr[3] is Sorted msvcr90.c:588: Test failed: badly sorted, strarr[4] is Hello msvcr90.c:589: Test failed: badly sorted, strarr[5] is . msvcr90.c:590: Test failed: badly sorted, strarr[6] is Wine === W7PROX64 (64 bit msvcr90) === msvcr90.c:584: Test failed: badly sorted, strarr[0] is Wine msvcr90.c:585: Test failed: badly sorted, strarr[1] is World msvcr90.c:586: Test failed: badly sorted, strarr[2] is Sorted msvcr90.c:587: Test failed: badly sorted, strarr[3] is . msvcr90.c:588: Test failed: badly sorted, strarr[4] is Hello msvcr90.c:589: Test failed: badly sorted, strarr[5] is ! msvcr90.c:590: Test failed: badly sorted, strarr[6] is Hopefully

1 0

Re: msvcrt: Add _atoflt and _atoflt_l implementations
by Alexandre Julliard Jan. 14, 2011

Jan. 14, 2011

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -333,6 +333,123 @@ double CDECL MSVCRT__atof_l( const char *str, MSVCRT__locale_t locale) > } > > /********************************************************************* > + * _atoflt_l (MSVCRT.@) > + * > + * Not exported by native msvcrt > + */ It is exported, that's why it's in the spec file. The non _l version isn't, but it doesn't need to be, the wrappers can go in the individual msvcr* dlls. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [3/3] dsound/tests: Add IEEE float buffer tests for dsound8
by Alexandre Julliard Jan. 14, 2011

Jan. 14, 2011

Owen Rudge <orudge(a)codeweavers.com> writes: > --- > dlls/dsound/tests/ds3d8.c | 7 ++++++- > dlls/dsound/tests/dsound8.c | 33 +++++++++++++++++++++++---------- > 2 files changed, 29 insertions(+), 11 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound8.c && touch dsound8.ok dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) dsound8.c:816: Test failed: IDirectSound_CreateSoundBuffer() returned: 8878001e (nil) make: *** [dsound8.ok] Error 24 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msxml3: Fixed memory leak (coverity)
by Jacek Caban Jan. 14, 2011

Jan. 14, 2011

On 1/14/11 2:01 PM, Jacek Caban wrote: > --- > dlls/msxml3/httprequest.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) It's actually a Valgrind fix. The commit message is a typo. Sorry about that. Jacek

1 0

Procedure for adding message contexts to PO messages?
by Frédéric Delanoy Jan. 14, 2011

Jan. 14, 2011

Hi, I'm quite green wrt PO files and was reviewing French PO file after recent rc -> po migration. So I read somewhat about PO format and Wine's "PO support code". I wonder how to add message contexts, and thought it might be this way: 1. Add msgctxt "myContext" next to the associated msgid "myMsgid" string in en.po 2. Replace myMsgid by #msgctxt#myContext#myMsgid in the relevant rc file (e.g. IDS_MY_KEY, "#msgctxt#myContext#myMsgid") 3. Translate Is that the correct procedure? Or am I missing something? I suppose, if there are multiple contexts (which should always be the case when introducing contexts, otherwise "#." extracted comments should be used IMHO), rc files key should be duplicated as well, so we'd rather have sthg like that? (originally) IDS_MY_KEY, "myMsgid" becomes IDS_MY_KEY1, "#msgctxt#myContext1#myMsgid" IDS_MY_KEY2, "#msgctxt#myContext2#myMsgid" with source code references adapted, or maybe IDS_MY_KEY, "myMsgid" IDS_MY_KEY1, "#msgctxt#myContext1#myMsgid" where IDS_MY_KEY uses the most common, "default" context. This would also minimize the amount of changes to be done in source files. Thanks for clarifications, Frédéric PS: For interested people, here's the "reference" I found : http://pology.nedohodnik.net/doc/user/ch-poformat.html

2 2

Re: Alexandre Julliard : winedump: Try to load the PDB string table from file number 4 too.
by Eric Pouech Jan. 14, 2011

Jan. 14, 2011

Le 12/01/2011 20:16, Alexandre Julliard a écrit : > Module: wine > Branch: master > Commit: 4f574ee942be99c7401a3bef472a81d0f2bb0b5b > URL: http://source.winehq.org/git/wine.git/?a=commit;h=4f574ee942be99c7401a3bef4… > > Author: Alexandre Julliard<julliard(a)winehq.org> > Date: Wed Jan 12 10:45:54 2011 +0100 > > winedump: Try to load the PDB string table from file number 4 too. > > > > Alexandre visiblement tu as un exemplaire de pdb sous la main différent de ceux que j'ai vu peux-tu me le passer (sauf si contrat spécifique CW bien sûr) j'ai toujours trouvé curieux les index constants pour certains streams dans les PDB, donc si j'en ai des différents, ca pourrait aider à trouver l'indirection (potentielle) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

3 3

wineqtdecoder: Initial version of the video decoder using Mac OS/X QuickTime Framework.
by Joerg-Cyril.Hoehle＠t-systems.com Jan. 14, 2011

Jan. 14, 2011

Aric, your post 1.3.9 patch needs additional autoconf help to detect systems where the QT framework developer files are not installed. wine fails to build here (MacOS 10.5.8) qtvdecoder.c:63:40: error: QuickTime/ImageCompression.h: No such file or directory qtvdecoder.c:139: error: expected specifier-qualifier-list before "ImageDescriptionHandle" I've configured my Mac as described in the "lightweight build" section of http://wiki.winehq.org/MacOSX/Building I propose to install the framework (likely located on the install DVD) on my machine after a patch to detect its absence goes into git, so that we know the detection works correctly. Regards, Jörg Höhle

1 0

Re: libs/wine: Fix regression caused by 5af634fd3b7ff7e4d6f8af34f6139315fdbbc8c4 for non-x86 architectures
by Austin English Jan. 14, 2011

Jan. 14, 2011

2011/1/13 André Hentschel <nerv(a)dawncrow.de>: > --- > libs/wine/config.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/libs/wine/config.c b/libs/wine/config.c > index e15012b..2c365a4 100644 > --- a/libs/wine/config.c > +++ b/libs/wine/config.c > @@ -456,7 +456,7 @@ const char *wine_get_build_id(void) > /* exec a binary using the preloader if requested; helper for wine_exec_wine_binary */ > static void preloader_exec( char **argv, int use_preloader ) > { > -#ifdef linux > +#ifdef linux && defined(__i386__) && defined(__x86_64__) > if (use_preloader) > { > static const char preloader[] = "wine-preloader"; > -- Causes a warning here: ./config.c:459:14: warning: extra tokens at end of #ifdef directive Additionally, you're mixing ifdef and if defined. I used the below patch on powerpc, which works well: diff --git a/libs/wine/config.c b/libs/wine/config.c index 4a2bced..7fce02b 100644 --- a/libs/wine/config.c +++ b/libs/wine/config.c @@ -456,7 +456,7 @@ const char *wine_get_build_id(void) /* exec a binary using the preloader if requested; helper for wine_exec_wine_binary */ static void preloader_exec( char **argv, int use_preloader ) { -#ifdef linux +#if defined (__linux__) && (defined(__i386__) || defined(__x86_64__)) if (use_preloader) { static const char preloader[] = "wine-preloader"; -- -Austin

1 0

Re: [2/7] kernel32: Improve parameter validation for ReadConsoleOutputCharacterA.
by Marvin Jan. 13, 2011

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

3 3

Re: kernel32/tests: Use the right return type and a better failed test message
by Marvin Jan. 12, 2011

Jan. 12, 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=8267 Your paranoid android. === W7PRO (32 bit pipe) === Failure running script in VM: Exceeded timeout limit of 135 sec === W7PROX64 (32 bit pipe) === Failure running script in VM: Exceeded timeout limit of 135 sec

1 0

Re: [PATCH] windowscodecs/tests: Fix crash introduced with eaf394a9ac4c.
by Marvin Jan. 12, 2011

Jan. 12, 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=8269 Your paranoid android. === WINEBUILD (build) === Patch failed to apply === W2K8SE (32 bit converter) === TestLauncher.c:200: Test failed: Can't locate import module name in C:\winetest\windowscodecs_test.exe === W7PRO (32 bit converter) === No test summary line found === W7PROX64 (32 bit converter) === No test summary line found

1 0

Re: [PATCH 1/3] msvcr90: Implement _set_abort_behavior [try2]
by Alexandre Julliard Jan. 12, 2011

Jan. 12, 2011

Detlef Riekenberg <wine.dev(a)web.de> writes: > @@ -36,6 +36,11 @@ static MSVCRT_purecall_handler purecall_handler = NULL; > > static const char szMsgBoxTitle[] = "Wine C++ Runtime Library"; > > +#ifndef _WRITE_ABORT_MSG > +#define _WRITE_ABORT_MSG 1 > +#define _CALL_REPORTFAULT 2 > +#endif These should go in msvcrt.h with the appropriate prefix and corresponding test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcrt: Partially implement _set_abort_behavior
by Detlef Riekenberg Jan. 12, 2011

Jan. 12, 2011

On Mi, 2011-01-12 at 00:48 +0300, Nikolay Sivov wrote: > Date: Wed, 12 Jan 2011 00:46:26 +0300 > Subject: [PATCH 1/1] Partially implement _set_abort_behavior Please search the patches queue first. try 2: http://source.winehq.org/patches/data/70231 try 1: http://source.winehq.org/patches/data/70136 > +static int MSVCRT_abort_behavior = MSVCRT__WRITE_ABORT_MSG | > MSVCRT__WRITE_CALL_REPORTFAULT; - _set_abort_behavior get unsigned int, but you use an int. Why? - mingw header have the same name as msdn. Why are you using different names? > /********************************************************************* > + * _set_abort_behavior (MSVCRT.@) > + * > + * Not exported by native msvcrt, added in msvcr80 > + */ > +int CDECL MSVCRT__set_abort_behavior(int flags, int mask) > +{ - need unsigned int > diff --git a/dlls/msvcrt/msvcrt.h b/dlls/msvcrt/msvcrt.h > > +/* _set_abort_behavior codes */ > +#define MSVCRT__WRITE_ABORT_MSG 1 > +#define MSVCRT__WRITE_CALL_REPORTFAULT 2 > + > +int __cdecl MSVCRT__set_abort_behavior(int,int); - correct location is stdlib.h - names are wrong - need unsigned int > -- By by ... Detlef

2 1

windowscodecs: Use Mac OS X native ICNS support, not libicns
by Joerg-Cyril.Hoehle＠t-systems.com Jan. 12, 2011

Jan. 12, 2011

Ken, Thank you! Indeed I never installed libicns on my Mac (why use an external library on the particular OS that created the need for ICNS format support?) and even reverted Damjan's patch to still create .png images like the Linux systems. Then I use sips -i to create .command files with icons -- as I explained on the Wiki. http://wiki.winehq.org/MacOSX/FAQs >Besides being referenced by .desktop files which aren't used, Why not instead create .command files like I explain on the Wiki? Basically, instead of xyz.desktop: Path=/foo/bar Exec=env WINEPREFIX=... wine ... Icon=... create a xyz.command: #! /bin/sh cd /foo/bar && exec env WINEPREFIX=... wine ... >the ICNS files are written to /tmp, as things stand. Good. It's valuable to have a place where to obtain the icons even after the installer finishes. I'm used to peeking at ~/.local/share/icons to see which icons I can associate with .command files on MacOS (and .desktop on Linux). In my particular case, it's useful to have the .png because I can use it for both Linux and MacOS. Regards, Jörg Höhle FWIW, I've compiled 1.3.11 which includes your patch but have not tested it yet.

1 0

Re: d3d9/tests: Skip tests if not running in the foreground
by Marvin Jan. 12, 2011

Jan. 12, 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=8260 Your paranoid android. === W2K8SE (32 bit device) === Can't copy TestLauncher to VM: Cannot connect to the virtual machine

1 0

windowscodecs: Use Mac OS X native ICNS support, not libicns.
by Ken Thomases Jan. 12, 2011

Jan. 12, 2011

Hi Damjan, I was intrigued to see the ICNS support you added to windowscodecs some months ago. Neat work! However, I'm confused about why you used the third-party libicns library. As near as I can tell, the ICNS support is only used on Mac OS X and it's not likely to ever be used elsewhere. If that's the case, why did you not build it on top of the native ICNS support built into Mac OS X? Using the native frameworks would avoid one more external dependency that would need to be shipped with Wine on the Mac. I'm attaching a patch that changes to using the ApplicationServices framework instead of libicns. I wanted to get your input before sending it to wine-patches. What do you think? Thanks, Ken ----------------------------------------------------------------------- The ICNS support is only used on Mac OS X and is not anticipated to be used on any other platform. So, we can rely on the native frameworks rather than a third-party dependency. --- configure.ac | 16 +-- dlls/windowscodecs/Makefile.in | 1 + dlls/windowscodecs/icnsformat.c | 270 ++++++++++++++++----------------------- include/config.h.in | 10 +- 4 files changed, 119 insertions(+), 178 deletions(-)

3 5

Re: [PATCH 1/3] winemenubuilder: Icon heights/widths of 0 mean 256, for Vista icons.
by Damjan Jovanovic Jan. 12, 2011

Jan. 12, 2011

The 256x256 pixel icons are designed to be viewed in that size. They can, and often do, contain a different picture to the smaller icons. When you scale them down to a smaller size, they look bad. On MacOS that may not matter since multiple icon sizes are written and the best is chosen, but on freedesktops we only write 1 icon size at the moment, and then it gets scaled to something like 64x64, so it really does make a difference. Install eMule and see its icons on Gnome as an example. On Tue, Jan 11, 2011 at 5:48 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > > The existing code would always prefer a smaller icon because it was > misinterpreting 256x256 icons as 0x0. > --- > programs/winemenubuilder/winemenubuilder.c | 32 +++++++++++++++------------ > 1 files changed, 18 insertions(+), 14 deletions(-) > > > > >

2 3