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

Re: How are we doing?

by Hans Leidekker

On Wednesday 31 May 2006 12:43, Kai Blin wrote: > that the whole process improves code quality. It still is hard in to get > started. Unfortunately I don't really know how this can be changed. I think we could focus more on the motivation aspects of becoming a Wine developer. Yes, you need specific technical skills but you also have to align with Wine's goals before you are willing to make an enduring effort. And it apparently also takes courage to invest in Wine, because of what Microsoft could do to hamper Wine. So if we can convince more people of the usefulness and legality of Wine we will attract more skilled developers. For example, we should stress the fact that Wine is a net gain for open source if it allows a user to switch from Windows to Linux, even though the program running on Wine is "proprietary Windows bloatware". We should even stress that Wine is a *temporary* solution in many scenario's, Wine is not a threat to a native ports! If Wine brings users to Linux it actually helps create a user base that in turn justifies the additional cost of a native port. At the same time we should think of exciting new possibilities that an open source implementation of the Windows API brings to the table. -Hans

May 31, 2006

Re: getuname: add stub implementation [try 2]

by Robert Shearman

Vitaly Lipatov wrote: >+/*********************************************************************** >+ * GetUName [ 2000 / XP ] >+ * >+ * undocumented fn: GetUName() >+ * The information is not available by API. The thing MS did >+ * here -- parsing the data from nameslist.txt in the Unicode Character >+ * Database (UCD). >+ * See >+ * http://groups.google.com/groups?hl=en&threadm=ODVecQBoBHA.2416%40tkmsftngp02 >+ * RETURNS >+ * unknown >+ */ >+void WINAPI GetUName(void) >+{ >+ FIXME("stub\n"); >+} > > You should add a test for this function and document at least the number of parameters of the function. Presumably it should take some parameters or return something, or the DLL is useless. If the former is incorrect then the stack will be trashed after the call. -- Rob Shearman

May 31, 2006

Re: getuname: add stub implementation [try 2]

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > +/*********************************************************************** > + * GetUName [ 2000 / XP ] > + * > + * undocumented fn: GetUName() > + * The information is not available by API. The thing MS did > + * here -- parsing the data from nameslist.txt in the Unicode Character > + * Database (UCD). > + * See > + * http://groups.google.com/groups?hl=en&threadm=ODVecQBoBHA.2416%40tkmsftngp02 > + * RETURNS > + * unknown > + */ > +void WINAPI GetUName(void) > +{ > + FIXME("stub\n"); > +} If you don't know the parameters you should leave the function as stub in the spec file, at least this way it will crash cleanly. Also you have to make the dll handle the PREATTACH value to prevent it from getting loaded if native is present. Look at how other stub dlls are doing it. -- Alexandre Julliard julliard(a)winehq.org

May 31, 2006

Re: urlmon: Use FindMimeFromData to determine MIME type.

by Jacek Caban

Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > > >> dlls/urlmon/binding.c | 25 ++++++++++++++++++++----- >> 1 files changed, 20 insertions(+), 5 deletions(-) >> > > This breaks the tests: > > ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so url.c && touch url.ok > url.c:401: Test failed: unexpected call OnProgress_MIMETYPEAVAILABLE > url.c:401: Test failed: unexpected call OnProgress_MIMETYPEAVAILABLE > make[1]: *** [url.ok] Error 2 > > Sorry, I forgot about one line. I'll send a correct version. Thanks, Jacek

May 31, 2006

Re: wine problems on a 64bit system

by Pavel Troller

