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

WINE's way to find out about MS headers?

by Christoph Frick

hiho after reading the SetProperty documentation on MSDN about the direct input interface, i found out about four "defines" that are not yet included in the dinput.h of WINE. #define DIPROP_APPDATA MAKEDIPROP(?) #define DIPROP_CPOINTS MAKEDIPROP(?) #define DIPROP_INSTANCENAME MAKEDIPROP(?) #define DIPROP_PRODUCTNAME MAKEDIPROP(?) i guess the ids they represend are not documented anywhere but the dinput.h from Microsoft. what is the "best practise" for cases like this, to add them to wine's headers? -- cu

March 9, 2006

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

by Jan Zerebecki

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: 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." 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 radically alters some vital Wine settings and thus makes many other apps fail. 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). Currently no Winetools developer works closely with the Wine developers to correct problems of interaction between Winetools and Wine. IMHO it would be best to either not include Winetools in a distribution or find a more active developer for it who is willing to support Winetools and cooperate with Wine developers. Or at least put up a big warning where it is read by a user that installs Winetools through the distributions package management. Jan

March 9, 2006

RE: WINED3D: Implement GetCreationParameters

by Rolf Kalbermatter

Alexandre Julliard wrote: > Rolf Kalbermatter <rolf.kalbermatter(a)citeng.com> writes: > > > Alexandre Julliard schrieb: > > > >>I fail to see in how far returning an error is hiding a bug. > >>Imho if the library detects an error[*] it should pass the > >>information to the application and let the application handle > >>it. The library doesn't know if the application maybe can cope > >>with it. Just ultimately crash is a bad idea imo. > > Please be careful with how you quote text, I didn't write that, Peter > did. Sorry about that. The first draft contained the entire communication and was syntactially correct but unnecessary long. When trimming it down I messed up the quote line. Will try to not do this again in the future. Rolf Kalbermatter

March 9, 2006

Re: WINED3D: Implement GetCreationParameters

by Alexandre Julliard

Rolf Kalbermatter <rolf.kalbermatter(a)citeng.com> writes: > Alexandre Julliard schrieb: > >>I fail to see in how far returning an error is hiding a bug. >>Imho if the library detects an error[*] it should pass the >>information to the application and let the application handle >>it. The library doesn't know if the application maybe can cope >>with it. Just ultimately crash is a bad idea imo. Please be careful with how you quote text, I didn't write that, Peter did. -- Alexandre Julliard julliard(a)winehq.org

March 9, 2006

GTA/FEAR vs mscoree/.NET

by Ivan Gyurdiev

Marcus Meissner wrote: > On Sun, Oct 16, 2005 at 04:22:10PM -0400, Ivan Gyurdiev wrote: > >> Grand Theft Auto... the never ending struggle to get it working. >> >> First I thought it was broken because of OLE...subsequently found out >> the installer was freezing, because of hidden message boxes. Now I've >> managed to install it in Desktop mode, but it dies when ran, with no >> output of any kind... >> >> Investigating shows: >> >> 000b:Call kernel32.SetUnhandledExceptionFilter(2027f1a8) ret=0115fbe9 >> 000b:Ret kernel32.SetUnhandledExceptionFilter() retval=0115fb7c >> ret=0115fbe9 >> 000b:Call kernel32.GetModuleHandleA(015459f4 "mscoree.dll") ret=0115ae6b >> 000b:Call ntdll.RtlInitAnsiString(7fcaf528,015459f4 "mscoree.dll") >> ret=2018d4fc >> 000b:Ret ntdll.RtlInitAnsiString() retval=00000000 ret=2018d4fc >> 000b:Call ntdll.RtlAnsiStringToUnicodeString(7fffcbf8,7fcaf528,00000000) >> ret=2018d55b >> 000b:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=2018d55b >> 000b:Call ntdll.RtlInitUnicodeString(7fcaf52c,7fffcc00 L"mscoree.dll") >> ret=201a554d >> 000b:Ret ntdll.RtlInitUnicodeString() retval=00000018 ret=201a554d >> 000b:Call ntdll.LdrGetDllHandle(00000000,00000000,7fcaf52c,7fcaf534) >> ret=201a555b >> 000b:Ret ntdll.LdrGetDllHandle() retval=c0000135 ret=201a555b >> 000b:Call ntdll.RtlNtStatusToDosError(c0000135) ret=201a558a >> 000b:Ret ntdll.RtlNtStatusToDosError() retval=0000007e ret=201a558a >> 000b:Ret kernel32.GetModuleHandleA() retval=00000000 ret=0115ae6b >> 000b:Call kernel32.ExitProcess(00000001) ret=0115ae8f >> 000b:Call ntdll.LdrShutdownProcess() ret=201b03bd >> >> Looks like it doesn't like the missing mscoree.dll. >> I thought the .NET framework was not a core windows dll? >> Why would it require it? Also, installing a native dll doesn't seem to >> help... >> > > You are trying to execute a .NET binary. > > Same happens for me when I run "wine f-spot.exe" ;) > > Ciao, Marcus > So, what does that mean for the end user - is there hope that in the future I'll be able to run GTA or, F.E.A.R (which has the exact same problem) under Wine? Will the wine project integrate with mono? Note: if I install a native mscoree, the applications are still not able to find it.

March 9, 2006

Re: WINED3D: Implement GetCreationParameters

by Rolf Kalbermatter

Alexandre Julliard schrieb: >I fail to see in how far returning an error is hiding a bug. >Imho if the library detects an error[*] it should pass the >information to the application and let the application handle >it. The library doesn't know if the application maybe can cope >with it. Just ultimately crash is a bad idea imo. Many applications ignore returned error codes (especially if you have to call GetLastError()) if the programmer was under the assumption that there will be never a possibility to cause an error. While this assumption may be true on Windows (or at least a certain Windows version the programmer has tested on) it is certainly not necessarily true in Wine. There could have been a Wine call just before, that was wrongly implemented, returning an invalid pointer or such. Just returning an error may hide that error for many lines, to crash in some much more unrelated area eventually. Tracking such dependant error causes is already hard enough and hiding an invalid pointer access or other invalid parameter by checking for its validness makes it even harder if an application doesn't ridicully check every possible error condition and believe me I haven't seen many programs that really do that. Crashing may be not what most end users very much like but it is in my opinion just as fine than displaying a dialog box that an unrecoverable error has occurred and that it must shut down and much better than relying on the application to actually do proper error checking, but it makes the life of every Wine programmer just a little bit easier and Wine still being far from a release state can use any help on the programmer side. Wine's policy is to do parameter checking only if Windows is doing it in all versions too and sometimes even then only when there is at least one application that depends on it to work properly. Lets look at the example at hand. There is a function that does not check the pointer in Windows. If an application crashes in that function because of that, this means basically that the application did not do proper pointer checking already and then it is very questionable that it would check the error indication of that function at all, since it wouldn't get such an error indication on Windows anyhow. Also this application will either crash on Windows too, and then it is the programmers problem to make this application behave better or it does not crash on Windows because some previous function does behave differently than the Wine equivalent and then every wine programmer would like to know as soon as possible that this error occurres, not 5000 lines further down the program. If you would talk about a stable and final Wine release (which with Wine chasing the Windows API propably never will be) this might be a little different but we talk about a software project heavily under development. Rolf Kalbermatter

March 9, 2006

Re: BF2 demo

by Ivan Gyurdiev

> Nope. I do have to use OSS instead of ALSA, Doesn't help. > or it will hang right at > the point where the "Join Game" button should get shown, but it never > gives me the "nested exception on signal stack" error. It might be > usefull to add a few traces to the debug log, eg +d3d9,+d3d,+seh and > maybe others depending on what that shows you. > I've attached the trace - I see some texture-related errors before the exception is thrown. http://bugs.winehq.org/show_bug.cgi?id=4745

March 9, 2006

Re: BF2 demo

by H. Verbeet

On 08/03/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > You were able to get the BF2 demo to show something? Yes. > Is this with native d3dx9_25.dll ? Yes. > Did you run into this bug at all? > http://bugs.winehq.org/show_bug.cgi?id=4745 Nope. I do have to use OSS instead of ALSA, or it will hang right at the point where the "Join Game" button should get shown, but it never gives me the "nested exception on signal stack" error. It might be usefull to add a few traces to the debug log, eg +d3d9,+d3d,+seh and maybe others depending on what that shows you.

March 9, 2006

Re: Wine and OS X

by Jim White

Segin wrote: > Jim White wrote: > >> Segin wrote: >> >>> Obchod id wrote: >>> >>>> There could be at least mention in FAQ about possible OS x version or >>>> whether there is no plan. >>>... >>> OSx86 Wiki entry: >>> http://wiki.osx86project.org/wiki/index.php/Darwine >>> >>> Darwine project page: >>> http://darwine.opendarwin.org/ >> >> ... > If you check that wiki page, there is a .dmg for a i386 build. Cool. Hopefully Wine will soon have a volunteer to be the maintainer, and the Downloads and FAQ pages will be updated. Even without a maintainer, those pages could be updated with this information. For those who may not be clear, Darwine is not a fork of Wine, but a Wine developer forum focused on OS X (and Darwin) specific issues. And yes, while I'm harping on FAQ updating, I'm aware that needs to be done on Darwine's site too. Jim White

March 9, 2006

Re: Wine and OS X

by Segin

Jim White wrote: > Segin wrote: > >> Obchod id wrote: >> >>> Hi, >>> >>> There could be at least mention in FAQ about possible OS x version or >>> whether there is no plan. >>> >>> Best wishes >>> >>> Frantisek >>> >> It already exists, but only for Intel Macs (The name 'Wine' is a >> recursive emulator for Wine Is Not a Emulator, from the fact it >> doesn't emulate a CPU. Therefore you cannot run x86 Windows programs >> on a PowerPC Macintosh.) >> >> OSx86 Wiki entry: >> http://wiki.osx86project.org/wiki/index.php/Darwine >> >> Darwine project page: >> http://darwine.opendarwin.org/ > > > What Obchod said is that the information about Wine on OS X is not > readily apparent in the FAQ. While being obscure during the days of > PowerPC-only OS X, the question now of "What about Wine on OS X?" has > become quite frequent in the Intel-era and will become more so. > > While a download of Wine for Intel OS X is probably still a month or > two away, updating the FAQ and making a link to it from the Downloads > page would be the user-friendly thing to do (particularly since there > is bound to be a flood of inquiries when CodeWeavers makes their > CrossOver Office release). > > Jim White > > > > If you check that wiki page, there is a .dmg for a i386 build.

March 9, 2006

Re: Wine and OS X

by Jim White

Segin wrote: > Obchod id wrote: > >> Hi, >> >> There could be at least mention in FAQ about possible OS x version or >> whether there is no plan. >> >> Best wishes >> >> Frantisek >> > It already exists, but only for Intel Macs (The name 'Wine' is a > recursive emulator for Wine Is Not a Emulator, from the fact it doesn't > emulate a CPU. Therefore you cannot run x86 Windows programs on a > PowerPC Macintosh.) > > OSx86 Wiki entry: > http://wiki.osx86project.org/wiki/index.php/Darwine > > Darwine project page: > http://darwine.opendarwin.org/ What Obchod said is that the information about Wine on OS X is not readily apparent in the FAQ. While being obscure during the days of PowerPC-only OS X, the question now of "What about Wine on OS X?" has become quite frequent in the Intel-era and will become more so. While a download of Wine for Intel OS X is probably still a month or two away, updating the FAQ and making a link to it from the Downloads page would be the user-friendly thing to do (particularly since there is bound to be a flood of inquiries when CodeWeavers makes their CrossOver Office release). Jim White

March 9, 2006

Re: Wine and OS X

by Segin

Obchod id wrote: >Hi, > >There could be at least mention in FAQ about possible OS x version or >whether there is no plan. > >Best wishes > >Frantisek > > > It already exists, but only for Intel Macs (The name 'Wine' is a recursive emulator for Wine Is Not a Emulator, from the fact it doesn't emulate a CPU. Therefore you cannot run x86 Windows programs on a PowerPC Macintosh.) OSx86 Wiki entry: http://wiki.osx86project.org/wiki/index.php/Darwine Darwine project page: http://darwine.opendarwin.org/

March 9, 2006

Re: WINED3D: Implement GetCreationParameters

by Francois Gouget

On Wed, 8 Mar 2006, Peter Beutner wrote: > Francois Gouget schrieb: >> * or the application does not pass a NULL here because it would cause >> it to crash on Windows. But if we merely return an error the application >> will merrily go on, only to crash or report that DirectX does not work a >> while later. By then the source of the problem will be very hard to find >> due to all that happened since this function call. >> The point is that we need to fix the bug that causes the application >> to pass a NULL to Wine in the first place. And the best way to spot it, >> and thus fix it, is if Wine segfaults in the same way as Windows when >> given a NULL. > The whole point of my email was that a crash here doesn't help you > to find the real problem. And you are wrong there. When an application crashes you have a very clear point where you know things went very wrong. This point is very clearly identified by the SEH traces and the winedbg backtrace. This information makes it *much* easier to find the original bug. And this is from experience. When an application doesn't crash but doesn't do what you want either, it's hard to even know which part of the log is relevant to the problem. > Imo a library is supposed to validate given parameters as much as > possible and rather return an error to the caller than to crash. No. A library can say that a given function must not be caled with a NULL parameter in which case it is perfectly valid to crash if that rule is violated. There's no point for both the callee and the caller to check for NULL parameters. > Let's just hope the kernel devs don't adopt your > "Better-crash-than-return-an-error" strategy :p The design of kernels, servers, and other pieces of code that have to deal with untrusted data (e.g. browsers), is completely different from that of general purpose libraries. Trying to apply the rules of one to the other will only give bad results. And, as was pointed out before, Wine is in yet a different situation since its number one requirement is compatibility with the Win32 API rather than breaking clean with it and 'doing things the right way' (whatever that is). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

March 9, 2006

BF2 demo

by Ivan Gyurdiev

H. Verbeet wrote: > Currently pixel shaders get created, but not used. This patch enables > OpenGL fragment programs if pixel shaders are enabled and the harware > supports it. Makes fonts readable in the menu for the BF2 demo. This > patch should be applied after the one that removes the FIXME in > drawPrimitiveDrawStrided. > You were able to get the BF2 demo to show something? Is this with native d3dx9_25.dll ? Did you run into this bug at all? http://bugs.winehq.org/show_bug.cgi?id=4745

March 9, 2006

Re: fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented

by Rainer Dorsch

Am Montag, 6. März 2006 09:34 schrieben Sie: > On Sunday 05 March 2006 21:50, you wrote: > > I went to 'Arbeitsplatz' in the Shell and then 'C'. MyDocuments was shown > > as a file, not a folder. I.e. the problem persists. > > I don't quite understand, since MyDocuments is on the Desktop, not on > 'Arbeitsplatz'. Could you please browse to 'Arbeitsplatz\C:\windows'? The hierarchy I see is Desktop->Arbeitsplatz->C:->windows > Just to be sure: In notepad the filedialog works fine, right? Yes, that works fine. Thanks, Rainer -- Rainer Dorsch Alzentalstr. 28 D-71083 Herrenberg 07032-919495 Icq: 32550367

March 8, 2006

Re: AlphaImageLoader - tranparent pngs 4 IE

by Adam Cooper

On Wed, 2006-03-08 at 11:02 -0500, Jason Green wrote: > On 3/8/06, Axel Huizinga <axel(a)3dragons.com> wrote: > > Did anybody get DXImageTransform.AlphaImageLoader working > > to render transparent png in IE on wine? > > If I recall correctly, transparent .PNG's don't even work in IE on > Windows (at least until the upcoming IE7.0). > With a bit of javascript wizardry and the aforementioned DXImageTransform you can get transparent pngs on IE. At least on a windows install of IE. I don't know if it works on wine. Regards Adam

March 8, 2006

Re: Trying to fix bug 2400 - delete and comma

by agaro

I know now what scancode, keycode and vkey are! :) Some references: * ScanCode and KeyCode http://lct.sourceforge.net/lct/x60.html http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-2.html http://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html * Virtual-Key Codes (vkey) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu… I thought the problem was in TranslateMessage (dlls/user/message.c) and X11DRV_ToUnicodeEx (dlls/x11drv/keyboard.c) functions but I found others suspects: EVENT_event_to_vkey and X11DRV_InitKeyBoard (boths in dlls/x11drv/keyboard.c). What is happening? (in brazilian abnt2 keyboard with wine-0.9.9) The EVENT_event_to_vkey function return the wrong value 0x2E to X11DRV_KeyEvent which emits an event through X11DRV_send_keyboard_input. On MSDN and dlls/user/spy.c VK_SEPARATOR virtual key code apears as 0x6C, however in trace below apears as 0x2E while in both cases keycodes are equals. The 0x2E virtual key code value corresponds to VK_DELETE. My guess for now: X11DRV_InitKeyboard function initialize keyc2vkey array with wrong value for this case. Trace ($ WINEDEBUG=+key wine winecfg) of NumPad Delete key with NumLock key activated: trace:key:X11DRV_KeyEvent type 2, window a0000a, state 0x0010, keycode 0x005b trace:key:X11DRV_KeyEvent state = 10 nbyte = 1, status 0x4 trace:key:X11DRV_KeyEvent KeyPress : keysym=FFAC (KP_Separator), # of chars=1 / 0x2c / ',' trace:key:EVENT_event_to_vkey e->keycode = 5b trace:key:X11DRV_KeyEvent keycode 0x5b converted to vkey 0x2e trace:key:X11DRV_KeyEvent bScan = 0x53. trace:key:X11DRV_send_keyboard_input wParam=002e, lParam=00530001, InputKeyState=c1 trace:key:TranslateMessage Translating key VK_DELETE (002e), scancode 53 trace:key:GetKeyboardState (0x7faff024) trace:key:X11DRV_ToUnicodeEx (002E, 0053) : faked state = 0x0010 trace:key:EVENT_event_to_vkey e->keycode = 5b trace:key:X11DRV_ToUnicodeEx type 2, window a0000a, state 0x0010, keycode 0x005b trace:key:X11DRV_ToUnicodeEx Translating char 0x2c to unicode trace:key:X11DRV_ToUnicodeEx ToUnicode about to return 1 with char 2c trace:key:TranslateMessage 1 -> PostMessageW(0x10050,WM_CHAR,002c,00530001) trace:key:GetKeyState key (0x12) -> 0 trace:key:GetKeyState key (0x10) -> 0 trace:key:GetKeyState key (0x11) -> 0 trace:key:GetKeyState key (0x11) -> 0 trace:key:X11DRV_KeyEvent type 3, window a0000a, state 0x0010, keycode 0x005b trace:key:X11DRV_KeyEvent state = 10 nbyte = 0, status 0x1 trace:key:X11DRV_KeyEvent KeyRelease : keysym=0 (No Name), # of chars=0 / 0x00 / '' trace:key:EVENT_event_to_vkey e->keycode = 5b trace:key:X11DRV_KeyEvent keycode 0x5b converted to vkey 0x2e trace:key:X11DRV_KeyEvent bScan = 0x53. trace:key:X11DRV_send_keyboard_input wParam=002e, lParam=c0530001, InputKeyState=41 []s agaro

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Alexandre Julliard

Peter Beutner <p.beutner(a)gmx.net> writes: > Just take the example you have written something in Office and the given behaviour(passing a > NULL pointer) happens when you click on the print button. If it crashes your work is lost, if > it returns an error( and the app handles it in a sane way ) you just won't be able to print > it, but may save it and print it somehow else. > In that case my main concern is certainly not that a crash helps me to find a bug, but > to don't loose my data ;) 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. -- Alexandre Julliard julliard(a)winehq.org

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Peter Beutner

Hi Andreas Mohr schrieb: > Hi, > Can you mention an example of Windows popping up an error message "function > foo baz called with invalid parameter ..., what do you want me to do?". > See? Me neither... heh, the message will more likely looks like "Failed to initialize {Direct3D/DirectDraw/OpenGL/Foo}" Which still leaves you puzzled what the hell actually went wrong, but at least shows that sometimes the return values are actually checked for errors ;) > Any additional error checking in Wine that's *not done by Windows* to make > (semi-)abnormal code flow keep running is A Very Bad Thing (tm). So if a windows function crashes with a given set of parameters the aim is to exactly replicate that behaviour? hmm seems I have to re-think my argument I usually tell people that bugs in windows are not neccessarily also present in wine. Let's hope there is never a exploitable bug that needs to be implemented in wine :p >>> If there's a problem that we need to be aware of, then we'd better get to know >>> about it NOW, not 5 lines, not 3000 relay lines and not 10 minutes after it >>> occurred and nobody ever remembers what the actual problem was. >> To repeat it, if that crash happens you are *already* "3000 relay lines" after the actually >> problem and you have *no* clue what the actual problem is. > That may well be the case, but I sure as hell don't want to even increase > my trouble by orders of magnitude by waiting a lot longer in this error case... So let's remove the dozens of NULL pointer checks already in place ;) And better also the whole exception handling which gives applications the chance to carry on execution even in case of a segmentation fault, which highly increases the trouble to find the original source of the problem *scnr*.

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Peter Beutner

