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

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

by Tony Lambregts

Jason Green wrote: > On 3/11/06, Tony Lambregts <tony.lambregts(a)gmail.com> wrote: >> In simple terms we get WineTools to query the AppDB with an application name (ie >> somename.exe) and we return a list of applications for the user to choose from >> and the after the user selects the program WineTools gets the appropriate >> overrides from the AppDB and sets them for the user. >> >> I think that that this is do-able if we work together. > > First, great idea. > > Second, here's a [very incomplete] list of what would need to be done > to pull this off: > - AppDB would have to be extended to be able to get and report this > data, and it would make sense for each App's maintainer to be able to > manage that information. > - Biggest issue here is that this information could have a tendency > to change very rapidly, so it might overload the app maintainers if > they had to track this for each version of wine. What I think would > make sense is to have regular snapshots (every 3 months?) and release > a new version of "Winetools Plus" or whatever you want to call this > thing a month later to give the maintainers time to update each of > their apps based on the frozen version. Well how often this should be updated depends on the development of the various dll. If all a program requires wine to emulate Windows 3.1 then it might not need updating ever. > - Data needed: AppID, AppVersionID, WineVersionID, Window Version, DLL > Overrides, Window settings (fullscreen/windowed - sometimes and > issue), Sound options, Video acceleration required, General notes or > HOWTO's, etc. You would need separate overrides/settings for > Installing vs. Running the app. You are right that we will probably need entries for both the installer and the program itself. > - AppDB could dump this information to an xml format which "Winetools > Plus" could be distributed with. Maybe have an option to download the > latest xml file directly from winehq.org. I see this as a dynamic thing as the list could get quite large. and downloading the whole thing for just one program seems excessive. > - The 'Winetools Plus' front-end would just be a menu which would > query all of the apps in the xml dump. The user picks they app they > want to install, and it reads the necessary information, verifies the > source installation media, and goes at it. I think that it would be better if the user entered into WineTools the name of the exe they were trying to run but you may be right about this option > - Applying patches to apps might get tricky (e.g., where wine only > successfully runs version 1.5 of the app, but 1.0 is on the CD), but > I'm sure it could be worked out. We cannot solve all the problems at once. > > Anyway, there's a start. That would encourage users to get involved > in the AppDB reporting process as well as better organize how to just > "get things done" using wine. > I would like to here from Joachim as to what WineTools would need. The main thing I would like to get away from in WineTools is the blanket changes that it now does of making wine emulate windows 95 and use native Dlls by default. Thanks for your input -- Tony Lambregts Tony Lambregts

March 11, 2006

Re: [Bugzilla] Add note to not paste logs and back traces.

by Vitaliy Margolen

Saturday, March 11, 2006, 11:19:57 AM, Rein Klazes wrote: > On Sat, 11 Mar 2006 08:14:03 -0700, you wrote: >>Change Log: Add note to attach and not paste logs and back traces. >> >>Files changed: template/en/default/bug/edit.html.tmpl >>template/en/default/bug/create/create.html.tmpl > Not pasting back traces will make following the bug list by email rather Well it might be true, but to a point. Most of the debug traces are too wide and e-mail wraps them (so does maillist archive). That _does_ make it nearly impossible to see anything. > useless. IMO what people are currently posting in bugzilla do not > require such recommendations. What? You mean having all the pastes in this bug: http://bugs.winehq.org/show_bug.cgi?id=4131 adds to it's readability? This is just one bug that I could think of. Also note that the biggest paste by author has nothing to do with the bug itself. Vitaliy

March 11, 2006

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

by Tomas Carnecky

Vitaliy Margolen wrote: > Anything wrong with this patch? It does fix the "stuck alt" problem for > games I use alt+tab on. > I can confirm that this fixes the bug. This patch is very important for me as I don't have to switch back and forth between desktop and WoW to un-stuck they alt-key. This patch works fine and I don't see any side-effects. tom

March 11, 2006

Re: [Bugzilla] Add note to not paste logs and back traces.

by Tony Lambregts

Rein Klazes wrote: > On Sat, 11 Mar 2006 08:14:03 -0700, you wrote: > >> Change Log: Add note to attach and not paste logs and back traces. >> >> Files changed: template/en/default/bug/edit.html.tmpl >> template/en/default/bug/create/create.html.tmpl > > Not pasting back traces will make following the bug list by email rather > useless. There is always a link in the email to the attachment. >IMO what people are currently posting in bugzilla do not > require such recommendations. > Well if that was the case there would not be so many comments telling people not to paste[1]. I can only see the situation getting worse as more people report bugs. [1] http://bugs.winehq.org/buglist.cgi?query_format=&short_desc_type=allwordssu… http://bugs.winehq.org/buglist.cgi?query_format=&short_desc_type=allwordssu…'t+paste

March 11, 2006

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

by Jason Green

On 3/11/06, Tony Lambregts <tony.lambregts(a)gmail.com> wrote: > In simple terms we get WineTools to query the AppDB with an application name (ie > somename.exe) and we return a list of applications for the user to choose from > and the after the user selects the program WineTools gets the appropriate > overrides from the AppDB and sets them for the user. > > I think that that this is do-able if we work together. First, great idea. Second, here's a [very incomplete] list of what would need to be done to pull this off: - AppDB would have to be extended to be able to get and report this data, and it would make sense for each App's maintainer to be able to manage that information. - Biggest issue here is that this information could have a tendency to change very rapidly, so it might overload the app maintainers if they had to track this for each version of wine. What I think would make sense is to have regular snapshots (every 3 months?) and release a new version of "Winetools Plus" or whatever you want to call this thing a month later to give the maintainers time to update each of their apps based on the frozen version. - Data needed: AppID, AppVersionID, WineVersionID, Window Version, DLL Overrides, Window settings (fullscreen/windowed - sometimes and issue), Sound options, Video acceleration required, General notes or HOWTO's, etc. You would need separate overrides/settings for Installing vs. Running the app. - AppDB could dump this information to an xml format which "Winetools Plus" could be distributed with. Maybe have an option to download the latest xml file directly from winehq.org. - The 'Winetools Plus' front-end would just be a menu which would query all of the apps in the xml dump. The user picks they app they want to install, and it reads the necessary information, verifies the source installation media, and goes at it. - Applying patches to apps might get tricky (e.g., where wine only successfully runs version 1.5 of the app, but 1.0 is on the CD), but I'm sure it could be worked out. Anyway, there's a start. That would encourage users to get involved in the AppDB reporting process as well as better organize how to just "get things done" using wine. My 2 cents. Jason

March 11, 2006

Re: "IE5 or higher required". Grr.

by Vitaliy Margolen

Saturday, March 11, 2006, 8:27:59 AM, Jeremy White wrote: >> BTW is there are some particular reason that you have to cc every >> single bug that you file to wine-devel mailing as well? I'm sorry, but >> quality of those bugs are not that good really to go directly to >> wine-devel list. With this particular bug you could at least try to find >> what is that program looks at to decide if you do have IE installed or >> not. > I certainly don't want wine-devel to turn into wine-users, > but I think you are wrong to lump Dan's emails into that category. > Dan is a very capable developer; he may not be the most > accomplished Wine hacker, but he is not without his chops. > Note that many of the @ucla.edu patches that come to wine-devel > are from his students. > Further, I think that Dan is triaging issues that are > of fairly critical interest to Wine. > For example, IE dependence is a very hard problem for Wine; > a lot of programs have that as an issue. I, for one, am > grateful to Dan for running with the Windows version > of Firefox, as it helps us be better ready to understand > how to use Firefox to solve that problem. > Further, I happen to know that the Munich considered > using Wine for their desktop migration, and they felt that > Wine was 'awful'; so it is very interesting to me, personally, > to explore why that might be. > Cheers, > Jeremy Ah ok. I want to apologize then. I'm trying to get reasonable bug reports with enough information so any developer can go in and look without downloading giga-bytes of stuff to just get something like WINEDEBUG=warn+all. Also most of the bugs end up being a duplicates of already known problems. In this particular case, I won't be surprised if all that software does is checks for one particular file somewhere in system32 directory. It's long know outstanding problem. I think if we search bugzilla we will come up with at least dozen of files that programs check for in this way. Again, sorry for the extra noise. Vitaliy.

