March 2006 - Wine-Devel - list.winehq.org

ddraw design flaw

by Tomas Carnecky

I have found a design flaw in ddraw and described it in my 'World of Warcraft 0.10 Public Test Real (PTR)' thread. Why has nobody adressed this issue? In my eyes it is a severe design flaw if an application can't unload ddraw.dll without side effects (especially if this side-effect is that all opengl/directx applications are unusable after that). So please, will someone explain me why nobody wants to fix this? It's nothing bad now, but if WoW still loads Survey.dll (and thus ddraw.dll) in the final public release many people will demand a fix. Very few people play on the PTR, but there are quite a lot who play WoW under wine.. and they will not be happy if they can't play anymore. tom

March 10, 2006

Re: DDraw->WineD3D refcounting hack

by Stefan Dösinger

> You could have a function to explicitly destroy the object, regardless > of reference count. However, I think that one already got mentioned > last time :-) :-) Yes, that was mentioned, and indeed I have one internal function, mainly for code readability. The problem is that I can't destroy the sublevel surfaces when the root surface is destroyed, I have to wait until the WineD3DTexture is destroyed. In most cases, this is equal, and the root surface holds the only reference to the WineD3DTexture, but in some cases WineD3D holds an internal reference. If I just destroy the sublevels with the root, then WineD3D will get angry(aka crash) because I take away the Textures surfaces. The first wineD3D surface survives because it's parent is an IParent object, and destroying the root surface does only Release the WineD3DTexture, not the WineD3DSurface.

March 10, 2006

Re: Trying to fix bug 2400 - delete and comma

by Marin Glibic

agaro wrote: > Only posting here a litle news about this thread subject. > I sent an patch to fix this problem: > http://www.winehq.org/pipermail/wine-patches/2006-March/024891.html > Works for your keyboard layout? Please, let me know! :) works great for croatian. hooray!

March 10, 2006

Re: May be a bad idea to have Winetools in the next SUSE release

by Tom Wickline

On 3/9/06, Joachim von Thadden <thadden(a)web.de> wrote: > > > This leads to many users asking for help in #winehq on freenode. > > But nobody there wants to support winetools and thus can only > > suggest them to remove their .wine and redo it without winetools > > (which usually makes it work). > > Yes, this is true. As we are a freetime project we have not the time to > sit on an IRC channel. But there is always > > a) this mailinglist where we sit and listen > b) the possibility to mail us directly > Hello, I don't believe you would have to spend all of your free time sitting on a # winetools IRC channel. The channel could maintained by current users.. You know, users helping users kinda thing. And if you guys have some extra time to spend on the channel fine if you don't that would be fine as well. The way it is now WineTools users don't have a mailing list, a IRC channel or forum to ask questions or any real way to seek help other than sending you a direct mail. And experienced users don't have any of these venues to help people. Just my $.02 Tom

March 10, 2006

Re: Use a property for the colour dialog's information.

by Mike McCormack

>> - SetWindowLongPtrW(hDlg, DWLP_USER, 0); /* we >> don't need it anymore */ >> + SetPropW( hDlg, szColourDialogProp, lpp ); > SetPropW( hDlg, szColourDialogProp, lpp ) should be SetPropW( hDlg, > szColourDialogProp, NULL ). That's what I get for writing code at 1am after a couple of beers :/ It probably should be RemovePropW. Mike

March 10, 2006

Re: May be a bad idea to have Winetools in the next SUSE release

by Mike McCormack

Rich Gilson wrote: > On Thursday 09 March 2006 08:27, Joachim von Thadden wrote: >>customized to point and click interfaces. Again: The goal is not to >>develop Wine. The goal is to use it easy. I think you'd have alot more friends around here if your goal was to help develop Wine. As it stands, WineTools somewhat impedes testing and bug reporting of Wine versions of dlls (eg. ole32, oleaut32, rpcrt4) since you encourage your users to use Windows versions of those dlls, even though the Wine ones work for many applications. > IMHO, the Wine developers should spend less time b*tching about Winetools and > more time figuring out how they can 1) build a front-end that is better than > Winetools, or 2) help improve Winetools so that it works more to their liking > but still offers an easy, user-friendly interface. As Joachim states, his "goal is not to develop Wine". That's kind of incompatible with the goals of "Wine developers", isn't it? Mike