Alexandre Julliard schrieb: > Peter Beutner <p.beutner(a)gmx.net> writes: > >> Or look at it from the view of a user developing a winelib application. I'm sure >> he will very much appreciate it when wine does a better parameter checking than MS >> and returns an error instead of a crash backtrace ;) >> Imo a library is supposed to validate given parameters as much as possible and >> rather return an error to the caller than to crash. > > It's just the opposite actually. A good library (which the MS ones > certainly aren't...) should crash on bad pointers, so that bugs can be > found and fixed. Hiding bugs and trying to stumble along is the MS > way, this is what leads to idiocy like having an exception handler in > lstrlen(). So if in this case Windows doesn't have a check we > certainly don't want one either. I fail to see in how far returning an error is hiding a bug. Imho if the library detects an error[*] it should pass the information to the application and let the application handle it. The library doesn't know if the application maybe can cope with it. Just ultimately crash is a bad idea imo. Just take the example you have written something in Office and the given behaviour(passing a NULL pointer) happens when you click on the print button. If it crashes your work is lost, if it returns an error( and the app handles it in a sane way ) you just won't be able to print it, but may save it and print it somehow else. In that case my main concern is certainly not that a crash helps me to find a bug, but to don't loose my data ;) [*] Obviously you can't check against every possible failure. And it certainly may be a bit too much to check against bad pointers in general, but a NULL pointer check is cheap, easy and certainly doable.

March 8, 2006

Re: AlphaImageLoader - tranparent pngs 4 IE

by Jason Green

On 3/8/06, Axel Huizinga <axel(a)3dragons.com> wrote: > Did anybody get DXImageTransform.AlphaImageLoader working > to render transparent png in IE on wine? If I recall correctly, transparent .PNG's don't even work in IE on Windows (at least until the upcoming IE7.0).

March 8, 2006

AlphaImageLoader - tranparent pngs 4 IE

by Axel Huizinga

Hi! Did anybody get DXImageTransform.AlphaImageLoader working to render transparent png in IE on wine? Cordially, Axel

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Andreas Mohr

Hi, On Wed, Mar 08, 2006 at 03:49:55PM +0100, Peter Beutner wrote: > Hi > Andreas Mohr schrieb: > > We're not a library.We're a very, very, very, very specific piece of software > Well, I remember I was told that wine is just another gui toolkit like gtk+ or qt *scnr*. Good memory ;) However I didn't state that, and I wouldn't want to ;) > > that is required to absolutely, positively fully emulate Windows to the > > closest extent possible (within practical limits, of course). > > As such debating whether to delay a crash by adding useless checks > > *that do not exist in Windows*(!) to *work around* strange behaviour most > > likely caused by our own non-conformant code is utterly pointless. > And I thought the whole idea behind error-checking was not just to delay the crash > but to entirely prevent it and instead inform the user what and where something failed. > I would prefer it if the application pops up a message "xyz failed" rather than a crash. > (admittingly, in how far the application does this in a proper way is entirely out of > our hands ;) ) Can you mention an example of Windows popping up an error message "function foo baz called with invalid parameter ..., what do you want me to do?". See? Me neither... And how do you want to """prevent""" anything?? Forget it... > Let's just hope the kernel devs don't adopt your "Better-crash-than-return-an-error" strategy :p The kernel developers code according to their very own rules, they're the ones to design stuff properly and thus fully know error conditions and corner cases of the code they're designing from scratch. We *absolutely* don't - especially when considering MSDN "correctness" <expletive deleted>. Any additional error checking in Wine that's *not done by Windows* to make (semi-)abnormal code flow keep running is A Very Bad Thing (tm). > > If there's a problem that we need to be aware of, then we'd better get to know > > about it NOW, not 5 lines, not 3000 relay lines and not 10 minutes after it > > occurred and nobody ever remembers what the actual problem was. > To repeat it, if that crash happens you are *already* "3000 relay lines" after the actually > problem and you have *no* clue what the actual problem is. That may well be the case, but I sure as hell don't want to even increase my trouble by orders of magnitude by waiting a lot longer in this error case... Andreas Mohr

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Peter Beutner

Hi Andreas Mohr schrieb: > On Wed, Mar 08, 2006 at 02:08:52PM +0100, Peter Beutner wrote: >> Imo a library is supposed to validate given parameters as much as possible and >> rather return an error to the caller than to crash. > We're not a library.We're a very, very, very, very specific piece of software Well, I remember I was told that wine is just another gui toolkit like gtk+ or qt *scnr*. > that is required to absolutely, positively fully emulate Windows to the > closest extent possible (within practical limits, of course). > As such debating whether to delay a crash by adding useless checks > *that do not exist in Windows*(!) to *work around* strange behaviour most > likely caused by our own non-conformant code is utterly pointless. And I thought the whole idea behind error-checking was not just to delay the crash but to entirely prevent it and instead inform the user what and where something failed. I would prefer it if the application pops up a message "xyz failed" rather than a crash. (admittingly, in how far the application does this in a proper way is entirely out of our hands ;) ) Let's just hope the kernel devs don't adopt your "Better-crash-than-return-an-error" strategy :p > If there's a problem that we need to be aware of, then we'd better get to know > about it NOW, not 5 lines, not 3000 relay lines and not 10 minutes after it > occurred and nobody ever remembers what the actual problem was. To repeat it, if that crash happens you are *already* "3000 relay lines" after the actually problem and you have *no* clue what the actual problem is.

March 8, 2006

Fwd: Can't run DirectX games on x86_64 biarch Linux

by Jason Green

On 3/8/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > [...] > I also build Wine on an amd64 system (running gentoo/ amd64), no problems. But > there's one thing I noticed a while ago: Wine continues to compile and > install even if some of the DLLs won't compile. I had this a few times in the > past, and ended up with a basically working Wine install that missed a few > DLLs, mostly OpenGL-related stuff. Maybe something like that happens to you? > Just check that all DLLs are built and in place, and make sure there were no > errors during compile (like I said, with some DLLs, Wine just continues to > build even though errors appear)... Correct, wine will compile and run without a lot of features and never warn you that they don't exist. See this wiki page for an example of what your include/config.h file should probably look like: http://wiki.winehq.org/Recommended_Packages I just added the Fedora Core 5 and Ubuntu Dapper sections yesterday, and I believe that they are at least 95% accurate, although I might have missed one somewhere. If someone can add the package names required for a gentoo build (or possibly create and maintain wine-cvs packages with all of the necessary deps???), it would probably help out many users trying to compile from source.

March 8, 2006

Re: ntdll: Fix Directory Searching when VFAT_IOCTL_READDIR_BOTH returns an invalid d_reclen

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > No, the file it is searching for exists, but doesn't seem to be > returned by the ioctl for some reason. It is likely a x86-64 kernel > bug, but we should still fix in our code IMHO. Yes, but falling through to readdir when we reach the end of the directory is not correct behavior, it will cause every directory to be searched twice. This needs more investigation. -- Alexandre Julliard julliard(a)winehq.org

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Alexandre Julliard

Peter Beutner <p.beutner(a)gmx.net> writes: > Or look at it from the view of a user developing a winelib application. I'm sure > he will very much appreciate it when wine does a better parameter checking than MS > and returns an error instead of a crash backtrace ;) > Imo a library is supposed to validate given parameters as much as possible and > rather return an error to the caller than to crash. It's just the opposite actually. A good library (which the MS ones certainly aren't...) should crash on bad pointers, so that bugs can be found and fixed. Hiding bugs and trying to stumble along is the MS way, this is what leads to idiocy like having an exception handler in lstrlen(). So if in this case Windows doesn't have a check we certainly don't want one either. -- Alexandre Julliard julliard(a)winehq.org

March 8, 2006

Re: System wide registry

by Stefan Dösinger

Hi, > In WINE user guide I read int the System Administration Tips > about global registry files (f.i. /usr/local/etc/wine.systemreg) > But I can't find any code in WINE about it. It is obsoleted now? > Is it possible to use system wide registry now? I created an /etc/wine directory with a system.reg, userdef.reg and dosdevices file, owned by a user "wine". In the other users .wine directory, there's a individual user.reg file, and a symlink to the files in /etc/wine/. The virtual c drive is in /opt/windows, owned by wine:users This way, there's a system-wide system.reg file, and wine is more or less the admistrator. The Linux file permissions prevent others from writing to /opt/windows and system.reg. An user can modify HKLM, but the changes won't get written to disk and get lost after his wine process terminates. Theoretically, you can use the root account instead of a special user, but it's highly discoraged to run wine as root, due to security concernes. You have to be aware that many Windows apps require full access to system directories or their install directories, but that's a problem Wine can't solve, and Windows suffers from that too.

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Andreas Mohr

Hi, On Wed, Mar 08, 2006 at 02:08:52PM +0100, Peter Beutner wrote: > Imo a library is supposed to validate given parameters as much as possible and > rather return an error to the caller than to crash. We're not a library. We're a very, very, very, very specific piece of software that is required to absolutely, positively fully emulate Windows to the closest extent possible (within practical limits, of course). As such debating whether to delay a crash by adding useless checks *that do not exist in Windows*(!) to *work around* strange behaviour most likely caused by our own non-conformant code is utterly pointless. If there's a problem that we need to be aware of, then we'd better get to know about it NOW, not 5 lines, not 3000 relay lines and not 10 minutes after it occurred and nobody ever remembers what the actual problem was. Andreas Mohr

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Kuba Ober

> Or look at it from the view of a user developing a winelib application. I'm > sure he will very much appreciate it when wine does a better parameter > checking than MS and returns an error instead of a crash backtrace ;) Ooooh, don't I smell bait-and-switch here? :) Always good to learn from your adversaries, right? Kuba

March 8, 2006

System wide registry

by Vitaly Lipatov

In WINE user guide I read int the System Administration Tips about global registry files (f.i. /usr/local/etc/wine.systemreg) But I can't find any code in WINE about it. It is obsoleted now? Is it possible to use system wide registry now? -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

March 8, 2006

Re: ntdll: Fix Directory Searching when VFAT_IOCTL_READDIR_BOTH returns an invalid d_reclen

by Robert Shearman

Alexandre Julliard wrote: >Robert Shearman <rob(a)codeweavers.com> writes: > > > >>--- a/dlls/ntdll/directory.c >>+++ b/dlls/ntdll/directory.c >>@@ -1245,7 +1245,11 @@ static NTSTATUS find_file_in_dir( char * >> unix_name[pos - 1] = '/'; >> for (;;) >> { >>- if (!de[0].d_reclen) break; >>+ if (!de[0].d_reclen) >>+ { >>+ unix_name[pos - 1] = 0; >>+ break; >> >> > >We should probably have a 'goto not_found' here instead. > No, the file it is searching for exists, but doesn't seem to be returned by the ioctl for some reason. It is likely a x86-64 kernel bug, but we should still fix in our code IMHO. -- Rob Shearman

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Peter Beutner

Francois Gouget schrieb: > * or the application does not pass a NULL here because it would cause > it to crash on Windows. But if we merely return an error the application > will merrily go on, only to crash or report that DirectX does not work a > while later. By then the source of the problem will be very hard to find > due to all that happened since this function call. > The point is that we need to fix the bug that causes the application > to pass a NULL to Wine in the first place. And the best way to spot it, > and thus fix it, is if Wine segfaults in the same way as Windows when > given a NULL. The whole point of my email was that a crash here doesn't help you to find the real problem. It only says you that the function was called with a NULL pointer as parameter. Well, grepping through the trace log where a DirectX function returned an error most probably will get you the same result. And with the ERR() message that was in the original patch it would have been even easier to spot. Anyway both cases do _not_ tell you where things went wrong in the first place. You have to work through the whole trace log before that call to check where something wrong could have been returned. It might be even a bug in the application itself (e.g. forgotten check after malloc), who knows ... Or look at it from the view of a user developing a winelib application. I'm sure he will very much appreciate it when wine does a better parameter checking than MS and returns an error instead of a crash backtrace ;) Imo a library is supposed to validate given parameters as much as possible and rather return an error to the caller than to crash. But as the patch already was commited, I think any further discussion is pointless.

March 8, 2006

Re: linking errors in Winelib code (version 0.9.9) on Solaris 10

by Robert Shearman

Arun Kumar Khandelwal wrote: >I am compiling Winelib (version 0.9.9) on Solaris 10 machine. I am >getting below linking errors: > >gcc -c -I. -I. -I../../include -I../../include -I/usr/include/libxml2 >-I/usr/include/libxml2 -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT >-fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ >-Wdeclaration-after-statement -Wpointer-arith -g -O2 -o main.o main.c > >Undefined first referenced > symbol in file >GetStartupInfoA ../../dlls/libwinecrt0.a(exe_main.o) >GetModuleHandleA ../../dlls/libwinecrt0.a(exe_main.o) >GetCommandLineA ../../dlls/libwinecrt0.a(exe_main.o) >WinMain ../../dlls/libwinecrt0.a(exe_main.o) >ld: warning: Symbol referencing errors > > >Please suggest how to get rid of these errors. > I think you should be using winegcc. I'm afraid I don't know much more than that about winelib and the documentation is out of date so I can't refer you there. -- Rob Shearman

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Willie Sippel

[...] > > Second, some programs run fine with wine, e. g. pcAnywhere. And some > games do start up and show the title menu (like StarCraft or AOE2), but > crash when selecting a game. > > Third, as I said before, I've compiled wine from source on a Pentium II > Debian box which doesn't even know what x86_64 is, and copied the > installation directory /opt/wine-CVS... to my x86_64 box. But that > didn't help. I also used the setarch-utility to make the Wine configure > script see an i686-machine, and setting the -m32 flags for GCC by hand, > but the effect was the same. I also build Wine on an amd64 system (running gentoo/ amd64), no problems. But there's one thing I noticed a while ago: Wine continues to compile and install even if some of the DLLs won't compile. I had this a few times in the past, and ended up with a basically working Wine install that missed a few DLLs, mostly OpenGL-related stuff. Maybe something like that happens to you? Just check that all DLLs are built and in place, and make sure there were no errors during compile (like I said, with some DLLs, Wine just continues to build even though errors appear)... Ciao, Willie -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 8, 2006

linking errors in Winelib code (version 0.9.9) on Solaris 10

by Arun Kumar Khandelwal

I am compiling Winelib (version 0.9.9) on Solaris 10 machine. I am getting below linking errors: gcc -c -I. -I. -I../../include -I../../include -I/usr/include/libxml2 -I/usr/include/libxml2 -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -g -O2 -o main.o main.c Undefined first referenced symbol in file GetStartupInfoA ../../dlls/libwinecrt0.a(exe_main.o) GetModuleHandleA ../../dlls/libwinecrt0.a(exe_main.o) GetCommandLineA ../../dlls/libwinecrt0.a(exe_main.o) WinMain ../../dlls/libwinecrt0.a(exe_main.o) ld: warning: Symbol referencing errors Please suggest how to get rid of these errors. Thanks and Regards, Arun Khandelwal

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by H. Verbeet

On 08/03/06, Christoph Frick <frick(a)sc-networks.de> wrote: > the vertex-shader there goes nuts (rainbow cars) and about 2/3 of the > textures looks like only one pixel-row of the texture is scaled over the > whole polygone. > > the game used to work completly before that change - except the shadows > and the overlayed textures for the instruments. I think Roderick mentioned that shaders are currently broken in d3d8 and that he was working on fixing them. @Christian: For what it's worth, I'm on AMD64 as well and it seems to work just fine. As Stefan said, you should probably verify that it link against the correct libraries (although I'm not sure if trying to link against 64-bit libs would even compile).

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Christian Schneider

Am Mittwoch, den 08.03.2006, 10:20 +0100 schrieb Stefan Dösinger: > Hi, > > > > About half a year ago I replaced my old desktop by an AMD64 box and my > > > > previous x86 Linux from Scratch (LFS) installation by a x86_64 multilib > > > > LFS. And since then I'm not able to run any DirectX title anymore that > > > > used to work before. > > I tried, but it didn't help. I've also tried different audio outputs > > (ALSA and OSS), but the error messages are the same. > > > > Anyways, thanks for your reply. > It looks to me that something went wrong with compilation. Roderic does DX > development on an AMD64 machine without problems. Are you sure that Wine is > compiled for 32 Bit? The question is quite obvious, but yes, I am sure its 32-bit. First, the output of the following command is empty, so there are no 64-bit binaries in the wine directory: $ file /opt/wine/lib/{,wine/}*.so /opt/wine/bin/* | grep "64-bit" Second, some programs run fine with wine, e. g. pcAnywhere. And some games do start up and show the title menu (like StarCraft or AOE2), but crash when selecting a game. Third, as I said before, I've compiled wine from source on a Pentium II Debian box which doesn't even know what x86_64 is, and copied the installation directory /opt/wine-CVS... to my x86_64 box. But that didn't help. I also used the setarch-utility to make the Wine configure script see an i686-machine, and setting the -m32 flags for GCC by hand, but the effect was the same. > Perhaps some problem with the 32 bit libraries? In general 32-bit apps work fine on my machine. I can run Opera, Firefox, VMware 4.5, Quake III Arena, UT2004 and much other binary software without any problems. Are there some libs known to cause trouble with Wine? How can I check this? Cheers, Christian Schneider

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Christoph Frick

On Wed, Mar 08, 2006 at 11:01:06AM +0100, Christian Schneider wrote: > > > As you can see, the most common errors are err:seh:setup_exception > > > and err:ntdll:RtlpWaitForCriticalSection. I've also done some more > > > tests with other games like Revolt, Anno 1503, Half-Life 2, and > > > the errors all look alike. > > anno 1503 never ever worked for me (there where some discussion > > about apps like this that follow a pattern with ddraw and threads, > > that wine might be able to handle (ever)). > I know that it's not supposed to work, but don't you think it's > strange that I only get two types of error messages with any game, > regardless if it's known to work or not? like Stefan i would also consider this more like a problem with the installation? i also run all the games on a opteron box with 64bit gentoo and manual compiled wine. i had no problems as i switched last year from the 32bit platform other then the problems i had beforehand. although anno1503 is the only game you mentioned, that is also on my list - beside that i know the following games work: black mirror, nibiru (demo) il2 (stormovik, foreign battles, aces, pacific fighters), jagged alliance 2, grand prix legends, baldurs gate2, planescape torement - and i have problems running ankh, raven shield, richard burns rally. -- cu

March 8, 2006

ole:ITypeInfo_fnInvoke, failed to convert param 0

by Tomas Carnecky

I got this when the WoW patcher started: err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not registered err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59} could be created for for context 0x1 fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 err:ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT|VT_BYREF from VT_VARIANT|VT_BYREF and the last line doesn't make sense to me, the patcher runs fine though... tom

March 8, 2006

Re: Problem while compiling wine-0.9.9 source on solaris

by Francois Gouget

On Tue, 7 Mar 2006, Vikas Gera wrote: [...] > I tried to build Wine Library on Solaris 10 platform today. It gave > error while compiling dll/dxerr8 module. > The error message says "Don't know how to make target: install-lib" [...] > But similar error message is getting repeated for other modules as well. > I would like to fix it in one shot, probably a fix in the configure > script is needed. Has anybody faced this problem and fixed it? Please > suggest. Are you using GNU make or the standard make? Switching to GNU make may help. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Francois Gouget

On Tue, 7 Mar 2006, Peter Beutner wrote: [...] > Unless some app relies on this crashing behaviour(which I doubt), I don't think wine > should implement bugs just because MS does it. > Seems a bit obscure strategy to me to crash in case of an error instead of proper > error checking/reporting. This has been discussed many times before (but maybe not in the recent past). There are two cases to consider: * either some applications do pass NULL thus causing a segfault and then expect to catch that exception. As you said, this is pretty unlikely here but it has happened with other (non-DirectX) APIs. In this case, then Wine must segfault too otherwise the application will fail. * or the application does not pass a NULL here because it would cause it to crash on Windows. But if we merely return an error the application will merrily go on, only to crash or report that DirectX does not work a while later. By then the source of the problem will be very hard to find due to all that happened since this function call. The point is that we need to fix the bug that causes the application to pass a NULL to Wine in the first place. And the best way to spot it, and thus fix it, is if Wine segfaults in the same way as Windows when given a NULL. So segfaulting like Windows does is really the right thing to do. It may warrant a comment in the code though, especially if there is a test with a message right before. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Christian Schneider

Am Mittwoch, den 08.03.2006, 09:46 +0100 schrieb Christoph Frick: > On Wed, Mar 08, 2006 at 12:09:28AM +0100, Christian Schneider wrote: > > > As you can see, the most common errors are err:seh:setup_exception and > > err:ntdll:RtlpWaitForCriticalSection. I've also done some more tests > > with other games like Revolt, Anno 1503, Half-Life 2, and the errors > > all look alike. > > anno 1503 never ever worked for me (there where some discussion about > apps like this that follow a pattern with ddraw and threads, that wine > might be able to handle (ever)). > I know that it's not supposed to work, but don't you think it's strange that I only get two types of error messages with any game, regardless if it's known to work or not? Regards, Christian Schneider

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Christoph Frick

On Wed, Mar 08, 2006 at 10:18:32AM +0100, Stefan Dösinger wrote: > > anno 1503 never ever worked for me (there where some discussion > > about apps like this that follow a pattern with ddraw and threads, > > that wine might be able to handle (ever)). > Anno 1503 is not multi threaded, I had the demo running, but it was > VERY slow. But there might be other glx context bugs i guess i have tried running this game over a year now - everytime it crashes at the exact same place (choosing a flag and then switching to "3d-mode"). last week i tar:ed it and gave up - now you tell me it works ;) btw: for all the d3d8 -> wined3d gurus out there another demo, that make trouble: http://www.liveforspeed.net/ the vertex-shader there goes nuts (rainbow cars) and about 2/3 of the textures looks like only one pixel-row of the texture is scaled over the whole polygone. the game used to work completly before that change - except the shadows and the overlayed textures for the instruments. -- cu

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Stefan Dösinger

Hi, > > > About half a year ago I replaced my old desktop by an AMD64 box and my > > > previous x86 Linux from Scratch (LFS) installation by a x86_64 multilib > > > LFS. And since then I'm not able to run any DirectX title anymore that > > > used to work before. > I tried, but it didn't help. I've also tried different audio outputs > (ALSA and OSS), but the error messages are the same. > > Anyways, thanks for your reply. It looks to me that something went wrong with compilation. Roderic does DX development on an AMD64 machine without problems. Are you sure that Wine is compiled for 32 Bit? Perhaps some problem with the 32 bit libraries?

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Stefan Dösinger

Hi, > anno 1503 never ever worked for me (there where some discussion about > apps like this that follow a pattern with ddraw and threads, that wine > might be able to handle (ever)). Anno 1503 is not multi threaded, I had the demo running, but it was VERY slow. But there might be other glx context bugs

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Christian Schneider

Am Dienstag, den 07.03.2006, 16:39 -0700 schrieb Jesse Allen: > On 3/7/06, Christian Schneider <mail(a)chrschn.de> wrote: > > Hi all. > > > > About half a year ago I replaced my old desktop by an AMD64 box and my > > previous x86 Linux from Scratch (LFS) installation by a x86_64 multilib > > LFS. And since then I'm not able to run any DirectX title anymore that > > used to work before. > > > > > Try disabling the sound in winecfg. I tried, but it didn't help. I've also tried different audio outputs (ALSA and OSS), but the error messages are the same. Anyways, thanks for your reply. Cheers, Christian Schneider

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Christoph Frick

On Wed, Mar 08, 2006 at 12:09:28AM +0100, Christian Schneider wrote: > As you can see, the most common errors are err:seh:setup_exception and > err:ntdll:RtlpWaitForCriticalSection. I've also done some more tests > with other games like Revolt, Anno 1503, Half-Life 2, and the errors > all look alike. anno 1503 never ever worked for me (there where some discussion about apps like this that follow a pattern with ddraw and threads, that wine might be able to handle (ever)). -- cu

March 8, 2006

Re: GDI32: [4/5] freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

Hi. I found another registry key in my korean MS Windows XP. ----------------------------------------------------- [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc \Associated Charset] "ANSI(00)"="YES" "OEM(FF)"="YES" "SYMBOL(02)"="NO" [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc \Associated DefaultFonts] "AssocSystemFont"="gulim.ttc" "FontPackage"="GulimChe" "FontPackageDontCare"="굴림" "FontPackageRoman"="바탕" "FontPackageSwiss"="굴림" "FontPackageModern"="바탕" "FontPackageScript"="바탕" "FontPackageDecorative"="굴림" --------------------------------------------------------------- I think that create_child_font_list(), WineEngCreateFontInstance() have to this key. and then I can remove "defSystem" in all my patch(4/5 and 5/5). I working. but, create_child_font_list(), WineEngCreateFontInstance() will not create directly this key. I want your advice. Thanks. 2006-03-08 (수), 01:41 +0900, Byeong-Sik Jeon 쓰시길: > 2006-03-07 (화), 14:34 +0000, Huw D M Davies 쓰시길: > > On Tue, Mar 07, 2006 at 09:29:14PM +0900, Byeong-Sik Jeon wrote: > > > ChangeLog: > > > Improved create_child_font_list(), get_nearest_charset(), more using > > > font-linking mechanism. > > > > > > If lfCharSet == DEFAULT_CHARSET, then ALL font(LOGFONT) can see current > > > locale letter, (have to exist least one font corresponding current > > > locale ). > > > > > > > - If lfCharSet == DEFAULT_CHARSET then use the current locale codepage. > > > > and If selected font is not support current ansi codepage, then it fixup > > > > the problem in "create_child_font_list()" function. > > > > > > > > > > > I'm slightly confused about what you're trying to do here. Could you > > try to explain it again please? > > > Sorry, my poor english... > > assume "Arial.ttf" is exist in the system. > ------------------------------------------ > string = "Hello. 안녕하세요. 安寕"; /* include non-western character */ > > logfont.lfCharSet = DEFAULT_CHARSET; > logfont.lfFaceName = "Arial"; > hfont = CreateFontIndirect(&logfont); > SelectObject(hdc, hfont); > > TextOut(hdc, 10, 10, string, strlen(string)); > -------------------------------------------- > at this case, now Wine print out broken shape, because glyph missing on > Arial.ttf. > > font-linking mechanism help this situation. but need to > ------------------------------- > [HKLM\\...\SystemLink] > "Arial"="......" > -------------------------------- > New get_nearest_charset(), create_child_font_list() solve this situation > without any additional config file change. > > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontex… > ---------------------------------- > Windows NT/2000/XP: DEFAULT_CHARSET is set to a value based on the > current system locale. For example, when the system locale is English > (United States), it is set as ANSI_CHARSET. > ---------------------------------- > Korean locale => HANGEUL_CHARSET, > Japanese locale => SHIFTJIS_CHARSET. > .... > but, Arial.ttf is missing these charset, therefore incorrect operation > in the get_nearest_charset(). > > Sorry again. Please see the code.... > > > > Moving this TRACE is clearly not correct. > Yes. I mistake...

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Vitaliy Margolen

Tuesday, March 7, 2006, 3:22:28 PM, Peter Beutner wrote: > H. Verbeet schrieb: >> On 07/03/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: >>> This doesn't really make sense to me - the point of unspecified behavior >>> if a parameter is NULL would be to speed up the function under contract >>> with the caller. If you're already doing the check, why not handle it in >>> some way other than crashing? >> Because we *want* to crash and get a nice backtrace. > hm maybe I'm missing something but afaik you will get a backtrace right back into the > application code, which will help you exactly nothing (unless you have the source > code of the game and the binary doesn't have its debugging information stripped > which is very likely not the case). > So you have to figure out where you might have returned something wrong by looking at > the traces from _before_ GetCreationParameters. > The backtrace itself won't give you _any_ clues. > Unless some app relies on this crashing behaviour(which I doubt), I don't think wine > should implement bugs just because MS does it. > Seems a bit obscure strategy to me to crash in case of an error instead of proper > error checking/reporting. If anything Wine does crash in much more cases then native. Look at all the ntdll functions. Native never crash there (because all those are direct kernel calls). Wine on the other hand will crash whenever you have a bad pointer dereference. So I don't see any reasons why we should check for NULL pointer here. It will still crash if pointer is bogus, but not NULL. Also having a crash in a debug trace helps to find the place where did it crash. If Wine just returns from this function, you never know where it will cause the real problem. Vitaliy.

March 8, 2006

Can't run DirectX games on x86_64 biarch Linux

by Christian Schneider

Hi all. About half a year ago I replaced my old desktop by an AMD64 box and my previous x86 Linux from Scratch (LFS) installation by a x86_64 multilib LFS. And since then I'm not able to run any DirectX title anymore that used to work before. This is the way I usually compile wine (GCC 3.4.4): ./configure --prefix=/opt/wine-CVS20060307 \ --x-libraries=/usr/X11R6/lib && make depend && make && su -c "make install" Here are some games that used to work on my old LFS, their behaviour and the error messages. I've also attached a short log of each game to this messages. All these logs have been recorded with the CVS version of wine from 2006/03/05. Age of Empires 2 starts up, I can hear sound. When I click on "Single Player", the game hangs with the following message: err:seh:setup_exception stack overflow 24 bytes in thread 0009 eip 55726262 esp 55ca0fe8 stack 0x55ca1000-0x55db0000 Backgammon Pro is an older (7 years or so) backgammon game, quite simple and 2D, but uses DirectDraw. It crashes at startup: err:ntdll:RtlpWaitForCriticalSection section 0x5574d040 "directory.c: dir_section" wait timed out in thread 000b, blocked by 000c, retrying (60 sec) err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x55701230 Diablo 2 VidTest (D2VidTest.exe) runs fine and suggests Direct3D for rendering. When I click on the ok-button to quit, it keeps hanging: err:ntdll:RtlpWaitForCriticalSection section 0x6ffa0730 "?" wait timed out in thread 0009, blocked by 000a, retrying (60 sec) Diablo 2 crashes at startup after some time: err:ntdll:RtlpWaitForCriticalSection section 0x5574d6c0 "virtual.c: csVirtual" wait timed out in thread 0010, blocked by 0000, retrying (60 sec) err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x55701230 Half-Life crashes at startup: err:seh:setup_exception nested exception on signal stack in thread 0009 eip 55725f43 esp 55589c90 stack 0x55ca1000-0x55db0000 Monkey Island 4 (OpenGL-mode) crashes at startup: err:seh:setup_exception stack overflow 240 bytes in thread 0009 eip 557013e6 esp 55ca0f10 stack 0x55ca1000-0x55db0000 StarCraft starts to the title menu, but clicking on "Single Player" crashes it: err:seh:setup_exception stack overflow 276 bytes in thread 0009 eip 557013e6 esp 55ca0eec stack 0x55ca1000-0x55db0000 WarCraft 3 (OpenGL-mode) doesn't show up anything, just hangs silently. As you can see, the most common errors are err:seh:setup_exception and err:ntdll:RtlpWaitForCriticalSection. I've also done some more tests with other games like Revolt, Anno 1503, Half-Life 2, and the errors all look alike. I have tried the following things to solve the problem: * Deleted my ~/.wine, over and over again ;-) * Compiled wine without any optimization flags * Compiled wine on a x86 Debian box and copied the installation over * Copied my ~/.wine to that Debian box, where most of the games run fine * Tried different wine versions, starting with pre-0.9 versions, ending with the latest CVS version * Used winetools to setup an environment with many native DLLs. Installation of most of the software including IE worked fine, but did not help though. * Searched this mailing list archive and the web for similar errors Something is definitely going wrong with this. Anybody an idea? I would appreciate any help. Cheers, Christian Schneider

March 7, 2006

Re: WINED3D: Implement GetCreationParameters

by Peter Beutner

H. Verbeet schrieb: > On 07/03/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: >> This doesn't really make sense to me - the point of unspecified behavior >> if a parameter is NULL would be to speed up the function under contract >> with the caller. If you're already doing the check, why not handle it in >> some way other than crashing? > Because we *want* to crash and get a nice backtrace. hm maybe I'm missing something but afaik you will get a backtrace right back into the application code, which will help you exactly nothing (unless you have the source code of the game and the binary doesn't have its debugging information stripped which is very likely not the case). So you have to figure out where you might have returned something wrong by looking at the traces from _before_ GetCreationParameters. The backtrace itself won't give you _any_ clues. Unless some app relies on this crashing behaviour(which I doubt), I don't think wine should implement bugs just because MS does it. Seems a bit obscure strategy to me to crash in case of an error instead of proper error checking/reporting.

March 7, 2006

Re: valgrinding mozilla on wine

by Dan Kegel

On 3/7/06, Eric Pouech <eric.pouech(a)wanadoo.fr> wrote: > - the good news: most of the points related to false positives is either > in latest Wine and will be present in yet to come 3.1.1 (RC1 is for > Friday this week) > > - the bad news: the SEH support is still deficient, and we still have > stack issues (what you get). I updated the VG patch on the Wiki that > fixes (for me) some errors that look very close to what you describe > (the stack ones). OK. I'll try your new patch when 3.1.1 rc1 comes out. > As of today, the VG folks are rather sluggish to look > at those issues and to integrate some of the patches. So, they won't be > present for 3.1.1, perhaps for 3.2 (somewhere in April). That's still more responsive than a lot of projects. Thanks for moving this along! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 7, 2006

Re: valgrinding mozilla on wine

by Eric Pouech

Dan Kegel wrote: > On 3/7/06, Dan Kegel <dank(a)kegel.com> wrote: > >>I'm trying to track down a wine crash in firefox >>(http://bugs.winehq.org/show_bug.cgi?id=4762) >>and thought valgrind might be helpful. So, following >>http://wiki.winehq.org/Wine_and_Valgrind > > > When I posted the above, I hadn't yet applied the patch > mentioned in the wiki page. When I did, valgrind itself > crapped out: > > ==18736== Warning: client switching stacks? SP change: 0xBE857B4C --> 0x48DFFF0 > ==18736== to suppress, use: --max-stackframe=1174963364 or greater > --18707-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting > --18707-- si_code=1; Faulting address: 0x57E58959; sp: 0x62527DA4 > > valgrind: the 'impossible' happened: > Killed by fatal signal > ==18707== at 0xB001AB5C: vgPlain_get_StackTrace2 (m_stacktrace.c:147) > ==18707== by 0xB001AC31: vgPlain_get_StackTrace (m_stacktrace.c:331) > ==18707== by 0xB000DDCF: vgPlain_record_ExeContext (m_execontext.c:199) > ==18707== by 0xB0001116: create_MAC_Chunk (mac_malloc_wrappers.c:139) > ==18707== by 0xB0001B17: vgMAC_malloc (mac_malloc_wrappers.c:203) > ==18707== by 0xB002D9C3: do_client_request (scheduler.c:987) > ==18707== by 0xB002D498: vgPlain_scheduler (scheduler.c:721) > ==18707== by 0xB003BB99: thread_wrapper (syswrap-linux.c:86) > ==18707== by 0xB003BC5D: run_a_thread_NORETURN (syswrap-linux.c:119) > > so I guess there's definitely some work left to do on valgrind... yes :-/ actually, I haven't updated the wiki page lately - the good news: most of the points related to false positives is either in latest Wine and will be present in yet to come 3.1.1 (RC1 is for Friday this week) - the bad news: the SEH support is still deficient, and we still have stack issues (what you get). I updated the VG patch on the Wiki that fixes (for me) some errors that look very close to what you describe (the stack ones). As of today, the VG folks are rather sluggish to look at those issues and to integrate some of the patches. So, they won't be present for 3.1.1, perhaps for 3.2 (somewhere in April). A+ -- Eric Pouech

March 7, 2006

Re: wine 0.9.9 vs. Ned For Speed V -- already better

by Stefan Dösinger

> Here goes the log for running NFS5: PU, in win 0.9.9, the first version > which manages to allow NFS to initialize the video mode, apparently. The demo installer stops with a message box that DirectX7.0a is required. How did you get that game installed? Can you send me a +ddraw,+tid trace? The trace suggests multi-threaded Direct3D to me, which doesn't work yet. I haven't tested it with my code yet, because the installer failed. Stefan

March 7, 2006

Re: valgrinding mozilla on wine

by Dan Kegel

On 3/7/06, Dan Kegel <dank(a)kegel.com> wrote: > I'm trying to track down a wine crash in firefox > (http://bugs.winehq.org/show_bug.cgi?id=4762) > and thought valgrind might be helpful. So, following > http://wiki.winehq.org/Wine_and_Valgrind When I posted the above, I hadn't yet applied the patch mentioned in the wiki page. When I did, valgrind itself crapped out: ==18736== Warning: client switching stacks? SP change: 0xBE857B4C --> 0x48DFFF0 ==18736== to suppress, use: --max-stackframe=1174963364 or greater --18707-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --18707-- si_code=1; Faulting address: 0x57E58959; sp: 0x62527DA4 valgrind: the 'impossible' happened: Killed by fatal signal ==18707== at 0xB001AB5C: vgPlain_get_StackTrace2 (m_stacktrace.c:147) ==18707== by 0xB001AC31: vgPlain_get_StackTrace (m_stacktrace.c:331) ==18707== by 0xB000DDCF: vgPlain_record_ExeContext (m_execontext.c:199) ==18707== by 0xB0001116: create_MAC_Chunk (mac_malloc_wrappers.c:139) ==18707== by 0xB0001B17: vgMAC_malloc (mac_malloc_wrappers.c:203) ==18707== by 0xB002D9C3: do_client_request (scheduler.c:987) ==18707== by 0xB002D498: vgPlain_scheduler (scheduler.c:721) ==18707== by 0xB003BB99: thread_wrapper (syswrap-linux.c:86) ==18707== by 0xB003BC5D: run_a_thread_NORETURN (syswrap-linux.c:119) so I guess there's definitely some work left to do on valgrind... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 7, 2006

Wine and OS X

by Obchod id

Hi, There could be at least mention in FAQ about possible OS x version or whether there is no plan. Best wishes Frantisek -- !!! Nová prodejna v Plzni. Od 9.11. otevíráme druhou prodejnu na Náměstí Republiky 21, v 1. patře přímo nad kanceláří Annonce, na zastávce tramvaje směr Slovany. Tel: 377 331 256!!! >>>Stesticko.cz - pro radostny a naplneny zivot. http://www.stesticko.cz > Knihkupectvi, internetovy a zásilkovy obchod http://shop.stesticko.cz >> Pecujeme o vase telo i dusi Knihy pro osobni rust, duchovno, esoteriku, hudba, tarot. karty, feng-shui Americka 20, Plzen, Po-Pa 9-18, So 10-12 h,tel: 377 91 91 73, 777 263 352 Namesti Republiky 21, Plzen, Po-Pa 10-18 h tel: 377 331 256, 608 702 719 > Alternativni knihovna a antikvariat http://www.stesticko.cz/knihovna/ >>> http://sweb.cz/wingmakers - Tvurci kridel - WingMakers.com <<<

March 7, 2006

Problem while compiling wine-0.9.9 source on solaris

by Vikas Gera

I tried to build Wine Library on Solaris 10 platform today. It gave error while compiling dll/dxerr8 module. The error message says "Don't know how to make target: install-lib" I compared the Makefiles and added the target "install-lib" for dxerr8 module, like below: Makefile: install install-lib:: install_lib $(WIN16_INSTALL) install_lib: $(MODULE) $(MKINSTALLDIRS) $(DESTDIR)$(dlldir) $(INSTALL_PROGRAM) $(MODULE) $(DESTDIR)$(dlldir)/$(MODULE) It was able to build the dxerr8 module. But similar error message is getting repeated for other modules as well. I would like to fix it in one shot, probably a fix in the configure script is needed. Has anybody faced this problem and fixed it? Please suggest. regards, Vikas Gera

March 7, 2006

valgrinding mozilla on wine

by Dan Kegel

I'm trying to track down a wine crash in firefox (http://bugs.winehq.org/show_bug.cgi?id=4762) and thought valgrind might be helpful. So, following http://wiki.winehq.org/Wine_and_Valgrind I installed valgrind-3.1.0 and ran valgrind --trace-children=yes /home/dank/wine/wine /home/dank/.wine/drive_c/Program\ Files/Mozilla\ Firefox/firefox.exe This got as far as putting up a window (but not filling it in) before croaking, so I guess valgrind still has some ways to go. Before it bailed, it printed out a few interesting warnings: ... ==16329== Warning: noted but unhandled ioctl 0x30B with no size/direction hints ==16329== This could cause spurious value errors to appear. ==16329== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==16329== ==16329== Syscall param writev(vector[...]) points to uninitialised byte(s) ==16329== at 0x20000772: (within /lib/ld-2.3.5.so) ==16329== by 0x202D2BD8: wine_server_call (in /home/dank/wine/dlls/ntdll/ntdll.dll.so) ==16329== by 0x202C85D3: NtSetValueKey (reg.c:755) ==16329== by 0x205BFFF8: create_scsi_entry (oldconfig.c:170) ==16329== by 0x205C07BD: convert_old_config (oldconfig.c:400) ==16329== by 0x205C482E: __wine_kernel_init (process.c:751) ==16329== by 0x202C0BB2: __wine_process_init (loader.c:2276) ==16329== by 0x2002448E: wine_init (loader.c:600) ==16329== by 0x7BF01001: main (main.c:58) ==16329== Address 0xBEBF0874 is on thread 1's stack ... err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not registered err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59} could be created for for context 0x1 fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 ==16329== ==16329== Invalid read of size 4 ==16329== at 0x600195C4: ??? ==16329== Address 0x208BE16C is not stack'd, malloc'd or (recently) free'd ==16329== ==16329== Conditional jump or move depends on uninitialised value(s) ==16329== at 0x463876: ??? ==16329== ==16329== Invalid read of size 4 ==16329== at 0x603514C4: ??? ==16329== Address 0x208BCC70 is not stack'd, malloc'd or (recently) free'd ... err:seh:segv_handler Got unexpected trap 0 err:seh:segv_handler Got unexpected trap 0 err:seh:segv_handler Got unexpected trap 0 ... -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 7, 2006

problem in configure/make wine 0.9.9

by Lalit Aggarwal

When I rum make command it shows the following error, can somebody please help me in to come out of this. Undefined first referenced symbol in file GetStartupInfoA ../../dlls/libwinecrt0.a(exe_main.o) GetCommandLineA ../../dlls/libwinecrt0.a(exe_main.o) WinMain ../../dlls/libwinecrt0.a(exe_main.o) ld: warning: Symbol referencing errors Tried editing /var/installs/wine-0.9.9/dlls/ddraw/Makefile at line number 367 and put the /var/installs/wine-0.9.9/dlls/kernel/environ.o after -o option, it build the shared object successfully. Can anybody suggest how to fix this in configure or config.status script so the environ.o file is automatically included in the Makefile. Thanks -Lalit

March 7, 2006

Re: GDI32: [4/5] freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

2006-03-07 (화), 14:34 +0000, Huw D M Davies 쓰시길: > On Tue, Mar 07, 2006 at 09:29:14PM +0900, Byeong-Sik Jeon wrote: > > ChangeLog: > > Improved create_child_font_list(), get_nearest_charset(), more using > > font-linking mechanism. > > > > If lfCharSet == DEFAULT_CHARSET, then ALL font(LOGFONT) can see current > > locale letter, (have to exist least one font corresponding current > > locale ). > > > > > - If lfCharSet == DEFAULT_CHARSET then use the current locale codepage. > > > and If selected font is not support current ansi codepage, then it fixup > > > the problem in "create_child_font_list()" function. > > > > > > > I'm slightly confused about what you're trying to do here. Could you > try to explain it again please? > Sorry, my poor english... assume "Arial.ttf" is exist in the system. ------------------------------------------ string = "Hello. 안녕하세요. 安寕"; /* include non-western character */ logfont.lfCharSet = DEFAULT_CHARSET; logfont.lfFaceName = "Arial"; hfont = CreateFontIndirect(&logfont); SelectObject(hdc, hfont); TextOut(hdc, 10, 10, string, strlen(string)); -------------------------------------------- at this case, now Wine print out broken shape, because glyph missing on Arial.ttf. font-linking mechanism help this situation. but need to ------------------------------- [HKLM\\...\SystemLink] "Arial"="......" -------------------------------- New get_nearest_charset(), create_child_font_list() solve this situation without any additional config file change. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontex… ---------------------------------- Windows NT/2000/XP: DEFAULT_CHARSET is set to a value based on the current system locale. For example, when the system locale is English (United States), it is set as ANSI_CHARSET. ---------------------------------- Korean locale => HANGEUL_CHARSET, Japanese locale => SHIFTJIS_CHARSET. .... but, Arial.ttf is missing these charset, therefore incorrect operation in the get_nearest_charset(). Sorry again. Please see the code.... > Moving this TRACE is clearly not correct. Yes. I mistake...

March 7, 2006

Re: GDI32: [1/5] freetype.c add more font selecting&linking mechanism support.

by Huw D M Davies

On Tue, Mar 07, 2006 at 03:01:34PM +0000, Huw D M Davies wrote: > The def* strings are supposed to be the default fallback names for the > various fonts. Here you just want to use the string "System", so > please leave it as it was. Actually, what you really want to use is SystemW[]. The def* strings should go at some point, but that's another story. Huw. -- Huw Davies huw(a)codeweavers.com

March 7, 2006

Repeatable crash in firefox

by Dan Kegel

This morning, using wine from cvs from a few days ago, I ran into a reproducible crash in firefox on wine. I have the Flash plugin installed; that might be involved, but the same recipe doesn't seem to crash Linux firefox. I filed http://bugs.winehq.org/show_bug.cgi?id=4762 for this; I'll try again with fresh cvs. -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 7, 2006

Re: GDI32: [1/5] freetype.c add more font selecting&linking mechanism support.

by Huw D M Davies

On Tue, Mar 07, 2006 at 11:58:01PM +0900, Byeong-Sik Jeon wrote: > 2006-03-07 (화), 14:22 +0000, Huw D M Davies 쓰시길: > > > > Why don't you just use "tahoma.ttf" in the code where you call > > find_face_from_filename, there's no point in initializing a char > > string like this. > Yes. will be change to static const char Tahoma_ttf[] = "tahama.ttf"; Just remove the variable completely and call find_face_from_filenae("tahoma.ff") > > > - system_font_link->font_name = strdupW(System); > > > + system_font_link->font_name = strdupW(defSystem); > > > > Please don't use defSystem here. That's supposed to be a fallback for > > System. Please leave it as it was. > I can't understand. defSans, defFixed, defSerif is already using in the WineEngCreateFontInstance(). > this is different case? The def* strings are supposed to be the default fallback names for the various fonts. Here you just want to use the string "System", so please leave it as it was. Huw. -- Huw Davies huw(a)codeweavers.com

March 7, 2006

Re: GDI32: [1/5] freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

2006-03-07 (화), 14:22 +0000, Huw D M Davies 쓰시길: > On Tue, Mar 07, 2006 at 09:10:12PM +0900, Byeong-Sik Jeon wrote: > > ChangeLog: > > init_system_links support .ttc file. > > add "Tahoma" registry value for CJK font link. > > find_face_from_filename support .ttc file > > > > I think you could spilt out the 'add Tahoma registry value' bit from > this patch to make it a little smaller. Yes. I understand. add_reg_value_system_font_link() will be removed. > > > --- 000/dlls/gdi/freetype.c 2006-03-07 19:09:53.000000000 +0900 > > +++ 001/dlls/gdi/freetype.c 2006-03-07 20:28:14.000000000 +0900 > > @@ -909,14 +935,16 @@ > > SYSTEM_LINKS *font_link, *system_font_link; > > CHILD_FONT *child_font; > > static const WCHAR Tahoma[] = {'T','a','h','o','m','a',0}; > > - static const WCHAR tahoma_ttf[] = {'t','a','h','o','m','a','.','t','t','f',0}; > > - static const WCHAR System[] = {'S','y','s','t','e','m',0}; > > + static const char Tahoma_ttf[] = {'t','a','h','o','m','a','.','t','t','f',0}; > > Why don't you just use "tahoma.ttf" in the code where you call > find_face_from_filename, there's no point in initializing a char > string like this. Yes. will be change to static const char Tahoma_ttf[] = "tahama.ttf"; > > > @@ -990,15 +1046,15 @@ > > that Tahoma has */ > > > > system_font_link = HeapAlloc(GetProcessHeap(), 0, sizeof(*system_font_link)); > > - system_font_link->font_name = strdupW(System); > > + system_font_link->font_name = strdupW(defSystem); > > Please don't use defSystem here. That's supposed to be a fallback for > System. Please leave it as it was. I can't understand. defSans, defFixed, defSerif is already using in the WineEngCreateFontInstance(). this is different case? Thanks.

March 7, 2006

Re: GDI32: [4/5] freetype.c add more font selecting&linking mechanism support.

by Huw D M Davies

