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

Something broke winetest?

by Paul Millar

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Looks like something broke building cross-compiled tests last night. I now get: [paulm(a)quisquiliae tests]$ make i686-mingw32msvc-gcc dpa.o imagelist.o subclass.o tab.o testlist.o -o comctl32_test.exe -lcomctl32 -luser32 -lgdi32 imagelist.o(.text+0x1077): In function `DoTest3': /home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:265: undefined reference to `ImageList_DrawIndirect(a)4' imagelist.o(.text+0x10b7):/home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:267: undefined reference to `ImageList_DrawIndirect(a)4' imagelist.o(.text+0x10f6):/home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:269: undefined reference to `ImageList_DrawIndirect(a)4' imagelist.o(.text+0x1132):/home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:271: undefined reference to `ImageList_DrawIndirect(a)4' imagelist.o(.text+0x1186):/home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:277: undefined reference to `ImageList_DrawIndirect(a)4' imagelist.o(.text+0x11ba):/home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:279: more undefined references to `ImageList_DrawIndirect(a)4' follow distcc[21076] ERROR: compile on localhost failed make: *** [comctl32_test.exe] Error 1 [paulm(a)quisquiliae tests]$ Which causes comctl32_test.exe not to be built, so the build of winetest.exe fails. Do others get this too? Cheers, Paul. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBLIJM/9JwS78PA+kRAjN+AKCUTBxmUZlJQnPvUKZWuM2n8rGBVgCaA7Wz qE5hC6AGHcijndK6umrZygQ= =vivD -----END PGP SIGNATURE-----

Aug. 25, 2004

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

by Jim White

Mike Hearn wrote: >> 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. > > Certainly dealing with the syscalls alone is a lot easier than flipping > on every Windows API. You may wish to talk to TransGaming. They've > actually *done* what you guys are trying to do, and run x86 > software/games on a Mac. IIRC they found it unworkable (due to > endianness conversion) even when using virtualization software more > advanced than QEMU, however they were focussing on games where > performance is critical. So maybe it doesn't matter to you guys. 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). 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 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! > The problem with running x86 Wine in QEMU is that it's harder to access > the OS X APIs. I guess you could use some kind of IPC to do it but you'd > end up recreating the X protocol for Quartz which seems a bit silly > (amongst other things). 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. Jim White

Aug. 25, 2004

Re: Wine Emulation: Swapping functions

by Pierre d'Herbemont

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.

Aug. 25, 2004

Re: Non-perfect epoll patch

by Mike McCormack

Shachar Shemesh wrote: > Hi all, > > Attached is a non-perfect patch for review. This is a migration of the > wineserver to use epoll instead of poll (if it's available). > > current known issue with this patch: > 1. Will not compile if HAVE_SYS_EPOLL_H is not 1 (i.e. - won't compile > if epoll not available at compile time) > 2. Segfaults on wine exit. > 3. Lots of debug asserts. > > Comments welcome. > Shachar If you're going to use syscalls instead of epoll_create etc, then you don't need to check whether epoll functions exist in glibc, since you're not using them anyway. In any case, seeing that getting your patch accepted will take some effort, it's probably a good idea to use the glibc version functions first, and deal with the problem of missing epoll functions in older glibcs in a seperate patch. Mike

Aug. 25, 2004

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

by Mike Hearn

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

Aug. 25, 2004

Re: Wine Emulation: Swapping functions

by Mike Hearn

> 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. Certainly dealing with the syscalls alone is a lot easier than flipping on every Windows API. You may wish to talk to TransGaming. They've actually *done* what you guys are trying to do, and run x86 software/games on a Mac. IIRC they found it unworkable (due to endianness conversion) even when using virtualization software more advanced than QEMU, however they were focussing on games where performance is critical. So maybe it doesn't matter to you guys. 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. The problem with running x86 Wine in QEMU is that it's harder to access the OS X APIs. I guess you could use some kind of IPC to do it but you'd end up recreating the X protocol for Quartz which seems a bit silly (amongst other things).

Aug. 25, 2004

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

by Joris Huizer

Hello, I'm thinking of trying to do some helpfull work on wine; 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 ;) ) - 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..) About a month ago, I saw a thread, including an interesting patch, about the W->A calls; Could someone find that link? Are there tutorials/manuals/guides/... about Unicode funcitons you recommend ? Now, on to the work: if you can hand me that thread, how do I start? Are there unit tests? Where should I put tests ..? How do I run the tests? Thanks for any help -- I hope it's not too much trouble to answer these questions! Oh.. and if the W->A thing is already covered.. is there some other area where a starter like me could start? regards, Joris

Aug. 25, 2004

Re: poll vs. epoll

by Mike Hearn

> 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?

Aug. 25, 2004

Re: poll vs. epoll

by Shachar Shemesh

Dan Kegel wrote: > Shachar Shemesh wrote: > >>> Now don't go and do level-triggered stuff just because it's easier :-) >>> >> That's not it at all, and edge vs. level is not part of my >> considerations. Libevent does support a wider variety of selection >> interfaces, and with wider platform support, than your library. > > > Don't get me wrong. Libevent is good stuff. Niels is a very good guy. > I don't think platform support is an issue (which platform do you need?) We are trying to have as wide support as we can, obviously. > The one interface rn is missing, I think, is a timer. Which wineserver needs. > Buffered events would be a fine addition, too. > But rn has the basic notification stuff; it was intended to focus on > those. But then why NOT use libevent :-) If you are really itching, why not just add edge trigger to libevent? >> The more I think about it, the more I'm getting the impression that >> going edge trigger means we need to maintain our own cache of >> not-yet-useful data > > The same cache is maintained in the kernel for you if you use level > triggering. True, but that does save me on writing and debugging. After all, that's why libraries are there for to begin with. Also, it would seem to me that keeping data in the fd cache until it's actually needed saves on copies. Isn't that the case? >> Also, can you show me how to do edge trigger via poll? > > > There is no need for that, since Linux and *BSD all support some > form of edge-triggered notification. For Linux platforms prior to epoll, what's there? >> I'll qualify the starvation claim. >> >> Suppose we have five fds we are watching. Suppose one (let's call it >> "3") of them is really really intensive in it's request rate. Using >> the current interface (as used in the preliminary patch I sent), each >> time we call epoll we will see that 3 is active, but any time any >> other fd has anything to do, it will be handled. >> >> Suppose we go edge triggered now. We call epoll, and it's likely that >> 3 will be the only one active. We will call the 3 handling function, >> which will try to exhaust the requests arriving on 3 before >> returning. No it's a problem - requests potentially are never >> exhausted on 3. When do we exit the handler to do other stuff? We >> would need to write some mechanism to introduce this fairness ourselves. > > > Yes, but that's easy. It's about four lines of code. I'm sure it is. So is managing the buffers etc. Thing is - why go into it at all if the difference is small? As an aside I'll mention that I'd like to see those four lines :-) > What's this about partial memory buffering? Sounds like you're inventing > a difficulty here. It may be that I'm referring to a difficulty that also exists in the usual case. I'm talking about half received "packets" of information on stream entities (such as TCP sockets and pipes). > - Dan Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 25, 2004

RE: iostream and msvcrt?

by Scott Snell

Hi Boaz, Have been off the case for a few days. Is it possible for you to post a copy of your stl_wine.h, stlcomp.h and makefile? I seem to be missing something as I cant get it to work. thanks, Scott. > -----Original Message----- > From: Boaz Harrosh [SMTP:boaz(a)hishome.net] > Sent: Sunday, 22 August 2004 22:18 > To: Scott Snell > Cc: Dimitrie O. Paun; Wine-Devel (E-mail) > Subject: Re: iostream and msvcrt? > > You need to have your stlport/config/stl_wine.h (I based mine on > stl_mycomp.h, not stl_gcc.h) and change /stlport/config/stlcomp.h to > include it (based on a WINE_GCC flag). You need to do that because of > the way STLPort works with headers. you must put a path that will > Definitely select wine/msvcrt as the source of stdc. I used ../msvcrt in > the header and than Just fixed up the -I list in makefiles (and the > WINE_GCC flag or is there a flag that is defined by wingcc). > > Free Life > Boaz >

Aug. 25, 2004