May 2006 - Wine-Devel - list.winehq.org

Re: building win32/wine .exe's

by NikNot

On 5/30/06, Dan Kegel <dank(a)kegel.com> wrote: > Nik wrote: > > [I build my Windows apps on Win2k. How can I do it on Linux? > > winegcc doesn't seem the right way.] > ... > Or, if you can get away with using Mingw instead of Microsoft's compiler, > see http://www.winehq.com/site/docs/winedev-guide/cross-compiling-tests > for info about how to set up a mingw cross-compiler. Thank you Dan for your kind help. Indeed, as my "clover" example implies, our C programs are probably as straightforward as Win32 software gets, and we actually use both MS C and MinGW when we build them under Win2K/XP. One more question, if I may: where would I find an example of a makefile or shell script that uses MingW32 on Linux, once installed as your reference above suggests? Nik N.

May 30, 2006

Re: How are we doing?

by Dmitry Timoshkov

"Mike Hearn" <mike(a)plan99.net> wrote: > But most developers who come to Wine are not Windows developers, they > are Linux developers who want to run an app or game. Often finding the > bug is much harder than fixing it these days. It takes practice to > learn how to read a relay trace or debug a mysterious crash. I've quoted the whole e-mail, and it implied that the bug already has been found but a real fix was not clear. -- Dmitry.

May 30, 2006

Re: World of Warcraft (WoW) patch/more address space layout stuff

by Mike Hearn

> WoW Has a all chain of checks that go up all the way to rootkit reveler > to make sure the user is not aided by an automatic system, Given the > player an advantage other players do not have. The Memory layout checks > is for making sure the program is not loaded by a Debugger of sorts. Or > that core Dll(s) where not replaced/hooked/emulated. Yes, it could be the Warden, but I doubt it. If the Warden is triggered you get banned from the game yet this bug surfaces not as spurious bannings but some kind of mouse control/targetting problem. To be honest I'm amazed we haven't seen any reports of Wine triggering anti-cheat systems like Blizzards before, and I'm sure we'd hear about it if it did .... > It is possible that approaching Blizzard might be helpful. Is WoW > supported by Cedega? Yes, using a slightly more generic version of the same memory layout hack. thanks -mike

May 30, 2006

Re: How are we doing?

by Mike Hearn

On 5/30/06, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > I can't believe that writing a good test case showing the bug and adding > it to the Wine test harness is such hard thing to do for a good Windows > developer who already knows what he expects from a particular Win32 API. But most developers who come to Wine are not Windows developers, they are Linux developers who want to run an app or game. Often finding the bug is much harder than fixing it these days. It takes practice to learn how to read a relay trace or debug a mysterious crash. There is documentation showing how to do this with examples but I guess it could go further. > Once the test is in the Wine tree that becomes *much* easier to pinpoint > the bug and decide what is the real fix for it. Yes, sometimes. Some things are hard to show with unit tests. Consider the case of "I run my game and the audio glitches". It turned out that for some people that was due to scheduling problems and a fix is to use POSIX capabilities to add SetThreadPriority support to the wineserver. For somebody new to Wine that would be a very difficult problem to track down and fix, and hard to unit test. I agree that proving a problem using a test is a good way to start for many bugs however, especially message related ones. thanks -mike

May 30, 2006

Re: --without-opengl problems

by Stefan Dösinger

Am Montag, 29. Mai 2006 15:46 schrieb Jakob Eriksson: > Off-topic, has anyone run Wine with this? > http://bugle.sourceforge.net/ > > It checks OpenGL calls for validity. I use it sometimes to find out which calls WineD3D does to debug rendering problems. It's quite nice combined with wine traces

May 30, 2006

Re: World of Warcraft (WoW) patch/more address space layout stuff

by Boaz Harrosh

Mike Hearn wrote: > It's a bug in WoW itself, it relies upon the exact way NT maps memory > which is different to how Linux does it. I guess they are storing > information in the high bits of a pointer somewhere or some similar > trick. > One can never be sure, but I suspect this is not do to a bug but to a fixture. WoW Has a all chain of checks that go up all the way to rootkit reveler to make sure the user is not aided by an automatic system, Given the player an advantage other players do not have. The Memory layout checks is for making sure the program is not loaded by a Debugger of sorts. Or that core Dll(s) where not replaced/hooked/emulated. It is possible that approaching Blizzard might be helpful. Is WoW supported by Cedega? Free Life Boaz

May 30, 2006

Re: Set up wine-macosx? (Re: How are we doing?)

by Robert Shearman

Jim White wrote: >Jim White wrote in Darwine on 2006-05-24: > > >>Jeremy White wrote: >> >> >> >>>Speaking of a better way...is there any reason we couldn't shift >>>the bulk of this development work over to WineHQ and to the Wine >>>develoment mailing lists? That's where we do all of our work. >>> >>> >>... >>Of course, then you'll be subject to Alexandre's oppresive regime :-/. >> >>I don't have a problem with Alexandre. It's guys like Mike Hearn that >>give me heartburn... >> >> > >While I realize it was a long email, it's clear you got to the end. The >point of the email was to make a suggestion for action at WineHQ, >creating a wine-macosx mailing list, having provided a sound >justification for it. > I wouldn't object to a mailing list, but I would really like to see the Darwine developers using wine-devel for discussing all wine-connected development. P.S. Don't let the opinions of one person put you off wine-devel. As Alexandre as tried to make clear in the past, they don't represent the opinions of the majority of the people active on wine-devel. -- Rob Shearman

May 30, 2006

Re: Set up wine-macosx? (Re: How are we doing?)

by Jim White

Mike Hearn wrote: > Tell people they should work on a port to a platform they don't use and > you'll be told to do the work yourself. Dismissive? Maybe. Unexpected? I'd > hope not. I never told anyone they should work on anything. I've got an idea for a processor emulation technique to enable Intel Windows applications to run on PowerPC Mac OS X with high efficiency. My project plan to use Intel Darwin to port Wine (one of the necessary steps) has worked out beautifully. Did you notice it won the 2006 Sourceforge Community Choice Awards in the Desktop Environment category? I'm looking forward to Wine for Intel Mac OS X development moving to WineHQ so Darwine's focus can return to the interesting part. >>Lest you think I'm complaining here, I'm not. > > You clearly are complaining, there's no other way to describe it. Actually the only complaint I've made has been about you. I appreciate you making it clear to everyone who's got the attitude problem here. Jim White wrote in Darwine on 2006-05-24: > Jeremy White wrote: > >> Speaking of a better way...is there any reason we couldn't shift >> the bulk of this development work over to WineHQ and to the Wine >> develoment mailing lists? That's where we do all of our work. > ... > Of course, then you'll be subject to Alexandre's oppresive regime :-/. > > I don't have a problem with Alexandre. It's guys like Mike Hearn that > give me heartburn... While I realize it was a long email, it's clear you got to the end. The point of the email was to make a suggestion for action at WineHQ, creating a wine-macosx mailing list, having provided a sound justification for it. Jim

May 30, 2006

Re: How are we doing?

by Dmitry Timoshkov

"Mike Hearn" <mike(a)plan99.net> wrote: > Got a reply from somebody who would rather remain anonymous: > > --------------------------------------------------------------------- > > This may be just me, but the learning curve is probably much more > steep for a "general purpose" hacker than for a particular dll. I have > some apps I'd like to get working, but I find that the underlying > problems tend to take a long time to find, and when I do find them > they tend to fall into one of these categories: > -relatively simple to hack around, but difficult to really fix > -involves implementing or fixing something that's way beyond my skills > -it's unclear how to properly fix the problem > > None of those result in a patch. Usually they only will only result in > a bug report or (if it's something the developers are aware of) > nothing at all. On the other hand, I'm not really interested in > working on a particular dll; I just want my apps to run correctly on > wine with as little kludging around things as possible. > > --------------------------------------------------------------------- > > ... which is certainly true, it has a steep learning curve. But I think we > need more people doing such things :/ I can't believe that writing a good test case showing the bug and adding it to the Wine test harness is such hard thing to do for a good Windows developer who already knows what he expects from a particular Win32 API. Once the test is in the Wine tree that becomes *much* easier to pinpoint the bug and decide what is the real fix for it. -- Dmitry.

