wine-devel

wine-devel@winehq.org

2 participants
84470 discussions

New Wine ISV case study: Synapticad
by Dan Kegel 16 Dec '05

16 Dec '05

Thanks to Stefan Munz of ITOMIG, I now have a nice writeup by Dan Notestein about SynaptiCAD's success with Winelib; it's online at http://kegel.com/wine/isv/synapticad.html It was first written about a year ago, but languished in cyberspace. I think I've given it its first home on a web site, and updated it a bit after emailing with Mr. Notestein. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Suggested changes to the menubuilder etc.
by Bill Medland 16 Dec '05

16 Dec '05

I am intending doing some work and submitting some patches to "improve" the integration with the operating system desktop integration. Rather than waste time coding up my ideas and having Alexandre reject them I thought I'd start by specifying what I intend and awaiting a barrage of complaints. So please do comment. 1. I reckon it would be a good idea if somewhere we actually wrote some prose that actually declared what it was we were trying to achieve. I have a real issue with trying to decide if the code does what it does because of a deliberate decision, because either Windows or Linux or ... changed or because we just had not got around to implementing what we want. Prose is much better for that. I could put it in the Wine Developer's Guide, in the Wiki (where?), or as a text file in the winemenubuilder directory (my preference). Any comments? 2. My main issue is that we do not replicate the menu structure under the start menu (and presumably the desktop too but I haven't looked there). The program I am working with goes several layers below the Programs directory. I see that wineshelllink is able to take a path for the link but winemenubuilder doesn't use that. I intend adding to winemenubuilder so that it passes a more complete link, with path, to get the depth. 3. I want to do something about looking for icons when the target is actually data, not an executable. Either I will just use no icon or I will see what I can do about looking up the handler for the file type and going from there (possibly even using the native OS's handler e.g. pdf files). Any complaints? -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

4 6

Re: DirectDraw over Direct3D
by Roderick Colenbrander 16 Dec '05

16 Dec '05

> 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 15 Dec '05

15 Dec '05

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 15 Dec '05

15 Dec '05

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 15 Dec '05

15 Dec '05

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 15 Dec '05

15 Dec '05

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 15 Dec '05

15 Dec '05

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 15 Dec '05

15 Dec '05

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 15 Dec '05

15 Dec '05

"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 15 Dec '05

15 Dec '05

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 15 Dec '05

15 Dec '05

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

Re: [mscms/tests/profile.c] Add another possible error
by Saulius Krasuckas 15 Dec '05

15 Dec '05

* On Wed, 14 Dec 2005, Paul Vriens wrote: > > GetStandardColorSpaceProfileW with a non-NULL machinename will return > ERROR_NOT_SUPPORTED on 2000/WinXP/2003 (and maybe more). > > --- a/dlls/mscms/tests/profile.c > +++ b/dlls/mscms/tests/profile.c > @@ -515,7 +515,7 @@ static void test_GetStandardColorSpacePr > /* Parameter checks */ > > todo_wine > - fail_GSCSPW(machineW, 0, newprofile, &size, 0, (GLE == ERROR_INVALID_PARAMETER)); > + fail_GSCSPW(machineW, 0, newprofile, &size, 0, (GLE == ERROR_INVALID_PARAMETER || GLE == ERROR_NOT_SUPPORTED)); Hm, while I believe you, Paul, I don't like testing of several invalid parameters in one check. If different versions of mscms.dll are coded in different ways, we'll be getting one GLE on one platforms and another GLE on anothers. IMHO this way we can test algorithmic (conditional) branching of GetStandardColorSpaceProfile(), which won't be the same on all platforms. So I offer to skip it and test only single parameter in one check. I'll try to send a patch.

1 0

Re: sysparams : nonclient metric fixes
by Alexandre Julliard 15 Dec '05

15 Dec '05

Rein Klazes <wijn(a)wanadoo.nl> writes: > Changelog: > dlls/user : sysparams.c > dlls/user/tests : sysparams.c > Implement saving and fix reading of nonclient metrics with conformance > tests. The test fails here: sysparams.c:195: Test failed: Wrong action got 42 expected 47 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: PATCH: msvcrt.wctime
by Alexandre Julliard 15 Dec '05

15 Dec '05

Marcus Meissner <marcus(a)jet.franken.de> writes: > Used by Google Earth. If anyone has a better > idea on the static buffer handling please speak up.. ;) It should go in the per-thread data structure (cf. msvcrt_get_thread_data). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: setupapi: Added stubs for SetupGetInfInformation and SetupQueryInfFileInformation [RESEND]
by Alexandre Julliard 15 Dec '05

15 Dec '05

James Hawkins <truiken(a)gmail.com> writes: > Is there anything wrong with this patch? Yes, the patch file is truncated. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: Create the compatible bitmap from the screen, not the bitmap we're copying
by Paul Vriens 15 Dec '05

15 Dec '05

> Hi, > > This patch fixes bug 1715. > > Changelog > * Create the compatible bitmap from the screen, not the bitmap we're > copying. > > dlls/comctl32/toolbar.c | 12 ++++++++---- > 1 files changed, 8 insertions(+), 4 deletions(-) > > -- > James Hawkins > > Hi James, somehow you managed to attach an empty file. (I think). Paul.

2 1

Re: chdir to /tmp/.wine-1000/server-307-6930068 : No such file or directory
by David Nolden 15 Dec '05

15 Dec '05

> There is no change in Wine that would have caused this. I seem to > remember that this or a similar error was caused by threading problems > in glibc in the past. Perhaps you upgraded glibc or the kernel on your > system? But when I checkout a cvs from the end of november, it runs.. when I checkout a current one it doesn't. I didn't upgrade glibc, nor the kernel. (I checked out and compiled a cvs from november just an hour ago, and it ran fine) greetings, David

2 1

Printf Integer Conversions update
by Jesse Allen 14 Dec '05

14 Dec '05

Hi All, I've updated my patch and need comments on it. The patch is for a portible method for integer conversions in printf. Since it's primarily intended for I64 sizes that it is all it is used for to avoid breaking anything else, even though, it should be able to handle all integers. You can find it at http://www.chez.com/alors/ along with lots of tests. Since last time, I was wondering what to do about %I64e, and well, testing it out it seems to be just like %e on windows so I decided to not worry about our own float I64 conversion since it's the same. So only I64 integer types get fowarded to pf_integer_conv and floats just get put through libc's printf. I still wonder about %I64e versus %e just because libc's %lle and %e are different hmmmm. This time I use pf_output_format_A to handle the field output. I had to modify it to account for the extra sign and alternate formatting. I guess I need to modify pf_output_format_W the same way, but some one let me know if it is needed and whether just copying what I have over is ok. I added pf_is_integer_format to detect when I have an integer and I64 size case. I modified the others so each uppercase and lowercase type is explicit: static inline BOOL pf_is_valid_format( char fmt ) { - char float_fmts[] = "acdefginoux"; + char float_fmts[] = "acCdeEfgGinouxX"; if (!fmt) return FALSE; - fmt = tolower( fmt ); return strchr( float_fmts, fmt ) ? TRUE : FALSE; } Because D is not a valid conversion type, and especially 'I'. If we get passed %I0d for example, it should print I0d. If I didn't do this, then it tries to convert 'I' as an 'i' type, which would be a bug. I don't know if this will cause other things to regress, so I could back out the change. In my testing of I64 on windows 2k3 (x86), I hit an obscure bug? '%#+25.22I64u' for -1 prints ' 18446744073709551615' returning 21 but normally it should be ' 0018446744073709551615' returning 25. It only does it only for I64 types, and only in this exact combination -- precision and field doesn't matter what number, but #+ must be there and be unsigned. If I try '%+#25.22I64u' then I get correct output. You can see this in the tests and try it out. I tried about 20-30 other combinations and it only happens this way. I haven't built in support of the bug yet, but it is there. So I'm thinking, great, we have to support this obscure I64 with bugs too. Jesse

1 0

chdir to /tmp/.wine-1000/server-307-6930068 : No such file or directory
by David Nolden 14 Dec '05

14 Dec '05

To get to another issue.. since a few weeks, the current CVS doesn't work for me. Whenever I compile it, I get the error mentioned in the subject. New .wine-dir and wiping /tmp doesn't help. When I checkout an older version, for example one from the end of november, it runs fine. Does anyone know the reason for this, or will I have to inspect the code to find it out? Sorry in case this is the wrong mailing-list.. greetings, David

3 3

Re: gethostbyname(my_name) and IL2-Sturmovik
by Juan Lang 14 Dec '05

14 Dec '05

Hi David, thanks for continuing to work on this. > What's wrong with the new version? The first thing to make it acceptable is to write a regression test to go along with it. I think the test should check that gethostbyname(your_host_name) returns something besides 127.0.0.1, _if_ you in fact have a public IP address. Perhaps use SIOCGIFCONF in the test to check whether you do have a public IP. + BOOL getpublicIP(char* target,int size) The name should be spelled get_public_ip or so, and this should be static. + if (skfd < 0) + { + WARN("A socket could not be created"); + return FALSE; + } On any failure you need to SetLastError with an appropriate error. + if(ip[0]==127&&ip[1]==0&&ip[2]==0&&ip[3]==0)continue; /*Exclude 127.0.0.1*/ + + sprintf(buffer,"%i.%i.%i.%i", (int)ip[0],(int)ip[1],(int)ip[2],(int)ip[3]); I think this is specific to little-endian machines, this should succeed on big-endian machines too. (Not all uses of Wine are to run x86 executables.) + if(strcmp(ifr[i].ifr_name,"lo")==0)continue; + if(size>strlen(buffer))strcpy(target,buffer); Some spaces somewhere would be nice :) + char myname[1000]; + gethostname(myname,(size_t)1000); In WS_gethostbyname you pay a penalty of doing a gethostname call every time. I think this could be optimized. For instance, you could only check it if the returned address is 127.0.0.1. Also, I'm not sure about declaring a buffer of 1000 bytes on the stack. It's also unnecessary: according to rfc1035, each name label is at most 255 chars. I assume, at any rate, that gethostname will not return a dotted name, but a single label. To get this off the stack altogether, you could have a static buffer that's set every time WS_gethostname is called. WS_gethostbyname could use this value instead of calling gethostname(2) itself. I'm not sure whether this optimization is worth it. If you use a static buffer, it needs to be protected by a critical section. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 2

Re: Wine: DirectDraw over Direct3D
by Stefan Dösinger 14 Dec '05

14 Dec '05

Hello, > Following your mail on wine-devel about DDRAW, I now understand better > what's going on behind the scenes. Below is the result of an experiment I > did at the beginning of this month. Reading your message, I wanted to share > it with you. First, thanks for your comments, and one suggestion: You should also CC the mails to wine-devel(a)winehq.org, so others can read it too. > I'm an occasional wine user for games, and an experienced developper in > other projects. Age of Empires II has always been really slow, so I finally > decided to run an oprofile session. The results are attached to this > message (wine cvs of 2005-12-04). When I saw the results, I immediately > thought "put that conversion on the GPU". It seems you found that solution > long ago :) Yes, this is known quite well, and if you search the archives, you'll see that it has been mentioned over and over > Of course, there still are the ~35% used by X11, but even if these are not > compressible (DC stuff), a potential x5 increase in game speed due to DIB > would make it much more playable. The need for a better DIB engine is also known, and there are 2 DIB engines ready to be included into Wine: One was sponsored by Transgaming, and the other one is the DIB engine from ReactOS. The ReactOS engine is said to be faster, and it's favored. We'll see, perhaps we can include it with the DirectDraw re-work. The other problem is hardware 2D accelleration: Most DirectDraw functionality is handled by the GPU on Windows, since the beginning of DirectDraw, long before 3D accellerators were around. In Wine, there are 2 ways: The first is to use X calls, which is safe, but slow. The other one is the use of DGA, which is as fast as the Windows way, but it requires root preveliges, or at least write access to /dev/mem, which is a HORRIBLE security risk. That's were OpenGL comes into play: It is hardware accellerated, and doesn't require /dev/mem access. But the drawback is, that it needs a 3D accellerator, and a decent driver. It works fine for nvidia cards, but it is horribly slow for ati cards. > it seems using 3D as > the 2D backend it the only option that makes sense nowadays and in the near > future. In Wine case, this supports your DDraw using D3D idea. Yeah, that perfectly true for current hardware, rumors even have it, that today's GPUs don't have a 2D engine any more, and whatever you do, it will make use of the 3D functionality. The problem are older cards: It would be nice, if games worked on systems for which they were designed for, for example, I'd love to see Anno 1602 working in Wine on my old Acer Extensa 660 with an 120 MHZ Pentium CPU, and a Chips and Technologies 65000 GPU. Thanks for your interest, and I'd appreciate performance tests once my work is stable ;) Stefan