On Tue, Mar 07, 2006 at 09:29:14PM +0900, Byeong-Sik Jeon wrote: > ChangeLog: > Improved create_child_font_list(), get_nearest_charset(), more using > font-linking mechanism. > > If lfCharSet == DEFAULT_CHARSET, then ALL font(LOGFONT) can see current > locale letter, (have to exist least one font corresponding current > locale ). > > > - If lfCharSet == DEFAULT_CHARSET then use the current locale codepage. > > and If selected font is not support current ansi codepage, then it fixup > > the problem in "create_child_font_list()" function. > > > I'm slightly confused about what you're trying to do here. Could you try to explain it again please? > --- 003/dlls/gdi/freetype.c 2006-03-07 20:29:58.000000000 +0900 > +++ 004/dlls/gdi/freetype.c 2006-03-07 20:30:31.000000000 +0900 > + if(!TranslateCharsetInfo((DWORD*)(INT)font->charset, &csi, TCI_SRCCHARSET)) > + return FALSE; > > + TRACE("found entry in system list\n"); > + > + fs.fsCsb[0] = fs.fsCsb[1] = 0; > LIST_FOR_EACH_ENTRY(font_link, &system_links, SYSTEM_LINKS, entry) > { > - if(!strcmpW(font_link->font_name, font->name)) > + if(!strcmpiW(font_link->font_name, font->name)) > { > - TRACE("found entry in system list\n"); Moving this TRACE is clearly not correct. Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

March 7, 2006

Re: GDI32: [1/5] freetype.c add more font selecting&linking mechanism support.

by Huw D M Davies

On Tue, Mar 07, 2006 at 09:10:12PM +0900, Byeong-Sik Jeon wrote: > ChangeLog: > init_system_links support .ttc file. > add "Tahoma" registry value for CJK font link. > find_face_from_filename support .ttc file > I think you could spilt out the 'add Tahoma registry value' bit from this patch to make it a little smaller. > --- 000/dlls/gdi/freetype.c 2006-03-07 19:09:53.000000000 +0900 > +++ 001/dlls/gdi/freetype.c 2006-03-07 20:28:14.000000000 +0900 > @@ -909,14 +935,16 @@ > SYSTEM_LINKS *font_link, *system_font_link; > CHILD_FONT *child_font; > static const WCHAR Tahoma[] = {'T','a','h','o','m','a',0}; > - static const WCHAR tahoma_ttf[] = {'t','a','h','o','m','a','.','t','t','f',0}; > - static const WCHAR System[] = {'S','y','s','t','e','m',0}; > + static const char Tahoma_ttf[] = {'t','a','h','o','m','a','.','t','t','f',0}; Why don't you just use "tahoma.ttf" in the code where you call find_face_from_filename, there's no point in initializing a char string like this. > @@ -990,15 +1046,15 @@ > that Tahoma has */ > > system_font_link = HeapAlloc(GetProcessHeap(), 0, sizeof(*system_font_link)); > - system_font_link->font_name = strdupW(System); > + system_font_link->font_name = strdupW(defSystem); Please don't use defSystem here. That's supposed to be a fallback for System. Please leave it as it was. -- Huw Davies huw(a)codeweavers.com

March 7, 2006

Re: GDI32: freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

2006-03-07 (화), 10:45 +0000, Huw D M Davies 쓰시길: > As Mike has said the patch is too long to review properly, so please > break it down into much smaller pieces. > > On Tue, Mar 07, 2006 at 04:29:04PM +0900, Byeong-Sik Jeon wrote: > > and, I add some basic registry value. "Tahoma", "Gulim", "MS UI Gothic", > > "Simsun", "PMingLiU". > > One thing that caught my eye was that these strings are locale > dependent rather like the bitmap font strings (see update_font_info). Sorry, Huw. I understand. update_font_info() have to create the [HKLM\\Software\\Microsoft\ \Windows NT\\CurrentVersion\\FontLink\\SystemLink] and add Tahoma, etc value. it's more more better good approach. I'll remove add_reg_value_system_font_link().

March 7, 2006

Re: GDI32: freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

I resended five splited patches. Thanks advice... 2006-03-07 (화), 16:58 +0900, Mike McCormack 쓰시길: > Byeong-Sik Jeon wrote: > > > ChangeLog: > > - add more font selecting & linking mechanism support. > > Nice work! > > Some comments: > > * Please split each fix into a separate patch. This makes patch reviews > and isolating regressions easier. A number of small patches will be > accepted into the Wine tree faster than one big patch. > > * There's also alot of unnecessary formatting changes in your patch, > which could be avoided. eg. > > > - LIST_FOR_EACH_ENTRY(family, &font_list, Family, entry) > > - { > > + LIST_FOR_EACH_ENTRY(family, &font_list, Family, entry) { > > * Please stick to coding style in the file you're change, so that we > don't end up with a mix of many different coding styles in the same > file. (and you don't add unnecessary changes like the above). > > thanks, > > Mike

March 7, 2006

Trying to fix bug 2400 - delete and comma

by agaro agaro

Hi all, I'm trying to fix bug 2400 - removes one char and puts comma simultaneously. My guess: this old bug is in dlls/x11drv/keyboard.c or dlls/user/message.c, something about dead keys implementation. Can somebody help me with a little explanation or documentation? I don't know what scancode, keycode and vkey mean. Thanks, agaro

March 7, 2006

Re: WINED3D: Implement GetCreationParameters

by H. Verbeet

On 07/03/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > This doesn't really make sense to me - the point of unspecified behavior > if a parameter is NULL would be to speed up the function under contract > with the caller. If you're already doing the check, why not handle it in > some way other than crashing? Because we *want* to crash and get a nice backtrace. Since native d3d crashes when passed a NULL pointer, chances are that if we do get passed a NULL pParameters here, it is because we passed it to the application ourselves somewhere earlier. In the case of GetCreationParameters it's probably not very likely to get passed a NULL pointer anyway, but that's the general idea.

March 7, 2006

Re: GDI32: freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

2006-03-07 (화), 11:33 +0000, Huw D M Davies 쓰시길: > Right, but even Tahoma is locale dependent - the order of Gulim, MS UI > Gothic etc changes. Yes. but lucky thing... fsCsb[0] information of each font are: Gulim : ANSI, EASTEUROPE, RUSSIAN, GREEK, TURKISH, BALTIC, "HANGEUL" MS UI Gothic: ANSI, ASTEUROPE, RUSSIAN, GREEK, TURKISH, BALTIC, "SHIFTJIS" MingLiU : ANSI, "CHINESEBIG5" SimSun : ANSI, "GB2312" therefore, at japanese locale, if call "tahoma" then use "msgothic.ttc" (not "gulim.ttc"). But, I think that this is "FIXME" feature.

March 7, 2006

Re: WINED3D: Implement GetCreationParameters

by Robert Reif

H. Verbeet wrote: >On 07/03/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > >>Native D3D crashes if it's called with a NULL pointer? Are you sure that you >>shouldn't return something like D3DERR_INVALIDCALL if pParamters == NULL? >> >> >Yes. I verified that with DirectX 9.0c on win2k. > > > > > The Retail version of the dll might not check the parameters but the Debug version probably does.

March 7, 2006

Re: WINED3D: Implement GetCreationParameters

by Ivan Gyurdiev

H. Verbeet wrote: > On 07/03/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > >> Native D3D crashes if it's called with a NULL pointer? Are you sure that you >> shouldn't return something like D3DERR_INVALIDCALL if pParamters == NULL? >> > Yes. I verified that with DirectX 9.0c on win2k. > This doesn't really make sense to me - the point of unspecified behavior if a parameter is NULL would be to speed up the function under contract with the caller. If you're already doing the check, why not handle it in some way other than crashing? Anyway, I'm not familiar with wine development practices, so I wouldn't know whether this is the right thing to do - just wanted to point it out. I also see the same thing done in other wined3d patches.

March 7, 2006

Re: GDI32: freetype.c add more font selecting&linking mechanism support.

by Huw D M Davies

On Tue, Mar 07, 2006 at 08:22:36PM +0900, Byeong-Sik Jeon wrote: > 2006-03-07 (화), 10:45 +0000, Huw D M Davies 쓰시길: > > As Mike has said the patch is too long to review properly, so please > > break it down into much smaller pieces. > Yes. now working... Great. > > One thing that caught my eye was that these strings are locale > > dependent rather like the bitmap font strings (see update_font_info). > Yes. that is just thing like example, I will remove that. > > but, tahoma is important. "Tahoma" is linked at the "System" and, > many resource files use "MS Shell Dlg", and font substitutes "MS Shell > Dlg"="Tahoma". therefore, if font(gulim.ttc, msgothic.ttc, ...) is > exist, then we(CJK users) can see our latter at first start. > > just only "tahoma"... > HKLM: > [Software\\Microsoft\\Windows NT\\CurrentVersion\\FontLink\\SystemLink] > "Tahoma"=str(7):"Gulim.ttc,Gulim\0MsGothic.ttc,MS UI Gothic > \0SimSun.ttc,SimSun\0Mingliu.ttc,PMingLiU\0" Right, but even Tahoma is locale dependent - the order of Gulim, MS UI Gothic etc changes. Huw. -- Huw Davies huw(a)codeweavers.com

March 7, 2006

Re: GDI32: freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

2006-03-07 (화), 10:45 +0000, Huw D M Davies 쓰시길: > As Mike has said the patch is too long to review properly, so please > break it down into much smaller pieces. Yes. now working... > > and, I add some basic registry value. "Tahoma", "Gulim", "MS UI Gothic", > > "Simsun", "PMingLiU". > > One thing that caught my eye was that these strings are locale > dependent rather like the bitmap font strings (see update_font_info). Yes. that is just thing like example, I will remove that. but, tahoma is important. "Tahoma" is linked at the "System" and, many resource files use "MS Shell Dlg", and font substitutes "MS Shell Dlg"="Tahoma". therefore, if font(gulim.ttc, msgothic.ttc, ...) is exist, then we(CJK users) can see our latter at first start. just only "tahoma"... HKLM: [Software\\Microsoft\\Windows NT\\CurrentVersion\\FontLink\\SystemLink] "Tahoma"=str(7):"Gulim.ttc,Gulim\0MsGothic.ttc,MS UI Gothic \0SimSun.ttc,SimSun\0Mingliu.ttc,PMingLiU\0"

March 7, 2006

Re: GDI32: freetype.c add more font selecting&linking mechanism support.

by Huw D M Davies

As Mike has said the patch is too long to review properly, so please break it down into much smaller pieces. On Tue, Mar 07, 2006 at 04:29:04PM +0900, Byeong-Sik Jeon wrote: > and, I add some basic registry value. "Tahoma", "Gulim", "MS UI Gothic", > "Simsun", "PMingLiU". One thing that caught my eye was that these strings are locale dependent rather like the bitmap font strings (see update_font_info). Keep up the good work! Huw. -- Huw Davies huw(a)codeweavers.com

March 7, 2006

Re: WINED3D: Implement GetCreationParameters

by H. Verbeet

On 07/03/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Native D3D crashes if it's called with a NULL pointer? Are you sure that you > shouldn't return something like D3DERR_INVALIDCALL if pParamters == NULL? Yes. I verified that with DirectX 9.0c on win2k.

March 7, 2006

Re: advpack: Forward OpenINFEngineA and TranslateInfString/ExA to their unicode counterparts

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > + > + res = TranslateInfStringW(filenameW.Buffer, installW.Buffer, > + translateW.Buffer, keyW.Buffer, NULL, > + dwBufferSize, &len, NULL); > + > + if (res == S_OK) > + { > + bufferW = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + > + res = TranslateInfStringW(filenameW.Buffer, installW.Buffer, > + translateW.Buffer, keyW.Buffer, bufferW, > + dwBufferSize, &len, NULL); > + > + *pdwRequiredSize = WideCharToMultiByte(CP_ACP, 0, bufferW, -1, > + pszBuffer, dwBufferSize, > + NULL, NULL); > + The buffer size and overflow handling is not correct here. -- Alexandre Julliard julliard(a)winehq.org

March 7, 2006

Re: WINED3D: Implement GetCreationParameters

by Stefan Dösinger

Am Dienstag, 7. März 2006 08:50 schrieb H. Verbeet: > On 07/03/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > > > + if (!pParameters) { > > > + ERR("(%p) : Called with a NULL pParameters\n", This); > > > + } > > > + > > > + *pParameters = This->createParms; > > > > This is dereferencing a NULL pointer. > > Yes. Native d3d does that as well. The NULL pointer check there is > purely informational. Native D3D crashes if it's called with a NULL pointer? Are you sure that you shouldn't return something like D3DERR_INVALIDCALL if pParamters == NULL? Might be worth a test case if native really crashes.

March 7, 2006

Re: winegdb: Fix crash in empty first command

by Eric Pouech

2006/3/6, Vitor T. Sessak <vitor.sessak(a)m4x.org>: > > 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.

March 7, 2006

Re: GDI32: freetype.c add more font selecting&linking mechanism support.

by Mike McCormack

Byeong-Sik Jeon wrote: > ChangeLog: > - add more font selecting & linking mechanism support. Nice work! Some comments: * Please split each fix into a separate patch. This makes patch reviews and isolating regressions easier. A number of small patches will be accepted into the Wine tree faster than one big patch. * There's also alot of unnecessary formatting changes in your patch, which could be avoided. eg. > - LIST_FOR_EACH_ENTRY(family, &font_list, Family, entry) > - { > + LIST_FOR_EACH_ENTRY(family, &font_list, Family, entry) { * Please stick to coding style in the file you're change, so that we don't end up with a mix of many different coding styles in the same file. (and you don't add unnecessary changes like the above). thanks, Mike

March 7, 2006

Re: WINED3D: Implement GetCreationParameters

by H. Verbeet

On 07/03/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > > > + if (!pParameters) { > > + ERR("(%p) : Called with a NULL pParameters\n", This); > > + } > > + > > + *pParameters = This->createParms; > > > This is dereferencing a NULL pointer. Yes. Native d3d does that as well. The NULL pointer check there is purely informational.

March 7, 2006

Re: riched20: Implements FR_WHOLEWORD for EM_FINDTEXT

by Lei Zhang

On Monday 06 March 2006 01:28 pm, Phil Krylov wrote: > On Sun, 05 Mar 2006 14:20:47 -0800 > > Lei Zhang <leiz(a)ucla.edu> wrote: > > + if ((flags & FR_WHOLEWORD) && iswalnum(wLastChar)) > > Probably a test checking if native richedit does not use user's word > breaking procedure (set via EM_SETWORDBREAKPROC) for FR_WHOLEWORD > searches would be cool. > > -- Ph. Thanks, I will add this along with some i18n tests at a later time. - Lei

March 7, 2006

Re: WINED3D: Implement GetCreationParameters

by Ivan Gyurdiev

> + if (!pParameters) { > + ERR("(%p) : Called with a NULL pParameters\n", This); > + } > + > + *pParameters = This->createParms; > This is dereferencing a NULL pointer.

March 7, 2006

Re: How to link and run applications using WinLib

by Robert Shearman

Segin wrote: > Arun Kumar Khandelwal wrote: > >> Hi All, >> I am able to compile and link my test program using winemaker. It >> generates a test.exe.so and not test.exe. I do not know how to run this >> *.so? What should I do to link and run program using winlib? Thanks, >> Arun > > you use it like any executable. The '.so' part is to signify that the > file is a ELF shared object. > > Also, can you attach the source code and executable in your reply? I'd > like to take a look at it, if that's not a problem. You use wine to run the program. If that is a problem then you can always provide a wrapper script or hack the source to always load your .exe.so file (if you are shipping wine with your program). -- Rob Shearman

March 7, 2006

Re: PATCH: define __user

by Robert Shearman

dmitry serpokryl wrote: > Hi, > > please beg my pardon for the kind of a possible stupidity, but: > > 1. I'm using SuSE kernel for SuSE 10 x86-64, so all compiliation goes > into x86-64 (not in i386) mode by default Wine automatically adds the -m32 flag to gcc to force it to compile in i386 mode. > 2. gcc - 4.0.2 (release): > Target: x86_64-unknown-linux-gnu > Configured with: ../configure --prefix=/usr/local/gcc-4.0.2 > Thread model: posix > gcc version 4.0.2 That's fine. > 3. $ wine --version > Wine 0.9.7 > (compiled some times ago from CVS. I make CVS updates monthly) As is this. > 4. $ locate unistd.h | egrep usr/include > /usr/include/asm-i386/unistd.h > /usr/include/asm-x86_64/ia32_unistd.h > /usr/include/asm-x86_64/unistd.h > /usr/include/asm.default/ia32_unistd.h > /usr/include/asm.default/unistd.h > /usr/include/kpathsea/c-unistd.h > /usr/include/linux.default/unistd.h > /usr/include/sys/unistd.h > /usr/include/unistd.h > > > 5. /usr/include/asm is a symlink, pointing to -> > /usr/src/linux/include/asm/ I think this is the problem. Is this a default symlink on your distro or was it put there by installing kernel source? > So, I'm not quite understand the reason of compiliation error at this > time. In 32-bit mode the i386 headers should be used instead of x86-64 ones. On your system this isn't happening, although the headers are there. Try looking in /usr/include/asm.default and seeing whether they try to do the right thing and select the right unistd.h for the environment. > > Please beg my pardon for the disturbing. > > Thanks, > > My best regards, > Dmitry > > > > On Tue, 28 Feb 2006 08:08:45 -0300, Robert Shearman > <rob(a)codeweavers.com> wrote: > >> dmitry serpokryl wrote: >> >>> Hi, thanks for your feedback. >>> >>> I just updated wine cvs, no ./configure errors but still "make" >>> unable to complete: >>> >>> gcc -m32 -c -I. -I. -I../../include -I../../include >>> -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe >>> -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement >>> -Wpointer-arith -g -O2 -o signal_i386.o signal_i386.c >>> signal_i386.c: In function ‘wine_sigaction’: >>> signal_i386.c:123: error: ‘__NR_sigaction’ undeclared (first use in >>> this function) >> >> >> >> You're using some buggy headers that define SYS_sigaction, but don't >> define __NR_sigaction. You should have /usr/include/asm/unistd.h >> that includes /usr/include/asm-i386/unistd.h if not compiling in >> x86_64 mode, and the latter should have a define for __NR_sigaction. >> > > > -- Rob Shearman

March 7, 2006

Re: How to link and run applications using WinLib

by Segin

Arun Kumar Khandelwal wrote: >Hi All, > I am able to compile and link my test program using winemaker. It >generates a test.exe.so and not test.exe. I do not know how to run this >*.so? What should I do to link and run program using winlib? >Thanks, >Arun > > > > > you use it like any executable. The '.so' part is to signify that the file is a ELF shared object. Also, can you attach the source code and executable in your reply? I'd like to take a look at it, if that's not a problem.

March 6, 2006

Re: riched20: Implements FR_WHOLEWORD for EM_FINDTEXT

by Phil Krylov

On Sun, 05 Mar 2006 14:20:47 -0800 Lei Zhang <leiz(a)ucla.edu> wrote: > + if ((flags & FR_WHOLEWORD) && iswalnum(wLastChar)) Probably a test checking if native richedit does not use user's word breaking procedure (set via EM_SETWORDBREAKPROC) for FR_WHOLEWORD searches would be cool. -- Ph.

March 6, 2006

Re: Error while compiling code using wineg++ / winegcc on solaris

by Kuba Ober

> I am not able to compile a test program on solaris using winegcc tool. > Can anybody help? . . . > When I try to compile it using winegcc, it gives following error > message: > testuser(a)testbox:~/test >wineg++ test.cpp > winegcc: -fshort-wchar failed. > > On adding a flag '-v' with wineg++, a detailed error message is > displayed: > testuser(a)testbox:~/test >wineg++ -v test.cpp > -fshort-wchar -DWINE_UNICODE_NATIVE -D_REENTRANT -fPIC -DWIN32 -D_WIN32 . . . Pardon me, but this kinda looks like wineg++ is not finding the compiler. Here's how it looks on my FC4 box with wine 0.9.7: $ wineg++ -v q.cpp g++ -fshort-wchar -DWINE_UNICODE_NATIVE . . . ^^^ You should investigate why wineg++ doesn't find what the name of the compiler is. It tried actually invoking an executable by the name of -fshort-wchar, as a session with truss would have shown ;) Cheers, Kuba

March 6, 2006

Re: KERNEL32: Improve descriptions

by Kuba Ober

> > > -UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, > > > UINT unique, LPWSTR buffer ) +UINT WINAPI GetTempFileNameW( > > > LPCWSTR lpPathName, LPCWSTR lpPrefixString, UINT uUnique, > > > LPWSTR lpTempFileName ) > > > > *Please* don't change nice readable parameter names into the > > horrible Hungarian line noise format. > > Sorry, I thought we need to fix parameter names according to > MSDN :( Weren't the parameter names an implementation detail that's essentially invisible to the api user (docs nothwithstanding)? I.e. there's no such thing as 'fixing them' according to MSDN, because the api spec itself has no authority over parameter names. Heck, they can be different (or nonexistent) in the header files than in implementation files, and so on, right? Presumably the names should be nice so that wine maintainers can maintain the implementation ;) Cheers, Kuba

March 6, 2006

Re: FONTS: fix Courier font

by Huw D M Davies

On Mon, Mar 06, 2006 at 07:02:47PM +0300, Vitaly Lipatov wrote: > В сообщении от 6 марта 2006 17:27 Вы написали: > > "Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > > > > What are you trying to fix? > > > > > > There is screenshot from notepad with Courier font selected in > > > attachment. > > > > Do you see the same problem with Windows font? > No, only with WINE's courier without my path Looks like this might be a fontforge or FreeType problem. Windows courier at 13 ppem should have an ascent of 11 and a descent of 2, which is what we have in the .sfd. Now, when I run sfnt2fnt on the generated .ttf I get an ascent of 13, ppem of 13 and hence a descent of 0. I'm not going to have time to look into this soon, so please feel free to investigate more. Huw. -- Huw Davies huw(a)codeweavers.com

March 6, 2006

Re: [dsound] DllCanUnloadNow

by Alexandre Julliard

Christian Gmeiner <christian.gmeiner(a)students.fh-vorarlberg.ac.at> writes: > This patch > + implements LockServer > + implements DllCanUnloadNow You need to maintain the lock count when creating/deleting objects too. -- Alexandre Julliard julliard(a)winehq.org

March 6, 2006

Re: riched20: Implements FR_WHOLEWORD for EM_FINDTEXT

by Alexandre Julliard

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. -- Alexandre Julliard julliard(a)winehq.org

March 6, 2006

