- Wine-Devel - list.winehq.org

Re: DirectDraw over Direct3D
by Roderick Colenbrander Dec. 16, 2005

Dec. 16, 2005

> This patch seems similar to glSDL where it wraps SDL's 2d API to > OpenGL. The good thing about this it can provide acceleration and not > require root like DGA. The bad thing with this idea is that it can't > be used on older video cards or even some newer ones that lack proper > direct rendering. Am I correct that even when just doing depth > conversions, without direct rendering it will still be slow? > Perhaps I should clarify some misunderstandings that some people have. (I hope I explain it correctly) Basicly DirectDraw provides a mechanism to directly access the framebuffer of the videocard. This is the fastest way to render 2D images on the screen. Games like StarCraft, Total Annihilation, C&C and lots of others use DirectDraw in this way. Second there's another class of games like Age Of Empires2, Heroes of Might and Magic IV and others which mix ddraw with GDI. They for instance render a image using ddraw and then use GetDC/ReleaseDC to get a device context so that they can draw in the surface. (directly into the video memory) In case of X direct framebuffer access is only possible through DGA but it is unsecure and has other issues. When DGA works correctly it can accelerate games like StarCraft. Further DGA doesn't have any depth conversion issues as it does depth switching. Without DGA the rendering operations need to go through X. Because of limitations of X, depth conversion problems appear when the depth of the desktop and X aren't the same. For depth conversion purposes Wine's DirectDraw uses a DIB section. Basicly all pixels of an image are translated to the depth of X. This is slow and especially for the case when the application requests 8bit paletted mode using a 24bit desktop. In this case a color lookup needs to happen in a palette for each pixel. The end result is then shown on the screen (if the game is of the StarCraft type) Games that use GetDC/ReleaseDC can't work using DGA. The performance in general isn't great as lots of X calls happen. (things like conversions from XPixmap to XImages and the way around and also depth conversions happen a lot) The patch I sent works for both classes of games though it won't help much for the second class as GetDC/ReleaseDC stuff is slow. As explained before the patch uploads the surface to a texture which is then rendered using OpenGL. This is quite fast and as a bonus the videocard can do all depth conversion for us as it isn't limited to rendering textures which are at the same depth as X. For old videocards the GL renderer won't work and the old code should work fine (except for performance issues). You might have heard people talking about a 'dibengine' which would let Wine do all DIB related operations in software which would save a lot of XImage/XPixmap conversions. (conversion is only needed for the final rendering stage) This dibengine would mainly accelerate games that use GetDC/ReleaseDC. It won't help games like StarCraft (much) as for those DIBs were only used for depth conversion and the conversion algorithm stays the same (it can't be tweaked much if at all). So there's not really a way to speedup games like StarCraft for old videocards. Perhaps XShm might be of use but not sure how much it would help. (think it would only be usefull for GetDC/ReleaseDC games) Roderick -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie -- Highspeed-Freiheit. Bei GMX superg�nstig, z.B. GMX DSL_Cityflat, DSL-Flatrate f�r nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl

4 6

question regarding FindWindow
by Marcus Meissner Dec. 15, 2005

Dec. 15, 2005

Hi, While debugging Google Earth I see hangs in FindWindow... Apparently the if (GetWindowTextW( list[i], buffer, len + 1 ) && !strcmpiW( buffer, title )) break; call hangs on the server... But how is this possible? +win,+server snippet: trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE 0009: redraw_window( window=0x10020, flags=00000005, region={} ) 0009: redraw_window() = 0 trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE 0009: redraw_window( window=0x10020, flags=00000005, region={} ) 0009: redraw_window() = 0 0009: get_window_children( parent=0x10020, atom=0000, tid=0000 ) 0009: get_window_children() = 0 { count=3, children={0x10026,0x10024,0x10022} } fixme:win:WIN_FindWindow before getwindowtext fixme:win:WIN_FindWindow after getwindowtext fixme:win:WIN_FindWindow before getwindowtext 0009: send_message( id=0010, type=1, flags=0, win=0x10024, msg=0000000d, wparam=00000023, lparam=55937970, x=0, y=0, time=000010a4, info=00 000000, timeout=0, callback=(nil), data={} ) 0009: send_message() = 0 0009: get_msg_queue( ) 0009: get_msg_queue() = 0 { handle=0x148 } 0009: set_queue_mask( wake_mask=00008040, changed_mask=00008040, skip_wait=1 ) 0009: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 } 0009: select( flags=4, cookie=0x55c1f6f8, signal=(nil), timeout=0, handles={0x148,0x80} ) 0009: select() = PENDING *hang* What debug to enable and what to look at? Ciao, Marcus