March 10, 2006

Re: dinput: Create single thread for mouse and keyboard hook procs. [try 3]

by Vitaliy Margolen

Any problems with this patch? I have not received any additional comments. And it does fix at least two games in question (see bug reports). And I have not seen any side-affects from it either. Vitaliy Margolen Wednesday, February 22, 2006, 8:10:16 AM, Vitaliy Margolen wrote: > ChangeLog: > dinput: Create single thread for mouse and keyboard hooks. > Put keyboard & mouse hook callbacks into separate thread. > Move few global variables into object. Delete no longer used crit section. > For hooks to work properly hook callback have to be in a thread > with message loop. Some games create separate threads just to handle > mouse and/or keyboard events that do not have message loop. This patch fixes > such games (Bug 4264) - mouse and (Bug 2981) - keyboard. > Try#2 (based on suggestions from Alexandre): > Using a message window in a dedicated thread with normal message loop. > Hooks are installed and removed using SendMessage to this window. > Only one mouse and one keyboard hook is permitted. > Hook handles are managed by dedicated thread and not given back to > caller. > Try#3 (with Robs suggestions) > Use critical section. > dlls/dinput/device.c | 132 > ++++++++++++++++++++++++++++++++++++++++++ > dlls/dinput/device_private.h | 2 + > dlls/dinput/keyboard.c | 130 > ++++++++++++++++------------------------- > dlls/dinput/mouse.c | 33 ++++------- > 4 files changed, 195 insertions(+), 102 deletions(-)

March 10, 2006

Re: x11drv: One more fix for "stuck" ctrl, shift & alt.

by Vitaliy Margolen

Anything wrong with this patch? It does fix the "stuck alt" problem for games I use alt+tab on. Vitaliy Margolen Tuesday, February 21, 2006, 10:30:39 PM, Vitaliy Margolen wrote: > ChangeLog: > x11drv: One more fix for "stuck" ctrl, shift & alt. > DInput needs scan code with each event - make sure we send one. > Also don't loose key state change events in mouse.c > I tested this with Keyboard DInput sample from DXSDK. It clearly showed > that we are loosing these events when focus is being changed. > dlls/x11drv/keyboard.c | 10 +++++----- > dlls/x11drv/mouse.c | 6 ++++-- > dlls/x11drv/x11drv.h | 2 ++ > 3 files changed, 11 insertions(+), 7 deletions(-)

March 10, 2006

Re: x11drv: Fix one case of "glXChooseFBConfig returns NULL" problem.

by Vitaliy Margolen

Anything wrong with this patch? According to MSDN ChoosePixelFormat should pick closest mode, but not fail. Vitaliy Margolen Saturday, March 4, 2006, 10:27:11 PM, Vitaliy Margolen wrote: > ChangeLog: > x11drv: Fix one case of "glXChooseFBConfig returns NULL" problem. Using alpha bits >> 8 makes this function fail, while it should not. > dlls/x11drv/opengl.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-)

March 10, 2006

Re: May be a bad idea to have Winetools in the next SUSE release

by Rich Gilson

