June 2008 - Wine-Devel - list.winehq.org

Re: user32: Handle GetTextMetricsW failure in get_text_metr_size
by Dmitry Timoshkov June 14, 2008

June 14, 2008

"Roy Shea" <royshea(a)gmail.com> wrote: > Initializes the tmHeight field of the TEXTMETRICW used by callers of > get_text_metr_size, even when calls to GetTextMetricsW fail. This fix > remedies the Valgrind errors of the form "normalize_nonclientmetrics > (sysparams.c:1043)" found throughout the advpack test suite. GetTextMetricsW should never fail. You need to find a reason of a failure. -- Dmitry.

1 0

Wine-1.0 release notes
by Vitaliy Margolen June 14, 2008

June 14, 2008

Since all of the 1.0 blocker bugs being pushed back, wine-1.0 release notes should list all of those as major known problems. Otherwise people will get a bad impression that wine-1.0 means more then less working release. Also release notes should mention that wine-1.0 is not suitable for most games (new or old) for numerous reasons, including video driver bugs, sound and video conflicts with default system setups, unavailability of required features from X server etc. And that wine-1.0 will not work at all for majority of people using other then default input methods. In short - that after everyone's hard work and 15 years of development wine-1.0 is just a release tag nothing more. Vitaliy.

7 15

twinview and user32/tests/monitor.c
by Dan Kegel June 13, 2008

June 13, 2008

My workstation was failing a test because it didn't have a 640x480 display mode. Turned out it was how the dual monitor support was configured, and changing a line in /etc/X11/xorg.conf from Option "MetaModes" "2560x1600,2560x1600; 1920x1200,1920x1200; 1600x1200,1600x1200; 1280x1024,1280x1024" to Option "MetaModes" "2560x1600,2560x1600; 1920x1200,1920x1200; 1600x1200,1600x1200; 1280x1024,1280x1024; 640x480,NULL" made the test happy. Probably not worth worrying about changing the test to expect crazy configurations like this...

1 1

Handy valgrind tips
by Dan Kegel June 13, 2008

June 13, 2008

I've started collecting tips about how to track down wine bugs using valgrind; they're at the bottom of http://wiki.winehq.org/Wine_and_Valgrind There are two right now (about building wine with -O0, and about using WINEDEBUG to flush out undefined values into the open). Share and enjoy...

1 0

-O0 nearly twice as fast to build as -O2
by Dan Kegel June 13, 2008

June 13, 2008

OK, this was confusing. I was getting repeatable five minute builds, i.e. "make clean; reboot; time make -j3" (more or less :-) was reliably showing five minutes wall clock time. Then I did "make distclean; ./configure; make depend". After that, I got repeatable nine minute builds, i.e. make clean; reboot; time make -j3 was showing nine minute wall clock time. Turns out, the difference was... I had been building without optimization. So configuring with CFLAGS="-g -O0" is almost a 2x speedup! This is with gcc-4.2.3. Might be handy to know when doing regressions.

4 5

Time to update Wine's status?
by Adam Petaccia June 13, 2008

June 13, 2008

http://winehq.org/site/status is the website showing Wine's status on implementing various DLLs, but it hasn't been updated in almost a year! The information is not only old, but Wine has added new DLLs that aren't listed. With Wine approaching its 1.0 release, perhaps it should be decided to update or remove the page. My vote would be for updating, but I'm not sure where those stats come from, and that may take away from time better spent on bug hunting. -- Adam Petaccia <adam(a)tpetaccia.com>

4 5

Re: [AppDB] application: Only show 'submitter' column when processing queued entries
by Edwin Smulders June 13, 2008

June 13, 2008

I'm not exactly sure where this removes the submitter column, but if this is on the test results page, please keep it as it is, I find it useful info, in multiple ways. One way is as a maintainer, being able to sort through the results, and one is as a user, being able to see which test results came from the maintainer of the app himself (i usually find these more accurate). Just a thought, and disregard this if it is not about this column but some other column :) On Fri, Jun 13, 2008 at 12:13 AM, Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> wrote: > That info is not very interesting for people browsing the database. > > > Alexander N. Sørnes > > > >

1 0

msvcrt and gcc-c++ header conflicts
by Praveenkumar Ponnusamy June 13, 2008

June 13, 2008

Hello Wine Developers- I am trying to compile a windows project on Linux using winemaker and I'm stuck with a problem and was wondering if any of you have encountered it before or have any suggestions. In some of the compilation units in my project, I am using std::ofstream that is defined in the "fstream" header file and included as #include <fstream>. Since wine does not provide this header file, the one provided by gcc is used by the wine compiler -- which in turn includes quite a few headers of its own. A number of symbols defined in these headers conflict with the ones provided by wine and produce compiler errors such as these: In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cwchar:52, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/postypes.h:47, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/iosfwd:47, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ios:44, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/istream:45, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/fstream:45, from /home/praveen/wine-projects/myProject/tengine.h:25, from /home/praveen/wine-projects/myProject/teassembly.h:19, from teassembly.cpp:17: /usr/include/wchar.h: At global scope: /usr/include/wchar.h:62: error: conflicting declaration 'typedef unsigned int wint_t' /usr/local/include/wine/msvcrt/ctype.h:30: error: 'wint_t' has a previous declaration as 'typedef short unsigned int wint_t' In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cwchar:52, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/postypes.h:47, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/iosfwd:47, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/ios:44, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/istream:45, from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/fstream:45, from /home/praveen/wine-projects/myProject/tengine.h:25, from /home/praveen/wine-projects/myProject/teassembly.h:19, from teassembly.cpp:17: /usr/include/wchar.h:246: error: declaration of C function 'wchar_t* wcstok(wchar_t*, const wchar_t*, wchar_t**)' conflicts with /usr/local/include/wine/msvcrt/string.h:122: error: previous declaration 'wchar_t* wcstok(wchar_t*, const wchar_t*)' here My understanding is that Wine has implemented msvcrt and provides the associated header files but not the c++ headers. Am I right? What could be the solution here? I would greatly appreciate any help. I am using wine-1.0-rc4 on Fedora 9. Thanks in advance. -Praveen

1 0

Nice 1.0 article by Steven J. Vaughan-Nichols
by Dan Kegel June 12, 2008

June 12, 2008

http://www.linux.com/feature/138160 It puts the release date at June 20th, but otherwise seems accurate. I was tickled by Jeremy's quote about my impact, but the real story is: Wine's lucky that a) Google happened to need Picasa on Linux, and the Picasa team was shorthanded b) I raised my hand at the right time, and said "I know a contractor that can get Picasa running on Linux..." and is even more lucky that c) Google is so open-source-friendly d) Chris DiBona works at Google e) my bosses believed me when I said a couple interns could make a big difference All in all a fortuitous coincidence. - Dan

1 0

Re: Revert "wined3d: Preload target in ActivateContext() for ORM_BACKBUFFER/ORM_PBUFFER."
by Stefan Dösinger June 12, 2008

June 12, 2008

Am Montag, 2. Juni 2008 06:50:15 schrieb Vitaliy Margolen: > This reverts commit 2d0016c5bc872afb562727278cfd341cea182600. > Partially fixes bug 11584. I think we can revert that patch(ie, apply this patch). I haven't had time to look over the code yet, but I can't think of any problems this would cause. If it does cause problems, there's a bug elsewhere. I think this patch was needed to work around some surface management bugs before the ModifyLocation / LoadLocation methods were introduced

6 11