January 2003 - Wine-Devel - list.winehq.org

Re: getting started

by Francois Gouget

On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: > On January 7, 2003 02:25 pm, Francois Gouget wrote: > > * winemaker > > The assumption is that you have a Windows application (complete with > > CR/LF), most likely based on Visual C++ and thus with no suitable > > makefiles. So winemaker's goal is to quickly generate suitable Makefiles > > that will build Winelib applications/dlls from what it's given and fix > > the simple issues in the source (CR/LF, #pragmas). The backend is > > somewhat secondary. > > This touches on an issue that I'd like to avoid discussing now -- > it deserves a separate thread. But just to note that the things > you've mentioned are not mutually exclusive: [...] > -- Having the make files portable between Wine/Linux/MinGW > can only be a good thing, right? I think our views are not incompatible and even that we basically agree. However there is a difference in emphasis. I'm more interested in improving the front-end, especially by adding support for dsp file which I think would improve the usefulness of winemaker tremendously (so that's what I would work on if I had time). You are more interested in the backend and in making it compatible with MinGW. However since I probably won't have time to make significant changes to winemaker in the near future my preferences are moot. Call for help: Please if you are interested in working on either aspect let us know (me or Dimitrie) and we will try to help you each with the part we are more familiar with. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

Jan. 7, 2003

Re: wxWindows: it's official!

by Francois Gouget

On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: > On January 7, 2003 03:00 pm, Francois Gouget wrote: > > For exactly the same reasons, Winelib applications, using Windows paths > > (c:\Windows\wininit.ini) on Unix have to link with the Wine C library > > (msvcrt) rather than the native one (glibc) in order to call functions > > with these paths. > > But this is missing the point. What you are saying is that we should > not allow people to link to the native libc, because you think that > the msvcrt behavior is more correct. I beg to differ. > > If people choose to ling to glibc, they must be aware the apps will not > work with Windows paths. It's their choice. No. I contend that applications making use of access and other similar APIs in Winelib will not work at all unless they have been specifically designed for that case, in which case they should not be using io.h anyway. Thus for me adding this header has no value and will only cause trouble due to the confusion it introduces. You contend that Windows applications calling the glibc access function will still work with no (related) modification (though you conceed they may only be partially functional), thus justifying the presence of io.h. That's where we differ. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation

Jan. 7, 2003

Re: Web CVS annotation

by Geoff Thorpe

* Eric Pouech (eric.pouech(a)wanadoo.fr) wrote: > sure, the main issue we have is that winehq runs cvsweb as the web cvs > frontend, and cvsweb only supports annotation under the condition I > posted (IOW, it doesn't implement the annotate feature - on WWW side - > with cvs annotate). But you're right on the constraints we get. > > so either check if a newer cvsweb implements annotate with cvs annotate, > or we hack cvsweb to get what we want/need... There's all sorts of versions of cvsweb floating around, no doubt one of them contains what you want. BTW: w.r.t. rw permissions on CVS for annotation functionality. Do you run cvsweb (or whatever) on a slave *copy* of the CVS repository rather than leaving any possible window of opportunity for the master repository to get hit? Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/

Jan. 7, 2003

Re: Problem in dlls/ddraw/dsufrace/main.c

by Sylvain Petreolle

--- Lionel Ulmer <lionel.ulmer(a)free.fr> a écrit : > > Well, I said the wrong words to explain me :/. > > Disabling the test in our code, will the function fail or not ? > > It will crash in the AddRef code. Better to try to do something like > that : > > if (found == NULL) { > TRACE("Did not find any valid surface\n"); > *ppSurface = NULL; > return DD_OK; > } I get the same behaviour with this code enabled as with the whole test disabled. ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 7, 2003

Possible Proformence Costs on Non-debug Builds

by Nathan Boyle

Why are there 20364 debug messages that get compiled into the code even w/ debug messages turned off? They don't actually do anything when you configure w/ --disable-debug, but shouldn't all those "if"s slow down execution incredibly? Why arn't the "if"s implemented in preprocessor directives? Please CC any replys to boylenate316(a)aol.com, i am using my junk-mail account to send this b/c i cant send e-mails from the AOL website on Linux[IE specific tags probably], and waol.exe insists that i need it to install the dun/ras files and reboot whenever i try to run it under wine. NOTE: i just updated my Wine code from CVS and compiled about an hour ago.. just another WindBlows X-tra P-ricey hater who misses WfW 3.11.... -- _______________________________________________ Get your free email from http://mymail.swirvemail.com

Jan. 7, 2003

Re: Re: Sound driver autodetection

by chrismorgan＠rcn.com

So the external tool would try to load each driver and put the detected one into the appropriate location in the registry? Chris > > From: Eric Pouech <eric.pouech(a)wanadoo.fr> > Date: 2003/01/07 Tue PM 05:09:02 EST > To: cmorgan(a)alum.wpi.edu > CC: wine-devel(a)winehq.com > Subject: Re: Sound driver autodetection > > chrismorgan(a)rcn.com wrote: > > I've been thinking about implementing sound driver autodetection in wine. On startup wine would try to open a device with each of the drivers until one was opened successfully. This seems pretty simple to implement, I was wondering if there was a dynamic way of detecting the list of drivers to try or whether this list would have to be hardcoded in a c file. Eric, any hints? > > I don't think this belongs to wine. What we could need is: > 1/ an external tool that lists all available drivers > 2/ then creates the corrects initialization of the registry. this would > also include defining the default driver > 3/ then all MM DLLs would get their configuration from the registry > > of course, 1/ will get complicated with different wine drivers outputing > to the same physical device, but we could infer some of the rules here > 1 & 2 could be implemented as a control panel (for better user > performance), but also as a pure command line tool so that it can be > invoked at wine initialisation (at least for 2/) > > as a matter of fact, I already have 3/ implemented, but never committed > it because of the lack of 1&2 > > A+ > -- > Eric Pouech > > >

Jan. 7, 2003

Re: Sound driver autodetection

by Eric Pouech

chrismorgan(a)rcn.com wrote: > I've been thinking about implementing sound driver autodetection in wine. On startup wine would try to open a device with each of the drivers until one was opened successfully. This seems pretty simple to implement, I was wondering if there was a dynamic way of detecting the list of drivers to try or whether this list would have to be hardcoded in a c file. Eric, any hints? I don't think this belongs to wine. What we could need is: 1/ an external tool that lists all available drivers 2/ then creates the corrects initialization of the registry. this would also include defining the default driver 3/ then all MM DLLs would get their configuration from the registry of course, 1/ will get complicated with different wine drivers outputing to the same physical device, but we could infer some of the rules here 1 & 2 could be implemented as a control panel (for better user performance), but also as a pure command line tool so that it can be invoked at wine initialisation (at least for 2/) as a matter of fact, I already have 3/ implemented, but never committed it because of the lack of 1&2 A+ -- Eric Pouech

Jan. 7, 2003

Re: Problem in dlls/ddraw/dsufrace/main.c

by Sylvain Petreolle

> It will crash in the AddRef code. Better to try to do something like > that : > > if (found == NULL) { > TRACE("Did not find any valid surface\n"); > *ppSurface = NULL; > return DD_OK; > } Thanks, I will try it. But with the test disabled, I get no crash in AddRef (??). See the following resuslts : trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface (0x402a9418)->Looking for caps: 4,0,1,1 output: 0x741ed0 Caps are : DDSCAPS_BACKBUFFER trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface Surface: (0x402a9b38) caps: 1000601c,0,0,0 Surface caps are : DDSCAPS_BACKBUFFER DDSCAPS_COMPLEX DDSCAPS_FLIP DDSCAPS_3DDEVICE DDSCAPS_VIDEOMEMORY DDSCAPS_LOCALVIDMEM trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface Returning surface 0x402a9b38 with description : - DDSD_CAPS : DDSCAPS_BACKBUFFER DDSCAPS_COMPLEX DDSCAPS_FLIP DDSCAPS_3DDEVICE DDSCAPS_VIDEOMEMORY DDSCAPS_LOCALVIDMEM - DDSD_HEIGHT : 480 - DDSD_WIDTH : 640 - DDSD_PITCH : 1280 - DDSD_LPSURFACE : 0x424b0000 - DDSD_PIXELFORMAT : ( DDPF_RGB , RGB bits: 16, R f800 G 07e0 B 001f) trace:ddraw:Main_DirectDrawSurface_AddRef (0x402a9b38)->(): increasing from 1 trace:ddraw:Main_DirectDrawSurface_AddAttachedSurface (0x402a9b38)->(0x402a90e8) trace:ddraw:Main_DirectDrawSurface_AddRef (0x402a90e8)->(): increasing from 1 The only err: that I get inddraw trace are unhandled dwRenderStateType. Argh, cant do it for now. > To be 100 %, the best would be for one to do a test in real Windows > and > check what happens when asking for a non-existant attached surface > and check > what happens (ie DD_OK with ppSurface being NULL or DDERR_NOTFOUND). > > > The reason I write is that : in fact, I disabled the failing test > and > > the game (Re-Volt Demo) begins to start. > > Well, as said before, try to see if this call SHOULD fail or if it's > a bug > that we do not find this attached surface. > > Even better would be to disassemble the code handling the return of > this > function to see what kind of stuff the game expects. > > Lionel > > -- > Lionel Ulmer - http://www.bbrox.org/ ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 7, 2003

Re: Graphic cards for Wine [/Linux;)]

by Sylvain Petreolle

--- brett holcomb <brettholcomb(a)charter.net> a écrit : > What version of Nvidia card and drivers are you running? > I've found my GF3 to be solid and stable. Tried with a Geforce 2, Geforce 2 MX and Geforce 4 MX from Sparkle. Drivers : always with the latest binariesthat be found on NVidia site. Yes I know they are XFree86 opensource drivers but they are slow for 3D. ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 7, 2003

Re: Web CVS annotation

by Eric Pouech

Shachar Shemesh wrote: > I'm not sure that's right, and I am sure that this is very unwanted. > > The reason I don't think this is right is that the rw access is required > in order to create a lock file. Allowing it will have several very bad > side effects. > > * Anyone who breaks into the web site will have instant write access > to the CVS - VERY BAD!!! > * The chances that, when Alexander runs "cvs ci", he will have to > wait for CVS locks to be cleared. > > Instead, running cvs annotate with the -n switch (i.e. - "cvs -n > annotate filename") doesn't create a lock file, and will probably not > require rw access. sure, the main issue we have is that winehq runs cvsweb as the web cvs frontend, and cvsweb only supports annotation under the condition I posted (IOW, it doesn't implement the annotate feature - on WWW side - with cvs annotate). But you're right on the constraints we get. so either check if a newer cvsweb implements annotate with cvs annotate, or we hack cvsweb to get what we want/need... A+ -- Eric Pouech

Jan. 7, 2003