> Hi Pavel, Hi Steven! > I've only slightly followed wine-devel recently > > Are you using a stock Fedora kernel? No. I'm using vanilla kernels just with exec-shield patch from Ingo Molnar. I'm not using any well-known distro. > They are all (x86-64) built with SMP support. My ones are also built with SMP support, because both the 64bit machines have dual-core CPUs. One of them is Pentium-D and the second is Dual Opteron. > Would it be possible to check with a custom built non-smp > kernel to see if you have the same behavior? OK. These machines build a kernel in 3 minutes, no problem to try to disable SMP and verify. However, the 32bit one is also SMP :-); it's MSI K7D Master board populated with 2 Athlons MP. It works perfectly and it's ideal for gaming, because one CPU handles Xserver and similar and the other runs the game :-). wine has no problems with it. > I've been looking in to > this matter myself but its been slow going because I lack a 64bit > system here. Can you run a strace on a winelib process and send us the > results with both the SMP and non-smp kernels? Will do. With regards, Pavel Troller

May 31, 2006

Re: file timestamps in a git tree

by Saulius Krasuckas

* On Wed, 31 May 2006, Marcus Meissner wrote: > * On Wed, May 31, 2006 at 12:55:02PM +0300, Saulius Krasuckas wrote: > > > > $ git rebase master ugly_hack ... > > $ git checkout master > > $ make > > Makefile is older than Makefile.in configure, please rerun ./configure > > make: *** [Makefile] Error 1 ... > > I thought git would reset all the file timestamps once I switch to > > another (master) branch... Am I wrong? > > "Makefile" is not in git, so you need to run ./configure anyway? Well, yes, but what is changed in the tree after I checkout master branch back? If nothing changes, why make is complaining?

May 31, 2006

Re: How are we doing?

by Kai Blin

* James Hawkins <truiken(a)gmail.com> [30/05/06, 18:32:37]: > > > > * Are we turning away potential developers for any reason? Could we do > > more to attract new hackers? > > > > It seems a lot of developers are frustrated by our development model > (one pathway to commit) and by the amount of effort it takes to get a > patch committed. I say too bad for them. We have a great devel model > that substantially reduces the amount of bugs and bad code getting > into CVS. I agree here. The effort to figure out how to do the patches correctly is pretty high, and you need a lot of frustration tolerance at first. I'm not sure if I would have stayed around if it wasn't for Summer of Code 2005. Once you get past this, and figured out how to write your code so Alexandre will commit it, development is quite fun. I also agree that the whole process improves code quality. It still is hard in to get started. Unfortunately I don't really know how this can be changed. I think that the effort by some of the more experienced coders to provide feedback to patches already helps a lot. Cheers, Kai -- Kai Blin, (blin at gmx dot net) Quit worrying about your health. It'll go away. -- Robert Orben

May 31, 2006

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

by Tim Kosse

Mike Hearn wrote: > Well if you can get the email address of a WoW developer then maybe we > can track down where the problem in WoW is and work with them to fix > it. You might have some luck contacting Sam Lantinga. He is the creator and current maintainer of the SDL library and works for Blizzard as WoW developer and, as far as I know, responsible for UI and scripting. According to his personal homepage, his mail address is slouken at devolution.com. In the SDL source I've also found slouken at libsdl.org Due to his interest in free open source software, he might be able to refer you further. Regards, Tim

May 31, 2006

Re: urlmon: Use FindMimeFromData to determine MIME type.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > dlls/urlmon/binding.c | 25 ++++++++++++++++++++----- > 1 files changed, 20 insertions(+), 5 deletions(-) This breaks the tests: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so url.c && touch url.ok url.c:401: Test failed: unexpected call OnProgress_MIMETYPEAVAILABLE url.c:401: Test failed: unexpected call OnProgress_MIMETYPEAVAILABLE make[1]: *** [url.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

May 31, 2006

file timestamps in a git tree

by Saulius Krasuckas

I make an ugly hack in a branch at my git tree. Then I run after following after some git updates: $ git rebase master ugly_hack $ make Makefile is older than Makefile.in configure, please rerun ./configure make: *** [Makefile] Error 1 $ git checkout master $ make Makefile is older than Makefile.in configure, please rerun ./configure make: *** [Makefile] Error 1 Is this behaviour intended? I thought git would reset all the file timestamps once I switch to another (master) branch... Am I wrong?

May 31, 2006