August 2002 - Wine-Devel - list.winehq.org

Re: DInput patch - Bugzilla rights

by Jeremy Newman

Well... since you said please. ;-) On Mon, 2002-08-05 at 13:23, Tony Lambregts wrote: > Well if Jeremy Newman will give me the access I need to set this up, I > would be glad to "fix up" each developer that has an account in > Bugzilla. (Pretty Please). -- __ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | .` / -_) | | / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

Aug. 5, 2002

RE: DInput patch - Bugzilla rights

by Patrik Stridvall

> Lionel Ulmer wrote: > > > > >This fixes bug 941. By the way, could I have more 'bugzilla' > power, I hate > >not being able to move bugs out of Unconfirmed state or to > not being able to > >close them (/me thinks that all Wine developpers should have > these rights). > > > > > Yes I aggree all Wine developers should have full rights in bugzilla. Yes, please. I remember once trying to reclassfied a wrongly classified bug and failed. I wasn't that important so I didn't bother asking for more rights... I haven't used Bugzilla that much but I certainly won't not use it less if I get more rights rather more... > Right now Andriy Palamarchuk and Jeremy Newman are the ones > that can do > this. The only catch is the developers need to set up a > bugzilla account > first. I have one already. Same as my email adress: ps(a)leissner.se

Aug. 5, 2002

Re: DInput patch - Bugzilla rights

by Tony Lambregts

Lionel Ulmer wrote: > >This fixes bug 941. By the way, could I have more 'bugzilla' power, I hate >not being able to move bugs out of Unconfirmed state or to not being able to >close them (/me thinks that all Wine developpers should have these rights). > > Yes I aggree all Wine developers should have full rights in bugzilla. Right now Andriy Palamarchuk and Jeremy Newman are the ones that can do this. The only catch is the developers need to set up a bugzilla account first. Tony Lambregts

Aug. 5, 2002

Re: Isn't 'make depend' optional?

by Tony Lambregts

Bang Jun-Young wrote: >On Mon, Aug 05, 2002 at 04:49:21PM +0200, Joerg Mayer wrote: > > >>On Mon, Aug 05, 2002 at 11:22:54PM +0900, Bang Jun-Young wrote: >> >> >>>In what cases? >>> >>> >>I don't know. >> >> >> >>>I think you never understand what the purpose of 'make depend' is. >>> >>> >>You may be right here :-) I think make depend builds for each source file >>a list of all other files it includes (recursively). So if one of theses >>files has changed, an existing object file get rebuild. >>So if something in the include or #define structure (e.g. config.h) >>changes, you need to do a new make depend. >> >> > >If none of files in the source directories is supposed to change, >e.g. making a binary package from sources, 'make depend' is completely >unnecessary, > > > >>That's my understanding of what make depend is good for. >> >> > >I intepret "be good for" to "be useful for", not "be required for." > >Jun-Young > > > In this case required for would be true. Running make depend ensures that all dependencys are accounted for and in most cases they do not change from one snapshot to the next., but that is not guarnteed. It seems to me there have been quite a few changes that would affect dependencys since the last snapshot. What you are saying is that you don't "_have_to_" run make depend each time you compile wine, which is true. just as you dont "_have _to_ " run ./configure each time wine changes. There are times when you do and running make depend does not take that long and it makes sure that everything is in the right place. If you realy want to avoid it you can work around it as you have, or you can run make depend, your choice I suppose. Tony Lambregts

Aug. 5, 2002

FF8 and DirectMusic

by Martin Lexa

Hi! I tried Final Fantasy 8 under Wine (no Windows), yesterday. Got it running, but FF8Config refused to start complaining something about MIDI error. Of course no music. Here is what I found after debugging almost 6 hours :( 1. There are some missing registry entries which are needed. [Software\\Classes\\CLSID\\{58C2B4D0-46E7-11D1-89AC-00A0C9054129}] 1028325524 @="DirectMusicSynth" [Software\\Classes\\CLSID\\{58C2B4D0-46E7-11D1-89AC-00A0C9054129}\\InprocServer32] 1028325524 @="dmsynth.dll" "ThreadingModel"="Both" [Software\\Classes\\CLSID\\{636B9F10-0C7D-11D1-95B2-0020AFDC7421}] 1028325524 @="DirectMusic Object" [Software\\Classes\\CLSID\\{636B9F10-0C7D-11D1-95B2-0020AFDC7421}\\InprocServer32] 1028325524 @="dmusic.dll" "ThreadingModel"="Both" [Software\\Microsoft\\DirectMusic] 1028325524 @="" "GMFilePath"="gm.dls" [Software\\Microsoft\\DirectMusic\\Defaults] 1028325524 @="" "DefaultOutputport"="{58C2B4D0-46E7-11D1-89AC-00A0C9054129}" [Software\\Microsoft\\DirectMusic\\SoftwareSynths] 1028325524 @="" [Software\\Microsoft\\DirectMusic\\SoftwareSynths\\{58C2B4D0-46E7-11D1-89AC-00A0C9054129}] 1028325524 @="" "Description"="Microsoft Software Synthesizer" 2. Original (native) DMUSIC.DLL, DMUSIC16.DLL, DMUSIC32.DLL, DMSYNTH.DLL are needed too. After above changes FF8Config wasn't complaining about MIDI problems., but simply hanging after displaying window. I think problem is that I'm using native DirectMusic DLLs or am I wrong? Maybe not, because there is X11DRV error... Here is wine output: $ wine --debugmsg +ole FF8Config.exe trace:ole:OLE32_DllEntryPoint 0x40bda000 0x1 0x1 trace:ole:CoRegisterMallocSpy trace:ole:IMallocSpy_fnQueryInterface ({0000001d-0000-0000-c000-000000000046},0x405c6dec) trace:ole:OLE32_DllEntryPoint 0x40bda000 0x2 (nil) trace:ole:OLE32_DllEntryPoint 0x40bda000 0x2 (nil) fixme:ddraw:MESA_IDirect3D2Impl_EnumDevices (0x403d8f58)->(0x401e45,0x403d8f58),stub! fixme:ddraw:MESA_IDirect3D2Impl_EnumDevices (0x403d8f58)->(0x401e45,0x403d8f58),stub! trace:ole:OLE32_DllEntryPoint 0x40bda000 0x2 (nil) fixme:ddraw:MESA_IDirect3D2Impl_EnumDevices (0x403d8f58)->(0x401e45,0x403d8f58),stub! fixme:ddraw:MESA_IDirect3D2Impl_EnumDevices (0x403d8f58)->(0x401e45,0x403d8f58),stub! trace:ole:CoInitializeEx ((nil), 2) trace:ole:CoInitializeEx () - Initializing the COM libraries trace:ole:RunningObjectTableImpl_Initialize () trace:ole:WINE_StringFromCLSID 0x4155a0->{636B9F10-0C7D-11D1-95B2-0020AFDC7421} trace:ole:CoGetClassObject CLSID: {636b9f10-0c7d-11d1-95b2-0020afdc7421}, IID: {00000001-0000-0000-c000-000000000046} trace:ole:COMPOBJ_DLLList_Add fixme:setupapi:SetupDiGetClassDevsA {6994ad04-93ef-11d0-a3cc-00a0c9223196} (null) 0000 00000012 trace:ole:__CLSIDFromStringA {58C2B4D0-46E7-11D1-89AC-00A0C9054129} -> 0x405c6d4c trace:ole:WINE_StringFromCLSID 0x405c6d4c->{58C2B4D0-46E7-11D1-89AC-00A0C9054129} trace:ole:CoGetClassObject CLSID: {58c2b4d0-46e7-11d1-89ac-00a0c9054129}, IID: {00000001-0000-0000-c000-000000000046} trace:ole:COMPOBJ_DLLList_Add trace:ole:CoUninitialize () err:ntdll:RtlpWaitForCriticalSection section 0x40cd0424 "x11drv_main.c: X11DRV_CritSection" wait timed out, retrying (60 sec) tid=080720a8 If running wine like this 'wine --debugmsg +all FF8Config.exe &>log' the FF8Config not hangs in displaying window and looks like it's running ok! This means wine is running very slowly, because of writing debug messages, so there is some kind of timing error... may be not. Don't know for sure. Could somebody point me where should I look? What above "err:ntdll:..." really means? How should I debug it? And I'd like to ask is somebody who works on DirectMusic implementation under Wine? If no, could somebody tell me how hard should be add this? Is really necessary to implement each DLL or just DMSYNTH.DLL(?) contains needed rutines? I'd like to get FF8 running at any price :) Thank you in advance. Regards, Martin.

Aug. 5, 2002

Re: Isn't 'make depend' optional?

by Bang Jun-Young

On Mon, Aug 05, 2002 at 04:49:21PM +0200, Joerg Mayer wrote: > On Mon, Aug 05, 2002 at 11:22:54PM +0900, Bang Jun-Young wrote: > > In what cases? > > I don't know. > > > I think you never understand what the purpose of 'make depend' is. > > You may be right here :-) I think make depend builds for each source file > a list of all other files it includes (recursively). So if one of theses > files has changed, an existing object file get rebuild. > So if something in the include or #define structure (e.g. config.h) > changes, you need to do a new make depend. If none of files in the source directories is supposed to change, e.g. making a binary package from sources, 'make depend' is completely unnecessary, > > That's my understanding of what make depend is good for. I intepret "be good for" to "be useful for", not "be required for." Jun-Young -- Bang Jun-Young <junyoung(a)mogua.com>

Aug. 5, 2002

Re: Isn't 'make depend' optional?

by Joerg Mayer

On Mon, Aug 05, 2002 at 11:22:54PM +0900, Bang Jun-Young wrote: > In what cases? I don't know. > I think you never understand what the purpose of 'make depend' is. You may be right here :-) I think make depend builds for each source file a list of all other files it includes (recursively). So if one of theses files has changed, an existing object file get rebuild. So if something in the include or #define structure (e.g. config.h) changes, you need to do a new make depend. That's my understanding of what make depend is good for. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Aug. 5, 2002

Re: Isn't 'make depend' optional?

by Bang Jun-Young

On Mon, Aug 05, 2002 at 03:21:47PM +0200, Joerg Mayer wrote: > On Mon, Aug 05, 2002 at 10:05:48PM +0900, Bang Jun-Young wrote: > > Why do I have to do 'make depend' when I can build Wine without it? > > Only because it's said so there? Sounds unreasonable to me. > > No, not because it is said there. Definitely not because it is said > there. The current build process requires that this is done in some > cases. In what cases? > Because nobody wanted to document those cases, the message > was put at the end of configure. I had problems compiling wine without > make depend from time to time 6 or more years ago, so your problem is > in no way new. It may be new for you, but not for wine. I have been able to build Wine without 'make depend' for the past 8 months (or longer, probably). I couldn't test with releases earlier than 20011226 when NetBSD support was available for the first time. If you want, I can do the same test with earlier releases on Linux. I really wonder how the same problem has come and gone from time to time. Who broke it and who fixed it? > And because of this problem, you should do make depend. Or not, but > please don't complain in that case. Your agrument seems to go a bit > like that: "I've been speeding for years but never got a ticket. Why > should I get one now?" I think you never understand what the purpose of 'make depend' is. If you are only interested in getting binaries via source build, you should be able to do it without a time-spendng process that adds a large amount of explicit dependency to Makefiles. Jun-Young -- Bang Jun-Young <junyoung(a)mogua.com>

Aug. 5, 2002

OpenGL 'hack' patch

by Lionel Ulmer

Hi all, To make NWN's model viewer work in Wine, I did the attached patch... Warning, it's not for the faint of heart so ugly it is :-) Basically, the plan is to have two drawable per DC in the X11 driver, one for 'normal' drawings, the other for OpenGL drawings, the latter being the one associated with the window when goind a CLIPSIBLINGS GetDCEx. Now to do this 'nicely', the 'use ExtEscape to store data' method is not the right one (but it works :-) ). So my current plan is to really separate all the X11 stuff into the X11DRV and to have a 'portable' opengl32.dll library. Now my question is 'how to do this properly' ? Is extending the 'dc' function pointer array with all the needed OpenGL functions a way (even if these functions are NOT GDI functions but pure OpenGL) ? The problem with this solution is that I would need to use the 'DC_GetDCPtr' function outside of GDI (and that may break DLL separation). Another solution could be to add all the OpenGL functions as GDI functions, do the DC function pointer thing and then put a forward from all the wgl functions to the GDI32.* functions. What do you all think of it ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 5, 2002

cvs [update aborted]: request `update_template' not supported by server

by Shachar Shemesh

When trying to perform CVS operations on the WINE build from Solaris, I get the above mentioned error: cvs [update aborted]: request `update_template' not supported by server I am using cvs version 1.10.1 Anyone here knows what the problem is? Shachar

Aug. 5, 2002