4 4

Re: fixme:font:load_VDMX Failed to retrieve vTable
by Curro Amores Dec. 15, 2005

Dec. 15, 2005

hi , sorry but im a bit desperated, i dont find the way of sorting out my problem. i send a snapshot of my report so you could give me a hint of what is going wrong, It's a access 97 app and i can not display reports correctly. ill be very pleased. The problem is that i dont get any error with WINEDBG

2 1

IBM Homepage Builder mostly functional with wine-0.9.3
by Dan Kegel Dec. 15, 2005

Dec. 15, 2005

Man, wine is getting good! Homepage builder seems to install and mostly work. Even the flash demo works. Kudos to the Wine developers! A few of the included tools crash on startup, though, e.g. http://bugs.winehq.org/show_bug.cgi?id=4082 And then there's that regsvr installation problem I just posted about. -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: Wine IE6 and JVM
by Tom Wickline Dec. 15, 2005

Dec. 15, 2005

On 12/15/05, Adrian Munteanu <adrian.munteanu(a)oracle.com> wrote: > Hi guys, > > I am trying to use wine with IE 6. > Most of the pages are displaying fine, however the problem is with pages > requesting JVM running. > So could you please help me find away, if available, to make IE use > installed JVM? Did you install msjavx86.exe or the JVM that Sun provides? Tom > > Thanks and best regards > Adrian > > >

1 0

Re: feedback wanted from arts, esound and jack sound driver users.
by Emanuel Rumpf Dec. 15, 2005

Dec. 15, 2005