Re: ntdll: Fix Directory Searching when VFAT_IOCTL_READDIR_BOTH returns an invalid d_reclen

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > --- a/dlls/ntdll/directory.c > +++ b/dlls/ntdll/directory.c > @@ -1245,7 +1245,11 @@ static NTSTATUS find_file_in_dir( char * > unix_name[pos - 1] = '/'; > for (;;) > { > - if (!de[0].d_reclen) break; > + if (!de[0].d_reclen) > + { > + unix_name[pos - 1] = 0; > + break; We should probably have a 'goto not_found' here instead. -- Alexandre Julliard julliard(a)winehq.org

March 6, 2006

Re: Error while compiling code using wineg++ / winegcc on solaris

by Dimi Paun

> The version is 3.4.2. Here's the console dump. This is odd. Can you check if the -fshort-wchar is at all supported on Solaris? Is it Solaris on Intel or Sparc? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 6, 2006

Re: Errors in Win API Stats

by Robert Shearman

Peter Åstrand wrote: > > I've noticied that http://www.winehq.org/site/winapi_stats is not > quite correct. For example, it claims that "amstream" is 100% > implemented, which is not correct: There are 21 stubs or something > like that. > > How is this page generated? It only looks at functions exported in the spec file. It doesn't look at COM interfaces. -- Rob Shearman

March 6, 2006

Re: [user.dll] get rid of DPRINTF

by Alexandre Julliard

Christian Gmeiner <christian.gmeiner(a)students.fh-vorarlberg.ac.at> writes: > This patch eliminates DPRINTF calls and replaces it with TRACE calls, as > suggested here: http://wiki.winehq.org/DebugTracingCleanup This doesn't apply to relay traces I'm afraid, they use a different format. -- Alexandre Julliard julliard(a)winehq.org

March 6, 2006

RE: Error while compiling code using wineg++ / winegcc on solaris

by Vikas Gera

Hi Dimi, Thanks for replying. The version is 3.4.2. Here's the console dump. -bash-3.00$ winegcc --version gcc (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thanks & Regards, Vikas Gera HeadStrong Inc. -----Original Message----- From: Dimi Paun [mailto:dimi(a)lattica.com] Sent: Monday, March 06, 2006 6:11 PM To: Vikas Gera Cc: wine-devel(a)winehq.org Subject: Re: Error while compiling code using wineg++ / winegcc on solaris On Mon, 2006-03-06 at 14:47 +0530, Vikas Gera wrote: > testuser(a)testbox:~/test >wineg++ test.cpp > winegcc: -fshort-wchar failed. What version of gcc are you using? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 6, 2006

Re: FONTS: fix Courier font

by Vitaly Lipatov

В сообщении от 6 марта 2006 17:27 Вы написали: > "Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > > > What are you trying to fix? > > > > There is screenshot from notepad with Courier font selected in > > attachment. > > Do you see the same problem with Windows font? No, only with WINE's courier without my path -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

March 6, 2006

Errors in Win API Stats

by Peter Åstrand

I've noticied that http://www.winehq.org/site/winapi_stats is not quite correct. For example, it claims that "amstream" is 100% implemented, which is not correct: There are 21 stubs or something like that. How is this page generated? Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

March 6, 2006

Re: shdocvw: Added get_LocationURL implementation.

by Jacek Caban

Robert Shearman wrote: > > BSTR and LPWSTR are not interchangable. A lot of the time you can get > away with it, but if anything tries to access the length that prefixes > a BSTR on the LPWSTR then bad things will happen. > Right, thanks. I don't know, why I have changed it. I think I passed BSTR in one of modifications in my tree. I'll send a fixed version. Thanks, Jacek

March 6, 2006

Re: shdocvw: Added get_LocationURL implementation.

by Robert Shearman

Jacek Caban wrote: >c24b7d0d0c498ec98785b93eba54b41d53ab2c9b >diff --git a/dlls/shdocvw/navigate.c b/dlls/shdocvw/navigate.c >index 9c4893c..40d4a06 100644 >--- a/dlls/shdocvw/navigate.c >+++ b/dlls/shdocvw/navigate.c >@@ -316,7 +316,7 @@ static IBindStatusCallback *create_callb > return BINDSC(ret); > } > >-static void on_before_navigate2(WebBrowser *This, PBYTE post_data, ULONG post_data_len, >+static void on_before_navigate2(WebBrowser *This, LPWSTR url, PBYTE post_data, ULONG post_data_len, > LPWSTR headers, VARIANT_BOOL *cancel) > { > VARIANT var_url, var_flags, var_frame_name, var_post_data, var_post_data2, var_headers; >@@ -367,7 +367,7 @@ static void on_before_navigate2(WebBrows > V_VT(params+5) = (VT_BYREF|VT_VARIANT); > V_VARIANTREF(params+5) = &var_url; > V_VT(&var_url) = VT_BSTR; >- V_BSTR(&var_url) = SysAllocString(This->url); >+ V_BSTR(&var_url) = url; > > V_VT(params+6) = (VT_DISPATCH); > V_DISPATCH(params+6) = (IDispatch*)WEBBROWSER2(This); > > BSTR and LPWSTR are not interchangable. A lot of the time you can get away with it, but if anything tries to access the length that prefixes a BSTR on the LPWSTR then bad things will happen. -- Rob Shearman

March 6, 2006

Re: FONTS: fix Courier font

by Dmitry Timoshkov

"Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > > What are you trying to fix? > There is screenshot from notepad with Courier font selected in attachment. Do you see the same problem with Windows font? -- Dmitry.

March 6, 2006

Re: configure: add --with-fontfir (try3) with patch!

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > В сообщении от 6 марта 2006 14:18 Alexandre Julliard написал(a): >> Vitaly Lipatov <lav(a)etersoft.ru> writes: >> > I don't like WINE fonts in %_datadir/fonts/wine, I it crossed >> > with ALT Linux font policy and so on. >> >> Where do you install them then? > %_datadir/wine/fonts > %_datadir/fonts is default fontconfig's path for font search. Well yes, that was the idea, that they should be found by fontconfig. Now of course if we make the code look in that path explicitly then I agree we might as well put them in datadir/wine. -- Alexandre Julliard julliard(a)winehq.org

March 6, 2006

Re: FONTS: fix Courier font

by Vitaly Lipatov

В сообщении от 6 марта 2006 15:07 Вы написали: > "Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > > > Last time I asked Huw said that this is a bug in fontforge, > > > the font files have correct values. > > > > If the bug in fontforge will exists for ages... > > Well, I will use the patch as fast hack for courier font correcting. > > What are you trying to fix? There is screenshot from notepad with Courier font selected in attachment. -- Lav Виталий Липатов Россия, Санкт-Петербург. www.etersoft.ru GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!

March 6, 2006

How to link and run applications using WinLib

by Arun Kumar Khandelwal

Hi All, I am able to compile and link my test program using winemaker. It generates a test.exe.so and not test.exe. I do not know how to run this *.so? What should I do to link and run program using winlib? Thanks, Arun

March 6, 2006

Re: Feedback request on wininet patch

by Robert Shearman

Victor Pelt wrote: >@@ -2447,7 +2485,18 @@ BOOL WINAPI InternetSetOptionW(HINTERNET > TRACE("Option INTERNET_OPTION_DISABLE_PASSPORT_AUTH: harmless stub, since not enabled\n"); > break; > case INTERNET_OPTION_RECEIVE_TIMEOUT: >- FIXME("Option INTERNET_OPTION_RECEIVE_TIMEOUT: STUB\n"); >+ { >+ unsigned long conns=*(unsigned long*)lpBuffer; >+ /* have HINTERNET hInternet , handle where to set the options */ >+ int result = setsockopt(INET_getSocketHelper(lpwhh), INET_getProtocolHelper(lpwhh), SO_RCVTIMEO, lpBuffer, (int)sizeof(lpBuffer)); >+ >+ if (result == 0) { >+ ret = TRUE; >+ } else { >+ /* Translate the result in the right error to return */ >+ ret = FALSE; >+ } >+ } > > It would be much better to implement this in netconnection.c. Perhaps calling it something like NETCONNECTION_set_timeout and allow both the send and receive timeouts to be set with it. -- Rob Shearman

March 6, 2006

Re: Error while compiling code using wineg++ / winegcc on solaris

by Dimi Paun

On Mon, 2006-03-06 at 14:47 +0530, Vikas Gera wrote: > testuser(a)testbox:~/test >wineg++ test.cpp > winegcc: -fshort-wchar failed. What version of gcc are you using? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 6, 2006

Re: Feedback request on wininet patch

by Vijay Kiran Kamuju

Hi Victor, If you are interested in implementing more features. You can have a look at my wininet pacthes, almost all of them have been rejected. I hope you might improve those or get new ideas from those. As i am going to pick some other well documented portion in windows api. Leaving the wininet for the time being, i might come back to it sometime lateer (in distant future). bye, Vijay On 3/6/06, Mike McCormack <mike(a)codeweavers.com> wrote: > > Victor Pelt wrote: > > > - FIXME("Option INTERNET_OPTION_RECEIVE_TIMEOUT: STUB\n"); > > + { > > It would be nice if you could use indentation consistent with the rest > of the file, and avoid tabs. > > > + unsigned long conns=*(unsigned long*)lpBuffer; > > What's 'conns' for? > > > + /* have HINTERNET hInternet , handle where to set the options */ > > + int result = setsockopt(INET_getSocketHelper(lpwhh), INET_getProtocolHelper(lpwhh), SO_RCVTIMEO, lpBuffer, (int)sizeof(lpBuffer)); > > + > > + if (result == 0) { > > + ret = TRUE; > > + } else { > > + /* Translate the result in the right error to return */ > > + ret = FALSE; > > + } > > + } > > How about "ret = (result == 0);"? > > > @@ -2455,6 +2504,9 @@ BOOL WINAPI InternetSetOptionW(HINTERNET > > case INTERNET_OPTION_CONNECT_RETRIES: > > FIXME("Option INTERNET_OPTION_CONNECT_RETRIES: STUB\n"); > > break; > > + case INTERNET_OPTION_CONTEXT_VALUE: > > + FIXME("Option INTERNET_OPTION_CONTEXT_VALUE; STUB\n"); > > + break; > > default: > > FIXME("Option %ld STUB\n",dwOption); > > INTERNET_SetLastError(ERROR_INVALID_PARAMETER); > > This chunk should be in a separate patch, since it's unrelated. > > > +/* Helper functions to get unix backend stuff based in windows handles (LPWININETHANDLEHEADER s) */ > > +int INET_getSocketHelper(LPWININETHANDLEHEADER); > > +int INET_getProtocolHelper(LPWININETHANDLEHEADER); > > Why not just make these static, and get rid of these declarations? > > Mike > > >

March 6, 2006

Re: Wine compilation error (flex related)

by Christian Lachner

ah, found something: http://sourceforge.net/tracker/index.php?func=detail&aid=1439346&group_id=9… greets On 3/6/06, Christian Lachner <gladiac.lists(a)gmail.com> wrote: > I have the same problem with a gcc-4.0 and flex 2.5.33. 2.5.4a works > ok ;). I don't think it's a wine-problem but the flex-releases are as > rare as a solar ecplipse so the fix must be in wine (maybe a > workaround or reformatting of the code since it's a syntaxing > problem). But i could also be wrong. > > On 2/27/06, Elvis Pranskevichus <elprans(a)gmail.com> wrote: > > Hello! > > > > Both emerge =wine-0.9.8 and the latest git workdir fail to compile on current > > Gentoo with: > > > > gcc -c -I. -I. -I../../include -I../../include > > -DINCLUDEDIR="\"/usr/local/include/wine\"" -Wall -pipe -fno-strict-aliasing > > -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -g -O2 -o lex.yy.o > > lex.yy.c > > lex.yy.c:2610: error: parse error before numeric constant > > lex.yy.c: In function `yy_scan_string': > > lex.yy.c:2611: error: number of arguments doesn't match prototype > > lex.yy.c:305: error: prototype declaration > > lex.yy.c:2613: warning: passing arg 1 of `strlen' makes pointer from integer > > without a cast > > lex.yy.c:2613: warning: passing arg 1 of `yy_scan_bytes' makes pointer from > > integer without a cast > > make[2]: *** [lex.yy.o] Error 1 > > make[2]: Leaving directory `/home/el/projects/wine/wine-git/tools/wrc' > > make[1]: *** [wrc] Error 2 > > make[1]: Leaving directory `/home/el/projects/wine/wine-git/tools' > > make: *** [tools] Error 2 > > > > The flex --version is flex 2.5.33 (the latest one, released on February 21, > > 2006). > > gcc --version is gcc (GCC) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8) > > > > widl and wmc lexers compiled fine. > > > > Downgrading to flex 2.5.4a makes everything compile again. > > Is this a flex issue or is a Wine problem? > > > > Thanks, > > -- > > Elvis Pranskevichus - elprans(a)gmail.com > > > > > > >

March 6, 2006

Re: Wine compilation error (flex related)

by Christian Lachner

I have the same problem with a gcc-4.0 and flex 2.5.33. 2.5.4a works ok ;). I don't think it's a wine-problem but the flex-releases are as rare as a solar ecplipse so the fix must be in wine (maybe a workaround or reformatting of the code since it's a syntaxing problem). But i could also be wrong. On 2/27/06, Elvis Pranskevichus <elprans(a)gmail.com> wrote: > Hello! > > Both emerge =wine-0.9.8 and the latest git workdir fail to compile on current > Gentoo with: > > gcc -c -I. -I. -I../../include -I../../include > -DINCLUDEDIR="\"/usr/local/include/wine\"" -Wall -pipe -fno-strict-aliasing > -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -g -O2 -o lex.yy.o > lex.yy.c > lex.yy.c:2610: error: parse error before numeric constant > lex.yy.c: In function `yy_scan_string': > lex.yy.c:2611: error: number of arguments doesn't match prototype > lex.yy.c:305: error: prototype declaration > lex.yy.c:2613: warning: passing arg 1 of `strlen' makes pointer from integer > without a cast > lex.yy.c:2613: warning: passing arg 1 of `yy_scan_bytes' makes pointer from > integer without a cast > make[2]: *** [lex.yy.o] Error 1 > make[2]: Leaving directory `/home/el/projects/wine/wine-git/tools/wrc' > make[1]: *** [wrc] Error 2 > make[1]: Leaving directory `/home/el/projects/wine/wine-git/tools' > make: *** [tools] Error 2 > > The flex --version is flex 2.5.33 (the latest one, released on February 21, > 2006). > gcc --version is gcc (GCC) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8) > > widl and wmc lexers compiled fine. > > Downgrading to flex 2.5.4a makes everything compile again. > Is this a flex issue or is a Wine problem? > > Thanks, > -- > Elvis Pranskevichus - elprans(a)gmail.com > > >

March 6, 2006

Re: FONTS: fix Courier font

by Dmitry Timoshkov

"Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > > Last time I asked Huw said that this is a bug in fontforge, > > the font files have correct values. > If the bug in fontforge will exists for ages... > Well, I will use the patch as fast hack for courier font correcting. What are you trying to fix? -- Dmitry.

March 6, 2006

Re: configure: add --with-fontfir (try3) with patch!

by Vitaly Lipatov

В сообщении от 6 марта 2006 14:18 Alexandre Julliard написал(a): > Vitaly Lipatov <lav(a)etersoft.ru> writes: > > I don't like WINE fonts in %_datadir/fonts/wine, I it crossed > > with ALT Linux font policy and so on. > > Where do you install them then? %_datadir/wine/fonts %_datadir/fonts is default fontconfig's path for font search. -- Lav Виталий Липатов Россия, Санкт-Петербург. www.etersoft.ru GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!

March 6, 2006

Floating point problem in WineEngGetGlyphOutline

by Jeff L

I have started to get a floating point problem "First chance exception: invalid float operation in 32-bit code (0x00e6b6f9).". I don't know a lot about floating point but from what I have read, the FLDCW most likely is unmasking an interrupt when it reloads the control word. Winedbg does not seem to have support for displaying floating point registers and control word etc. Can someone point me in the direction of getting to the bottom os this? Jeff Latimer Wine-dbg> 0x00e6b6d1 WineEngGetGlyphOutline+0x1d9 [/winf/dlls/gdi/freetype.c:2818] in gdi32: movl 0xffffff00(%ebp),%eax 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> 0x00e6b6d7 WineEngGetGlyphOutline+0x1df [/winf/dlls/gdi/freetype.c:2818] in gdi32: movl 0x54(%eax),%ecx 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> 0x00e6b6da WineEngGetGlyphOutline+0x1e2 [/winf/dlls/gdi/freetype.c:2818] in gdi32: movl 0x20(%ecx),%edx 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> 0x00e6b6dd WineEngGetGlyphOutline+0x1e5 [/winf/dlls/gdi/freetype.c:2818] in gdi32: fld %st(0) 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> 0x00e6b6df WineEngGetGlyphOutline+0x1e7 [/winf/dlls/gdi/freetype.c:2818] in gdi32: pushl %edx 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> 0x00e6b6e0 WineEngGetGlyphOutline+0x1e8 [/winf/dlls/gdi/freetype.c:2818] in gdi32: fimuls 0x0(%esp) 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> 0x00e6b6e3 WineEngGetGlyphOutline+0x1eb [/winf/dlls/gdi/freetype.c:2818] in gdi32: fnstcw 0xffffff92(%ebp) 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> 0x00e6b6e6 WineEngGetGlyphOutline+0x1ee [/winf/dlls/gdi/freetype.c:2818] in gdi32: movw 0xffffff92(%ebp),%ax 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> 0x00e6b6ea WineEngGetGlyphOutline+0x1f2 [/winf/dlls/gdi/freetype.c:2818] in gdi32: movb $0xc,%ah 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> 0x00e6b6ec WineEngGetGlyphOutline+0x1f4 [/winf/dlls/gdi/freetype.c:2818] in gdi32: movw %ax,0xffffff90(%ebp) 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> 0x00e6b6f0 WineEngGetGlyphOutline+0x1f8 [/winf/dlls/gdi/freetype.c:2818] in gdi32: fldcw 0xffffff90(%ebp) 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> 0x00e6b6f3 WineEngGetGlyphOutline+0x1fb [/winf/dlls/gdi/freetype.c:2818] in gdi32: fistps 0xffffff10(%ebp) 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> 0x00e6b6f9 WineEngGetGlyphOutline+0x201 [/winf/dlls/gdi/freetype.c:2818] in gdi32: fldcw 0xffffff92(%ebp) 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64; Wine-dbg> Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:00e6b6f9 ESP:7fc5cce0 EBP:7fc5ce2c EFLAGS:00200206( - 00 - -IP1) EAX:7d820c72 EBX:00e94bc8 ECX:7d82ed70 EDX:00030840 ESI:7fedcb40 EDI:0000001a Wine-dbg>stepi First chance exception: invalid float operation in 32-bit code (0x00e6b6f9). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:00e6b6f9 ESP:7fc5cce0 EBP:7fc5ce2c EFLAGS:00210306( - 00 -RITP1) EAX:7d820c72 EBX:00e94bc8 ECX:7d82ed70 EDX:00030840 ESI:7fedcb40 EDI:0000001a Stack dump: 0x7fc5cce0: 00030840 7fe90020 7fe90000 7fc5cd0c 0x7fc5ccf0: 0026d2aa 00000000 00000000 00000002 0x7fc5cd00: 00e94bc8 00000122 7fc5ce10 7fc5cd6c 0x7fc5cd10: 00e71fee 7fe90000 00000000 7fedc218 0x7fc5cd20: 7feddac2 001716ae 00e8edda 7d828d90 0x7fc5cd30: 0000000e 00000010 7d828f00 7d828e68 0200: sel=1007 base=7befc000 limit=00001fff 32-bit rw- Backtrace: =>1 0x00e6b6f9 WineEngGetGlyphOutline+0x201 [/winf/dlls/gdi/freetype.c:2818] in gdi32 (0x00e6b6f9) 2 0x00e72810 WineEngGetTextExtentPoint+0xd0(font=0x7fedc6b0, wstr=0x7fc5e3bc, count=0xa, size=0x7fc5cf54) [/winf/dlls/gdi/freetype.c:3685] in gdi32 (0x00e72810) 3 0x00e64347 GetTextExtentPoint32W+0x47(hdc=0x1c0, str=0x7fc5e3bc, count=0xa, size=0x7fc5cf54) [/winf/dlls/gdi/font.c:1104] in gdi32 (0x00e64347) 4 0x00e67010 GetCharacterPlacementW+0x134(hdc=0x1c0, lpString=0x7fc5e3bc, uCount=0xa, nMaxExtent=0x0, lpResults=0x7fc5e398, dwFlags=0x8103b) [/winf/dlls/gdi/font.c:2780] in gdi32 (0x00e67010) 5 0x004022b5 in script_test (+0x22b5) (0x004022b5) 6 0x00401141 in script_test (+0x1141) (0x00401141) 7 0x3266f6e6 in cc3260 (+0x6f6e6) (0x3266f6e6) 8 0x00000000 (0x00000000) 9 0x00793ccb wine_switch_to_stack+0x17 in libwine.so.1 (0x00793ccb) 0x00e6b6f9 WineEngGetGlyphOutline+0x201 [/winf/dlls/gdi/freetype.c:2818] in gdi32: fldcw 0xffffff92(%ebp) 2818 left = (INT)(ft_face->glyph->metrics.horiBearingX * widthRatio) & -64;

March 6, 2006

Re: FONTS: fix Courier font

by Vitaly Lipatov

В сообщении от 6 марта 2006 14:38 Dmitry Timoshkov написал(a): > "Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > > The main change is > > -Ascent: 11 > > -Descent: 2 > > +Ascent: 10 > > +Descent: 3 > > Last time I asked Huw said that this is a bug in fontforge, > the font files have correct values. If the bug in fontforge will exists for ages... Well, I will use the patch as fast hack for courier font correcting. I tested with fontforge-20060209. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

March 6, 2006

Re: FONTS: fix Courier font

by Dmitry Timoshkov

"Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > The main change is > -Ascent: 11 > -Descent: 2 > +Ascent: 10 > +Descent: 3 Last time I asked Huw said that this is a bug in fontforge, the font files have correct values. -- Dmitry.

March 6, 2006

Re: configure: add --with-fontfir (try3) with patch!

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > I don't like WINE fonts in %_datadir/fonts/wine, I it crossed > with ALT Linux font policy and so on. Where do you install them then? -- Alexandre Julliard julliard(a)winehq.org

March 6, 2006

Re: WINE & prelink

by Mike McCormack

Vitaly Lipatov wrote: > Can anyone explain here or at http://wiki.winehq.com/ about prelink usage in > WINE. Is it necessary for build process? > I see it is recommended at http://wiki.winehq.com/Recommended_Packages It's used in an attempt to fix the load address of a few builtin dlls (ntdll, kernel32, user) so that Windows programs that rely on the address being the same across different programs work correctly. Mike

March 6, 2006

WINE & prelink

by Vitaly Lipatov

Can anyone explain here or at http://wiki.winehq.com/ about prelink usage in WINE. Is it necessary for build process? I see it is recommended at http://wiki.winehq.com/Recommended_Packages -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

March 6, 2006

Error while compiling code using wineg++ / winegcc on solaris

by Vikas Gera

Hi!! I am not able to compile a test program on solaris using winegcc tool. Can anybody help? Here's the program source code: // file test.cpp #include <stdio.h> #include <windows.h> int main () { SYSTEMTIME lpSystemTime; GetSystemTime(&lpSystemTime); printf("Today is: %d/%d/%d\n", lpSystemTime.wYear, lpSystemTime.wMonth, lpSystemTime.wDay); return 0; } When I try to compile it using winegcc, it gives following error message: testuser(a)testbox:~/test >wineg++ test.cpp winegcc: -fshort-wchar failed. On adding a flag '-v' with wineg++, a detailed error message is displayed: testuser(a)testbox:~/test >wineg++ -v test.cpp -fshort-wchar -DWINE_UNICODE_NATIVE -D_REENTRANT -fPIC -DWIN32 -D_WIN32 -D__WIN32 -D__WIN32__ -D__WINNT -D__WINNT__ -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__fastcall=__attribute__((__fastcall__)) -D_stdcall=__attribute__((__stdcall__)) -D_cdecl=__attribute__((__cdecl__)) -D_fastcall=__attribute__((__fastcall__)) -D__declspec(x)=__declspec_##x -D__declspec_align(x)=__attribute__((aligned(x))) -D__declspec_allocate(x)=__attribute__((section(x))) -D__declspec_deprecated=__attribute__((deprecated)) -D__declspec_dllimport=__attribute__((dllimport)) -D__declspec_dllexport=__attribute__((dllexport)) -D__declspec_naked=__attribute__((naked)) -D__declspec_noinline=__attribute__((noinline)) -D__declspec_noreturn=__attribute__((noreturn)) -D__declspec_nothrow=__attribute__((nothrow)) -D__declspec_novtable=__attribute__(()) -D__declspec_selectany=__attribute__((weak)) -D__declspec_thread=__thread -D__WINE__ -D__int8=char -D__int16=short -D__int32=int -D__int64=long long -c -o test-9pH6Aj.o -v test.cpp -isystem/opt/cfw/wine/include/wine/windows winegcc: -fshort-wchar failed. I can see a lot of compile flags/options. I want to be able to enable/disable these options. Or if there is some other way to be able to compile the code using wingcc, pleae tell me. The code works well on windows. I even managed to compile it using gcc, but it resulted in coredump. If somebody can guide me how to compile an application using winelib, which can run on solaris. I am getting linker/loader errors. thanks!! Vikas Gera

March 6, 2006

Re: configure: add --with-fontfir (try3) with patch!

by Alexandre Julliard

"StartCom Ltd." <eddy_nigg(a)startcom.org> writes: > I would like to through in my support for Vitaly on this issue (and > maybe similar ones) which happen to be the source of some discussions > lately (rpath was one, I think). > > More configuration options makes wine to be more easy configured, build > and adjusted, making it more scalable....Distribution based patches > should be the last resort - not the first. If a configure option, such > as in this case can be so easily implemented, it should supported...As > long as it hard coded during make, than there should be a configuration > option for this (font path) but also others.... The problem with adding an option for every single thing that someone might want to change is that you end up with a million of them, burying the few important options in a mass of useless details. So for things that are only used to build some special package, it's perfectly reasonable IMO to ask the packager to pass options to make instead of configure, since it's all done from a script anyway. -- Alexandre Julliard julliard(a)winehq.org

March 6, 2006

FW: Re: Wine testing and Guild Wars: Factions Beta weekend March 24th

by Jeremiah Powell

Please see below. >From: Alexandre Julliard <julliard(a)winehq.org> >To: "Jeremiah Powell" <waveclaw(a)hotmail.com> >Subject: Re: Wine testing and Guild Wars: Factions Beta weekend March 24th > >"Jeremiah Powell" <waveclaw(a)hotmail.com> writes: > > > I would like to extend this opportunity to someone in the wine > > development community. Who would like a chance to collect data on the > > behavior of running Guild Wars under wine? > > > > How about for free? > >That sounds good, you should ask on wine-devel, I'm sure people would >be interested. > >-- >Alexandre Julliard >julliard(a)winehq.org I have 3 guest keys for the Guildwars: Factions BWE starting March 24th. Everyone I know already plays Guildwars on Windows. The Wine D3D support has gotten to the point of running Guildwars in a playable state[1]. I'd like offer these keys to the wine developers for debug purposes. In particular, I'd like committers on the D3D subsystem and the sound systems to enjoy a little free game time while collecting some valuable data[2]. There are only 3 keys. These are free TRIAL accounts, good for only that weekend. If you buy the game, you can open the accounts back up at a later time. The game client generates the account-contact emails from personal email addresses I give it, but they are in no other way assocaited with my account(s). Please reply to me directly if you want the keys, but keep the spam to a minimum. A list of people getting the keys can be posted if the list wants. JD 'too much hotmail spam anyway' Powell --- 1. While not stable, normal play is possible. I use SuSE OSS 10 with ATI's fglx drivers, and Cedega chokes on for this 'supported' game during screen changes, which the Wine D3D code handles gracefully. 2. From the appdb: Guildwars is a pure DirectX game that uses no opengl, no SDL, etc. Guildwars was functional under wine until the September 2005 Sorrow's Furnace update. Now game client has two modes in which it can be run. Normally, guildwars tried to use DirectX's shading language. This causes it to fail under Wine. With the '-noshaders' option, the game falls back on only the older DirectX calls. Other interesting features include toggling sound support with '-nosound' and output of triangles, fps, networking information with 'perfs' and starting in a window with '-windowed.' A 3rd party sound expansion is available that integrates with the DRM system in Media Player 9, but can be patched out by moving the DLL to another location.

March 6, 2006

Re: wine 0.9.9 vs. Ned For Speed V -- already better

by Tom Wickline

On 3/5/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Sonntag, 5. März 2006 20:36 schrieb Samium Gromoff: > > manages to allow NFS to initialize the video mode, apparently. > You can try my directdraw patches: http://stud4.tuwien.ac.at/~e0526822/ > But wait before downloading, I have some updates I'll upload within the next > hours. > > Is a demo of that game available? Need for Speed V is: Porsche Unleashed The Demo: nfspudemo.zip : http://ftp.gameaholic.com/pub/demos/?N=D http://miningco.gameaholic.com/idgames.d/gamedemos/?offset=14 http://www.sports-gaming.com/downloads/demos/nfspudemo.shtml http://www.gamepro.com/computer/pc/1713/info.shtml http://www.fileshack.com/file.x?fid=701 http://www.gamershell.com/download_4366.shtml http://files.gameaholic.com/idgames.d/gamedemos/ http://www.ausgamers.com/files/demos.php http://www.3dgamers.com/ Tom > > Stefan > > > > > > >

March 6, 2006

Re: Feedback request on wininet patch

by Mike McCormack

Victor Pelt wrote: > - FIXME("Option INTERNET_OPTION_RECEIVE_TIMEOUT: STUB\n"); > + { It would be nice if you could use indentation consistent with the rest of the file, and avoid tabs. > + unsigned long conns=*(unsigned long*)lpBuffer; What's 'conns' for? > + /* have HINTERNET hInternet , handle where to set the options */ > + int result = setsockopt(INET_getSocketHelper(lpwhh), INET_getProtocolHelper(lpwhh), SO_RCVTIMEO, lpBuffer, (int)sizeof(lpBuffer)); > + > + if (result == 0) { > + ret = TRUE; > + } else { > + /* Translate the result in the right error to return */ > + ret = FALSE; > + } > + } How about "ret = (result == 0);"? > @@ -2455,6 +2504,9 @@ BOOL WINAPI InternetSetOptionW(HINTERNET > case INTERNET_OPTION_CONNECT_RETRIES: > FIXME("Option INTERNET_OPTION_CONNECT_RETRIES: STUB\n"); > break; > + case INTERNET_OPTION_CONTEXT_VALUE: > + FIXME("Option INTERNET_OPTION_CONTEXT_VALUE; STUB\n"); > + break; > default: > FIXME("Option %ld STUB\n",dwOption); > INTERNET_SetLastError(ERROR_INVALID_PARAMETER); This chunk should be in a separate patch, since it's unrelated. > +/* Helper functions to get unix backend stuff based in windows handles (LPWININETHANDLEHEADER s) */ > +int INET_getSocketHelper(LPWININETHANDLEHEADER); > +int INET_getProtocolHelper(LPWININETHANDLEHEADER); Why not just make these static, and get rid of these declarations? Mike

March 6, 2006

Re: [Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI

by Vitaly Budovski

Uwe Bonnes wrote: >>>>>> "H" == H Verbeet <hverbeet(a)gmail.com> writes: >>>>>> > > ... > >> Appended patch lets me circumvent that problem. > H> I'm not sure if GL_STENCIL_BACK_FAIL and GL_STENCIL_BACK_FAIL_ATI are > H> interchangeable, but more importantly it makes the same kind of > H> assumptions about what's going to be defined. > > I said "circumvent" not "solve"... > This patch http://www.winehq.org/pipermail/wine-patches/2006-March/024775.html should solve the problem with missing defines.

March 6, 2006

Re: DirectDraw -> WineD3D patch

by Stefan Dösinger

Hi, I've updated the patch to fix a few issues and take the merged header patches into account. It can still be found at http://stud4.tuwien.ac.at/~e0526822/ Thanks for all your feedback so far, Stefan

March 5, 2006

Re: [PATCH] [WineDbg test harness]: various updates

by Eric Pouech

Eric Pouech wrote: > - now supports all tests with or without 'in <modname>' information > - extended startup tests please, discard this patch A+ -- Eric Pouech

March 5, 2006

Re: configure: add --with-fontfir (try3) with patch!

by StartCom Ltd.

I would like to through in my support for Vitaly on this issue (and maybe similar ones) which happen to be the source of some discussions lately (rpath was one, I think). More configuration options makes wine to be more easy configured, build and adjusted, making it more scalable....Distribution based patches should be the last resort - not the first. If a configure option, such as in this case can be so easily implemented, it should supported...As long as it hard coded during make, than there should be a configuration option for this (font path) but also others.... Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost™ at www.mediahost.org <http://www.mediahost.org/> StartCom Certification Authority at cert.startcom.org <http://cert.startcom.org/> Skype: startcom <callto://startcom/> Phone: +1.213.341.0390 Vitaly Lipatov wrote: > On Monday 06 March 2006 00:43, Alexandre Julliard wrote: > >> Vitaly Lipatov <lav(a)etersoft.ru> writes: >> >>> On Sunday 05 March 2006 23:22, Alexandre Julliard wrote: >>> >>>> Could you please explain what you are trying to do? I >>>> don't think we want to hardcode more paths, I've just been >>>> getting rid of them. >>>> >>> I told about >>> fontdir = $(datadir)/fonts/wine >>> line in fonts/Makefile.in. It is _hardcoded_ path. I try to >>> get rid of this and get possibility to set path to fontdir >>> with configure options. >>> >> It's not less hardcoded if it's in configure... You still >> > I planned place _default_ path to configure. With --with-fontdir > option we can set it to any other place. > If we have this path hardcoded in fonts/Makefile.in we can't use > it from other places of WINE tree. > > >> haven't explained what you are trying to do, and why you can't >> put fonts in datadir. >> > I don't like WINE fonts in %_datadir/fonts/wine, I it crossed > with ALT Linux font policy and so on. > I have a small patch to check the font dir after C: > \\WINDOWS\\FONTS for bitmap/ttf fonts. It patch needs in > @FONTDIR@ substitution in Makefile. > Sorry if I can't express my thoughts in English clearly. > >

March 5, 2006

about Wingdings/Symbol

by Vitaly Lipatov

I wish to make a initial font file for Wingdings and Symbol fonts. Do anyone some font designing already? I plan to draw some common usable symbols for first. -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

March 5, 2006

Re: configure: add --with-fontfir (try3) with patch!

by Vitaly Lipatov

On Monday 06 March 2006 00:43, Alexandre Julliard wrote: > Vitaly Lipatov <lav(a)etersoft.ru> writes: > > On Sunday 05 March 2006 23:22, Alexandre Julliard wrote: > >> Could you please explain what you are trying to do? I > >> don't think we want to hardcode more paths, I've just been > >> getting rid of them. > > > > I told about > > fontdir = $(datadir)/fonts/wine > > line in fonts/Makefile.in. It is _hardcoded_ path. I try to > > get rid of this and get possibility to set path to fontdir > > with configure options. > > It's not less hardcoded if it's in configure... You still I planned place _default_ path to configure. With --with-fontdir option we can set it to any other place. If we have this path hardcoded in fonts/Makefile.in we can't use it from other places of WINE tree. > haven't explained what you are trying to do, and why you can't > put fonts in datadir. I don't like WINE fonts in %_datadir/fonts/wine, I it crossed with ALT Linux font policy and so on. I have a small patch to check the font dir after C: \\WINDOWS\\FONTS for bitmap/ttf fonts. It patch needs in @FONTDIR@ substitution in Makefile. Sorry if I can't express my thoughts in English clearly. -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

March 5, 2006

Re: configure: add --with-fontfir (try3) with patch!

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > On Sunday 05 March 2006 23:22, Alexandre Julliard wrote: >> Could you please explain what you are trying to do? I don't >> think we want to hardcode more paths, I've just been getting >> rid of them. > I told about > fontdir = $(datadir)/fonts/wine > line in fonts/Makefile.in. It is _hardcoded_ path. I try to get > rid of this and get possibility to set path to fontdir with > configure options. It's not less hardcoded if it's in configure... You still haven't explained what you are trying to do, and why you can't put fonts in datadir. -- Alexandre Julliard julliard(a)winehq.org

March 5, 2006

Re: World of Warcraft 0.10 Public Test Realm (PTR)

by Tomas Carnecky

Tomas Carnecky wrote: > so.. I know where the problem is.. WoW loads its own Survey.dll which > requires ddraw.dll, ddraw initializes itself and during that it creates > a drawable and a context and calls glXMakeCurrent(). After some tests > WoW unloads ddraw.dll but someone (ddraw, wine or WoW) fails to activate > the old drawable and context, eg. call glXMakeCurrent() with the real > window and rendering context. > > a trace with +x11drv,+x11settings,+ddraw,+loaddll is in the attachment.. > > in a full trace with +opengl,+ddraw,+loaddll I can see that there is no > wglMakeCurrent call after the ddraw dll is unloaded > for those who can't wait to login into the PTR, here is a little patch that disables opengl support in ddraw, so ddraw won't call glXMakeCurrent(). It's a really ugly solution, but at least now we can try to login into the PTR. The better solution would be to save the old drawable and context and reactivate it after ddraw initilizes opengl. Or whatever the ddraw author comes up with :-) tom

March 5, 2006

Re: [Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI

by H. Verbeet

On 05/03/06, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > I said "circumvent" not "solve"... Fair enough, but just removing the lines would probably work as well. :-)

March 5, 2006

Re: Question about copyright lines

by Troy Rollo

On Saturday 04 March 2006 12:32, Segin wrote: > >For protection in countries which are signatories to the UCC but NOT > >the Berne Convention (I don't know of any offhand), the year and name ... > Ok, but you still need to put the copyright year/holder's name in a > certain order, as your last paragraph said. Just not nessessrary for > most countries. Since accession to the Berne Convention is a requirement for membership of the WTO, parties (not signatories, which is a different thing with little practical meaning) to the UCC who are not parties to the Berne Convention are such a small set now that it is probably not worth worrying about. These days the copyright notice has more value as: a means of giving credit; a means of letting others know who they need to ask if they wish to do something outside the license; and a method to assist distant future users of materials in identifying when a work enters the public domain. -- Troy Rollo - wine(a)troy.rollo.name

March 5, 2006

Re: World of Warcraft 0.10 Public Test Realm (PTR)

by Tomas Carnecky

so.. I know where the problem is.. WoW loads its own Survey.dll which requires ddraw.dll, ddraw initializes itself and during that it creates a drawable and a context and calls glXMakeCurrent(). After some tests WoW unloads ddraw.dll but someone (ddraw, wine or WoW) fails to activate the old drawable and context, eg. call glXMakeCurrent() with the real window and rendering context. a trace with +x11drv,+x11settings,+ddraw,+loaddll is in the attachment.. in a full trace with +opengl,+ddraw,+loaddll I can see that there is no wglMakeCurrent call after the ddraw dll is unloaded tom trace:loaddll:load_builtin_dll Loaded module L"kernel32.dll" : builtin trace:loaddll:load_native_dll Loaded module L"Z:\\games\\World.of.Warcraft\\WoWTest\\WoW.exe" : native trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\msvcrt.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\advapi32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\gdi32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\user32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\comctl32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\iphlpapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\rpcrt4.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ole32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\shlwapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\shell32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ws2_32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\wsock32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\opengl32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\imm32.dll" : builtin trace:loaddll:load_native_dll Loaded module L"Z:\\games\\World.of.Warcraft\\WoWTest\\DivxDecoder.dll" : native trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\winmm.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\msacm32.dll" : builtin trace:loaddll:load_native_dll Loaded module L"Z:\\games\\World.of.Warcraft\\WoWTest\\fmod.dll" : native trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\mpr.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\wininet.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\winex11.drv" : builtin trace:x11settings:X11DRV_Settings_SetHandlers Resolution settings now handled by: NoRes trace:x11settings:X11DRV_Settings_SetHandlers Initialized new display modes array trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 0: 1280x1024x32 @0 Hz (NoRes) trace:x11drv:X11DRV_XF86DGA2_Init trace:x11drv:X11DRV_SetupXIM X display of IM = 0x7c0630e0 trace:x11drv:X11DRV_SetupXIM Using C locale of Input Method trace:x11drv:X11DRV_SetupXIM ximStyles->count_styles = 2 trace:x11drv:X11DRV_SetupXIM ximStyles[0] = XIMPreeditNone trace:x11drv:X11DRV_SetupXIM ximStyles[1] = XIMPreeditNothing trace:x11drv:X11DRV_SetupXIM Setting Style: ximStyleRoot = STYLE_ROOT trace:x11drv:X11DRV_SetupXIM No callback style avalable trace:x11drv:X11DRV_CreateBitmap (0x1a4) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x1a8) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a8, buffer=0x7fd2b944, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a4, buffer=0x7fd2b9c4, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x1ac) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x1b0) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1b0, buffer=0x7fd2bc14, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1ac, buffer=0x7fd2bc94, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x1c0) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1c4) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c4, buffer=0x7fd2c344, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c0, buffer=0x7fd2c364, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x1c8) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1cc) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1cc, buffer=0x7fd2c68c, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c8, buffer=0x7fd2c6ac, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x1d0) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1d4) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d4, buffer=0x7fd2c9d4, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d0, buffer=0x7fd2c9f4, count=0x300) trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\uxtheme.dll" : builtin trace:x11drv:X11DRV_CreateBitmap (0x210) 512x16 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x248) 1024x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x264) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x268) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x268, buffer=0x7fd30c54, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x264, buffer=0x7fd30c74, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x26c) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x270) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x270, buffer=0x7fd314e4, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x26c, buffer=0x7fd31564, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x274) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x278) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x278, buffer=0x7fd30fe4, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x274, buffer=0x7fd31004, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x27c) 16x16 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x27c, bits=0x7fd32180, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x280) 16x16 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x280, bits=0x7fd313b0, count=0x20) trace:x11drv:X11DRV_CreateBitmap (0x290) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x294) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x294, buffer=0x7fd3223c, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x290, buffer=0x7fd322bc, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x298) 32x32 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x298, bits=0x7fd32ed8, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x29c) 32x32 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x29c, bits=0x7fd30fd8, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x2ac) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x2b0) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x2b0, buffer=0x7fd3104c, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x2ac, buffer=0x7fd3106c, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x2b4) 16x16 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2b4, bits=0x7fd32180, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x2b8) 16x16 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2b8, bits=0x7fd31418, count=0x20) trace:x11drv:X11DRV_CreateBitmap (0x2c8) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x2cc) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x2cc, buffer=0x7fd322a4, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x2c8, buffer=0x7fd32324, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x2d0) 32x32 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2d0, bits=0x7fd32f40, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x2d4) 32x32 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2d4, bits=0x7fd32210, count=0x80) trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\msacm.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\midimap.dll" : builtin fixme:advapi:SetSecurityInfo stub trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\powrprof.dll" : builtin fixme:powrprof:DllMain (0x7c530000, 1, (nil)) not fully implemented fixme:ntdll:NtPowerInformation Unimplemented NtPowerInformation action: 11 fixme:powrprof:DllMain (0x7c530000, 0, (nil)) not fully implemented trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system32\\powrprof.dll" : builtin fixme:win:EnumDisplayDevicesW ((null),0,0x7fbfeed0,0x00000000), stub! trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\wined3d.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\d3d9.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system32\\d3d9.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system32\\wined3d.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\wined3d.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\d3d9.dll" : builtin fixme:d3d:IWineD3DImpl_GetDeviceCaps Caps support for directx9 is nonexistent at the moment! trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system32\\d3d9.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system32\\wined3d.dll" : builtin fixme:win:EnumDisplayDevicesW ((null),0,0x7fbff43c,0x00000000), stub! trace:x11settings:X11DRV_EnumDisplaySettingsEx mode 0 -- 1280x1024x32bpp (NoRes) trace:x11settings:X11DRV_EnumDisplaySettingsEx mode 1 -- not present (NoRes) fixme:win:EnumDisplayDevicesW ((null),0,0x7fbff6dc,0x00000000), stub! trace:x11settings:X11DRV_EnumDisplaySettingsEx mode 0 -- 1280x1024x32bpp (NoRes) trace:x11settings:X11DRV_EnumDisplaySettingsEx mode 1 -- not present (NoRes) fixme:win:EnumDisplayDevicesW ((null),0,0x7fbff6dc,0x00000000), stub! trace:x11settings:X11DRV_EnumDisplaySettingsEx mode -1 (current) -- getting current mode (NoRes) trace:x11settings:X11DRV_EnumDisplaySettingsEx mode 0 -- 1280x1024x32bpp (NoRes) trace:x11drv:X11DRV_CreateBitmap (0x308) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x30c) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x30c, buffer=0x7fd57074, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x308, buffer=0x7fd570f4, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x310) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x314) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x314, buffer=0x7fd33f5c, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x310, buffer=0x7fd33fdc, count=0x80) fixme:win:EnumDisplayDevicesW ((null),0,0x7fbff644,0x00000000), stub! trace:x11settings:X11DRV_EnumDisplaySettingsEx mode 0 -- 1280x1024x32bpp (NoRes) trace:x11drv:X11DRV_set_window_pos win 0x10022 window (0,0)-(1280,1024) client (0,0)-(1280,1024) style 87000000 trace:x11drv:X11DRV_CreateBitmap (0x31c) 32x32 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x31c, bits=0x7fd340c0, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x318) 32x32 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x318, bits=0x7fd57d10, count=0xc00) trace:x11drv:X11DRV_CreateWindow hwnd 0x10022 cs 0,0 1280x1024 trace:x11drv:X11DRV_set_window_pos win 0x10022 window (0,0)-(1280,1024) client (0,0)-(1280,1024) style 87000000 trace:x11drv:X11DRV_sync_window_position setting win 2000001 pos 0,0,1280x1024 after 7e7879ec changes=40 trace:x11drv:X11DRV_CreateWindow win 0x10022 window 0,0,1280,1024 client 0,0,1280,1024 whole 0,0,1280,1024 X client 0,0,1280,1024 xwin 2000001 trace:x11drv:WINPOS_MinMaximize 0x10022 3 trace:x11drv:X11DRV_SetWindowPos hwnd 0x10022, after (nil), swp 0,0 1280x1024 flags 00000034 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10022, after (nil), swp 0,0 1280x1024 flags 00001834 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(1280,1024) style 87000000 new (0,0)-(1280,1024) trace:x11drv:SWP_DoNCCalcSize hwnd 0x10022 old win (0,0)-(1280,1024) old client (0,0)-(1280,1024) new win (0,0)-(1280,1024) new client (0,0)-(1280,1024) trace:x11drv:X11DRV_set_window_pos win 0x10022 window (0,0)-(1280,1024) client (0,0)-(1280,1024) style 87000000 trace:x11drv:X11DRV_SetWindowPos status flags = 1827 fixme:win:EnumDisplayDevicesW ((null),0,0x7fbff630,0x00000000), stub! trace:x11settings:X11DRV_EnumDisplaySettingsEx mode 0 -- 1280x1024x32bpp (NoRes) trace:x11settings:X11DRV_ChangeDisplaySettingsEx (L"\\\\.\\DISPLAY1",0x7fbff89c,(nil),0x00000004,(nil)) trace:x11settings:X11DRV_ChangeDisplaySettingsEx flags=FULLSCREEN trace:x11settings:X11DRV_ChangeDisplaySettingsEx DM_fields=BITSPERPEL,PELSWIDTH,PELSHEIGHT trace:x11settings:X11DRV_ChangeDisplaySettingsEx width=1280 height=1024 bpp=32 freq=0 (NoRes) trace:x11settings:X11DRV_ChangeDisplaySettingsEx Requested display settings match mode 0 (NoRes) trace:x11settings:X11DRV_nores_SetCurrentMode Ignoring mode change request trace:x11drv:X11DRV_SetWindowPos hwnd 0x10022, after (nil), swp 0,0 1280x1024 flags 00002108 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10022, after (nil), swp 0,0 1280x1024 flags 00003908 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(1280,1024) style 87000000 new (0,0)-(1280,1024) trace:x11drv:X11DRV_set_window_pos win 0x10022 window (0,0)-(1280,1024) client (0,0)-(1280,1024) style 87000000 trace:x11drv:X11DRV_sync_window_position setting win 2000001 pos 0,0,1280x1024 after 7e7879ec changes=40 fixme:system:SystemParametersInfoW Unimplemented action: 113 (SPI_SETMOUSESPEED) trace:x11drv:X11DRV_SetWindowPos status flags = 1807 trace:x11drv:X11DRV_ShowWindow hwnd=0x10022, cmd=3, wasVisible 0 trace:x11drv:WINPOS_MinMaximize 0x10022 3 trace:x11drv:X11DRV_SetWindowPos hwnd 0x10022, after (nil), swp 0,0 1280x1024 flags 00000060 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10022, after (nil), swp 0,0 1280x1024 flags 00001860 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(1280,1024) style 87000000 new (0,0)-(1280,1024) trace:x11drv:SWP_DoOwnedPopups (0x10022) hInsertAfter = (nil) trace:x11drv:SWP_DoNCCalcSize hwnd 0x10022 old win (0,0)-(1280,1024) old client (0,0)-(1280,1024) new win (0,0)-(1280,1024) new client (0,0)-(1280,1024) trace:x11drv:X11DRV_set_window_pos win 0x10022 window (0,0)-(1280,1024) client (0,0)-(1280,1024) style 97000000 trace:x11drv:X11DRV_sync_window_position setting win 2000001 pos 0,0,1280x1024 after 7e7879ec changes=40 trace:x11drv:X11DRV_set_window_pos mapping win 0x10022 trace:x11drv:X11DRV_CreateBitmap (0x340) 32x32 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x340, bits=0x7fd340c0, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x33c) 32x32 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x33c, bits=0x7fd57d10, count=0xc00) trace:x11drv:X11DRV_SetWindowPos status flags = 1867 trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(960,768) client (0,0)-(960,768) style 04cf0000 trace:x11drv:create_icon_window created 2000003 trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(960,768) client (0,0)-(960,768) style 04cf0000 trace:x11drv:X11DRV_sync_window_position setting win 2000002 pos 4,23,952x741 after 7e7879ec changes=f trace:x11drv:X11DRV_CreateWindow hwnd 0x10024 cs 0,0 960x768 trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(960,768) client (4,23)-(956,764) style 04cf0000 trace:x11drv:X11DRV_sync_window_position setting win 2000002 pos 4,23,952x741 after 7e7879ec changes=40 trace:x11drv:X11DRV_CreateWindow win 0x10024 window 0,0,960,768 client 4,23,956,764 whole 4,23,956,764 X client 0,0,952,741 xwin 2000002 trace:x11drv:destroy_whole_window win 0x10024 xwin 2000002 fixme:win:EnumDisplayDevicesW ((null),0,0x7fbff14c,0x00000000), stub! trace:x11settings:X11DRV_EnumDisplaySettingsEx mode 0 -- 1280x1024x32bpp (NoRes) trace:x11settings:X11DRV_EnumDisplaySettingsEx mode 1 -- not present (NoRes) fixme:system:SystemParametersInfoW Unimplemented action: 112 (SPI_GETMOUSESPEED) fixme:system:SystemParametersInfoW Unimplemented action: 113 (SPI_SETMOUSESPEED) trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\lz32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\version.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\setupapi.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\dsound.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system32\\setupapi.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system32\\version.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system32\\lz32.dll" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\mswsock.dll" : builtin fixme:sync:CreateIoCompletionPort (0xffffffff, (nil), 00000000, 00000000): stub. fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT (5000): STUB fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_RECEIVE_TIMEOUT: STUB fixme:wininet:InternetSetOptionW Option 45 STUB trace:x11drv:X11DRV_ConfigureNotify win 0x10022 new X rect 0,0,1280x1024 (event 0,0,1280x1024) trace:x11drv:X11DRV_Expose win 0x10022 (2000001) 0,0 1280x1024 trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ddraw.dll" : builtin trace:loaddll:load_native_dll Loaded module L"Z:\\games\\World.of.Warcraft\\WoWTest\\WDB\\Survey.dll" : native trace:x11drv:X11DRV_DCICommand (20,(12,2040285540,543712117),(nil)) trace:x11drv:X11DRV_DCICommand (...): 16 - 0x79992390 - (nil) - (nil) trace:x11drv:X11DRV_DCICommand (20,(13,1792,543712117),0x799c4d40) trace:x11drv:X11DRV_DCICommand (20,(11,1792,543712117),0x799c4d60) trace:x11drv:X11DRV_DCICommand (20,(10,1792,543712117),0x799c4ea8) trace:x11settings:X11DRV_Settings_CreateDriver Setting up display settings for DDRAW (NoRes) trace:x11drv:X11DRV_DDHAL_SwitchMode (0,(nil),(nil)) trace:ddraw:initialize enabling DirectDraw HAL trace:ddraw:d3ddevice_init_at_startup Initializing GL... trace:ddraw:d3ddevice_init_at_startup GL version 2.0.1 trace:ddraw:d3ddevice_init_at_startup GL supports following extensions used by Wine : trace:ddraw:d3ddevice_init_at_startup - mirrored repeat trace:ddraw:d3ddevice_init_at_startup - texture lod bias trace:ddraw:d3ddevice_init_at_startup - multi-texturing (4 stages) trace:ddraw:d3ddevice_init_at_startup - S3TC compression supported trace:ddraw:fill_caps : max texture size = 4096 trace:ddraw:fill_caps : max active lights = 8 trace:ddraw:fill_caps : max clipping planes = 6 trace:ddraw:fill_caps : Z bits = 24 trace:ddraw:DDRAW_bind_to_s3tc No S3TC software decompression library seems to be present (libtxc_dxtn.so). trace:loaddll:MODULE_FlushModrefs Unloaded module L"Z:\\games\\World.of.Warcraft\\WoWTest\\WDB\\Survey.dll" : native trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system32\\ddraw.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system32\\mswsock.dll" : builtin fixme:imm:ImmAssociateContextEx (0x10022, (nil), 16): stub trace:x11drv:X11DRV_SetWindowPos hwnd 0x10022, after (nil), swp 0,0 0x0 flags 00000097 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10022, after (nil), swp 0,0 0x0 flags 00001897 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(1280,1024) style 97000000 new (0,0)-(1280,1024) trace:x11drv:SWP_DoOwnedPopups (0x10022) hInsertAfter = (nil) trace:x11drv:X11DRV_set_window_pos win 0x10022 window (0,0)-(1280,1024) client (0,0)-(1280,1024) style 87000000 trace:x11drv:X11DRV_set_window_pos unmapping win 0x10022 trace:x11drv:X11DRV_SetWindowPos status flags = 1887 trace:x11settings:X11DRV_ChangeDisplaySettingsEx ((null),(nil),(nil),0x00000000,(nil)) trace:x11settings:X11DRV_ChangeDisplaySettingsEx flags= trace:x11settings:X11DRV_ChangeDisplaySettingsEx Return to original display mode (NoRes) trace:x11settings:X11DRV_EnumDisplaySettingsEx mode 0 -- 1280x1024x32bpp (NoRes) trace:x11settings:X11DRV_ChangeDisplaySettingsEx Requested display settings match mode 0 (NoRes) trace:x11settings:X11DRV_nores_SetCurrentMode Ignoring mode change request trace:x11drv:X11DRV_ShowWindow hwnd=0x10022, cmd=6, wasVisible 0 trace:x11drv:WINPOS_MinMaximize 0x10022 6 trace:x11drv:X11DRV_SetWindowPos hwnd 0x10022, after (nil), swp 21,970 32x32 flags 00000120 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10022, after (nil), swp 21,970 32x32 flags 00001920 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(1280,1024) style a6000000 new (21,970)-(53,1002) trace:x11drv:SWP_DoNCCalcSize hwnd 0x10022 old win (0,0)-(1280,1024) old client (0,0)-(1280,1024) new win (21,970)-(53,1002) new client (21,970)-(53,1002) trace:x11drv:X11DRV_set_window_pos win 0x10022 window (21,970)-(53,1002) client (21,970)-(53,1002) style a6000000 trace:x11drv:X11DRV_sync_window_position setting win 2000001 pos 21,970,32x32 after 7e7879ec changes=4f trace:x11drv:X11DRV_SetWindowPos status flags = 0024 trace:x11drv:destroy_whole_window win 0x10022 xwin 2000001

