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

Re: Don't compile winetest as part of the main build

by Saulius Krasuckas

On Thu, 26 Aug 2004, Rein Klazes wrote: > On Wed, 25 Aug 2004 16:04:52 +0100, you wrote: > > Was this dropped? On my laptop (a 600mhz Pentium with 128mb of ram, so > > not too pokey) attempting to build the winetest binary actually kills > > the build dead. It ends up attempting to feed ~20mb of data to gas which > > doesn't make it very happy. I guess I misphrased it - it's not for > > slower machines, it's for machines with less memory. > > I have recently built wine on a P1-133 with 64MB of memory (with > success). > You should never be out of memory with enough swap. In my case it is a free space on the "/" filesystem which I get running out of. Knowing the fact I like to live with a very small amount of a free space on the "/" I should complain only to myself. On Wed, 25 Aug 2004, Alexandre Julliard wrote: > Mike Hearn <m.hearn(a)signal.qinetiq.com> writes: > > There's not much reason to run the entire winetest binary on Wine > > itself, so why do we always build it ? > > Because code that doesn't get built rots very quickly. You can disable > it in your tree, but the default should be to build it. And how exactly can I disable it? By editing wineinstall script?

Aug. 26, 2004

Re: Don't compile winetest as part of the main build

by Mike Hearn

> And how exactly can I disable it? By editing wineinstall script? Nah, just do what I did. There's a magic command you can put at the top of the makefile which leaves it out: look at the patch to see how to do it. Then run ./config.status and winetest will no longer be built.

Aug. 26, 2004

Re: runtime change to WINEDEBUG output

by Mike Hearn

James Hawkins wrote: > Oh ok thanks Rob I'll try it out. I tend to find piping stuff through sed is too slow (but then I have quite a slow computer). There is a patch floating around in the archives that lets you toggle debug logging on and off using the F12 key. It works at the level of the debug infrastructure itself so the app speeds up noticeably when it's not doing lots of printfs. It may have bitrotted. Alexandre wouldn't apply it, as it put policy into the Wine core (at least, if I remember correctly). FWIW I usually find +all traces give too much output for debugging anything other than startup problems where you have no idea what's wrong. Beyond a few seconds execution the logs get too big to work with, especially if you're working blind.

Aug. 26, 2004

Re: X86/PPC linking (was Re: [Darwine] Re: Wine Emulation: Swapping functions)

by Mike Hearn

>> b) TransGamings Cedega forked from Wine several years ago, back when >> it was under the X11 license which allowed that. So they don't have to >> contribute their code back. >> c) That fork was what motivated the switch to LGPL. > > > Well that makes sense. I couldn't make heads or tails of their > licensing. Although it does say something about the Wine of WineX 2 > being LGPL. In any case it seemed clear that whatever they had is not > free. Also I can't see why they would want to do any X86 emulation at > all since games do usually need maximum performance. I have to figure > that they are using Winelib. Parts of it are LGPLd, parts are X11d and parts are under the AFPL. What license things are under is pretty important you know. > That was indeed true before OS X. Typically ironic/tragic of Apple that > the machines most in need of WORA had lousy Java. Fortunately on OS X > the Java is at least as good and in some cases (such as Swing > performance) is better than on Windows. No, TransGaming has only ever worked with OS X. I'm afraid these stories were about quite recent behaviour (last two years or so). > This is another area that integration opens up for innovation. No it doesn't. If you want native theming you'd have to implement a UXTHEME bridge to appearance manager. X11/Quartz is orthogonal to this issue. > Of course even so, as I said to begin with, such driver layering is > devastating to performance and any hope of order-of-magnitude speed up. The truly graphics performance critical parts for games and such go via DGA/GL anyway, so I'm not convinced about that. It's like saying X11 on Windows can't possibly beat X11 on Linux because it has to go via the GDI, yet it can sometimes happen. > The ideal method would be to handle this with a trick loader that can > link to PPC code which is escaped from the X86 emulation. We can > automatically generate X86 DLLs for the PPC dynamic libraries (and hence > the OS X APIs) which have little emulation escape thunks in them. There > is zero performance penalty since the emulator can compile such escapes > as direct native calls. Callbacks use a similar sort of little thunk > which calls the emulator with a given X86 address. > I would really like to get away from having to write all the little > wrappers to deal with the namespace problem. I believe we can solve > that with a suitable naming convention as we began to do with the > winegcc patch. In order to write such thunks you would need a type description of the entire Windows API, as pointed out by Rob. Generating this in a usable form from the headers would be incredibly hard. > Alternatively we could go with with dynamic binding as proposed by > Alexandre and have a syscall (or emulation escape) to call PPC code. > This is probably the easiest to implement but leaves us with extra call > overhead (although apparently this is something that is currently done > in Wine and is quite small). Well more to the point it means you're emulating both the app and Wine, which won't be performant. > As for swapping functions, the preceding discussion reiterates my belief > that we should confine such fussy business to the relatively small bit > of code that calls into OS X, will be relatively stable over the long > haul, and over which we have full control. And as for the concern over > having Wine be X86 and hence incurring emulation overhead, this would be > one of the first bits of code which would be a candidate for having its > emulator-compiled code cached. If you look at how many native imports Wine requires on Linux to get full functionality I don't think you can say it's relatively small. It's many thousands of functions, possibly more. It's hard to measure because so much is dynamically loaded.