Hi I have tried to run some apps with the wine-jack-driver. It is working, but I found it pretty unstable, especially with MME buffersizes below 100ms What I would like to see improved: 1. More stability, no zombification on buffer underruns (xruns) 2. Law latency connection for audio and midi (maybe ASIO emulation?), (MME brings additional buffers and latencies, "DirectSound" driver doesnt work with wine-jack) 3. Midi-support: With the wine-jack driver, there is no midi in/out port visible, which makes the driver useless for more serious audio works. thanks for your efforts regards, emanuel some notes: When I select the audio tab in winecfg I get: err:midi:MIDI_AlsaToWindowsDeviceType Cannot determine the type (alsa type is 100000) of this midi device. Assuming FM Synth Why/when should "Driver Emulation" be selected in winecfg? Example: Native Instruments Reaktor Session With MME selected and 140ms latency, it's running for some minutes... # Often this appears: fixme:wave:JACK_widMessage unknown message 2069! fixme:wave:JACK_widMessage unknown message 2069! fixme:wave:JACK_widMessage unknown message 2069! # As soon, as there is an xrun it zombifies zombified - calling shutdown handler could not attach as client could not attach as client err:wave:JACK_OpenWaveOutDevice jack server not running? err:wave:JACK_shutdown_wwo unable to reconnect with jack... # output of another crash wine: Unhandled page fault on read access to 0x00000130 at address 0x130 (thread 0009), starting debugger... err:seh:start_debugger Couldn't start debugger ("") (5) Read the Wine Developers Guide on how to set up winedbg or another debugger err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. fixme:winmm:MMDRV_Exit Closing while ll-driver open fixme:winmm:MMDRV_Exit Closing while ll-driver open wine: Unhandled page fault on write access to 0x7ec67825 at address 0x856e69 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x7ec67825 in 32-bit code (0x00856e69). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:00856e69 ESP:7fbafa70 EBP:7fbafd1c EFLAGS:00210246( - 00 -RIZP1) EAX:0000036c EBX:0000000f ECX:7ec67821 EDX:7fbafd2c ESI:00010022 EDI:0000000f Stack dump: 0x7fbafa70: 0000036c 00861694 0000036c 7ce40048 0x7fbafa80: 00000002 7ce3fae8 0086d107 00000000 0x7fbafa90: 00000000 7fbafd3c 00000000 7ff8a044 0x7fbafaa0: 7fbafb20 00000000 00000000 7fbafb2c 0x7fbafab0: 7fbafb20 7fbafb2c 7fbafb04 00000000 0x7fbafac0: 7fbafb04 7fbafb10 7fbafb04 7fbafb10 0200: sel=1007 base=7ff8a000 limit=00001fff 32-bit rw- Backtrace: =>1 0x00856e69 in reaktorsession (+0x456e69) (0x00856e69) 2 0x00000000 (0x00000000) 0x00856e69: movl %eax,0x4(%ecx) Modules: Module Address Debug info Name (93 modules) PE 0x00400000-01235000 Export reaktorsession ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7dafd000-7dbe1000 Deferred libdb-4.3.so ELF 0x7dbe1000-7dc2f000 Deferred libgcrypt.so.11 ELF 0x7dc2f000-7dc3f000 Deferred libtasn1.so.2 ELF 0x7dc3f000-7dca7000 Deferred libgnutls.so.12 ELF 0x7dca7000-7dcc3000 Deferred libcups.so.2 ELF 0x7dcdb000-7dcf0000 Deferred midimap<elf> \-PE 0x7dce0000-7dcf0000 \ midimap ELF 0x7de05000-7de26000 Deferred msacm32<elf> \-PE 0x7de10000-7de26000 \ msacm32 ELF 0x7de26000-7de3d000 Deferred libjack.so ELF 0x7de3e000-7de55000 Deferred msacm.drv<elf> \-PE 0x7de40000-7de55000 \ msacm.drv ELF 0x7de55000-7de70000 Deferred winejack.drv<elf> \-PE 0x7de60000-7de70000 \ winejack.drv ELF 0x7df68000-7df99000 Deferred uxtheme<elf> \-PE 0x7df70000-7df99000 \ uxtheme ELF 0x7dff3000-7e00f000 Deferred imm32<elf> \-PE 0x7e000000-7e00f000 \ imm32 ELF 0x7e00f000-7e02c000 Deferred ximcp.so.2 ELF 0x7e02c000-7e034000 Deferred libxrender.so.1 ELF 0x7e043000-7e04c000 Deferred libxcursor.so.1 ELF 0x7e0a7000-7e810000 Deferred libglcore.so.1 ELF 0x7e810000-7e88f000 Deferred libgl.so.1 ELF 0x7e88f000-7e95a000 Deferred libx11.so.6 ELF 0x7e95a000-7e968000 Deferred libxext.so.6 ELF 0x7e968000-7e97f000 Deferred libice.so.6 ELF 0x7e97f000-7e9fb000 Deferred winex11.drv<elf> \-PE 0x7e990000-7e9fb000 \ winex11.drv ELF 0x7e9fb000-7ea1b000 Deferred libexpat.so.1 ELF 0x7ea1b000-7ea4a000 Deferred libfontconfig.so.1 ELF 0x7ea4a000-7ea5e000 Deferred libz.so.1 ELF 0x7ea5e000-7eacb000 Deferred libfreetype.so.6 ELF 0x7eae3000-7eb2e000 Deferred dsound<elf> \-PE 0x7eaf0000-7eb2e000 \ dsound ELF 0x7eb2e000-7eb42000 Deferred lz32<elf> \-PE 0x7eb30000-7eb42000 \ lz32 ELF 0x7eb42000-7eb6a000 Deferred winspool.drv<elf> \-PE 0x7eb50000-7eb6a000 \ winspool.drv ELF 0x7eb6a000-7ebfc000 Deferred comdlg32<elf> \-PE 0x7eb80000-7ebfc000 \ comdlg32 ELF 0x7ebfc000-7ec26000 Deferred ws2_32<elf> \-PE 0x7ec10000-7ec26000 \ ws2_32 ELF 0x7ec26000-7ec41000 Deferred wsock32<elf> \-PE 0x7ec30000-7ec41000 \ wsock32 ELF 0x7ec41000-7ecc1000 Deferred winmm<elf> \-PE 0x7ec50000-7ecc1000 \ winmm ELF 0x7ecc1000-7ed6f000 Deferred comctl32<elf> \-PE 0x7ecd0000-7ed6f000 \ comctl32 ELF 0x7ed6f000-7ed8d000 Deferred iphlpapi<elf> \-PE 0x7ed80000-7ed8d000 \ iphlpapi ELF 0x7ed8d000-7edd1000 Deferred rpcrt4<elf> \-PE 0x7eda0000-7edd1000 \ rpcrt4 ELF 0x7edd1000-7ee57000 Deferred ole32<elf> \-PE 0x7edf0000-7ee57000 \ ole32 ELF 0x7ee57000-7eead000 Deferred shlwapi<elf> \-PE 0x7ee70000-7eead000 \ shlwapi ELF 0x7eead000-7ef6c000 Deferred shell32<elf> \-PE 0x7eec0000-7ef6c000 \ shell32 ELF 0x7ef6c000-7efa6000 Deferred advapi32<elf> \-PE 0x7ef80000-7efa6000 \ advapi32 ELF 0x7f082000-7f09a000 Deferred version<elf> \-PE 0x7f090000-7f09a000 \ version ELF 0x7f09a000-7f99a000 Deferred gdi32<elf> \-PE 0x7f0e0000-7f99a000 \ gdi32 ELF 0x7f99a000-7fab0000 Deferred user32<elf> \-PE 0x7f9c0000-7fab0000 \ user32 ELF 0x7fbb0000-7fbb5000 Deferred libnss_db.so.2 ELF 0x7fc04000-7fd00000 Deferred kernel32<elf> \-PE 0x7fc20000-7fd00000 \ kernel32 ELF 0x7fe12000-7fe16000 Deferred libgpg-error.so.0 ELF 0x7fe16000-7fe1f000 Deferred libsm.so.6 ELF 0x7fe1f000-7fe2b000 Deferred libnss_files.so.2 ELF 0x7fe2b000-7fe41000 Deferred libnsl.so.1 ELF 0x7fe41000-7fe45000 Deferred iso8859-15.so ELF 0x7fe45000-7fe50000 Deferred libgcc_s.so.1 ELF 0x7fe52000-7fe55000 Deferred xlcdef.so.2 ELF 0x7fe55000-7fe59000 Deferred libxrandr.so.2 ELF 0x7fe59000-7fe7e000 Deferred libm.so.6 ELF 0x7fe7e000-7ff75000 Deferred libwine_unicode.so.1 ELF 0x7ff77000-7ff81000 Deferred libnss_nis.so.2 ELF 0x7ff81000-7ff8a000 Deferred libnss_compat.so.2 ELF 0x7ff8d000-80000000 Deferred ntdll<elf> \-PE 0x7ffa0000-80000000 \ ntdll ELF 0xb7e42000-b7e47000 Deferred libxxf86vm.so.1 ELF 0xb7e49000-b7e4d000 Deferred libdl.so.2 ELF 0xb7e4d000-b7f84000 Deferred libc.so.6 ELF 0xb7f84000-b7f96000 Deferred libpthread.so.0 ELF 0xb7f96000-b7fb0000 Deferred libwine.so.1 ELF 0xb7fc0000-b7fc2000 Deferred libnvidia-tls.so.1 ELF 0xb7fc2000-b7fc8000 Deferred libxxf86dga.so.1 ELF 0xb7fc9000-b7fe0000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\Programme\Native Instruments\Reaktor Session\ReaktorSession.exe 00000009 0 <== WineDbg terminated on pid 0x8 Getötet you wrote: > > Is anyone using the arts, esound or jack sound drivers for non > trivial use? By non trivial, I mean more than one application or > more than a single device. If so, I am interested in getting > information on the software you are using and how it is using > the drivers. > > Would redesigning these drivers to show up as a single device > per physical device which allowed being opened more than > once be a problem?

1 0

Re: [Wine] [Invalid ELF header] GSM audio codec in Ventrilo
by Molle Bestefich Dec. 15, 2005

Dec. 15, 2005

Pictor wrote: > I'm trying to run Ventrilo (voice chat) on WINE. > I have the latest version of wine. > I installed correctly Ventrilo. > > Now I have to setup it to use the GSM 6.10 codec. > I read on-line that I only need to add "MSACM.msgsm610=msgsm32.acm" to > the system.ini file, and add the file in the /system directory. > > I did it, but when I choose the codec GSM I get an error: > "Unable to find the specified codec" > > In the shell nothing appears with this error. > > So I tried to rename the msgsm32.acm file in msgsm32.acm.so > This time, when I select the GSM codec, it give the same error pop-up, > BUT in the shell I receive this error: > > "err:module:load_builtin_dll failed to load .so lib for builtin > L"msgsm32.acm": /usr/lib/wine/msgsm32.acm.so: invalid ELF header" You can't just rename the file to .so. That's because it's a Windows file and thus has PE headers, where .so files has ELF headers. Wine should fallback to loading the native .acm version if the .so is not there. Since Wine actually finds the .acm.so version, I imagine the acm is being loaded through LoadLibrary or some such DLL loading function. So maybe someone just forgot to make Wine check for native DLL files named .acm in the DLL loading code? Just a guess.

2 1

Re: Fix dsiplay of fonts with Symbol codepages (codepage 42) as well
by Dmitry Timoshkov Dec. 15, 2005

Dec. 15, 2005

"David Moore" <davidm(a)sjsoft.com> wrote: > The patch below first checks to see if the codepage is one of the > exceptions, and if it is, passes in NULLs for the last two arguments. I wonder how did you build the list of exceptions: why CP_UTF7 is there but CP_UTF8 is not? Why 50xxx,52xxx,57xxx code pages are there? I'd suggest as a start to have only CP_UTF7, CP_UTF8 and CP_SYMBOL in the exception list. -- Dmitry.

2 2

Regression in Wine on FreeBSD (DVD Shrink)
by Travis Poppe Dec. 15, 2005

Dec. 15, 2005

Hello All, Lately I've been trying to track down a problem that prevents DVD Shrink 3.2 from starting on FreeBSD in any version of Wine built on/after 04-20-2005 (including the recent beta releases). Any version built prior to this works fine. I've tracked the problem down to the changes made to x11drv/dib.c (and associated) on 04-20-2005. I'm not fluent in C; I merely found the problem through trial and error. If I copy the x11drv/dib.c (and ntdll/, so the old dib.c will work) from 04-18-2005 in place of the one introduced on the 20th, the problem disappears and DVD Shrink fires right up. Changing dib.c (and dib.c only) back to the 20th snapshot re-introduces the problem, and DVD Shrink hangs again. As I don't understand the code, I don't know how to detect where the problem really lies, as the dib.c changes may only be indirectly responsible. I am very willing to test for or aid anyone who wouldn't mind helping with this problem, however. I have already contacted the author of the changes (dib.c and associated) and he suggested I try this list. If anyone would like to glance at the differences between the two files I've mentioned above, I have posted a diff here: http://lickwid.net/~tlp/dib.c.diff --- are the old and working changes +++ are the new and broken changes Any help would be greatly appreciated. Thanks, -- Travis Poppe IRC: tlp @ irc.freenode.net

2 1

Re: There is no need to offset the source rectangle in the reverse direction before scrolling
by Rein Klazes Dec. 15, 2005

Dec. 15, 2005

On Tue, 13 Dec 2005 23:53:07 +0800, you wrote: >Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > There is no need to offset the source rectangle in the reverse > direction before scrolling. > >--- cvs/hq/wine/dlls/x11drv/scroll.c 2005-11-22 12:41:07.000000000 +0800 >+++ wine/dlls/x11drv/scroll.c 2005-12-13 23:42:15.000000000 +0800 > /* Then clip again to get the source rectangle that will remain in the > * clipping rect */ > rcSrc = rcClip; >- OffsetRect( &rcSrc, -dx, -dy); > IntersectRect( &rcSrc, &rcSrc, &rcClip); In the first place: with this change the IntersectRect call is a no-op I doubt you understand the reason for "to offset the source rectangle in the reverse direction": Scrolling should only occur in the clipping rectangle. When you talk about the *destination* pixels, a clipping with the cliprect is needed. Here we are talking about the *source* pixels, from destination to source is indeed reverse. *that* is what is happening here. If you are not convinced: the change is wrong and clipping fails. I have added a test to confirm that. The test also gives a nice visual idea what goes wrong, just add a Sleep() or two to get the picture. Changelog: dlls/x11drv : scroll.c dlls/user/tests : win.c Restore the previous change to X11DRV_ScrollDC. With a regression test to confirm it was wrong. Rein.

3 3