On Thursday 09 March 2006 08:27, Joachim von Thadden wrote: > Am Thu, Mar 09, 2006 at 01:41:06PM +0100 schrieb Jan Zerebecki: > > I think a quote from http://www.winehq.org/site/download somewhat > > sums up the cencus on this list regarding Winetools: "WineTools > > [is] only recommended if installation or operability of Windows > > software failed on pure Wine. Since WineTools radically alters > > your Wine configuration please do not report bugs in programs > > with WineTools installed. Instead contact the author of WineTools > > Joachim von Thadden." > > As there are arguments floating around about WineTools that are > definitely not correct I think I have to make some things here clear. > > > Some other facts: > > > > Winetools is only sporadically updated for new versions of Wine > > (as http://www.von-thadden.de/Joachim/WineTools/ indicates; this > > site also contains some warnings regarding the support status). > > WineTools is not "sporadically" updated as it makes no sense to update > it with every new Wine release. The purpose is not to keep track Wine, > the purpose is to have a stable basis. As such WineTools often stays > with a specific Wine version for a time. This is the same what > Crossover-Office does. So you would also not include that if you were > allowed to? > The reality that I have come up with is this: Even following the instructions provided in the appdb to install IE6 (which is necessary for almost anything else to work properly) I can't seem to get it to install properly. When I run an install through Winetools, it works flawlessly. When I try to install TurboTax under "pure" Wine, it fails miserably without having to do dll overrides and such. When I install it under Winetools, I have no problems getting it to run without having to tweak the hell out of it. > > Winetools radically alters some vital Wine settings and thus > > makes many other apps fail. > > This first part is true, the second definitely not. WineTools is at the > moment the only way to have all major commercial windows programs run > simultaneously with Wine under Linux if you do not want to pay for > Crossover-Office. > > If what you say is true then name the apps that fail with WineTools and > run with *plain* Wine. I am waiting for your list. And I will include > them in the next release (if I can download them legaly). > > > This leads to many users asking for help in #winehq on freenode. > > But nobody there wants to support winetools and thus can only > > suggest them to remove their .wine and redo it without winetools > > (which usually makes it work). > > Yes, this is true. As we are a freetime project we have not the time to > sit on an IRC channel. But there is always > > a) this mailinglist where we sit and listen > b) the possibility to mail us directly > > Again: I am nosy to know which apps work after removing a WineTools > .wine. > > > Currently no Winetools developer works closely with the Wine > > developers to correct problems of interaction between Winetools > > and Wine. > > What does that mean? We are making a tool to make Windows programs run > with Wine. We do not develop Wine and our main goal is not to achieve as > much debugging informations as possible. The goal is to make the usage > of Wine as easy as possible for users coming from Windows and who are > customized to point and click interfaces. Again: The goal is not to > develop Wine. The goal is to use it easy. > > Regards > Joachim von Thadden Please don't misunderstand me, I have a great deal of respect for what what the Wine developers have accomplished so far; however, I feel that those that have put the effort into Winetools have done so because they saw a need and filled it. In the realm of ease of use and user-friendliness, Wine is horribly lacking. Yes, it is getting better, but I think that Winetools is the closest thing I've seen that would make it so that an average user could us it. IMHO, the Wine developers should spend less time b*tching about Winetools and more time figuring out how they can 1) build a front-end that is better than Winetools, or 2) help improve Winetools so that it works more to their liking but still offers an easy, user-friendly interface. Personally, I would like to see an application (be it Winetools or something else, it doesn't really matter to me) that would interface with the appdb. You could launch this front-end and it would pull up a list of all the applications in the appdb that have special "config" files. These files would tell this front-end EXACTLY what dll overrides are necessary, what files to run, what needs to be installed beforehand, etc. Then, if there is ever a change (due to Wine improving support for a particular dll so that an override is no longer needed, for example) all that would have to be done is to update the "config" file attached to the program in the appdb and *bingo*, you've just "update" your front-end! I say I would like to see it because I do not personally have the requisite programming skill to accomplish such a task, but I'm convinced it could be done and that there are programmers out there in the Wine community that would easily be able to accomplish such a task. This whole Wine/Winetools argument has been a thorn in my side for a while because I see both sides of the argument and can understand both stances. However, I'm also watching and not seeing any compromise being made. It's like both sides have formed ranks and dug in. It's not my intention to just whine and cry about things, but I'm not in a position to directly help. What I can do is offer my ideas and opinions. I have I haven't pissed too many people off because that was not my intention. I do look forward to every new release of Wine that comes out, hoping that it's that much closer to allowing me to leave Windows behind for good. -- -- In a world without fences, who needs Gates?

March 10, 2006

Re: May be a bad idea to have Winetools in the next SUSE release

by Sven.Paschukat＠t-online.de

Marcus Meissner schrieb: > Hmm, I have some kind of recommendation here. > > What about winetools using ".winetools" as WINEPREFIX setting? > > This would make it possible to keep a ".wine" for the purists, and > ".winetools" for the "just get things done" people. > > Up to now winetools does not seem to honor a WINEPREFIX setting > (also a bug I think). > > Ciao, Marcus Hey, you steal Joachim's ideas ;-) That's one point we have discussed in similar form. One directory for the present winetools mode and another for a new builtin mode where winetools just acts as a menu driven loader and installer. Sven

March 9, 2006

Updated DDraw over WineD3D patch

by Stefan Dösinger

Hi, I've uploaded anothe update of my DDraw->WineD3D patch to http://stud4.tuwien.ac.at/~e0526822/. It fixes some refcounting issues and the D3D renderer of the Half-Life 1 Steam version works. It also takes the merged header patches into account ;) I am quite busy the next time, so I won't be able to do a lot ddraw development. I'll continue to send patches, but only header changes, no added functionality. I'll keep myself up to date and anser feedback mails, but I don't think I've the time to do intensive development. I expect I can continue in April. Have fun playing, Stefan

March 9, 2006

Re: May be a bad idea to have Winetools in the next SUSE release

by Hiji

> Hmm, I have some kind of recommendation here. > > What about winetools using ".winetools" as > WINEPREFIX setting? > > This would make it possible to keep a ".wine" for > the purists, and > ".winetools" for the "just get things done" people. > > Up to now winetools does not seem to honor a > WINEPREFIX setting > (also a bug I think). Seperating .wine and .winetools would be cool. In fact, the only reason I don't use winetools is because it "dilutes" my pure wine install. Just tossing in my 2 cents! Hiji __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

March 9, 2006

Re: May be a bad idea to have Winetools in the next SUSE release

by Marcus Meissner

> > Currently no Winetools developer works closely with the Wine > > developers to correct problems of interaction between Winetools > > and Wine. > > What does that mean? We are making a tool to make Windows programs run > with Wine. We do not develop Wine and our main goal is not to achieve as > much debugging informations as possible. The goal is to make the usage > of Wine as easy as possible for users coming from Windows and who are > customized to point and click interfaces. Again: The goal is not to > develop Wine. The goal is to use it easy. Hmm, I have some kind of recommendation here. What about winetools using ".winetools" as WINEPREFIX setting? This would make it possible to keep a ".wine" for the purists, and ".winetools" for the "just get things done" people. Up to now winetools does not seem to honor a WINEPREFIX setting (also a bug I think). Ciao, Marcus

March 9, 2006

Re: Trying to fix bug 2400 - delete and comma

by Sven.Paschukat＠t-online.de

agaro schrieb: > Works for your keyboard layout? Please, let me know! :) Fixes the bug in my german layout :-) Sven

March 9, 2006

Re: Trying to fix bug 2400 - delete and comma

by agaro

Only posting here a litle news about this thread subject. I sent an patch to fix this problem: http://www.winehq.org/pipermail/wine-patches/2006-March/024891.html Works for your keyboard layout? Please, let me know! :) []s agaro

March 9, 2006

Re: DDraw->WineD3D refcounting hack

by H. Verbeet

On 09/03/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Is such a thing acceptable for Wine? Does anyone have a better solution? If > you need some code to look at, I'll upload an updated patch to my homepage > later. You could have a function to explicitly destroy the object, regardless of reference count. However, I think that one already got mentioned last time :-)

March 9, 2006

DDraw->WineD3D refcounting hack

by Stefan Dösinger

Hello, I have a a question regarding some code that might be rejected by Alexandre when I submit it. The problem is that I have to do an refcount hack in my new ddraw code to destroy textures properly. I CC this mail to AJ because it's him who has the last word ;) WineD3D and Direct3D7 have different ideas about handling mipmap textures. In d3d7 they are complex surfaces - a bunch of surfaces with a root and sublevels. All surfaces in the compound have their own refcount, but they are all destroyed when the root is destroyed. In WineD3D there's the texture as a container, and the surfaces in the container have their refcount linked to the container(See the patch H. Verbeet sent a few days ago). In d3d7 the application destroys the first surface to release the whole texture. My first idea was to Release the WineD3DTexture. It would then call the Release method of all the sublevel ddraw surfaces, which would destroy them. This works for a correctly written application, but applications call GetAttachedSurface for the sublevels, which addrefs, and many do not Release the sublevels after GetAttachedSurface(). This leaves the sublevel surfaces with a refcount of 2 or more when the root is destroyed. To make sure that they are destroyed, I set their refcount to 1 when the root is destroyed. When the last reference to the WineD3D Texture is released, wineD3D will destroy the sublevel surfaces. Is such a thing acceptable for Wine? Does anyone have a better solution? If you need some code to look at, I'll upload an updated patch to my homepage later. Thanks, Stefan

March 9, 2006

ChangeDisplaySettings

by Jan Dvorak

While trying to run Scratches game, the game tries to set fullscreen resolution but fails - heres the log: trace:x11settings:X11DRV_EnumDisplaySettingsEx mode -1 (current) -- getting current mode (desktop) trace:x11settings:X11DRV_EnumDisplaySettingsEx mode 0 -- 800x600x32bpp (desktop) trace:x11settings:X11DRV_ChangeDisplaySettingsEx ((null),0x406bf9cc, (nil),0x00000004,(nil)) trace:x11settings:X11DRV_ChangeDisplaySettingsEx flags=FULLSCREEN trace:x11settings:X11DRV_ChangeDisplaySettingsEx DM_fields=BITSPERPEL,PELSWIDTH,PELSHEIGHT,DISPLAYFREQUENCY trace:x11settings:X11DRV_ChangeDisplaySettingsEx width=0 height=0 bpp=32 freq=0 (desktop) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (desktop) it's the second game i encountered trying to do this (calling changedisplaysettings with PELSWIDTH and PELSHEIGHT masks set but setting the values of width and height itself to 0 ). It is buggy application ? Or some undocumented hack in winapi? Or error in wine ? And if it is, what can we do about it (as the games itself runs perfectly otherwise , just windowed ) ? Thanks. JD

March 9, 2006

Re: Use a property for the colour dialog's information.

by Robert Shearman

Mike McCormack wrote: >@@ -1217,7 +1220,7 @@ static INT_PTR CALLBACK ColorDlgProc( HW > DeleteDC(lpp->hdcMem); > DeleteObject(lpp->hbmMem); > HeapFree(GetProcessHeap(), 0, lpp); >- SetWindowLongPtrW(hDlg, DWLP_USER, 0); /* we don't need it anymore */ >+ SetPropW( hDlg, szColourDialogProp, lpp ); > > SetPropW( hDlg, szColourDialogProp, lpp ) should be SetPropW( hDlg, szColourDialogProp, NULL ). -- Rob Shearman

March 9, 2006

Re: WINED3D: Color fixups for vertex shaders

by H. Verbeet

On 09/03/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > In my local tree I have some simple d3d8 shaders working. (See for instance > http://roderick.student.utwente.nl/dolphin1.png and dolphin2.png on windows; > there's some color issue but apart from that it works). This patch causes in > combination with the other vshader patch you sent some drawing issues. Check > http://roderick.student.utwente.nl/dolphin3.png Any idea why that could be happening? In particular, is it the fixup for DIFFUSE, SPECULAR or either that causes the problem? What are the values for reg, arrayUsageMap[WINED3DSHADERDECLUSAGE_DIFFUSE] and arrayUsageMap[WINED3DSHADERDECLUSAGE_SPECULAR]? It looks like texture coordinates are wrong, but those shouldn't be affected by this patch, do you initialise arrayUsageMap correctly?

March 9, 2006

Re: WINED3D: Color fixups for vertex shaders

by Roderick Colenbrander

> Direct3D stores vertex color data in BGRA order, OpenGL stores it in > RGBA order. This causes red and blue to be swapped in d3d applications > when run under wine. This patch fixes this problem for vertex shaders > by enabling the flag that causes red and blue to be swapped in > vshader_program_add_input_param_swizzle, when appropriate. > > Changelog: > - Enable color fixups for vertex shaders > In my local tree I have some simple d3d8 shaders working. (See for instance http://roderick.student.utwente.nl/dolphin1.png and dolphin2.png on windows; there's some color issue but apart from that it works). This patch causes in combination with the other vshader patch you sent some drawing issues. Check http://roderick.student.utwente.nl/dolphin3.png Regards, Roderick -- "Feel free" mit GMX FreeMail! Monat f�r Monat 10 FreeSMS inklusive! http://www.gmx.net

March 9, 2006

Re: May be a bad idea to have Winetools in the next SUSE release

by Andreas Jaeger

Jan Zerebecki <jan.wine(a)zerebecki.de> writes: > Hi. > > For Andreas Jaeger: I CCed you, because you said on > http://en.opensuse.org/Wishlist_Packages_that_are_already_there > that Winetools got included for the next SUSE release. I hope you > are the correct person to talk to or at least can forward this to > someone who is. The following might be usefull information for > you: Winetools is not part of our default installation and will not be provided with the CD set, it's just an extra optional package that people that know about it can easily use, Andreas -- Andreas Jaeger, aj(a)suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

March 9, 2006

Re: May be a bad idea to have Winetools in the next SUSE release

by Joachim von Thadden

Am Thu, Mar 09, 2006 at 01:41:06PM +0100 schrieb Jan Zerebecki: > I think a quote from http://www.winehq.org/site/download somewhat > sums up the cencus on this list regarding Winetools: "WineTools > [is] only recommended if installation or operability of Windows > software failed on pure Wine. Since WineTools radically alters > your Wine configuration please do not report bugs in programs > with WineTools installed. Instead contact the author of WineTools > Joachim von Thadden." As there are arguments floating around about WineTools that are definitely not correct I think I have to make some things here clear. > Some other facts: > > Winetools is only sporadically updated for new versions of Wine > (as http://www.von-thadden.de/Joachim/WineTools/ indicates; this > site also contains some warnings regarding the support status). WineTools is not "sporadically" updated as it makes no sense to update it with every new Wine release. The purpose is not to keep track Wine, the purpose is to have a stable basis. As such WineTools often stays with a specific Wine version for a time. This is the same what Crossover-Office does. So you would also not include that if you were allowed to? > Winetools radically alters some vital Wine settings and thus > makes many other apps fail. This first part is true, the second definitely not. WineTools is at the moment the only way to have all major commercial windows programs run simultaneously with Wine under Linux if you do not want to pay for Crossover-Office. If what you say is true then name the apps that fail with WineTools and run with *plain* Wine. I am waiting for your list. And I will include them in the next release (if I can download them legaly). > This leads to many users asking for help in #winehq on freenode. > But nobody there wants to support winetools and thus can only > suggest them to remove their .wine and redo it without winetools > (which usually makes it work). Yes, this is true. As we are a freetime project we have not the time to sit on an IRC channel. But there is always a) this mailinglist where we sit and listen b) the possibility to mail us directly Again: I am nosy to know which apps work after removing a WineTools .wine. > Currently no Winetools developer works closely with the Wine > developers to correct problems of interaction between Winetools > and Wine. What does that mean? We are making a tool to make Windows programs run with Wine. We do not develop Wine and our main goal is not to achieve as much debugging informations as possible. The goal is to make the usage of Wine as easy as possible for users coming from Windows and who are customized to point and click interfaces. Again: The goal is not to develop Wine. The goal is to use it easy. Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"

March 9, 2006

Re: WINED3D: Implement GetCreationParameters

by Peter Beutner

Alexandre Julliard schrieb: > Your mistake is to assume that the app will handle the error in a sane > way. That's extremely unlikely, especially for things like bad > pointers since the app obviously didn't expect to be passing bad > pointers. If the app really wants to handle that sort of error it can > always add an exception handler around the call; so not trapping the > error in the library doesn't prevent the app from catching the error, > it just avoids forcing a lot of useless checks on well-written apps. > > And it's not clear at all that crashing is more likely to lose data > than not crashing. With the Windows way, the app will merrily continue > working with corrupt data, which gives it a lot more opportunities to > add garbage to your data without noticing, than if it crashed right > away before having done too much damage. > I surrender, you convinced me ;). Sorry for the noise.

March 9, 2006