Aug. 26, 2004

Re: Don't compile winetest as part of the main build

by Mike Hearn

> I have a 500 mhz laptop with 128 mv of ram, and winetest builds quite > successfully, so maybe it's something wrong with > your build toolchain, or your configuration, or something else like that? Maybe, yes. How long does it take? I think I killed it after about 5 minutes of constant thrashing. Possibly it's something to do with using the FC2 kernel instead of a stock one ?

Aug. 26, 2004

Re: Don't compile winetest as part of the main build

by Rein Klazes

On Wed, 25 Aug 2004 16:04:52 +0100, you wrote: > Was this dropped? On my laptop (a 600mhz Pentium with 128mb of ram, so > not too pokey) attempting to build the winetest binary actually kills > the build dead. It ends up attempting to feed ~20mb of data to gas which > doesn't make it very happy. I guess I misphrased it - it's not for > slower machines, it's for machines with less memory. I have recently built wine on a P1-133 with 64MB of memory (with success). You should never be out of memory with enough swap. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Aug. 26, 2004

Re: Don't fall back to OSS when Drivers=""

by Mike Hearn

> Not sure I see the point, could you please elaborate on what you are > trying to achieve here? Setting Drivers="" in the config file is supposed to prevent sound from being used at all - there are actually howtos and such on the net that say this and it's sometimes given as tech support advice, so I assumed it worked. But, it doesn't seem to - Drivers="" always causes wineoss.drv to be loaded instead. So this patch lets you to make the app think there are no sound cards in the machine.

Aug. 26, 2004

Re: Simple bugzilla question

by Ivan Leo Puoti

> Do I put the bug in fixed state and submit the patch or leave that > change to the raised? I suppose you can submit the patch, and change the bug status to fixed once the patch is committed. Ivan.

Aug. 26, 2004

Re: Don't compile winetest as part of the main build

by Ivan Leo Puoti

> On my laptop (a 600mhz Pentium with 128mb of ram, so > not too pokey) attempting to build the winetest binary actually kills > the build dead. I have a 500 mhz laptop with 128 mv of ram, and winetest builds quite successfully, so maybe it's something wrong with your build toolchain, or your configuration, or something else like that? Ivan.

Aug. 26, 2004

Re: runtime change to WINEDEBUG output

by James Hawkins

Oh ok thanks Rob I'll try it out. On Thu, 26 Aug 2004 01:49:41 +0100, Robert Shearman <rob(a)codeweavers.com> wrote: > James Hawkins wrote: > > >I ran WINEDEBUG=trace+all wine setup.exe 2>&1 | sed '1,/Debug mark/d' > >in the terminal, and all of the debug output is being displayed > >already without selecting the "Put..log" option. I switched > >"Managed" to "N" at Vincent's suggestion. Any ideas? > > > > > Try this instead: > > WINEDEBUG=trace+all wine setup.exe 2>&1 | sed '1,/Debug mark requested/d' > > It then shouldn't match against a call to the menu functions that put > the debug log option into the system menu. > > Rob > > -- James Hawkins

Aug. 25, 2004