March 5, 2006

Re: [Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI

by Uwe Bonnes

>>>>> "H" == H Verbeet <hverbeet(a)gmail.com> writes: ... >> Appended patch lets me circumvent that problem. H> I'm not sure if GL_STENCIL_BACK_FAIL and GL_STENCIL_BACK_FAIL_ATI are H> interchangeable, but more importantly it makes the same kind of H> assumptions about what's going to be defined. I said "circumvent" not "solve"... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

March 5, 2006

Re: fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented

by Rainer Dorsch

Am Sonntag, 5. März 2006 19:15 schrieb Michael Jung: > On Sunday 05 March 2006 18:27, Rainer Dorsch wrote: > > Do you have any free easy to install app in mind which might show the > > same issue? > > Unfortunately, no. All the apps I've tested with seem to work fine. It > might be a problem with the unix filesystem shell namespace extension. > Could you try to browse the old drive letter based shell namespace (under > 'My Computer' or 'Arbeitsplatz' on a german system) and figure if the > problem persists there, too? Not sure if I understood that correctly. I do everything within the notes file select box: I went to 'Arbeitsplatz' in the Shell and then 'C'. MyDocuments was shown as a file, not a folder. I.e. the problem persists. Thanks, Rainer -- Rainer Dorsch Alzentalstr. 28 D-71083 Herrenberg 07032-919495 Icq: 32550367

March 5, 2006

Re: configure: add --with-fontfir (try3) with patch!

by Vitaly Lipatov

On Sunday 05 March 2006 23:22, Alexandre Julliard wrote: > Could you please explain what you are trying to do? I don't > think we want to hardcode more paths, I've just been getting > rid of them. I told about fontdir = $(datadir)/fonts/wine line in fonts/Makefile.in. It is _hardcoded_ path. I try to get rid of this and get possibility to set path to fontdir with configure options. -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

March 5, 2006

Re: configure: add --with-fontfir (try3) with patch!

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: >> Can't you achieve the same thing with the standard configure >> options? What are you trying to do with the fonts? > I wish remove direct path to font dir from fonts/Makefile.am and > make in configurable via configure option. > I can't place fonts in datadir/wine/fonts now. > > P.S. > I have plans to use @FONTDIR@ in other Makefiles. Could you please explain what you are trying to do? I don't think we want to hardcode more paths, I've just been getting rid of them. -- Alexandre Julliard julliard(a)winehq.org

March 5, 2006

Re: World of Warcraft 0.10 Public Test Realm (PTR)

by Tomas Carnecky

Tomas Carnecky wrote: > At a certain point the screen just turns black, it's always at the same > point, and when looking through the +x11drv trace I can see these > messages at that point: > > trace:x11drv:X11DRV_DCICommand (20,(12,2079885668,543712117),(nil)) > trace:x11drv:X11DRV_DCICommand (20,(13,1792,543712117),0x7bf88d40) > trace:x11drv:X11DRV_DCICommand (20,(11,1792,543712117),0x7bf88d60) > trace:x11drv:X11DRV_DCICommand (20,(10,1792,543712117),0x7bf88ea8) > > also, these messages don't appear in version 1.9.4 (which is the 'live' > version). So I suspect that Blizzard added something related to this > function to the 0.10 version which breaks something. > > When the screen turns black, its just the screen, everything else works, > keyboard for sure, I can press 'Esc' to get out of the game, not sure > about the mouse though.. > It seems that Blizzard added DDraw HAL.. right after these CDICommand calls I see: trace:x11settings:X11DRV_Settings_CreateDriver Setting up display settings for DDRAW (NoRes) trace:x11drv:X11DRV_DDHAL_SwitchMode (0,(nil),(nil)) which changes the display setting, but I disabled xvidmode and xrandr so this really shouldn't do anything. also, it seems like WoW draws to a completely different buffer after that because I see two different pictures changing, like the application would call SwapBuffers() on two buffer that are not updated.. like WoW would set up a new drawable but not switch to it.. tom

March 5, 2006

Re: wine 0.9.9 vs. Ned For Speed V -- already better

by Stefan Dösinger

Am Sonntag, 5. März 2006 20:36 schrieb Samium Gromoff: > manages to allow NFS to initialize the video mode, apparently. You can try my directdraw patches: http://stud4.tuwien.ac.at/~e0526822/ But wait before downloading, I have some updates I'll upload within the next hours. Is a demo of that game available? Stefan

March 5, 2006

wine 0.9.9 vs. Ned For Speed V -- already better

by Samium Gromoff

Here goes the log for running NFS5: PU, in win 0.9.9, the first version which manages to allow NFS to initialize the video mode, apparently. The wine debug output is attached.

March 5, 2006

Re: WRT: winetest-latest is outdated

by Paul Millar

Hi Detlef, On Friday 03 Mar 2006 22:49, Detlef Riekenberg wrote: > Hi. > > The latest Winetest-Binaries are outdated > ( http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/?N=D ). Yup. I'm trying to migrate from the old computer (an old RH-7.3 box much like Frankenstein's monster) to a more manageable machine (running Debian etch). Cross-building isn't working on the new machine yet and is currently broken on the old one. > Winetest (ELF) compiled again recently > ( http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php ), > but the crossbuilds are still missing. That's true: the two builds are independent. The wine tests had a different problem, for which I've a work-around now. > Is there anything that we can do for help? Yes. The autoconf-generated script seems to be getting confused when cross-compiling. When cross-compiling, I do something similar to the following: 1. get the source-code and move to directory wine-cross-source 2. In directory wine-cross-elf, do: ../wine-cross-source/configure && make depend && make tools 3. In directory wine-cross-pe, do: ../wine-cross-source/configure --host=i686-mingw32msvc \ --with-wine-tools=../wine-cross-elf After that, it does a "make depend" and a bunch of other stuff to get winetest.exe, the DLLs and other EXEs. Step 3 is failing. It looks as if the configure script becomes confused between cross-building and native environments, in particular with OpenGL libraries. Although the code is cross-compiling, it seems to pick up the native GL libraries and header files. Then, when the cross-compiler fails (to link some glx symbol, iirc), the configure script dies. When it fails, the configure script gives a hint that the file /usr/X11R6/lib/libGL.a should be removed. Doing this certainly fixes the cross-compilation and the ELF compilation still works as it links against the .so version. However, removing the xlibmesa-gl-dev package isn't feasible as its need by many other -dev packages and would break OpenGL compilation. This looks like a bug in configure.ac, as why should a native static library break cross-compilation. Any clues? Cheers, Paul. config.log is available from: http://www.astro.gla.ac.uk/users/paulm/config.log The last few lines from running configure are: ... checking for GL/gl.h... yes checking for GL/glx.h... yes checking for GL/glext.h... yes checking for up-to-date OpenGL version... yes checking for glXCreateContext in -lGL... no configure: error: /usr/X11R6/lib/libGL.a is present on your system. This prevents linking to OpenGL. Delete the file and restart configure.

March 5, 2006

Feedback request on wininet patch

by Victor Pelt

Hey I implemented one of the missing options in InternetSetOption. Any feedback about the way i implemented it would be appreciated. If it is alright i will implement the other missing options too regards Victor Pelt

March 5, 2006

Re: configure: add --with-fontfir (try3) with patch!

by Vitaly Lipatov

On Sunday 05 March 2006 20:43, Alexandre Julliard wrote: > Vitaly Lipatov <lav(a)etersoft.ru> writes: > > On Tuesday 21 February 2006 20:10, Vitaly Lipatov wrote: > >> I made some fixes to correct work. > >> > >> Changelog > >> add --with-fontdir parameter to configure for set WINE > >> fonts placement. ... > Can't you achieve the same thing with the standard configure > options? What are you trying to do with the fonts? I wish remove direct path to font dir from fonts/Makefile.am and make in configurable via configure option. I can't place fonts in datadir/wine/fonts now. P.S. I have plans to use @FONTDIR@ in other Makefiles. -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

March 5, 2006

Re: fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented

by Michael Jung

On Sunday 05 March 2006 18:27, Rainer Dorsch wrote: > Do you have any free easy to install app in mind which might show the same > issue? Unfortunately, no. All the apps I've tested with seem to work fine. It might be a problem with the unix filesystem shell namespace extension. Could you try to browse the old drive letter based shell namespace (under 'My Computer' or 'Arbeitsplatz' on a german system) and figure if the problem persists there, too? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

March 5, 2006

Re: configure: add --with-fontfir (try3) with patch!

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > On Tuesday 21 February 2006 20:10, Vitaly Lipatov wrote: >> I made some fixes to correct work. >> >> Changelog >> add --with-fontdir parameter to configure for set WINE fonts >> placement. > Sorry, what is broken with my patch? > http://www.winehq.org/pipermail/wine-patches/2006-February/024535.html Can't you achieve the same thing with the standard configure options? What are you trying to do with the fonts? -- Alexandre Julliard julliard(a)winehq.org

March 5, 2006

Re: fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented

by Rainer Dorsch

Hello Michael, thanks for the prompt reply. I have one other (also commercial) program (a map viewer which came with a map CDROM) running on wine but it shows a completely different file select box. I could recompile wine if you have a patch which generates more debug output and send the debug output (though I am the next 3 days away from my computer). These are the two specific setting which I do for wine: - I need to set win98 (winecfg) to get the file select box working at all - I need to set WINEDLLOVERRIDES="usp10=n" Do you have any free easy to install app in mind which might show the same issue? Thanks, Rainer Am Sonntag, 5. März 2006 18:14 schrieben Sie: > Hello Rainer, > > On Sunday 05 March 2006 17:48, Rainer Dorsch wrote: > > wine-0.9.9 still does not display folders correctly in a file select box > > (Lotus Notes in this case). Folders and files are displayed with the file > > symbol. It seems to be only a display issue, clicking on folders still > > opens them. > > I would like to take a look at this, but I don't have a Notes license. Do > you observe this behaviour with any other program available for free or > with a demo version availabe? > > Bye, -- Rainer Dorsch Alzentalstr. 28 D-71083 Herrenberg 07032-919495 Icq: 32550367

March 5, 2006

Re: fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented

by Michael Jung

Hello Rainer, On Sunday 05 March 2006 17:48, Rainer Dorsch wrote: > wine-0.9.9 still does not display folders correctly in a file select box > (Lotus Notes in this case). Folders and files are displayed with the file > symbol. It seems to be only a display issue, clicking on folders still > opens them. I would like to take a look at this, but I don't have a Notes license. Do you observe this behaviour with any other program available for free or with a demo version availabe? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

March 5, 2006