December 2005 - Wine-Devel - list.winehq.org

Re: D3D9: Add a test for BeginStateBlock & EndStateBlock

by Alexandre Julliard

"H. Verbeet" <hverbeet(a)gmail.com> writes: > +START_TEST(d3d9_test) > +{ > + init_d3d9(); > +} Please don't add that sort of pseudo-tests just to share code with other tests. If you need init code put it directly in the tests that need it. A test C file should be self-contained as far as possible to make it easier to build on Windows. -- Alexandre Julliard julliard(a)winehq.org

Dec. 8, 2005

Re: shell32: Bind to correct drop target after drag scrolling

by Michael Jung

Hi, On Tuesday 06 December 2005 00:26, Alexandre Julliard wrote: > I don't really know what the right way is, I just know that faking > mouse messages probably isn't it <g> You were right (of course ;-) Attached is a small test application, which supports the bare minimum to get drag & drop running. It traces all calls to the IDropTarget interface to a listbox. As it turns out WinXP calls DragOver approx. every 200ms while the mouse hovers over a registered DropTarget window (This makes it really easy for drop-targets to implement drag-scrolling). In addition DragOver is called after one of the drag-modifier-keys (shift+ctrl) is pressed or released. Wine doesn't do neither yet. Is there any sensible way to transform this into a unit test? Or do we have a repository for this kind of small test applications, which are hard to implement as unit-tests? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Dec. 8, 2005

Re: OLE without TLS libraries

by Marcus Meissner

On Thu, Dec 08, 2005 at 12:35:32PM +1000, Cihan Altinay wrote: > Hi, > > having a Xen system my Linux tls library path is not > in place (renamed to /lib/tls.disabled). > When I run a program that uses OLE/DCOM (with native > ole libraries) it crashes immediately. Using > LD_LIBRARY_PATH=/lib/tls.disabled wine program > makes it work again. > I am not sure if this is true for all OLE apps. > > Is this known/expected behaviour or a bug? Do you have a backtrace of the crash or similar? Ciao, Marcus

Dec. 8, 2005

Re: how do I find where wine itself is segfaulting?

by Keith Dunwoody

Hi, I'm running into the same problem. File on the resulting core tells me it was generated from wine-preloader. I'm using wine 0.9.2 for Fedora Core 3 from winehq (the i686 version I believe). I'm running an x86_64, if that matters. -- Keith --- Bill Medland <billmedland(a)mercuryspeed.com> wrote: > Background. I am trying to figure out why a program that I > thought ran OK on 25 October no longer runs and no longer runs > when I recompile from that code too. > > So the program accesses invalid memory down inside the WNDPROC > stuff (winproc.c line 418, it says, so I guess it means line > 416) > > So I turn on WINDEBUG=+relay to see what is being passed. > > And wine segfaults. > > Even > export WINEDEBUG=+relay > wine --version > > which yields > 0009:Call kernel32.__wine_kernel_init() ret=77ed4e4d > Segmentation fault > > I can't use gdb and I can't use winedbg. > > Anyone know what is going on? > > -- > Bill Medland > mailto:billmedland(a)mercuryspeed.com > http://webhome.idirect.com/~kbmed > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Dec. 8, 2005

Re: Hungarian keyboard detection problem

by Dmitry Timoshkov

