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

64bit debugging or 32/64bit wine coexistence?
by Geoff Hart 15 Jan '11

15 Jan '11

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 15 Jan '11

15 Jan '11

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 15 Jan '11

15 Jan '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=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 15 Jan '11

15 Jan '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=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 14 Jan '11

14 Jan '11

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 14 Jan '11

14 Jan '11

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 14 Jan '11

14 Jan '11

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 14 Jan '11

14 Jan '11

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 14 Jan '11

14 Jan '11

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 14 Jan '11

14 Jan '11

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