March 11, 2006

Re: [Bugzilla] Add note to not paste logs and back traces.

by Rein Klazes

On Sat, 11 Mar 2006 08:14:03 -0700, you wrote: >Change Log: Add note to attach and not paste logs and back traces. > >Files changed: template/en/default/bug/edit.html.tmpl >template/en/default/bug/create/create.html.tmpl Not pasting back traces will make following the bug list by email rather useless. IMO what people are currently posting in bugzilla do not require such recommendations. Rein.

March 11, 2006

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

by Tony Lambregts

Rich Gilson wrote: > On Thursday 09 March 2006 08:27, Joachim von Thadden wrote: >> 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 think this is a "Good Idea" (tm) There are always going to be programs that need tweaks to get them to run. I know of a few that will work fine just by changing the windows version but fail miserably with a "clean wine" [1]. These programs usually fail in XP as well but it would be nice for the users to have an easy way to get them to run "out of the box" in wine There are others that look for a certain file and if it does not exist the program fails[2]. Just creating an empty file with the appropriate name is often enough to get the program working. This is a class of bug that is sure to be around for a while. The last class of bugs are the ones that require native (windows) DLL's [3]. It would be nice to be able to keep track of these somewhere so that developers know which files need to be worked on Most people are not programmers and even fewer are capable of being developers but if we can find a way to make everyones life easier both developers and users then we should do it. In simple terms we get WineTools to query the AppDB with an application name (ie somename.exe) and we return a list of applications for the user to choose from and the after the user selects the program WineTools gets the appropriate overrides from the AppDB and sets them for the user. I think that that this is do-able if we work together. -- Tony Lambregts [1] http://appdb.winehq.org/appview.php?versionId=4349 [2] http://bugs.winehq.org/show_bug.cgi?id=4796 http://bugs.winehq.org/show_bug.cgi?id=3661 [3] http://bugs.winehq.org/show_bug.cgi?id=4631

March 11, 2006

Re: GL_STENCIL-related build failures in dlls/wined3d/device.c

by Gerald Pfeifer

I've seen half a dozen or more changes to dlls/wined3d/device.c since that message of mine, but appare On Sun, 5 Mar 2006, Gerald Pfeifer wrote: > The recent changes to dlls/wined3d/device.c cause the following build > failures for me on FreeBSD 5.4, though I assume this is in fact not > related to FreeBSD but to xorg 6.8.2 or libglut 6.4.1 on this system. > > device.c: In function `IWineD3DDeviceImpl_SetRenderState': > device.c:3776: error: `GL_STENCIL_BACK_FAIL' undeclared (first use in this function) > device.c:3776: error: (Each undeclared identifier is reported only once > device.c:3776: error: for each function it appears in.) > device.c:3777: error: `GL_STENCIL_BACK_PASS_DEPTH_FAIL' undeclared (first use in this function) > device.c:3778: error: `GL_STENCIL_BACK_PASS_DEPTH_PASS' undeclared (first use in this function) > gmake[2]: *** [device.o] Error 1 > gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/wined3d' > gmake[1]: *** [wined3d] Error 2 > > The most straightforward patch would be the one below, but it leaves > three "variable may be used uninitialized" warnings in the first of the > two affected spots. > > Gerald > > Index: device.c > =================================================================== > RCS file: /home/wine/wine/dlls/wined3d/device.c,v > retrieving revision 1.145 > diff -u -3 -p -r1.145 device.c > --- device.c 4 Mar 2006 17:10:57 -0000 1.145 > +++ device.c 5 Mar 2006 08:35:52 -0000 > @@ -3226,9 +3226,15 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetRen > > GLint action = StencilOp(Value); > > +#ifdef GL_STENCIL_FAIL > glGetIntegerv(GL_STENCIL_FAIL, &stencilFail); > +#endif > +#ifdef GL_STENCIL_PASS_DEPTH_FAIL > glGetIntegerv(GL_STENCIL_PASS_DEPTH_FAIL, &depthFail); > +#endif > +#ifdef GL_STENCIL_PASS_DEPTH_PASS > glGetIntegerv(GL_STENCIL_PASS_DEPTH_PASS, &stencilPass); > +#endif > > if(WINED3DRS_STENCILFAIL == State) { > stencilFail = action; > @@ -3773,9 +3779,15 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetRen > > GLint action = StencilOp(Value); > > +#ifdef GL_STENCIL_BACK_FAIL > glGetIntegerv(GL_STENCIL_BACK_FAIL, &stencilFail); > +#endif > +#ifdef GL_STENCIL_BACK_PASS_DEPTH_FAIL > glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_FAIL, &depthFail); > +#endif > +#ifdef GL_STENCIL_BACK_PASS_DEPTH_PASS > glGetIntegerv(GL_STENCIL_BACK_PASS_DEPTH_PASS, &stencilPass); > +#endif > > if(WINED3DRS_CCW_STENCILFAIL == State) { > stencilFail = action; > -- Gerald (Jerry) Pfeifer gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