6 8

Re: 100% CPU usage in Wine-0.9
by Mark Knecht 14 Dec '05

14 Dec '05

On 11/15/05, Mark Knecht <markknecht(a)gmail.com> wrote: > On 11/10/05, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > <SNIP> > > > > > LATE BREAKING NEWS: It appears that when I switch to the Alsa > > > driver the CPU usage does down to normal. Were you using Alsa or OSS? > > > I tried both alsa and oss(with oss emulation in alsa), both are working fine. > > I don't use any hw acceleration. So is this program useable for you now with > > alsa? > > > > Stefan, > After having a few people test this it seems that it is not simply > enough to use the Alsa driver. A couple of people have tried that and > continue to see 100% CPU usage, so apparently there is something more > involved. > > In the bug report I have attached some debug info I was asked to > get. Hopefully that will help a developer in some way. > > I am here to test other ideas or do more debug work. I think this > problem is real. > > Cheers, > Mark > Hi, I haven't seen any responses on this in the last month. Did I possibly miss something? Thanks, Mark

1 0

josystick driver layer and support of multiple devices of one kind
by Christoph Frick 14 Dec '05

14 Dec '05

hiho i did recently some patches to mostly make joystick_linuxdinput.c handle things more like joystick_linux.c. the main thing, that i dont like on this work, is the fact, that i am just copy-and-paste code from one end to another. i assume someone started back then the joystick_linuxdinput part and if there where changes at either one of them they where not done (or not all the time) also in the other file. also if i have understood this correctly there is no support for multiple joysticks of one kind at least in the joystick_linuxdinput part (i can not confirm this, because i had for now a js-joystick and a event-wheel - but a event-joystick is on the way). for many game-types it is much likely, that the users want to use more than one input-device (e.g. use the wheel and the pedals from two different manufactures, use the pedals from your wheel with your flight stick, use two gamepads, ...) and its most likely that such a device is nowadays a usb device poping up in /dev/input. if the current implementation works fine with more than one js/event-driven joystick - so let me know; my windows/dinput knowledge ist zero and i have not the hardware to test it yet. so my point: i want to make the joystick_... interface to be more abstract. so to bring the code, that is common for the js and event into one common part and then utilize implementations of a interface for each js and event based joysticks. with this step it would make sense to also allow the "driver" (i call it that way now) to report the joysticks that are available and so have support for multiple joysticks. a split like this would also allow an easier integration of e.g. joystick support for OSX or other opteration systems that handle joysticks in another way then unix/linux does. so my questions: - i this an approach, that would be acceptablefor wine? so if i start on something like this, is there a chance it would be submitted to the tree - or is there a problem in terms of "wine does not work like this and we would ignore such an approach" - is the sound-system of wine with its lots of implementations a place to get ideas for such a change; or is this totally off, because the user only chooses one driver to use (instead of: only build the driver if appropriate and then let each driver search for hardware) -- cu

3 3

Problems generating c++ project since wine 0.9.3
by Sergio 14 Dec '05

14 Dec '05

Hi all, I've been having problems trying to compile one c++ project since latest wine version (0.9.3). This project compiled and worked fine with previous versions. The error messages look like: /usr/include/wine/windows/unknwn.h:26: error: expected unqualified-id before ‘{’ token ... /usr/include/wine/windows/objidl.h:66: error: expected unqualified-id before ‘:’ token ... /usr/include/wine/windows/oaidl.h:553: error: expected unqualified-id before ‘:’ token ... /usr/include/wine/windows/propidl.h:287: error: expected unqualified-id before ‘:’ token ... /usr/include/wine/windows/oleidl.h:46: error: expected unqualified-id before ‘:’ token ... Is there something that I am misisng when generating this project? Or is this a known issue? Thanks. Sergio.

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel