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

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

by Mike Hearn

Ditto, was there something wrong with this one? > Mike Hearn <mike_at_navi.cx> > Don't fall back to OSS when Drivers="" > > --- dlls/winmm/lolvldrv.c.~1.58.~ 2004-06-01 20:40:48.000000000 +0100 > +++ dlls/winmm/lolvldrv.c 2004-08-03 22:01:16.795976000 +0100 > @@ -731,6 +731,9 @@ > size = sizeof(buffer); > if (!RegQueryValueExA(hKey, "Drivers", 0, &type, (LPVOID)buffer, &size)) { > p1 = buffer; > + > + if (!*p1) return TRUE; /* if Drivers="" don't load sound */ > + > while (p1) { > p2 = strchr(p1, ';'); > if (p2) *p2++ = '\0';

Aug. 25, 2004

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

by Mike Hearn

Hi Alexandre, 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. There's not much reason to run the entire winetest binary on Wine itself, so why do we always build it ? thanks -mike > Mike Hearn <mike_at_navi.cx> > Don't compile winetest as part of the main build to avoid > problems on low memory machines. > > --- programs/winetest/Makefile.in.~1.30.~ 2004-07-22 20:43:42.000000000 +0100 > +++ programs/winetest/Makefile.in 2004-08-01 23:44:24.334453984 +0100 > @@ -1,3 +1,7 @@ > +# MKPROG_SKIP > + > +# This program must be built explicitly to make compiles on slower machines easier > + > TOPSRCDIR = @top_srcdir@ > TOPOBJDIR = ../.. > SRCDIR = @srcdir@

Aug. 25, 2004

Re: poll vs. epoll

by Mike Hearn

> Maybe he's referring to the case where libc.so doesn't have > the epoll bindings, but the underlying kernel does? Oh yes, I bet that's it. I never really thought about that before but I guess there's no reason why libc would always support every feature of the kernel. Thanks Dan!

Aug. 25, 2004

Re: Wine Emulation: Swapping functions

by Pierre d'Herbemont

Alexandre, As a conclusion, would accept that we swap (using the regular way) the headers in order to load exe on a Big Endian host? (since the exe headers are Little Endian for each NT implementation) Pierre PS : the exe header is Little Endian even on a PowerPC NT exe, since the PowerPC NT implementation was actually running on Little Endian mode, so we won't be able to run PowerPC NT exe on Mac OS X.

Aug. 25, 2004

Re: Wine Emulation: Swapping functions

by Pierre d'Herbemont

From the limited experience I have the problem is that if a portion of code expect to have a certain type of endianness, it would make some special assumption, we won't be able to track out (See [1]). And it will be even harder to track the issues for the x86 already compiled code, in Wine we can for instance track the specific function that cause troubles and replace it with safer functions (see strcmp, strlen...). Finally I think we should only relay on call conversion, and that my swapping on-the-fly technics is not sure enough to be applied here. Pierre. [1] http://stegefin.free.fr/wine/ On 25 août 04, at 14:37, Pablo Bendersky wrote: > Not sure if what I'm thinking would even work, but let's mention it. > Could we add the swapping to qemu? We would end up with a x86 > emulation that used big endian instead of little endian. > This way, all memory accesses (from the wine api) would end up > unswapped, while the method calls from the .exe files would be swapped > (as they will be emulated). > Is this a viable alternative? > > On Wed, 25 Aug 2004 13:32:22 +0200, Pierre d'Herbemont > <stegefin(a)free.fr> wrote: >> >> On 24 août 04, at 22:50, Alexandre Julliard wrote: >> >>> "Pierre d'Herbemont" <stegefin(a)free.fr> writes: >>> >>>> Hi Alexandre, >>>> >>>> This patch allows to load a PE exe to memory. You may notice that >>>> there is no "mass" byte swapping. The technics used here is a bit >>>> developer here: >>>> http://stegefin.free.fr/wine/ >>>> You might prefer a more conventional way of doing the byte swapping, >>>> in this case tell me. We might still need this approach since it >>>> could >>>> efficient for sharing data accross the LE exe and the BE winelib. >>> >>> It doesn't seem very efficient to trap on every memory access... >>> Besides, I don't see how this can possibly work, there is no >>> guarantee >>> that the compiler is going to generate accesses that always match the >>> size of the requested type, memcpy() being the obvious example. >> >> I agree. though memcpy would need a wrapper which would set the dest >> memory region to litlle endian, but we are coming to the limitation of >> this method. >> >>> I think you are going in the wrong direction with this; the right way >>> IMO is to compile Wine for x86 and run the whole Wine+app under the >>> CPU emulator. Otherwise you'll have to write wrappers for each of the >>> 15,000 APIs. >> >> I agree it is easier, but as mike pointed we can't easily access OS X >> API, though I am sure there is a way. Anyway I would like to give the >> emulation inside method a try. I think using automatically generated >> wrapper can work for most APIs. For sure it won't be easy but I think >> there is hope in succeeding. I'll also try to add to qemu the >> darwin-user target, so we can see the limitation of going this way ;) >> >> Pierre. >> >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >> _______________________________________________ >> Darwine-devel mailing list >> Darwine-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/darwine-devel >> > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Darwine-devel mailing list > Darwine-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/darwine-devel

Aug. 25, 2004

Re: poll vs. epoll

by Dan Kegel

Mike Hearn wrote: >> That's fine, except that compiling your library on a machine that has >> epoll, and then trying to run it on a machine without will not work. >> It will not load if runtime glibc doesn't have epoll. I'm using >> "syscall" to work around that problem in wine. > > > Why not use dlopen? Maybe he's referring to the case where libc.so doesn't have the epoll bindings, but the underlying kernel does? - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

Aug. 25, 2004

Re: [Darwine] Re: Wine Emulation: Swapping functions

by Mike Hearn

> I agree that flipping the syscalls is a much more promising approach > than the WIN32 API. I'm also thinking that there is bound to be some > relevant code around aleady (perhaps even in QEMU). Yes QEMU can do syscall conversion iirc, at least in some modes. > While the current phase of the Darwine effort is concerned with making > something that works, naturally performance is an important issue. In > fact one of the architectural motivations for Darwine is that it will be > able to achieve much higher performance than approaches that virtualize > the OS (in addition to the objectives of not having to run Windows). I don't think you could get much higher performance than eg, Virtual PC to be honest. Maybe if you developed some way of pre-converting the binaries beforehand rather than doing it on the fly, but VPC type systems have the advantage of having very limited interaction points between the host OS and the client OS which can be tightly optimized (eg, video ram), so they can perform a lot of tricks you can't do if you want to integrate better with the OS. > > I think they were only converting the syscalls but I don't really > > remember .... Gav told me various stories of their Mac porting efforts > > at WineConf. > > It would be interesting to chat with those folks indeed. I take it that > given that their product is dependent on Wine, which is GPL, the > relevant code which enables it to run on Mac OS X must be available as > well? That would dramatically simplify what we need to do! Please do some basic research, otherwise you just come off sounding ignorant: a) Wine is not under the GPL and never was, it's under the LGPL 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. d) Quite a few of TransGamings porting projects don't seem to involve Wine at any level. For instance Gav told me about a game they ported which used Java. Intererestingly, I think Gav thought the Java port was *harder* than Wine ports were due to the huge instability of Java on the Mac platform. He said at one point Apple pushed out an online update to Java which broke their game and then withdrew it, leaving no way for them to duplicate the environment that their customers were having problems with (amongst other problems)! So much for "write once, run anywhere" ... > Hmmm, not sure what you mean there. Initially we patched winegcc to > make the OS X API accessible, but at Alexandre's suggestion to Pierre > we've switched to binding to the symbols dynamically. Of course using > the native Carbon API is necessary, otherwise we're stuck in the X11 box > which is as foreign to the Mac user as having Windows running via VPC. You realise that a quartzdrv would not change the fact that Windows apps look like Windows apps, right? All it changes is the way the bits drawn by Wine get to the screen. To be honest I think you'd achieve much better results by improving the quartzwm so X11 windows integrate better with the dock etc. If quartzwm is proprietary (don't recall) then writing a new WM that is equivalent and has all the features you need would be another way forward. While it's interesting from a technical perspective to do a quartzdrv, I'm really not convinced you would get better integration than just improving the X11 support in the OS, which would obviously also benefit those who use Linux/X11 apps on the Mac as well as Wine users. Anyway .. what I meant by that statement is that if you're running x86 Wine in QEMU you can't access the Carbon APIs directly. I think in the mode where you run foreign binaries QEMU will perform syscall conversion but obviously this is of limited use - the OS X APIs aren't accessible via syscalls. One thing you could do I guess is expose each OS X API that you wanted as a new "fake" syscall and then use a customized version of QEMU that converted it into a Mac API call, ie marshal the calls in and out of the emulated environment. You'd still pay a performance penalty but that's unavoidable. I'm not sure how you'd deal with callbacks.

Aug. 25, 2004

Re: [Darwine] Re: Wine Emulation: Swapping functions

by Pablo Bendersky

Not sure if what I'm thinking would even work, but let's mention it. Could we add the swapping to qemu? We would end up with a x86 emulation that used big endian instead of little endian. This way, all memory accesses (from the wine api) would end up unswapped, while the method calls from the .exe files would be swapped (as they will be emulated). Is this a viable alternative? On Wed, 25 Aug 2004 13:32:22 +0200, Pierre d'Herbemont <stegefin(a)free.fr> wrote: > > On 24 août 04, at 22:50, Alexandre Julliard wrote: > > > "Pierre d'Herbemont" <stegefin(a)free.fr> writes: > > > >> Hi Alexandre, > >> > >> This patch allows to load a PE exe to memory. You may notice that > >> there is no "mass" byte swapping. The technics used here is a bit > >> developer here: > >> http://stegefin.free.fr/wine/ > >> You might prefer a more conventional way of doing the byte swapping, > >> in this case tell me. We might still need this approach since it could > >> efficient for sharing data accross the LE exe and the BE winelib. > > > > It doesn't seem very efficient to trap on every memory access... > > Besides, I don't see how this can possibly work, there is no guarantee > > that the compiler is going to generate accesses that always match the > > size of the requested type, memcpy() being the obvious example. > > I agree. though memcpy would need a wrapper which would set the dest > memory region to litlle endian, but we are coming to the limitation of > this method. > > > I think you are going in the wrong direction with this; the right way > > IMO is to compile Wine for x86 and run the whole Wine+app under the > > CPU emulator. Otherwise you'll have to write wrappers for each of the > > 15,000 APIs. > > I agree it is easier, but as mike pointed we can't easily access OS X > API, though I am sure there is a way. Anyway I would like to give the > emulation inside method a try. I think using automatically generated > wrapper can work for most APIs. For sure it won't be easy but I think > there is hope in succeeding. I'll also try to add to qemu the > darwin-user target, so we can see the limitation of going this way ;) > > Pierre. > > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Darwine-devel mailing list > Darwine-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/darwine-devel >

Aug. 25, 2004

Re: USB?

by Uwe Bonnes

>>>>> "Alex" == Alex Zeiger <zeiger(a)nospam.snowbird.net> writes: Alex> I'm interested in possibly working on USB support for Wine. I'm Alex> not particularly familiar with USB programming, but I'm fluent in Alex> C and C++. Where do I start? Maybe http://www.lvr.com/usb.htm#HostSoftware has some usefull references. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 25, 2004

Re: Get rid of W->A calls : help me help ?

by James Hawkins

Hey Joris, I started developing wine in exactly the same way you are starting: working on the janitorial projects. My current project is converting the crypt cross calls, and it is almost finished, but im waiting for my CryptSetProviderExA patch to be committed before I send the rest of my cross call cleanup patches. If you would like I can write a little howto concerning W->A cross call cleanup and the like (unit tests). There are a bunch of little nitpicky things you just have to know before you can really start cracking in on it...a while back i tried to submit a cleanup patch like 6 times and it was reject everytime because I didnt know the details yet. So if you would like this information, let me know. We're glad you're here to help with wine. On Wed, 25 Aug 2004 11:01:09 +0100, Mike Hearn <m.hearn(a)signal.qinetiq.com> wrote: > Joris Huizer wrote: > > Hello, > > > > I'm thinking of trying to do some helpfull work on wine; > > Cool! > > > I have the following problem, > > - I don't know where to start (I have never done stuff in wine or > > another open source project) ; but I hope you have patience to guide me > > into that (but I'm a informatica student, I like learning stuff like > > htis ;) ) > > Well, you can do lots of things. You could sit down and try and make > apps work, which is fun and rewarding but has a STEEP learning curve, or > you can tackle the janitorial tasks (like you said), or you can hack on > the tools we use like the debugger/test suite, or you can work on ease > of use issues and desktop integration. There's a ton of things, really. > > Most people hack on making particular applications they like work. > > > - I don't know the details about Unicode functions; > > > > I think the W->A thing of the janitorial might be a great way to start > > working in wine code; as it doesn't require too much overview about the > > way wine does its work I think.. (and I don't yet have much of that > > overview..) > > I've started work about a week ago on a "Wine developer cheatsheet" that > covers the basics like important debugging channels, how to use the > debugger, some basic Win32 API guidance and so on. I'll publish it here > in a week or two. > > thanks -mike > > -- James Hawkins

Aug. 25, 2004