March 11, 2006

Re: "IE5 or higher required". Grr.

by Jeremy White

> BTW is there are some particular reason that you have to cc every > single bug that you file to wine-devel mailing as well? I'm sorry, but > quality of those bugs are not that good really to go directly to > wine-devel list. With this particular bug you could at least try to find > what is that program looks at to decide if you do have IE installed or > not. I certainly don't want wine-devel to turn into wine-users, but I think you are wrong to lump Dan's emails into that category. Dan is a very capable developer; he may not be the most accomplished Wine hacker, but he is not without his chops. Note that many of the @ucla.edu patches that come to wine-devel are from his students. Further, I think that Dan is triaging issues that are of fairly critical interest to Wine. For example, IE dependence is a very hard problem for Wine; a lot of programs have that as an issue. I, for one, am grateful to Dan for running with the Windows version of Firefox, as it helps us be better ready to understand how to use Firefox to solve that problem. Further, I happen to know that the Munich considered using Wine for their desktop migration, and they felt that Wine was 'awful'; so it is very interesting to me, personally, to explore why that might be. Cheers, Jeremy

March 11, 2006

Re: "IE5 or higher required". Grr.

by Dan Kegel

On 3/10/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > BTW is there are some particular reason that you have to cc every > single bug that you file to wine-devel mailing as well? I'm sorry, but > quality of those bugs are not that good really to go directly to > wine-devel list. The two apps I posted about yesterday were ones that a European city needed for its transition to desktop Linux, so they seemed important enough to post about. But if others think I'm spamming the devel list, I can certainly stop. > With this particular bug you could at least try to find > what is that program looks at to decide if you do have IE installed or > not. I did look at WINEDEBUG=+reg, but didn't see anything obvious. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 11, 2006

Re: Francois Gouget : user32: Handle WM_ENDSESSION in DefWinProc().

by Rein Klazes