May 30, 2006

Re: Re: Wine 1.0 Tasks

by David Goodenough

fenix(a)club-internet.fr wrote: > Hi, > >>> (Note the #3902 should be renamed as 'DIB Engine rewrite' >> >>Agreed; done. http://bugs.winehq.org/show_bug.cgi?id=3902 > > :) > >>> and i don't think is mandatory for 1.0) >> >>Probably right. Let's create the next milestone after 1.0, say 1.1, and >>start >>retargeting bugs we don't plan to fix for 1.0. (That's what GCC does; >>some bugs they retarget early, some just before the release.) >> >>> But i think we must fix users most hated bugs as: >>> - dsound deadlocks/craps >>> - openGL problems (multi contexts, fb/visual configs) >>> - lotus problems >> >>The OpenGL child window bug, >>http://bugs.winehq.org/show_bug.cgi?id=2398 >>probably won't be fixed for 1.0 because it requires >>an X server change. > > No it must be doable without X changes > (But X additions as GLX_EXT_texture_from_pixmap will help a lot). > Only problem is to find time to fix it (as lionel, i have no time for > now). Anyway i having a simple and downloadable application to reproduce > this problem (not lightwave) must help. > > The only parts who really needs X change are for: > - glShareList: sharing fb/visual config between exitings GLX contexts > - dinput mouse management > >>I'm not sure lotus notes problems should block 1.0, as IBM has a native >>Linux client now, but if someone wants to fix them (especially the ones >>in usp10.dll netapi32.dll, that would be great. > > agree :) Not sure this is quite true. They are promising a native client for the next release of Notes, it is called Hannover, and it is built on the Eclipse Rich Client Platform in Java. But there is not one today that I am aware of. The next release is not due until early 2007 if I remember correctly. So it all depends on when 1.0 is due. David > >>> Note: it will be interesting to add user votes to wine-bugs (ala kde) to >>> better see user needs. >> >>There are already user votes in bugzilla, that should suffice. >>- Dan > > Oups i never seen it :) > > Regards, > Raphael

May 30, 2006