"Wallner Ádám" <Wallner.Adam(a)hktv.hu> wrote: > +/*** Hungarian keyboard layout (setxkbmap hu) | modified by Adam Wallner*/ > +static const char main_key_HU_new[MAIN_LEN][4] = > +{ > + "0Â§","1'","2\"","3+","4!","5%Â°","6/","7=","8(","9)","AsA-","AzAo","AlA"", > + "qQ","wW","eE","rR","tT","zZ","uU","iI","oOA¸","pP","AlA.","AsAs", > + "aA","sS","dD","fF","gG","hH","jJ","kK","lL","ASA?","AAA","AtA>", > + "yY","xX","cC","vV","bB","nN","mM",",?",".:","-_", > + "AA" > +}; > + > /*** Polish (programmer's) keyboard layout ***/ > static const char main_key_PL[MAIN_LEN][4] = > { > @@ -921,7 +931,7 @@ > {0x040a, "Spanish keyboard layout", &main_key_ES, &main_key_scan_qwerty, &main_key_vkey_qwerty}, > {0x0410, "Italian keyboard layout", &main_key_IT, &main_key_scan_qwerty, &main_key_vkey_qwerty}, > {0x040f, "Icelandic keyboard layout", &main_key_IS, &main_key_scan_qwerty, &main_key_vkey_qwerty}, > - {0x040e, "Hungarian keyboard layout", &main_key_HU, &main_key_scan_qwerty, &main_key_vkey_qwertz}, > + {0x040e, "Hungarian keyboard layout", &main_key_HU_new, &main_key_scan_qwerty, &main_key_vkey_qwertz}, I'd suggest instead of creating a new keyboard layout to patch an existing one. -- Dmitry.

Dec. 8, 2005

OLE without TLS libraries

by Cihan Altinay

Hi, having a Xen system my Linux tls library path is not in place (renamed to /lib/tls.disabled). When I run a program that uses OLE/DCOM (with native ole libraries) it crashes immediately. Using LD_LIBRARY_PATH=/lib/tls.disabled wine program makes it work again. I am not sure if this is true for all OLE apps. Is this known/expected behaviour or a bug? Cheers, Cihan

Dec. 8, 2005

how do I find where wine itself is segfaulting?

by Bill Medland

Background. I am trying to figure out why a program that I thought ran OK on 25 October no longer runs and no longer runs when I recompile from that code too. So the program accesses invalid memory down inside the WNDPROC stuff (winproc.c line 418, it says, so I guess it means line 416) So I turn on WINDEBUG=+relay to see what is being passed. And wine segfaults. Even export WINEDEBUG=+relay wine --version which yields 0009:Call kernel32.__wine_kernel_init() ret=77ed4e4d Segmentation fault I can't use gdb and I can't use winedbg. Anyone know what is going on? -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 8, 2005

Re: wglGetPixelFormatAttribivARB unexpected RenderType(100)

by Raphael

On Monday 05 December 2005 23:53, Toan T Nguyen wrote: > Hi, thanks for the clarification. Everything is fine then. Thank you > for the patch. was Nothing > BTW, do you know how to improve OpenGL performance in wine? I get > about 10-30% drop in FPS compared to the Windows version (the card is > overclocked about 10% both in CPU and memory frequencies in windows, > so that might explains some of the performance drop). I set UseDGA to > Y in "wine regedit" but that doesn't seem to help at all. 10-30% is not wine overhead (as wine overhead for opengl is very small) i think it's a driver problem: no linux graphic drivers have the maturity andd performances of windows drivers :( > > Thanks again, > Toan Regards, Raphael

Dec. 8, 2005

Re: Robert Reif : winecfg: Added support for auto detecting all drivers by attempting to

by Robert Reif

Eric Pouech wrote: > I do think all the recent changes to winecfg are going into the wrong > direction. > > First of all, allowing the devices to be opened more than once without > having the devices ready for that is a ready bad idea. Basically, > windows drivers come in two flavors: > - single instance (they can be loaded only once in memory) > - multiple instance (they can be loaded several times in memory) > For the second type, a specific init string (gotten from the registry, > and usually dealing with the HZ resources involved) is passed to the > driver. > In the wine implementation, we don't get anything from the registry, > we just let the device (from the unix interface it uses) return as > many audio/midi... ports it finds. This is typically the behavior > expected from single instance drivers. Among the issues we'll face > here are dual open of the same unix resource (contention) for several > instances, overwriting of internal data and structures (they are not > prepared for that). > Therefore, the multiple open patch has to be reverted. We never "load" a driver more than once. Winecfg calls winmm OpenDriver which will only ever load a single instance of the driver into memory. Subsequent OpenDriver calls will reference the existing in memory driver. Wine models the single instance device driver that supports multiple physical devices. I work with highend multichannel sound cards in windows that show up as a single 8 channel device (with one card or 16 channels with two cards) and as 4 (8) stereo devices. > > Secondly, I do think it's a bad idea to reconstruct in winecfg most > the driver management. It's not done correctly (the DRV_INIT, > DRV_ENABLE and DRV_LOAD messages are not correctly passed). If it > works today, it's by chance as the configure message is never handled > (we just put out a message box), but it doesn't access the internal > structures. To do it, we need the DRV_ messages sent. It is true that winecfg is not calling each sub system driver (WaveIn, WaveOut, ...) like windows but device probing is done at main driver load in most drivers (and I am fixing the ones that don't) because device configuration is dynamic rather than read from the registry so opening the sub drivers individually to query static data is not a problem. I have a version of the alsa driver that can change registry entries from the configure dialog. > > Finally, I'm not sure that presenting all the drivers, and the ports > available is really meaningful for most users. Some drivers return > just potential entries (esound for example). Even with the caps, most > users won't tell the difference between alsa and oss entries. Jack and esound are fundamentally flawed because they create 10 virtual sound cards that all reference a single physical device. This doesn't take into account multiple devices. The proper way to implement this is to allow multiple opens of the same device (just like windows). That way two or more programs can open one card and other programs can open another card and none of the programs are aware or even care about the others. I have multiple sound cards and headsets in a single computer for music and VoIP and I need a way for individual programs to work with specific devices (just like in windows). > > Lately, the available drivers button is not really useful. We > shouldn't present non available drivers to the users, and just let > him/her choose among the available ones (or just to mark the ones > which are not available). > It would be trivial to only show the drivers that opened properly so missing drivers or non-functioning drivers would not be displayed. You can infer that from the device tree now if no physical devices show up under a driver. I could add icons to broken or disabled drivers (just like windows) to show driver/hardware state. I also plan to add device and driver management to the device tree in future versions. This is really just wine's version of the audio portion of windows device manager. Hiding stuff in the registry without giving the user an easy way (GUI rather than reading the source and using regedit) of configuring the sound system is not good. The direction I am trying to take the winecfg it to allow specific driver configuration through the windows DRV_CONFIGURE mechanism which displays a driver specific dialog box for changing driver specific registry entries. This is the only time there is potential contention problems between programs but only if configuration is performed immediately while the other programs are accessing the driver. This can be avoided by doing the reconfiguration at wine reboot time (winmm.dll unload/load) or by checking for open drivers and using locking to prevent modifications by other programs. You could also move the sound drivers into the server but that won't happen.

Dec. 7, 2005

Re: josystick driver layer and support of multiple devices of one kind

by Eric Pouech

> > 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) there are several questions: - share as much as possible code between dinput and winmm (you have to choose which one could call the other) - how to abstract the interfaces: ddk is your friend. for the winmm part, check the include/mmddk.h, and dlls/winmm/joystick (the joystick driver). there's in it all what you need (google will help too). - from the MM experience, don't recreate a separate driver for each known HW or interface, but rather stick everything in a single driver, and handle the complexity here A+ -- Eric Pouech

Dec. 7, 2005