On Fri, 24 Feb 2006 14:29:45 -0600, you wrote: >Author: Francois Gouget <fgouget(a)codeweavers.com> >Date: Fri Feb 24 15:34:09 2006 +0100 > >user32: Handle WM_ENDSESSION in DefWinProc(). >DefWinProc() should call PostQuitMessage() on WM_ENDSESSION if the >shutdown is proceeding. Hi Francois, This patch is causing a problem in Pegasus Mail. Closing some dialogs cause termination of the complete program. Here is a part of SPY++ log when run under win2000, when I close the edit new mail dialog: |<00202> 00130A82 S ..........................WM_SYSCOMMAND uCmdType:SC_CLOSE xPos:672 yPos:121 [wParam:0000F060 lParam:007902A0] |<00203> 00130A82 S ...........................WM_CLOSE wParam:00000000 lParam:00000000 |<00204> 00130A82 S ............................WM_QUERYENDSESSION nSource:1 (End Task from Task List dialog) [wParam:00000001 lParam:00000000] |<00951> 00130A82 R ............................WM_QUERYENDSESSION fShutdownIsOk:True [lResult:00000001] ... |<00952> 00130A82 S ............................WM_ENDSESSION fEndSession:True [wParam:00000001 lParam:00000000] |<00953> 00130A82 R ............................WM_ENDSESSION lResult:00000000 The WM_QUERYENDSESSION and WM_ENDSESSION are sent by the program: |0009:Call user32.SendMessageA(00030024,00000011,00000001,00000000) ret=0040641d How did you check the behavior of the Windows DefWindowProc? If I put a DefWindowProc(hwnd, WM_ENDSESSION, 1, 0); some where in a windows program nothing happens, while a PostQuitMesage certainly closes the app. Rein.

March 11, 2006

Re: "IE5 or higher required". Grr.

by Vitaliy Margolen

Friday, March 10, 2006, 11:53:24 PM, Dan Kegel wrote: > On 3/10/06, Dan Kegel <dank(a)kegel.com> wrote: >> I heard KeepTool was an app used by some government >> developers, so I tried installing the free trial from http://keeptool.com. >> Sadly, the installer complained I needed IE5 or later. > Filed at http://bugs.winehq.org/show_bug.cgi?id=4796 > - Dan > -- > Wine for Windows ISVs: http://kegel.com/wine/isv Well I guess that's the one that does need the IE installed. There are lots of programmes that relay on some functionality provided by IE. Doesn't matter if they really need it or not. BTW is there are some particular reason that you have to cc every single bug that you file to wine-devel mailing as well? I'm sorry, but quality of those bugs are not that good really to go directly to wine-devel list. With this particular bug you could at least try to find what is that program looks at to decide if you do have IE installed or not. Vitaliy Margolen.

March 11, 2006

Re: "IE5 or higher required". Grr.

by Dan Kegel

On 3/10/06, Dan Kegel <dank(a)kegel.com> wrote: > I heard KeepTool was an app used by some government > developers, so I tried installing the free trial from http://keeptool.com. > Sadly, the installer complained I needed IE5 or later. Filed at http://bugs.winehq.org/show_bug.cgi?id=4796 - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 11, 2006

"IE5 or higher required". Grr.

by Dan Kegel

I heard KeepTool was an app used by some government developers, so I tried installing the free trial from http://keeptool.com. Sadly, the installer complained I needed IE5 or later. The registry key trick I've been using, [Software\\Microsoft\\Internet Explorer] "Version"="6.0.2900.2180" didn't seem to do the trick this time. Any suggestions on how to get past that? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 11, 2006

spss can't even install...

by Dan Kegel

I heard that SPSS was one of the apps governments like (so they crunch statistics -- who knew? :-), so I tried running the free eval. It wouldn't even install. The problems were already described in http://bugs.winehq.org/show_bug.cgi?id=4700 Looks like an msi problem, but there might be something more general wrong; all wine apps hang for about twenty seconds at a certain point during the install, which is pretty strange. - Dan p.s. one downside of using wine to run firefox as your main browser is it's a bit more dangerous to do the rm -rf ~/.wine needed to do a really clean install of a test app :-) so this test was done with a fairly cluttered fake wine directory. But it seems to match the results in the PR. -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 11, 2006

Re: AlphaImageLoader - tranparent pngs 4 IE

by Mike Hearn

If you register and use a native dxtrans.dll it may work. On Wed, 08 Mar 2006 16:48:23 +0100, Axel Huizinga wrote: > Hi! > > Did anybody get DXImageTransform.AlphaImageLoader working > to render transparent png in IE on wine? > > Cordially, > Axel

