[no subject]
Subject: [PATCH 1/2 (try2)] mmdevapi: Don't fail if dwChannelMask is not set correctly
Hi, Andrew Eikum writes: (try2): Remove the test found by testbot. My Win7 Home VM passed that test, so it seems we can expect any behavior. I object to the removal of the test like that. It should be replaced with a comment to explain that the behaviour of IsFormatSupported is very surprising, hence skipped. Actually, that behaviour begs for even more tests to understand what's going on. So far I believed in the invariant: IsFormatSupported == S_OK = Initialize == S_OK which is verified using all standard formats (1-2 channels), with one exception on testbot: render.c:396: Initialize (1, 48000x16x1) returns 8889000f unlike IsFormatSupported ^1^ means in exclusive mode, and only there. Now you experienced A. on testbot: IsFormatSupported(dwChannelMask==) == S_OK, like Initialize which conforms to the above invariant and simply suggests that ChannelMask is not checked at all, therefore this code in Wine seems too much: +fmtex-dwChannelMask != 0 +fmtex-dwChannelMask != get_channel_mask(pwfx-nChannels)) B. your own Win7 Home system, with dwChannelMask=, IsFormatSupported returns +ok(hr == S_FALSE || hr == AUDCLNT_E_UNSUPPORTED_FORMAT while Initialize returns +ok(hr == S_OK, which is weird. When does IFS return UNSUPPORTED_FORMAT? When does it return S_FALSE? In the latter case, is the suggested format anything else than GetMixFormat? What does exclusive mode return? Unlike in Wine, the shared mode audio engine mixer is a completely different SW entity than the exclusive mode audio device, so it's important to check both. This needs more testing. In particular, tests performed on HW that supports more than 2 channels are welcome. Based on your surprising test result, I'd guess yours is such a system. Unlike DSound, mmdevapi has no GetSpeakerConfig that I'm aware of (short of Device Topology), so I don't know how apps find out about multi-channel abilities. BTW, I believe +fmtex-dwChannelMask != get_channel_mask(pwfx-nChannels)) in Wine is bogus anyway, because it's arbitrary. There exist different 3/4/5/6 channel configurations. Regards, Jörg Höhle
Re: 78632: Subject: po: Update Japanese translation.
Hi Akihiro, your patch does not apply here, perhaps it's slightly out of date? patching file po/ja.po Hunk #22 FAILED at 8231. Hunk #23 succeeded at 8271 (offset 1 line). Hunk #24 succeeded at 8347 with fuzz 2 (offset 1 line). Hunk #25 succeeded at 8540 (offset 1 line). Hunk #26 succeeded at 8549 (offset 1 line). Hunk #27 succeeded at 8566 (offset 1 line). Hunk #28 succeeded at 8581 (offset 1 line). Hunk #29 succeeded at 8647 (offset 1 line). Hunk #30 succeeded at 8791 (offset 1 line). Hunk #31 succeeded at (offset 1 line). Hunk #32 succeeded at 8912 (offset 1 line). Hunk #33 succeeded at 9004 (offset 1 line). Hunk #34 succeeded at 9045 (offset 1 line). Hunk #35 succeeded at 9872 (offset 1 line). Hunk #36 succeeded at 10329 (offset 1 line). Hunk #37 succeeded at 10490 (offset 1 line). Hunk #38 succeeded at 10733 (offset 1 line). Hunk #39 succeeded at 10758 (offset 1 line). Hunk #40 succeeded at 11246 (offset 1 line). Hunk #41 succeeded at 11260 (offset 1 line). Hunk #42 succeeded at 11381 (offset 1 line). Hunk #43 succeeded at 11415 (offset 1 line). 1 out of 43 hunks FAILED -- saving rejects to file po/ja.po.rej dank@pantry:~/wine-git$ git reset --hard origin HEAD is now at cb55d2a crypt32/tests: Remove dead assignment (clang). dank@pantry:~/wine-git$ git apply 78632 error: patch failed: po/ja.po:8198 error: po/ja.po: patch does not apply 2011/9/9 build...@kegel.com: This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. 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/0 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed git For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78262: Subject: [2/6] dinput: Added enumerated devices to ConfigureDevices dialog (try 3)
On Thu, Sep 1, 2011 at 23:37, build...@kegel.com wrote: The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/208 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot You might want to avoid testing patches [M+1..N/N] if [M/N] failed, 1=M=N-1
Re: 78262: Subject: [2/6] dinput: Added enumerated devices to ConfigureDevices dialog (try 3)
2011/9/2 Frédéric Delanoy frederic.dela...@gmail.com: On Thu, Sep 1, 2011 at 23:37, build...@kegel.com wrote: The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/208 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot You might want to avoid testing patches [M+1..N/N] if [M/N] failed, 1=M=N-1 I could... it'd take some thinking, though, as buildbot isn't really set up for patch series. In this case, though, the failure was unrelated to the patch series, so I'm not sure it would have quieted the noise much.
Re: 78256: Subject: [PATCH 1/5] wined3d: Print a FIXME for any flags passed to wined3d_surface_flip().
On Thu, Sep 1, 2011 at 1:01 PM, Henri Verbeet hverb...@gmail.com wrote: On 1 September 2011 21:02, Henri Verbeet hverb...@gmail.com wrote: I have some doubts about this being caused by this patch. That said, you may want to give 78289 a try. I plopped it into the buildbot, and since then no tests have failed. I hope it's the first thing Alexandre commits today. - Dan
Re: 78217: Subject: [PATCH 3/3] winecfg: Remove driver selection from Audio tab
On Wed, Aug 31, 2011 at 01:25:41PM -0700, Dan Kegel wrote: Ah, I see you resent a fixed version, sorry for the noise. Thanks just the same. Because of your bot's email, I was able to know to resend the patch before I ran out the door. Andrew (FWIW, the bot won't test your retry, since it was an incomplete patch series.) On Wed, Aug 31, 2011 at 1:22 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 31, 2011 at 1:10 PM, build...@buildbot.kegel.com wrote: The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/161 BUILD FAILED: failed git Something's fishy; looking at http://marc.info/?l=wine-patchesm=131134541100364w=2 I see that the July 22nd version seems to have interesting strings, but the August 31st version has all question marks when it comes to non-ascii text. What happened between the two? http://source.winehq.org/patches/data/78217, which is where I pulled the patch from, also has the question marks.
Re: 78256: Subject: [PATCH 1/5] wined3d: Print a FIXME for any flags passed to wined3d_surface_flip().
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/201 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78256: Subject: [PATCH 1/5] wined3d: Print a FIXME for any flags passed to wined3d_surface_flip().
On 1 September 2011 20:51, build...@kegel.com wrote: Backtrace: =0 0x7bc4772c HEAP_CreateFreeBlock+0xbb(subheap=0x110014, ptr=0x130910, size=0xdffe8) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/ntdll/heap.c:583] in ntdll (0x0032f444) 1 0x7bc47a57 HEAP_ShrinkBlock+0x42(subheap=0x110014, pArena=0x1308e8, size=0x20) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/ntdll/heap.c:685] in ntdll (0x0032f468) 2 0x7bc4abdd RtlAllocateHeap+0x2a8(heap=0x11, flags=0x2, size=0x1a) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/ntdll/heap.c:1699] in ntdll (0x0032f4c8) 3 0x40063383 OpenDriverA+0x96(lpDriverName=winealsa.drv, lpSectionName=0x0(nil), lParam=0) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/winmm/driver.c:361] in winmm (0x0032f518) 4 0x400666ac MMDRV_Install+0x151(drvRegName=winealsa.drv, drvFileName=winealsa.drv, bIsMapper=0) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/winmm/lolvldrv.c:456] in winmm (0x0032f5c8) 5 0x400670d1 MMDRV_Init+0x3b7() [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/winmm/lolvldrv.c:571] in winmm (0x0032f658) 6 0x40064d4d MMDRV_InitSingleType+0x2a(type=0x5) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/winmm/lolvldrv.c:80] in winmm (0x0032f668) 7 0x40065993 MMDRV_Get+0xc9(_hndl=0x0(nil), type=0x5, bCanBeID=0) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/winmm/lolvldrv.c:261] in winmm (0x0032f768) 8 0x4007c537 WINMM_DRVMessage+0xac(dev=0, message=0x814, param1=0x13050c, param2=0, is_out=0x1) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/winmm/waveform.c:2774] in winmm (0x0032f7b8) 9 0x4007c839 waveOutMessage+0x111(hWaveOut=(nil), uMessage=0x814, dwParam1=0x13050c, dwParam2=0) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/winmm/waveform.c:2832] in winmm (0x0032f7f8) 10 0x4002ed0b DSOUND_ReopenDevice+0x153(device=0x1304f8, forcewave=0) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/dsound/primary.c:108] in dsound (0x0032f878) 11 0x400225de DirectSoundDevice_Initialize+0x47e(ppDevice=0x1222dc, lpcGUID=0x400428f0) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/dsound/dsound.c:1412] in dsound (0x0032f9a8) 12 0x40020b4a IDirectSound8_IDirectSound8_Initialize+0x8e(iface=0x1222f8, lpcGuid=(nil)) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/dsound/dsound.c:920] in dsound (0x0032f9e8) 13 0x400214a6 DirectSoundCreate8+0x164(lpcGUID=(nil), ppDS=0x12d518, pUnkOuter=(nil)) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/dsound/dsound.c:1143] in dsound (0x0032fa38) 14 0x68f08e96 DSoundRender_create+0x20d(pUnkOuter=(nil), ppv=0x32fbfc) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/quartz/dsoundrender.c:519] in quartz (0x0032fbc8) 15 0x68f289fa DSCF_CreateInstance+0xa2(iface=0x122a60, pOuter=(nil), riid=0x6857404c, ppobj=0x685796d4) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/quartz/main.c:130] in quartz (0x0032fc18) 16 0x686cce9c CoCreateInstance+0x29a(rclsid=0x68575e9c, pUnkOuter=(nil), dwClsContext=0x1, iid=0x6857404c, ppv=0x685796d4) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/ole32/compobj.c:2641] in ole32 (0x0032fc98) 17 0x68565c80 create_dsound_renderer+0x43() [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/quartz/tests/dsoundrender.c:46] in quartz_test (0x0032fcd8) 18 0x68566e45 func_dsoundrender+0x25() [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/quartz/tests/dsoundrender.c:225] in quartz_test (0x0032fcf8) 19 0x685727a2 run_test+0x9e(name=dsoundrender.c) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/quartz/tests/../../../include/wine/test.h:556] in quartz_test (0x0032fd58) 20 0x68572bb9 main+0x23a(argc=couldn't compute location, argv=0x1103d8) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/quartz/tests/../../../include/wine/test.h:624] in quartz_test (0x0032fe28) 21 0x68572c46 __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/winecrt0/exe_entry.c:36] in quartz_test (0x0032fe60) 22 0x7b85fc74 call_process_entry+0xb() in kernel32 (0x0032fe78) 23 0x7b85fdbb start_process+0x144(peb=0x7ffdf000) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/kernel32/process.c:1087] in kernel32 (0x0032fec8) 24 0x7bc7dee8 call_thread_func+0xb() in ntdll (0x0032fed8) 25 0x7bc7df26 call_thread_entry_point+0x33(entry=0x7b85fc76, arg=0x7ffdf000) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) 26 0x7bc53805 start_process+0x25(kernel_start=0x7b85fc76) [/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) 27 0x68028b4d wine_call_on_stack+0x1c() in
Re: 78258: Subject: [PATCH 3/5] wined3d: Get rid of some redundant else statements in IWineD3DSurfaceImpl_BltOverride().
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/203 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78259: Subject: [PATCH 4/5] wined3d: Make the device parameter to wined3d_device_get_light_enable() const.
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/204 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78256: Subject: [PATCH 1/5] wined3d: Print a FIXME for any flags passed to wined3d_surface_flip().
On 1 September 2011 21:02, Henri Verbeet hverb...@gmail.com wrote: I have some doubts about this being caused by this patch. That said, you may want to give 78289 a try.
Re: 78260: Subject: [PATCH 5/5] wined3d: Make the device parameter to wined3d_device_get_clip_plane() const.
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/205 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78266: Subject: regedit: Remove the printing code
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/206 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78261: Subject: [1/6] dinput: Added ConfigureDevices dialog (try 3)
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/207 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78262: Subject: [2/6] dinput: Added enumerated devices to ConfigureDevices dialog (try 3)
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/208 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78265: Subject: [3/6] dinput: Added object/action enumeration to ConfigureDevices dialog (try 3)
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/209 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78264: Subject: [5/6] dinput: Added possibility to change the action mapping in the ConfigureDevices dialog (try 3)
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/211 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78267: Subject: [6/6] dinput: Working CANCEL and RESET buttons in ConfigureDevices dialog (try 3)
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/212 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78268: Subject: view: Install it inside Wine
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/213 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78269: Subject: Polish translation for release 1.3.27
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/214 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78270: Subject: widl: duplicate type in case of argument with range attribute
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/215 BUILD FAILED: failed git For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78273: Subject: [PATCH 1/5] cmd/tests: add more tests for command line parsing
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/218 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78271: Subject: rpcrt4:properly unmarshall EMUM16 discriminant
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/216 BUILD FAILED: failed git For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78276: Subject: [PATCH 2/5] cmd: use GetCommandline() rather than argv
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/219 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78278: Subject: [po]updated korean resource
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/223 BUILD FAILED: failed git For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78283: Subject: [PATCH] po: Update Japanese translation.
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/227 BUILD FAILED: failed git For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78284: Subject: user32: Fix support for CB_SETDROPPEDWIDTH in combobox
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/228 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78285: Subject: [PATCH] po: Update Japanese translation.
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/229 BUILD FAILED: failed git For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78286: Subject: Polish translation for release 1.3.27
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/230 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78287: Subject: po: Update German translation
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/231 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78291: Subject: urlmon/tests: Print out the wrong mime
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/235 BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78214: Subject: winusb: add new stub dll (resend)
On Wed, Aug 31, 2011 at 1:00 PM, build...@buildbot.kegel.com wrote: The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/158 BUILD FAILED: failed git For more info about this message, see http://wiki.winehq.org/BuildBot The error was fatal: corrupt patch at line 32 Your email program may have removed whitespace from the patch. Try attaching the patch instead of including it inline.
Re: 78217: Subject: [PATCH 3/3] winecfg: Remove driver selection from Audio tab
On Wed, Aug 31, 2011 at 1:10 PM, build...@buildbot.kegel.com wrote: The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/161 BUILD FAILED: failed git Something's fishy; looking at http://marc.info/?l=wine-patchesm=131134541100364w=2 I see that the July 22nd version seems to have interesting strings, but the August 31st version has all question marks when it comes to non-ascii text. What happened between the two? http://source.winehq.org/patches/data/78217, which is where I pulled the patch from, also has the question marks.
Re: 78217: Subject: [PATCH 3/3] winecfg: Remove driver selection from Audio tab
Ah, I see you resent a fixed version, sorry for the noise. (FWIW, the bot won't test your retry, since it was an incomplete patch series.) On Wed, Aug 31, 2011 at 1:22 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 31, 2011 at 1:10 PM, build...@buildbot.kegel.com wrote: The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/161 BUILD FAILED: failed git Something's fishy; looking at http://marc.info/?l=wine-patchesm=131134541100364w=2 I see that the July 22nd version seems to have interesting strings, but the August 31st version has all question marks when it comes to non-ascii text. What happened between the two? http://source.winehq.org/patches/data/78217, which is where I pulled the patch from, also has the question marks.
Re: 78222: Subject: configure: AC_C_CONST is obsolete
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/167 BUILD FAILED: failed git For more info about this message, see http://wiki.winehq.org/BuildBot
Re: 78223: Subject: configure: fix configure failures under -Werror -Wall
The Buildbot has detected a failed build on builder runtests while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests/builds/168 BUILD FAILED: failed git For more info about this message, see http://wiki.winehq.org/BuildBot
re: Subject: winemenubuilder: Use start.exe to open URLs to respect URL handlers in registry.
It doesn't apply here, looks like whitespace was corrupted. Try attaching the patch instead of sending it inline? patching file programs/winemenubuilder/winemenubuilder.c Hunk #1 FAILED at 2962. Hunk #2 FAILED at 3004. Hunk #3 FAILED at 3063. 3 out of 3 hunks FAILED -- saving rejects to file programs/winemenubuilder/winemenubuilder.c.rej (Log at http://buildbot.kegel.com:8010/builders/runtests/builds/22/steps/git/logs/stdio for a few days.)
[no subject]
http://2nax.awardspace.com/page.php
[no subject]
Ok, it didn't last very long, but for a brief period we had only greens for 4 different Windows versions on http://test.winehq.org, see attached screenshot. Nice to see some progress J Greg. attachment: NoErrors.png
[no subject]
From: Eric Pouech how come I got two different test results for the same patch ? moreover one is perfectly ok, while the other shows strange results any idea ? Yeah, that's a bit weird. The only thing I can think of is some kind of timing issue, but looking at the code that seems unlikely in this case. So basically, I don't have a clue. Ge.
[no subject]
[no subject]
Hello
As soon as I use Winedbg, the debugger stops at this exception:
First chance exception: page fault on write access to 0x00ad in 32-bit code
(0x7e96fc9d).
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
EIP:7e96fc9d ESP:0033f7a0 EBP:0033f818 EFLAGS:00010a02( R- --O I - - - )
EAX:80808081 EBX:7ea1a518 ECX: EDX:0067
ESI:00ac EDI:00ad
Stack dump:
0x0033f7a0: 031c 0010
0x0033f7b0: 0010 0010
0x0033f7c0: 0010 7e524eb0 0012bc20
0x0033f7d0: 00cc0020 0308 00330001 7e8c0001
0x0033f7e0: 0033f7f8 031c 0012c490 0328
0x0033f7f0: 0010 0010
Backtrace:
=0 0x7e96fc9d create_alpha_bitmap+0x1cd(color=is not available, mask=is not
available, src_info=0x12bc20, color_bits=0x7e524eb0)
[/home/david/wine/dlls/user32/cursoricon.c:771] in user32 (0x0033f8a8)
1 0x7e97077f CURSORICON_CreateIconFromBMI+0x74e(bmi=is not available,
hotspot={x=0x0008, y=0x0008}, bIcon=0x0001, dwVersion=0x3, width=0x0010,
height=0x0010, cFlag=0x8000) [/home/david/wine/dlls/user32/cursoricon.c:837] in
user32 (0x0033f908)
2 0x7e970895 CreateIconFromResourceEx+0xd4(bits=(, cbSize=0x0468,
bIcon=0x0001, dwVersion=0x3, width=0x0010, height=0x0010, cFlag=0x8000)
[/home/david/wine/dlls/user32/cursoricon.c:1159] in user32 (0x0033f9c8)
3 0x7e9735e0 CURSORICON_Load+0x6bf(hInstance=0x7e41, name=is not
available, width=0x0010, height=0x0010, depth=0x0020, fCursor=0,
loadflags=0x8000) [/home/david/wine/dlls/user32/cursoricon.c:1292] in user32
(0x0033fac8)
4 0x7e973b70 LoadImageW+0x1af(hinst=0x7e41, name=*** invalid address 0x1
***, type=0x0001, desiredx=0x0010, desiredy=0x0010, loadflags=0x8000)
[/home/david/wine/dlls/user32/cursoricon.c:2392] in user32 (0x0033fbb8)
5 0x7e97494e LoadImageA+0x19d(hinst=0x7e41, name=*** invalid address 0x1
***, type=0x0001, desiredx=0x0010, desiredy=0x0010, loadflags=0x8000)
[/home/david/wine/dlls/user32/cursoricon.c:2333] in user32 (0x0033fc08)
6 0x7e42d8e6 SIC_Initialize+0x1a5()
[/home/david/wine/dlls/shell32/iconcache.c:417] in shell32 (0x0033fc48)
7 0x7e4371b2 DllMain+0xb1(hinstDLL=0x7e41, fdwReason=0x0001,
fImpLoad=0x1) [/home/david/wine/dlls/shell32/shell32_main.c:1166] in shell32
(0x0033fc68)
8 0x7ef89d15 call_dll_entry_point+0x14() in ntdll (0x0033fda8)
9 0x7ef8cda3 MODULE_InitDLL+0xe2(wm=0x111858, reason=is not available,
lpReserved=0x1) [/home/david/wine/dlls/ntdll/loader.c:982] in ntdll (0x0033fe08)
10 0x7ef8d6e0 process_attach+0xbf(wm=0x111858, lpReserved=is not available)
[/home/david/wine/dlls/ntdll/loader.c:1071] in ntdll (0x0033fe68)
11 0x7ef8d6b2 process_attach+0x91(wm=0x1117a8, lpReserved=is not available)
[/home/david/wine/dlls/ntdll/loader.c:1063] in ntdll (0x0033fec8)
12 0x7ef8d6b2 process_attach+0x91(wm=0x110a50, lpReserved=is not available)
[/home/david/wine/dlls/ntdll/loader.c:1063] in ntdll (0x0033ff28)
13 0x7ef8d6b2 process_attach+0x91(wm=0x110690, lpReserved=is not available)
[/home/david/wine/dlls/ntdll/loader.c:1063] in ntdll (0x0033ff88)
14 0x7ef8d6b2 process_attach+0x91(wm=0x1107b8, lpReserved=is not available)
[/home/david/wine/dlls/ntdll/loader.c:1063] in ntdll (0x0033ffe8)
15 0x7ef8d8e3 attach_process_dlls+0x52(wm=0x1107b8)
[/home/david/wine/dlls/ntdll/loader.c:2541] in ntdll (0x)
0x7e96fc9d create_alpha_bitmap+0x1cd
[/home/david/wine/dlls/user32/cursoricon.c:771] in user32: movb
%dl,0x0(%edi,%ecx,4)
771 ptr[0] = ptr[0] * alpha / 255;
Any way to bypass it?
Thanks in advance
David
[no subject]
On 24 June 2010 05:18, Misha Koshelev misha680 at gmail.com wrote: Dan suggested tests ok during code freeze so blame Dan for my patches ;) Certainly will. wine-devel is an open mailing list, and posting is easy. You'll probably want to check with something like git shortlog -s -n if the advice you're getting is actually worth taking. The way I see it, you have more experience with getting patches accepted yourself. More to the point, if you look at http://source.winehq.org/patches/, you'll see 62909 is marked as Deferred, so resending in a slightly different form isn't going to help much. As for the patch itself, I'm not convinced there's value in having a separate file for Shape Drawing Functions, these are clearly mesh constructors. I thought the original patch was mostly ok in that regard, although there are (very) minor issues like using %d for unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 over simply IDirect3DDevice9 *. So I don't think I'm going to be getting much productive done with 1.2 bugs done in a single day, and the one I started working on yesterday is now fixed. So might as well start thinking about D3DX9. So here is why I thought maybe having a separate shape.c file might be good. I am very new to D3DX9 so please pardon my ignorance, but simply looking at SDK, I see: i) http://msdn.microsoft.com/en-us/library/bb172976%28v=VS.85%29.aspx Shape Drawing Functions are all defined in D3dx9shape.h whereas http://msdn.microsoft.com/en-us/library/bb172973%28v=VS.85%29.aspx Mesh Functions are all defined in D3dx9mesh.h This is not a reason to implement shape drawing functions in a separate file _per se_, but additionally: ii) all the tests in mesh.c do not rely on CreateWindow calls or Direct3DCreate9 calls whereas those for shape functions inherently will (like line.c) Thus, since I'm going to try to focus on d3dx9 stuff (hope code-freeze is over July 4th), it seems like it might be good to have a separate file. What is the argument for keeping them all in the mesh file besides that they are mesh creation functions? Thank you Misha
[no subject]
http://IvanaKalmus0627.co.cc
Re: [put the subject here]
Pavel Procházka pavelvonlost...@seznam.cz wrote: Subject:[2/3] wined3d: IWineGDISwapChainImpl_Present relevant to windows implementation Making multibuffering working well when flip - sequence is W RGB, R GBW, G BWR, B WRG, W RGB. When W = WHITE, R = RED, G = GREEN, B = BLUE. It is doing well for any count of backbuffers - for 1 too. Please try to make the patch subject short and clear. All additional comments put in the patch body. -back = (IWineD3DSurfaceImpl *) This-backBuffer[0]; +back = *((IWineD3DSurfaceImpl *)This-backBuffer[0]); /*this value can not be pointer*/ Any reason for the above change and comment? +/*moving data from backbuffers to left - no pointers!*/ +for(i=0;iThis-presentParms.BackBufferCount-1;i++) Some spaces wouldn't hurt, and would better match the code you are changing. -- Dmitry.
[no subject]
Hi, I have a huge amount of Windows code that I'm porting to Linux. Wine is turning out to be a read godsend, thank you guys! Anyway, I've had tons of luck including the directory wine_dir/include/wine/windows in my include path. All my Windows types are there and everything is wonderful. I've even been able to link against the libraries by renaming, for example, foo.dll.so to libfoo.so and using -lfoo on the g++ command line. I actually haven't got all my functions defined so I don't know if this will actually run yet because the link isn't complete yet. My first question is whether this will work. Will all my Windows functions with function declarations defined in the windows directory and code compiled into foo.dll.so actually run? Second, I see that some of the functions I want to use are actually defined by headers in the msvcrt directory. However, this directory contains tons of header files that my system (and gcc) also have under /usr/include and gcc's own directories. I understand that msvcrt is Windows lib c, but I wonder how I'm supposed to use it with gcc to compile? I've tried -nostdinc to gcc, but the number of errors I get is enormous. It's not the end of the world if I can't use Wine's msvcrt, but if I could use it, it would define dozens more functions on which my program relies, or if its use was mandatory in order to get the functions implemented in foo.dll.so to work, then obviously I wonder how I'm supposed to compile my Windows code with Wine to make everything work? I'm sorry if this is a dumb question. I can't find a way to search the wine-devel mailing list other than with google and I can't find anything on there or other docs that answer this question, which I'm sure has been asked a million times and has a simple answer. Thank you thank you, Jeff _ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_122008
[no subject]
Sorry my previous email got wrong format. Dan Kegel wrote: This guide seems rather well written: http://ldn.linuxfoundation.org/how-participate-linux-community Wine could probably use something similar. YES, the Wine development speed can be greatly improved if similar development process is adepted, specially the 'Chain of Commands'. I am sure that Alexandre has done a great job as the Wine maintainer, but he may be stressed out when he comes back from his holiday as there are pile of patches awaiting him to review and commit. Hongbo Ni _ Win a Nokia E51 with mobile Hotmail SMS alerts http://www.livelife.ninemsn.com.au/compIntro.aspx?compId=4589
[no subject]
[EMAIL PROTECTED]
[no subject]
Cc: Bcc: Subject: Re: xlviewer install cmdline passed from CreateProcessA to msiexec looks wrong Reply-To: In-Reply-To: [EMAIL PROTECTED] After doing further debugging I've come to the conclusion that the behaviour found when I was looking at bug 9628 is indeed a bug and have logged a new one accordingly with as much detail as I thought was necessary. http://bugs.winehq.org/show_bug.cgi?id=10618 Basically it turns out that if a program is called via CreateProcessW, the command line used may not result in the same argv being passed to the target program as it was called directly. In this case there was a difference in the argv seen by msiexec depending on whether it was run directly or called by the setup exe. Traced the bug to a corner case in the function build_argv in dlls/kernel32/process.c. Basically it does not detect the end of the argument correctly when dealing with the following text. SETUPEXEPATH=\C:\\windows\\temp\\IXP030.TMP\\\ Because of the escaped '\', which should be valid since it is part of a directory path, at the end followed by the escaped '', the function thinks that it has just encountered an escaped '' instead of the end of the argument. I'm not 100% sure how to solve this, so I will probably have to run some tests on windows using the CreateProcessW call and study the argv received by the target. I have a feeling that the rule is probably something like: If in quotes text before slashes != whitespace text after quote == whitespace: then found matching quote Hopefully I should be able to come up with test cases that will show the truth of this, and then be able to confirm what the function build_argv should be testing to catch cases like this. -- Darragh Nothing is foolproof to a sufficiently talented fool.
[no subject]
Hi! I'm trying to install Wine for a client, a Mac house, who run some software only supported under Windows or Classic. With the recent introduction of Intel Macs (that no longer support Classic) into the business, the Windows version is, unfortunately, their only upgrade path. I have C development experience and am familiar with compiling C applications under unix, although that was some years ago and processes seem to have changed somewhat. In particular, I am unfamiliar with the 'configure' executable described in your installation manual, which is raising an error. Could you please look briefly at the attached config.log? I would be interested to know if this is an issue to which I can attend, or whether it is a deficiency in the configuration process itself. I would also appreciate a workaround, if possible. Thanks in anticipation of your assistance. Regards, // // // / / Colin M Inglis BInfoTechComm // // / / Software Application Development /// //\//\\ infinite 15 Jasmine St, Strathpine, Q, Australia // // // // Snailmail PO Box 2188 Strathpine Q 4500 /// \\//\// interface email [EMAIL PROTECTED] / // // / / web http://www.infinitei.com.au // // // / / Ph/Fax+61 7 3881 3494 ABN: 40 030 880 342 Mobile+61 414 388 134 infinite interface programmes programmes users use config.log Description: Binary data
Re: No Subject
On Fr, 2007-11-09 at 11:38 +1000, Colin M Inglis wrote:
your gcc is unable to compile this simple program:
| int
| main ()
| {
|
| ;
| return 0;
| }
Reason:
/usr/bin/ld: can't locate file for: -lcrt1.o
you need the development files for the c runtime library
(this is libc6-dev here)
--- cut ---
GNU C Library: Development Libraries and Header Files
Contains the symlinks, headers, and object files needed to compile
and link programs which use the standard C library.
--- cut ---
--
By by ... Detlef
(no subject)
Rob Shearman wrote: -static OLEFontImpl* OLEFontImpl_Construct(LPFONTDESC fontDesc); +static OLEFontImpl* OLEFontImpl_Construct(const FONTDESC *fontDesc); static void OLEFontImpl_Destroy(OLEFontImpl* fontDesc); static ULONGWINAPI OLEFontImpl_AddRef(IFont* iface); Even if the compiler allows this, it does not make sense. Why would a constructor not want to modify the object it is constructing? If I'm not mistaken, the input parameter points to the template from which it is copying, rather than the object it is constructing, in this case. -- Andy.
(no subject) (WAS: Re: Drop-in replacement of windows dll's?)
On 5/8/07, Brian Vincent [EMAIL PROTECTED] wrote: On 5/8/07, Tom Spear [EMAIL PROTECTED] wrote: That would be the framework. I appreciate the response. Is this something that either now or in the future will be officially supported by wine, or even a true goal of wine, or is it more of a side project for you and some others? It's not an explicit goal, but it does work, and it is a configuration that we want to keep working. It's just not a configuration that gets tested every day, so there might be some little issues. Previously ReactOS was the big consumer of Wine DLL's as PE. Ok, thanks for the input. Thanks to all of the developers for their hard work, and dedication. Unfortunately I am going to have to mute myself on the list (I can hear the sighs of relief now), as I dont think I am getting anywhere trying to get even trivial patches committed. I sent a patch over a week ago to correct a trace message (not the one for winecfg, but one for uninstaller), and it never got committed. Then I get told to send all of my patches to a developer privately for review before I send them to the patches list, and when I send them to that developer, I _basically_ get told that I should bother submitting them. I know I'm not good enough to even write conformance tests right now, which is why I dont work on the major API's or even on the conformance tests, but sheesh, what do I have to do to get one problematic trace fixed? I'll send that patch one more time, just to make sure it got to the list, and I would appreciate someone offering some comment if there is a reason that it should not be committed. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email
(no subject)
(no subject)
I was installing ls2004.exe (Lan Suite) from http://www.software602.com on a Slackware Linux 10.2 system using wine 0.98 from your website when at the end of the installation this error was coming up ! Error Code:-5011 : 0x80020005 Error Information: Kernel\TextSubstitution.cpp (292) SetupDLL\SetupDLL.cpp (524) PAPP:602LAN SUITE PVENDOR:Software602 (www.software602.com) PGUID:40302AB2-A711-11D7-B6B5-0003476E88E5 $7.1.100.1248PAK @Windows 2000 Service Pack 4 (2195) BT_OTHER 30065.16410 I hope you can download and install and test this Lan Suite so that it will work in wine-1.0 WMH
Re: (no subject)
Hi, I was installing ls2004.exe (Lan Suite) from http://www.software602.com on a Slackware Linux 10.2 system using wine 0.98 from your website when at the end of the installation this error was coming up ! I doubt that this app can ever fully work in Wine. A mail server isn't the problem, an anti-spam filter shouldn't make a problem too, but a firewall and NAT need the windows packet filter. There's not much sense in allowing Windows apps to configure the Linux packet filter. There are many Linux apps that can do that much better, and it's a very low-level thing. The anti-virus functionality depends on how it works. If it's a check that just opens a file and checks it, then there's no reason why it shouldn't work, but if it has an on-demand checker, than it needs very deep kernel integration too. Stefan Dösinger PS: In general, general problems with applications should be discussed at the wine-users list. A mail subject is a good idea too ;) pgpy3Bknne2oM.pgp Description: PGP signature
(no subject)
Hi Maintainers, For the recent wine releases , is there any binary rpm's are available ? In the winehq.com I am able to get the following message only.. Binary packages are in the process of being built, but the source is available now. You can find out more about this release in the announcement. Check out our download page for packages for your favorite distribution. Even in the downloads, installation of the RPM's ( otherthan Source RPM ) is giving problems mainly ( dependancy problems ) . One more question : Is development RPM includes all the required S/W ? or Do I need to download other RPMs also ( i386 or i686 ) ? Thank you
Re: (no subject)
On Mon, Jan 16, 2006 at 02:40:57PM +0530, Ananth M wrote: Hi Maintainers, For the recent wine releases , is there any binary rpm's are available ? Sure. Just check http://sf.net/projects/wine/. Ciao, Marcus
(no subject)
I get this error when trying to install j2se with wine, i think is has something to do with windows installer, but ihave installed InstMSIA.exe manually with wine ( i dont get any error or see any installation box with wine InstMSI.exe). Has somebody tried to install JAva with wine? This is the output WINEDBG=+loaddll wine jdk-1_5_0_06-windows-i586-p.exe wine: Unhandled page fault on read access to 0x80002b1c at address 0x4d5d5b (thread 000c), starting debugger... WineDbg starting on pid 0x9 Unhandled exception: page fault on read access to 0x80002b1c in 32-bit code (0x004d5d5b). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:004d5d5b ESP:7fc8fd24 EBP:7fc8fd64 EFLAGS:00010282( - 00 - RIS1) EAX:0009 EBX: ECX:80002b08 EDX:000c ESI:80002b08 EDI: Stack dump: 0x7fc8fd24: 0048 004d5b8f 004d17c6 0x7fc8fd34: 7fec0b40 004d15a4 00bfd1b0 00911f7c 0x7fc8fd44: 7fc8fd64 00911fa2 7fc8fd34 7fc8f8e0 0x7fc8fd54: 7fc8ff2c 004d53e8 00514a70 0x7fc8fd64: 7fc8fd84 00bcc611 004d 0001 0x7fc8fd74: 0001 0001 0001 00bfd1b0 0200: sel=1007 base=7befc000 limit=1fff 32-bit rw- Backtrace: =1 0x004d5d5b in rpcrt4 (+0x5d5b) (0x004d5d5b) 2 0x00bcc611 call_dll_entry_point+0x15 in ntdll (0x00bcc611) 3 0x00bcd252 MODULE_InitDLL+0x12a [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:816] in ntdll (0x00bcd252) 4 0x00bcda98 process_attach+0x98 [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:891] in ntdll (0x00bcda98) 5 0x00bcda6e process_attach+0x6e [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:883] in ntdll (0x00bcda6e) 6 0x00bcda6e process_attach+0x6e [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:883] in ntdll (0x00bcda6e) 7 0x00bcfe19 LdrInitializeThunk+0x319(main_file=0x0, unknown2=0x0, unknown3=0x0, unknown4=0x0) [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:2001] in ntdll (0x00bcfe19) 8 0x005eff1f start_process+0x8b(arg=0x0) [/home/curro/WineHQrpm/wine-0.9.5/dlls/kernel/process.c:1017] in kernel32 (0x005eff1f) 9 0x0033185b _IO_vfprintf_internal in libc.so.6 (0x0033185b) 0x004d5d5b: cmpl0x14(%esi),%eax Modules: Module Address Debug info Name (43 modules) ELF 0x0025f000-00299000 Deferredadvapi32elf \-PE 0x0027-00299000 \ advapi32 ELF 0x002c8000-002cd000 Deferredlibxxf86vm.so.1 ELF 0x002d2000-002ee000 Deferredld-linux.so.2 ELF 0x002ee000-0031c000 Deferredlibfontconfig.so.1 ELF 0x002ee000-0031c000 Deferredlibfontconfig.so.1 ELF 0x002f4000-0041e000 Export libc.so.6 ELF 0x00346000-0043c000 Deferredlibwine_unicode.so.1 ELF 0x0042-00426000 Deferredlibxxf86dga.so.1 ELF 0x0042-00426000 Deferredlibxxf86dga.so.1 ELF 0x00446000-0044a000 Deferredlibdl.so.2 ELF 0x0044a000-004cb000 Deferredgdi32elf \-PE 0x0044c000-0045f000 \ libz.so.1 \-PE 0x0046-004cb000 \ gdi32 \-PE 0x0046-004cb000 \ gdi32 PE 0x004d-00522000 Deferredrpcrt4 ELF 0x00537000-00549000 Deferredlibpthread.so.0 ELF 0x0054b000-0055a000 Deferredlibxext.so.6 ELF 0x0055c000-00565000 Deferredlibsm.so.6 ELF 0x00567000-00581000 Deferredlibice.so.6 ELF 0x00583000-005a2000 Deferredlibexpat.so.0 ELF 0x00583000-005a2000 Deferredlibexpat.so.0 PE 0x005b-0067e000 DIA kernel32 PE 0x005b-0067e000 DIA kernel32 PE 0x005b-0067e000 DIA kernel32 PE 0x0068-0086c000 Deferredmsi ELF 0x0086c000-0097a000 Deferreduser32elf \-PE 0x0089-0097a000 \ user32 \-PE 0x0089-0097a000 \ user32 ELF 0x00975000-009f Deferredlibgl.so.1 ELF 0x00975000-009f Deferredlibgl.so.1 PE 0x009f-00a59000 Deferredwinex11 ELF 0x00b2d000-00b4c000 Deferredximcp.so.2 ELF 0x00b4c000-00b67000 Deferredimm32elf \-PE 0x00b5-00b67000 \ imm32 ELF 0x00b99000-00c09000 Stabs ntdllelf \-PE 0x00bb-00c09000 \ ntdll ELF 0x00ea3000-00ea5000 Deferredxlcutf8load.so.2 ELF 0x00ef1000-00f07000 Deferredmsiexecelf \-PE 0x00f0-00f07000 \ msiexec ELF 0x00fed000-00ff8000 Deferredlibnss_files.so.2 PE 0x65f0-65fc2000 Deferredole32 ELF 0x7bf0-7bf03000 Deferredwine-loader Threads: process tid prio (all id:s are in hex) 0009 (D) C:\windows\system32\MSIEXEC.EXE 000c0 == 0047 00080 001e 00262
Re: (no subject)
1. When wine changes screen resolution, it changes resolution of desktop and that move my icons and i must arrange it manually after game exit and that is the problem. Please make that resolution switching like cedega. Cedega changes the screen resolution, but desktop dimensions are unchanged. That's a Xrandr issue: Wine uses Xrandr to change the screen resulution: Both the virtual Desktop and the Screen resolution are changed. Cedega only changes the Screen resolution just as if you typed Ctrl + alt + +. The reason why Wine so is a mouse locking issue: dinput.dll fails to lock the mouse inside the Wine window often, and if the Desktop is bigger than the screen, one can accidentally move the mouse outside the game window. The solution to this one is to fix dinput and avoid the use of Xrandr. There's a registy key to force the cedega behavior I think it's HKCU\Software\Wine\X11 Driver\UseXrandr, but I am not sure. 2. Where is the config? Implementation of winecfg isn't good choice. Config file was good so why you have removed it? Existence of that config file will be welcomed for many users, which wants to edit some options, which they can't edit now. You can still edit them in the registry files. Have a look at HKCU/Software/Wine/ This path is stored in ~/.wine/user.reg, which can be edited with any text editor. 3. The -workdir option. When i try to run some programs or when i try to install something, sometimes wine can't find files needed by installer or installed game. Cedega uses -workdir parameter which sets the directory, where are that files. I couldn't install or run many games and programs because of Wine can't find that files, which are needed. (e.g. wine -workdir /root/.wine/drive_c/warcraft III/ C:/warcraft III/Frozen Throne.exe) I don't think such an option is needed - You can simply cd into the needed directory. If you want to run the app from a GUI menu, you can set a working path for that menu entry. pgpLWkudcT0bB.pgp Description: PGP signature
(no subject)
Hi! I have some reminds about your product Wine 1. When wine changes screen resolution, it changes resolution of desktop and that move my icons and i must arrange it manually after game exit and that is the problem. Please make that resolution switching like cedega. Cedega changes the screen resolution, but desktop dimensions are unchanged. 2. Where is the config? Implementation of winecfg isn't good choice. Config file was good so why you have removed it? Existence of that config file will be welcomed for many users, which wants to edit some options, which they can't edit now. 3. The -workdir option. When i try to run some programs or when i try to install something, sometimes wine can't find files needed by installer or installed game. Cedega uses -workdir parameter which sets the directory, where are that files. I couldn't install or run many games and programs because of Wine can't find that files, which are needed. (e.g. wine -workdir /root/.wine/drive_c/warcraft III/ C:/warcraft III/Frozen Throne.exe) Thats all what i wanted to write. U have done good work so good luck forever.
Subject: Re: Newsleecher Installer Failing
For information on debugging, these official docs may help http://www.winehq.org/site/docs/wine-devel/debugging http://www.winehq.org/site/docs/wine-devel/index http://wiki.winehq.org/DebuggingTutorials there is an unofficial list of examples from the mailing lists, here. http://wine-wiki.org/index.php/Debugging_Wine if you see or think of something that could be added to the official documents - please send a suggestion to the wine-devel list. -- Joseph Black
(no subject)
Still struggling here. looks like a bug in the start up checks of the app. since the file it is looking for exists in the current directory. how can I trace in to find out the real cause of the exceptions? TIA/ 21:02:38 File c:\windows\speech\vcmd.exe: Version 4.0.4.3405 21:02:38 File c:\windows\speech\vcmshl.dll: Version 4.0.4.2903 21:02:38 File c:\PROG~FBU\ScanSoft\NATU~BD1\Program\dnstk10.dll: Version 7.0.0.2 21:02:38 File c:\PROG~FBU\ScanSoft\NATU~BD1\Program\dmfc6.dll: Version 7.0.0.0 21:02:38 File c:\PROG~FBU\ScanSoft\NATU~BD1\Program\dd10enum.dll: Version 7.0.0$ 21:02:38 File c:\PROG~FBU\ScanSoft\NATU~BD1\Program\dmfc6.dll: Version 7.0.0.0 21:02:38 Exception thrown (d:\work\px\trouble\tests.cpp, 936). 21:02:38 21:02:38 Cannot find the file 'nstex50.dll' 21:02:38 QuickCheck Failed. 21:02:55 Final Termination
(no subject)
Dimi wrote: http://kegel.com/wine/qa Good page. Thanks! I'm afraid that it will not get enough exposure up on your site though, Don't underestimate the power of search engines to find obscure content... but I agree. it seems to me it would fit perfectly into our Wiki. Ditto for the other (excellent) Wine pages you have there. Sorry, I'm allergic to wikis. I much prefer editing in vi. I'd be happy to add it to the winehq.org web site once I've gotten it up to snuff. [ If the wiki stored its files in the same cvs archive as winehq.org does, we'd have the best of both worlds... wonder why no wikis are set up like that.] By the way, do you happen to know how one gets permission to modify bugzilla reports? That's kind of needed so the more experienced bug triage volunteers can add keywords, etc., and I'd like to add that info to my page. - Dan
(no subject)
You can also set it yourselves in in your app. As configuration is in registry, every app can modify it. I like this idea, thanks. There are still 2 issues with such a soultion: a) most likely, it won't work until 2nd start of the application (we will modify it on the first run, and it most likely won't be applied until the second run); b) current WINE guides are discouraging us from detecting WINE - and messing up with Windows Registry, especially HKEY_LOCAL_MACHINE, on all the millions of non-WINE machines is not a thing I would really like to do (the last thing we want is to be caught by some antivirus, which monitors activity it considers suspicious and changing HKEY_LOCAL_MACHINE can easily qualify). _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
(no subject)
To: Jan Jezabek [EMAIL PROTECTED] Cc: wine-devel@winehq.com Subject: Re: avifil32, msvfw32 and friends References: [EMAIL PROTECTED] [EMAIL PROTECTED] From: Michael Guennewig [EMAIL PROTECTED] Date: 12 Jun 2005 11:07:29 +0200 In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Lines: 43 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Jan Jezabek [EMAIL PROTECTED] writes: Jan Jezabek wrote: Hi, What is the current state of VfW support? I have tried a few applications, and they seem to fail sooner or later: - I've also got a program written by me, which reads an AVI and stores the video part on disk. Here the problem seems to be AviFileInit which seems not to be implemented. AviFileInit isn't implemented currently as the library is hard-linked to ole32.dll. Are there any parts of the AVI reader implemented or are they only stub= s? Most of the code should be in when I remember correctly. As far as I know the remote stuff, like the marshaller and proxy is missing. As well as it= =20 still is not thread safe. =20 Ok, this post was probably better suited for the 'users' list. Anyway, I've posted a patch that solves the first issue. The second one is a little harder; it works ok using builtin msvfw32 and native (winXP) avifil32.dll. With the builtin avifil32.dll I can open an AVI, get a video stream, read its format (dimensions etc.). After that I get a segfault somewhere in AviStreamGetFrame. Is this (AviStreamGetFrame) supposed to be working? Or is it partially implemented/broken? It seems that the AVI (or at least the header) is being parsed correctly. The IGetFrame interface uses the msvfw32.dll and the video codecs. It work= ed for some codecs that I have tried in past as I have written it, but it may = be that either a regression occured or that the video codec you are using just returns a NULL pointer where the code does not expect it. I could try to remember what I have written and support you to fix it, but I would need mo= re informations. Like which video codec, programm, AVI headers and which meth= ods=20 gets called and where does it segfaults. For the last parts it would be ni= ce=20 if you could send me a trace which shows msvfw32 and avifil32 calls. Regards, Michael G=FCnnewig
Subject: Re: Faster TlsAlloc() or zero_bit_scan
Not all You can every write in c/c++. Sometime You need a call for a library function. I think, that can be one and I think, not only TlsAlloc use a zero_bit_scan. Dietrich On Thu, 10 Feb 2005 18:59:21 +0100, Dietrich Teickner wrote: I have a suggestion for a faster implementation of the zero_bit_scan in RtlFindClearBits [EMAIL PROTECTED] (rlbitmap.c) for e.g. TlsAlloc() The main is the usage of the instruction 'bsf eax, eax' This I have implemented in the new experimental odinxp-tree for finding the first zero_bit in the first 'bytecount' bytes of the bitmap addr. Does this actually make a noticeable difference? Rewriting stuff in assembly for theoretical performance improvements isn't so great, as far fewer people can read/write assembly than C. thanks -mike
Subject: Re: Faster TlsAlloc() or zero_bit_scan
Not all You can every write in c/c++. Sometime You need a call for a library function. I think, that can be one and I think, not only TlsAlloc use a zero_bit_scan. It must be first zero_bit in the first 'bytecount' DWORD from the bitmap addr. Dietrich On Thu, 10 Feb 2005 18:59:21 +0100, Dietrich Teickner wrote: I have a suggestion for a faster implementation of the zero_bit_scan in RtlFindClearBits[EMAIL PROTECTED] (rlbitmap.c) for e.g. TlsAlloc() The main is the usage of the instruction 'bsf eax, eax' This I have implemented in the new experimental odinxp-tree for finding the first zero_bit in the first 'bytecount' bytes of the bitmap addr. Does this actually make a noticeable difference? Rewriting stuff in assembly for theoretical performance improvements isn't so great, as far fewer people can read/write assembly than C. thanks -mike
Re: (no subject)
Tom [EMAIL PROTECTED] wrote: I changed the format to reflect the other version.rc files +#define WINE_PRODUCTNAME_STR winsock You don't need to invent a product name, it's already defined in include/wine/wine_common_ver.rc. The product name is Wine. -- Dmitry.
Re: (no subject)
On Sun, 21 Nov 2004 00:27:46 +0800, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Tom [EMAIL PROTECTED] wrote: I changed the format to reflect the other version.rc files +#define WINE_PRODUCTNAME_STR winsock You don't need to invent a product name, it's already defined in include/wine/wine_common_ver.rc. The product name is Wine. Thanks, So should we remove the DirectX product name from the DirectX .rc files or just leave it as is ? Tom
Re: (no subject)
Tom [EMAIL PROTECTED] wrote: So should we remove the DirectX product name from the DirectX .rc files or just leave it as is ? I think it's up to DirectX maintainers, although I personally would prefer to use Wine as the product name everywhere without exceptions. After all that's a reason of include/wine/wine_common_ver.rc. -- Dmitry.
(no subject)
Maybe we should forbid TCHARs in the programs/ directory too... OK this is probably a lame question, but what does one do when he wants to implement a function that has a TCHAR parameter? Ivan. Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it
(no subject)
hi. i m new user Linux redhat.jop is Graphic Desgner.i want to shot Win Xp enought for virus and all bad thinks.but i need to use photoshop, flash, and other soft working with Windows. and i learned yesterday "wine" is makeing work with linux this software.is it true. i try to download it . but couldent find anywhere.could you give mea link . where ami download it. At your site too much packages . could you give to me a link all packages at 1 download file. couse i m newer user to diffucult do set up and download it for me at now. Regards.
(no subject)
I tried installing .net framework 1.1 on wine but it always fails. It says, Microsoft .NET Framework 1.1 setup has ended prematurely.. . Does anyone know what should be done like what are the dlls and configuration needed in order for it to finish installing? Yahoo! Messenger - Communicate instantly...Ping your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html
(no subject)
For example, if DirectX is broken for 3 consecutive releases, I would expect the people doing the release to label the old 'working' version and branch from there if any bugs fixes are needed. Things in wine break all the time, users know it and are used to it, if d3d8 breaks for 3 releases, people will just use an old version until things are fixed. Many people stayed at wine-20031212 for months because of regressions that weren't fixed for a few months, but people just kept wine-20031212 and were happy. With alpha software this is quite normal. Ivan.
Re: (no subject)
Am Freitag, 3. September 2004 22:35 schrieb Pablo Szuster: Hi, i´m trying to access a MSSQL server (in a windows machine in the network) from a Visual Basic Application running under wine, using an ODBC driver. Since there aren´t any MSSQL drivers for linux i decided to use de native ones, so i installed mdac_typ.exe . Then i configured the DSN using odbcad32.exe but when i tested the connection (configured using tcp/ip) an error message appeared ([Microsoft][ODBC SQL Server Driver][TCP/IP Sockets] General network error. Check your network documentation). Do i have to install some network drivers for wine?? Has anyone been able to connect to a MSSQL server remotely using odbc under wine?? __ Todavía no tenés tu Ciudad Internet Mail? Obtenelo ahora! - http://webmail.ciudad.com.ar Descargá Gratis el nuevo Internet Explorer 6.0, el mejor software para actualizar tu PC. http://www.ciudad.com.ar/ar/servicios/ie/ Did you set odbc32 = native in the config file ? Bye Stefan
Re:Re: (no subject)
Am Freitag, 3. September 2004 22:35 schrieb Pablo Szuster: Hi, i´m
trying to access a MSSQL server (in a windows machine in the network)
from a Visual Basic Application running under wine, using an ODBC
driver. Since there aren´t any MSSQL drivers for linux i decided to use
de native ones, so i installed mdac_typ.exe . Then i configured the DSN
using odbcad32.exe but when i tested the connection (configured using
tcp/ip) an error message appeared ("[Microsoft][ODBC SQL Server
Driver][TCP/IP Sockets] General network error. Check your network
documentation"). Do i have to install some network drivers for wine??
Has anyone been able to connect to a MSSQL server remotely using odbc
under wine??
__ Todavía no
tenés tu Ciudad Internet Mail? Obtenelo ahora! - http://webmail.ciudad.com.ar
Descargá Gratis el nuevo Internet Explorer 6.0, el mejor software para
actualizar tu PC. http://www.ciudad.com.ar/ar/servicios/ie/Did
you set"odbc32" = "native"in the config file
?Bye Stefan
yes, i tried both ways (native, builtin) without
success!
(no subject)
Hi, i´m trying to access a MSSQL server (in a windows machine in the network) from a Visual Basic Application running under wine, using an ODBC driver. Since there aren´t any MSSQL drivers for linux i decided to use de native ones, so i installed mdac_typ.exe . Then i configured the DSN using odbcad32.exe but when i tested the connection (configured using tcp/ip) an error message appeared ([Microsoft][ODBC SQL Server Driver][TCP/IP Sockets] General network error. Check your network documentation). Do i have to install some network drivers for wine?? Has anyone been able to connect to a MSSQL server remotely using odbc under wine?? __ Todavía no tenés tu Ciudad Internet Mail? Obtenelo ahora! - http://webmail.ciudad.com.ar Descargá Gratis el nuevo Internet Explorer 6.0, el mejor software para actualizar tu PC. http://www.ciudad.com.ar/ar/servicios/ie/
(no subject)
I have found a problem in wine,when I want to scroll in emulated apliccation.Wine crashes with an error message.And wine ask me if I want to debug crashed application.Please correct this problem in new version. --- VYHRAJ vlastn medaili ve sportovn arn na http://ateny2004.centrum.cz
Re: (no subject)
[EMAIL PROTECTED] wrote: I have found a problem in wine,when I want to scroll in emulated apliccation.Wine crashes with an error message. And wine ask me if I want to debug crashed application. Please correct this problem in new version. And how you could expect it fixed in the next version if you didn't provide any detail about the crash, neither backtrace, nor even Wine version? -- Dmitry.
(no subject)
The following patch to dlls/shell32/shlexec.c revision 1.50 date: 2004/06/15 00:44:14; author: julliard; state: Exp; lines: +11 -3 Dmitry Timoshkov [EMAIL PROTECTED] Restore default open functionality of ShellExecute. introduced the following warning regressions: shlexec.c:722: warning: format argument is not a pointer (arg 11) shlexec.c:722: warning: format argument is not a pointer (arg 12) Would you mind fixing this? Gerald -- Gerald Pfeifer (Jerry) [EMAIL PROTECTED] http://www.pfeifer.com/gerald/
Re: (no subject)
If not, I would like to give it a try, but I need some documentation c.q. information on the functionallity of these functions /what they do etc http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wsalookupservicebegin_2.asp Ivan.
(no subject)
hi, I'm wondering if anybody is working on the WSALookupServiceBegin functions in winsock (socket.c) . If not, I would like to give it a try, but I need some documentation c.q. information on the functionallity of these functions /what they do etc. Any help appreciated. Robbert Yahoo! Messenger - Communicate instantly...Ping your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html
(no subject)
I am trying to compile Wine (the latest CVS) on Mac os x. If I emailed the wrong list
sorry
I noticed what I think is a bug
in file dll/kernel/console.c
around line 1003 exists function below
when compiling it gives me an error about x being undefined or something similar
COORD WINAPI GetLargestConsoleWindowSize(HANDLE hConsoleOutput)
{
COORD c;
c.X = 80;
c.Y = 24;
TRACE((%p), returning %dx%d\n, hConsoleOutput, c.X, x.Y);
return c;
}
#endif /* defined(__i386__) */
Changing the x.Y to c.X seems to fix the problem
COORD WINAPI GetLargestConsoleWindowSize(HANDLE hConsoleOutput)
{
COORD c;
c.X = 80;
c.Y = 24;
TRACE((%p), returning %dx%d\n, hConsoleOutput, c.X, x.Y);
return c;
}
I am not a programmer nor do I know how to create a patch or if I am correct in my
assumptions. Could some one please help me out?
Jeff
ps.. I now get an error compiling dbghelp. I am not on the computer I am compiling on
so I can't copy and paste the error. If there are typos in the error that is because
I am copying the code by typing it up
elf_module.c:627: error: previous declaration of 'elf_read_wine_loader_dbg_info'
dbghelp_private.h:275: error: previous declaration of 'elf_read_wine_loader_dbg_info'
elf module.c:71: warning: '__wine_dbch___default' defined but not used
make[2]: *** [elf_module.o] Error 1
make[1]: *** [dbghelp] Error 2
make: *** [dlls] Error 2
Re: (no subject)
On Tue, 13 Apr 2004 17:40:46 +, j.cooper1 wrote: I am trying to compile Wine (the latest CVS) on Mac os x. Hi, Thanks for the bug report. The best thing to do is produce a patch and mail it to [EMAIL PROTECTED] Wine on MacOS/X does not compile reliably. See the darwine project (darwine.opendarwin.org) for more information. You certainly will not be able to run native Windows programs with it any day soon. thanks -mike
(no subject)
The email http://www.winehq.com/hypermail/wine-patches/2004/03/0032.html contains a zip attachment, that contains a .scr file, chances are it's a virus. If it is, please remove it from the archive. Ivan.
(no subject)
I am having a problem compiling a simple winelib program which relies on a dll which uses the stdcall calling convention. I used pexports on the dll avisynth_c.dll to created the spec and then edited the file to removed the leading underscore in the names (without that it would not link). That file is attached. Than with only avisynth_c.h, avs2yuv.cpp and libavisynth_c.def in the current directory. I ran winemaker --console -iavisynth_c --single-target avs2yuv.exe . ./configure --with-wine=/opt/wine/ make then I copy the required DLL in the current directory and attempt to run it. But I get: ./avs2yuv err:module:import_dll No implementation for avisynth_c.dll.avs_create_script_environment imported from LC:\\WINDOWS\\SYSTEM\\avs2yuv.exe, setting to 0xdeadbeef err:module:import_dll No implementation for avisynth_c.dll.avs_get_frame imported from LC:\\WINDOWS\\SYSTEM\\avs2yuv.exe, setting to 0xdeadbeef err:module:import_dll No implementation for avisynth_c.dll.avs_get_video_info imported from LC:\\WINDOWS\\SYSTEM\\avs2yuv.exe, setting to 0xdeadbeef err:module:import_dll No implementation for avisynth_c.dll.avs_invoke imported from LC:\\WINDOWS\\SYSTEM\\avs2yuv.exe, setting to 0xdeadbeef err:module:import_dll No implementation for avisynth_c.dll.avs_release_value imported from LC:\\WINDOWS\\SYSTEM\\avs2yuv.exe, setting to 0xdeadbeef err:module:import_dll No implementation for avisynth_c.dll.avs_release_video_frame imported from LC:\\WINDOWS\\SYSTEM\\avs2yuv.exe, setting to 0xdeadbeef err:module:import_dll No implementation for avisynth_c.dll.avs_take_clip imported from LC:\\WINDOWS\\SYSTEM\\avs2yuv.exe, setting to 0xdeadbeef Usage avs2yuv4mpeg avsfile outfile Does anyone know what is going on. Here is the output of make if it will help: sed -e 's,@bindir\@,/usr/local/bin,g' -e 's,@winelibdir\@,.,g' ./wineapploader.in wineapploader || rm -f wineapploader LD_LIBRARY_PATH=/opt/wine//lib:$LD_LIBRARY_PATH /opt/wine//bin/winebuild -o avs2yuv.exe.dbg.c --debug -C. avs2yuv.cpp gcc -c -I. -I/opt/wine//include/wine/windows -g -O2 -fPIC -D_REENTRANT -o avs2yuv.exe.dbg.o avs2yuv.exe.dbg.c g++ -c -I. -I/opt/wine//include/wine/windows -g -O2 -fpermissive -fno-for-scope-D_REENTRANT -o avs2yuv.o avs2yuv.cpp LD_LIBRARY_PATH=/opt/wine//lib:$LD_LIBRARY_PATH /opt/wine//bin/winebuild -fPIC -o avs2yuv.exe.spec.c --exe avs2yuv.exe -mcuiavs2yuv.o -L/opt/wine//lib/wine -lavisynth_c gcc -c -I. -I/opt/wine//include/wine/windows -g -O2 -fPIC -D_REENTRANT -o avs2yuv.exe.spec.o avs2yuv.exe.spec.c g++ -shared -Wl,-Bsymbolic -o avs2yuv.exe.so avs2yuv.o avs2yuv.exe.dbg.o avs2yuv.exe.spec.o-L/opt/wine//lib-lwine -lwine_unicode -lwine_uuid -lm test -f avs2yuv || install ./wineapploader avs2yuv I attached the zip file with the source and any files I thought were relevant. If required I can send additional files dll's in a private email (such as the required dll's). Wine version 20031212 built from source on a RedHat System. I had the exact same problem when I used the debs from unstable (also version 20031212) on a libranet system. Is this a bug, or am I doing something wrong? When I used a a version of avisynth_c.dll which used cdecl on all API functions -- without changing the .def or header files -- instead of stdlib I do not have this problem. Naturally I do not expect it to run since I didn't recompile my code with the proper header files. I discovered this by accident because the previous version used cdecl and I had some old dll laying around in a place wine was able to find. Can anyone help me get this working? Am I doing something wrong or is this a bug in wine? Thanks in advance. --- http://kevin.atkinson.dhs.org LIBRARY avisynth_c.dll EXPORTS [EMAIL PROTECTED] @1 [EMAIL PROTECTED] @2 [EMAIL PROTECTED] @3 [EMAIL PROTECTED] @4 [EMAIL PROTECTED] @5 [EMAIL PROTECTED] @6 [EMAIL PROTECTED] @7 [EMAIL PROTECTED] @8 [EMAIL PROTECTED] @9 [EMAIL PROTECTED] @10 [EMAIL PROTECTED] @11 [EMAIL PROTECTED] @12 [EMAIL PROTECTED] @13 [EMAIL PROTECTED] @14 [EMAIL PROTECTED] @15 [EMAIL PROTECTED] @16 [EMAIL PROTECTED] @17 [EMAIL PROTECTED] @18 [EMAIL PROTECTED] @19 [EMAIL PROTECTED] @20 [EMAIL PROTECTED] @21 [EMAIL PROTECTED] @22 [EMAIL PROTECTED] @23 [EMAIL PROTECTED] @24 [EMAIL PROTECTED] @25 [EMAIL PROTECTED] @26 [EMAIL PROTECTED] @27 [EMAIL PROTECTED] @28 [EMAIL PROTECTED] @29 [EMAIL PROTECTED] @30 [EMAIL PROTECTED] @31 [EMAIL PROTECTED] @32 [EMAIL PROTECTED] @34 [EMAIL PROTECTED] @35 [EMAIL PROTECTED] @36 avs_sprintf @33 avs2yuv.zip Description: Zip archive
Subject: Re: using glXGetProcAddressARB
Hi all, first of all thanks for your comments on this. Lionel: Just noticed I accidentially forgot to CC the list. On Wed, Nov 19, 2003 at 11:04:00AM +0100, Lionel Ulmer wrote: It's a bug in the DRI libraries that I reported some time ago and should be fixed in the XFree 4.4 (or 4.5) release of the library part of the DRI. What are you referring to by 4.4 (or 4.5)? XFree86 4.4.0 isn't out yet, so I'm assuming you do not mean XFree86. For that, could you send me the output of your 'glxinfo' ? ---snip--- name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Gareth Hughes, Leif Delgass, José Fonseca OpenGL renderer string: Mesa DRI Mach64 20020227 [Rage Pro] x86/MMX OpenGL version string: 1.2 Mesa 4.0.3 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_texture3D, GL_EXT_texture_object, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_window_pos, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x29 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow ---snip--- As you can see, it is reporting GLX version 1.2. However, GL/glx.h on my system mentions something about GLX 1.4. Go figure... So, what is the fix to this problem? It would be trivial to have process_attach (in $(TOPDIR)/dlls/opengl32/wgl.c) to call wine_dlsym() for glXGetProcAddressARB without checking whether it is listed as an extension or not and to then check whether an error occured. BTW, I think I have just found a potential (though unlikely) problem with the code in wglGetProcAddress. It checks whether p_glXGetProcAddressARB (the return value of wine_dlsym) != NULL. However, according to dlsym(3), the value of a symbol may be NULL. Daniel
Re: Subject: Re: using glXGetProcAddressARB
What are you referring to by 4.4 (or 4.5)? XFree86 4.4.0 isn't out yet, so I'm assuming you do not mean XFree86. Well, I did not follow at all XFree's development cycle lately. I was told that the next major XFree tree would have this fixed. So it must be 4.4.0 :-) server glx vendor string: SGI server glx version string: 1.2 Well, so you are using GLX 1.2 and not 1.4 as Raphael told :-) At least, Wine checks only the runtime version, NOT the built-in versions. So, what is the fix to this problem? It would be trivial to have process_attach (in $(TOPDIR)/dlls/opengl32/wgl.c) to call wine_dlsym() for glXGetProcAddressARB without checking whether it is listed as an extension or not and to then check whether an error occured. Yeah, the fix is simply to remove the extension check (which was the code before I had a fit of spec correctiveness :-) ). BTW, I think I have just found a potential (though unlikely) problem with the code in wglGetProcAddress. It checks whether p_glXGetProcAddressARB (the return value of wine_dlsym) != NULL. However, according to dlsym(3), the value of a symbol may be NULL. Well, if a symbol value is 'NULL', I won't be able to call it anyway, no ? So it's exactly the same for me as a symbol that is not defined :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
(no subject)
_ Charla con tus amigos en línea mediante MSN Messenger: http://messenger.microsoft.com/es