March 10, 2006

Re: winegdb: Fix crash in empty first command

by Eric Pouech

Eric Pouech wrote: > Vitor T. Sessak wrote: > >> 2006/3/7, Eric Pouech >> >>> >>> 2006/3/6, Vitor T. Sessak <vitor.sessak at m4x.org >>> <http://www.winehq.org/mailman/listinfo/wine-patches>>: >>> >>>> / >> >> >> />>/ Changelog: >> />>/ winegdb: Fix crash in empty first command >> />>/ >> />>/ Winedbg crashes when pressing enter as its first command. >> /> >> >>> >>> this is wrong as the last_line will be HeapFree'd when the next >>> command is >>> keyed in. >> >> >> >> You are right. I've changed it and fixed the FIXME too. > > your new code leaks the lines (you never free them) to be more precise, when you copy the pointers, both last and this refer to the same buffer, which is not what you want you should duplicate the buffer A+ -- Eric Pouech

March 10, 2006

Re: winegdb: Fix crash in empty first command

by Eric Pouech

Vitor T. Sessak wrote: > 2006/3/7, Eric Pouech > >> >> 2006/3/6, Vitor T. Sessak <vitor.sessak at m4x.org >> <http://www.winehq.org/mailman/listinfo/wine-patches>>: >> >>> / > > />>/ Changelog: > />>/ winegdb: Fix crash in empty first command > />>/ > />>/ Winedbg crashes when pressing enter as its first command. > /> > >> >> this is wrong as the last_line will be HeapFree'd when the next >> command is >> keyed in. > > > You are right. I've changed it and fixed the FIXME too. your new code leaks the lines (you never free them) A+ -- Eric Pouech

March 10, 2006

Re: riched20: Implements FR_WHOLEWORD for EM_FINDTEXT

by Lei Zhang

On Monday 06 March 2006 11:06 am, you wrote: > Lei Zhang <leiz(a)ucla.edu> writes: > > --- dlls/riched20/editstr.h 2 Mar 2006 11:18:19 -0000 1.27 > > +++ dlls/riched20/editstr.h 5 Mar 2006 06:36:50 -0000 > > @@ -29,6 +29,7 @@ > > #include <stdarg.h> > > #include <stdio.h> > > #include <stdlib.h> > > +#include <wctype.h> > > You can't use anything from wctype.h in Wine. Use the functions from > wine/unicode.h instead. Hi Alex, I did not know wctype.h is unusable in Wine. Is this documented anywhere? I took a quick glance around the site and did not see much information regarding i18n. Anyway, I posted a revised patch to wine-patches earlier in the week: http://www.winehq.org/pipermail/wine-patches/2006-March/024848.html - Lei

March 10, 2006

Re: WINED3D: Color fixups for vertex shaders

by H. Verbeet

On 10/03/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Because reg is set to 6 in the declaration, this translates to specular > because VertexDecl8_Registers[6] corresponds to specular. Yes, but that shouldn't make it into the arrayUsageMap. ArrayUsageMap defines usage, but in this case we don't know how the data will be used.

March 10, 2006

Re: WINED3D: Color fixups for vertex shaders

by Roderick Colenbrander

> Either way, arrayUsageMap doesn't get initialised correctly. If we > don't know what's in a register, we shouldn't pass it through > arrayUsageMap, but use some other way. > > I won't be around next week, but after that I'll probably try to have > a look at d3d8 shaders. > The declaration is converted to a d3d9 shader in parsedeclaration8. The function parsetoken8 handles the conversion of a token. In this case the following code is entered: case D3DVSD_TOKEN_STREAMDATA: if (token & 0x10000000) { TRACE(" 0x%08lx SKIP(%lu)\n", token, ((token & D3DVSD_SKIPCOUNTMASK) >> D3DVSD_SKIPCOUNTSHIFT)); } else { DWORD type = ((token & D3DVSD_DATATYPEMASK) >> D3DVSD_DATATYPESHIFT); DWORD reg = ((token & D3DVSD_VERTEXREGMASK) >> D3DVSD_VERTEXREGSHIFT); ERR("reg: %d\n", reg); TRACE(" 0x%08lx REG(%s, %s)\n", token, VertexDecl8_Registers[reg], VertexDecl8_DataTypes[type]); } Because reg is set to 6 in the declaration, this translates to specular because VertexDecl8_Registers[6] corresponds to specular. Someone in #winehackers thought that perhaps your code should only be called for FVF shaders. Roderick -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer

March 10, 2006

Re: WINED3D: Color fixups for vertex shaders

by H. Verbeet

On 10/03/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > I have walked through the code. This small demo (dolphinvs from dx8.1 sdk) > uses the following vertex declaration for the seafloor: > D3DVSD_STREAM( 0 ), > D3DVSD_REG( 0, D3DVSDT_FLOAT3 ), // Position of first mesh > D3DVSD_REG( 3, D3DVSDT_FLOAT3 ), // Normal > D3DVSD_REG( 6, D3DVSDT_FLOAT2 ), // Tex coords > D3DVSD_END() > > It stores texture coordinates in register 6 (D3DVSD_SPECULAR). Registers > should be general purpose I think and this should work fine. Your patch > assumes that 'D3DVSD_SPECULAR' is allways used for colors which should be > swizzled. Well, no. It assumes that arrayUsageMap[WINED3DSHADERDECLUSAGE_SPECULAR] contains the register number for the register that is used to store specular colors, or -1 if there are no specular colors. loadNumberedArrays() in drawprim.c uses arrayUsageMap in the same way. > Because we are storing texture coordinates in them they shouldn't > be swizzled but we don't know what is stored in them. I'm not sure how to > fix this bug but I think the code should be moved to a later stage. I don't think that will work. We really need to know if a certain block of data is going to be used for colors or not, or we can't fix the data, in the shader or otherwise. Also, we have to fix the data before it gets passed to the shader or on input, we can't do it on output because other components (with the correct color order) might have been added in the shader. Either way, arrayUsageMap doesn't get initialised correctly. If we don't know what's in a register, we shouldn't pass it through arrayUsageMap, but use some other way. I won't be around next week, but after that I'll probably try to have a look at d3d8 shaders.

March 10, 2006

Re: ddraw design flaw

by Stefan Dösinger

Hi, > 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). The ddraw implementation has some unloading bugs at the moment. Not restoring the glx context(that's the problem you reported, right) is only one of them. Another is that the screen resolution isn't restored when the app doesn't care for releasing it's object. I have this problem in mind, and I'll check WineD3D for it, as it most likely affects all D3D libs. Once it's fixed in wineD3D and ddraw uses wineD3D for rendering, this should be sorted out. Sorry for not fixing this at once, but time is limited ;). If you want a solution now, you're free to fix ddraw. But I registered that issue and it's on my lenghty todo list.

March 10, 2006

Re: WINED3D: Color fixups for vertex shaders

by Roderick Colenbrander

> 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? > > I have walked through the code. This small demo (dolphinvs from dx8.1 sdk) uses the following vertex declaration for the seafloor: D3DVSD_STREAM( 0 ), D3DVSD_REG( 0, D3DVSDT_FLOAT3 ), // Position of first mesh D3DVSD_REG( 3, D3DVSDT_FLOAT3 ), // Normal D3DVSD_REG( 6, D3DVSDT_FLOAT2 ), // Tex coords D3DVSD_END() It stores texture coordinates in register 6 (D3DVSD_SPECULAR). Registers should be general purpose I think and this should work fine. Your patch assumes that 'D3DVSD_SPECULAR' is allways used for colors which should be swizzled. Because we are storing texture coordinates in them they shouldn't be swizzled but we don't know what is stored in them. I'm not sure how to fix this bug but I think the code should be moved to a later stage. Swizzling won't be done in the shader then :( Roderick -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer

March 10, 2006

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