July 2012 - Wine-Devel - list.winehq.org

Re: [1/2] kernel32/tests: Improve some traces for the CreateTimerQueueTimer() tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19733 Your paranoid android. === WVISTAADM (32 bit sync) === sync.c:924: Test failed: DeleteTimerQueueTimer sync.c:925: Test failed: ChangeTimerQueueTimer

July 3, 2012

user32: Add test for ComboBox repositioning behavior (try 2).

by Sergey Guralnik

Alexandre Julliard writes: >> @@ -5807,6 +5814,13 @@ static void test_combobox_messages(void) >> log_all_parent_messages--; >> ok_sequence(WmKeyDownComboSeq, "WM_KEYDOWN/VK_DOWN on a >> ComboBox", FALSE); >> >> + SetWindowLongPtr(combo, GWLP_WNDPROC, >> (LONG_PTR)combobox_hook_proc_2); >> + SendMessage(combo, CB_SETCURSEL, 0, 0); >> + SetWindowPos(combo, 0, 0, 0, 120, 130, >> SWP_NOZORDER|SWP_NOMOVE); >> + ret = SendMessage(combo, CB_GETCURSEL, 0, 0); >> +todo_wine >> + ok(ret == 1, "expected 1, got %ld\n", ret); >> + > > There's no reason to test just WM_SIZE when we have support for > testing > full sequences. Once again, what are you trying to test? I only try to test that combobox should send WM_SIZE to it's wndproc during WM_WINDOWPOSCHANGED handling. -- Sergey

July 3, 2012

Wine on the front page of Reddit

by Caleb Hearon

Hi all, In a conversation between myself (MaggotBrain on the forums) and Jarrex, I expressed some frustration that Blizzard had been banning Diablo III users who used Wine. He posted some of the excerpts I sent him from WineHQ, and it quickly got to 17 pages on Blizzard's forums. http://us.battle.net/d3/en/forum/topic/5978861022 Then it made the front page of Reddit with 25k votes! http://www.reddit.com/r/gaming/comments/vyc4z/linux_users_permanently_banne… It's likely a mistake on Blizzard's part. But I thought this might be interesting to some people here. It's amazing that this conversation I had while at work led to more widespread awareness of Wine (one of the top comments on Reddit asks what Wine is). And Wine hackers- great work, I've just finished playing 2 hours of Diablo III and it runs great. -Caleb

July 3, 2012

Fwd: [GSoC Mentors] [Announce] 2012 GSoC Mentor Midterm Evaluations 9 July - 13 July

by Austin English

A friendly reminder for GSOC people. If you won't be able to submit your evaluation during the specified timeline, or have any other questions, please contact me privately. Cheers, Austin ---------- Forwarded message ---------- From: Carol Smith <carols(a)google.com> Date: Fri, Jun 29, 2012 at 11:41 AM Subject: [GSoC Mentors] [Announce] 2012 GSoC Mentor Midterm Evaluations 9 July - 13 July To: Google Summer of Code Mentors List <google-summer-of-code-mentors-list(a)googlegroups.com> Hi GSoC 2012 Mentors and Org Admins, Per the program timeline [0], starting 9 July you will will be able to submit an evaluation of your student(s)' progress on their projects thus far. Here's some important info on midterm evaluations for those not familiar: Midterm evaluations are done via Melange [1]. Starting at 19:00 UTC on 9 July you will be able to submit an evaluation for your student(s).You can find the evaluation links on your dashboard under 'Evaluations', one for each student you are a mentor (or co-mentor) for. If you are curious about who can see evaluations after they are submitted, please check out the FAQ on Evaluations [2]. I have also pre-published the evaluation questions below in this email so you can prepare. The deadline is 19:00 UTC on 13 July. You may not submit your evaluation before or after the evaluation window. Please ask your org admin to submit your evaluation for you if you absolutely cannot submit yours during the time allotted. Primary mentors, co-mentors, and org admins may all submit evaluations of their students.**Students must have an evaluation on file from both themselves *and* their mentors in order to receive their midterm payments.** There is no excuse for missing the submission of a student's evaluation. You must submit an evaluation for every student you are the primary mentor for this year. You must fill out the entire survey in one session as there's no auto-save in Melange. You may submit, modify, and resubmit an evaluation as many times as you choose up until the deadline. Please note that failing a student at the midterm evaluation means *this student is immediately removed from the program.* There is no way to fail a student at the midterm and have the student continue with the program to try to "make it up" at the final. If your student fails, your student is out. You might find the FLOSS manual on GSoC evaluations [3] helpful as well. There's some excellent wisdom in there from your fellow mentors and org admins on the evaluation process. Finally, a reminder: This year we will not allow any mentor who misses an evaluation deadline to attend the mentor summit (assuming no one else submits the evaluation on the mentor's behalf before the deadline either). Also, any org that misses 2 or more evaluation deadlines (for the midterm, final, or midterm and final combined) will not be invited to attend the mentor summit this year. Please let me know directly if you have questions or concerns. [0] - http://www.google-melange.com/gsoc/events/google/gsoc2012 [1] - http://google-melange.com [2] - http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/fa… [3] - http://www.booki.cc/gsoc-mentoring/evaluations/ Cheers, Carol ------------ How many years have you been a mentor for Google Summer of Code (Total - this doesn’t have to be consecutive)? This is my first year 2-3 years More than 3 years If you answered 2-3 years or more than 3 years, what years did you participate? How many years have you been a student in Google Summer of Code? I have never been a student 1 year 2 years 3+ years If you answered 1 year, 2 years, or 3+ years, what years did you participate? At what point did you first make contact with your student? Before the program was announced After my organization was selected to participate in Google Summer of Code During the student application/acceptance phase of the program During the community bonding period After the start of coding How often do you and your student interact? Daily Every few days Weekly Every few weeks Monthly How do you communicate with your student? (Check all that apply) Voice (phone, Skype, etc.) IM/IRC Private emails Mailing Lists Student blog updates In-person meeting(s) Google+ Hangout Other Of the communication methods listed above, which do you use most frequently? How much time do you spend on Google Summer of Code per week (take into consideration your interactions with your student as well as time working with your org and on your own). 1-5 hours 5-10 hours 10-15 hours 15-20 hours More than 20 hours per week How many time zones apart from your student are you? Less than 3 3-6 More than 6 How often do you require status updates from your student? Daily Every few days Weekly Only when explicitly asked for by me Please rate the quality of your interactions and communications with the student (consider his/her communication with you as well as your responses). Very Good (Student is regularly responsive and the quality of communication is high) Good (Student is somewhat responsive and the quality of communication is ok) Bad (Student is only somewhat or not at all responsive and the quality of communication is low) Please rate the quality of the student’s interactions with your organization and community. Very Good (Student is regularly responsive and the quality of communication is high) Good (Student is somewhat responsive and the quality of communication is ok) Bad (Student is only somewhat or not at all responsive and the quality of communication is low) Is your student on track to complete his/her project? The student has already completed his/her project He/she is ahead of schedule He/she is on schedule He/she is behind schedule Please rate the quality of code/work the student has produced thus far. Amongst the best people I’ve ever worked with Solid-quality performance Good performance Mediocre performance Disappointing or not performing at all Give an example of a very good or very bad interaction you had with your student. What one thing could you do to improve the quality of interaction and communications with your student? Anything else you’d like to tell us or suggestions on how we could improve the program? -- You received this message because you are subscribed to the Google Groups "Google Summer of Code Mentors List" group. To post to this group, send email to google-summer-of-code-mentors-list(a)googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-mentors-list+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-mentors-list?hl=en. -- -Austin

July 2, 2012

[1/2] comctl32: Fix message sequence when right-clicking a treeview

by Daniel Jelinski

Resend from last month

July 2, 2012

Re: msvcp90: Fix __cdecl functions definitions that returns structures

by Alexandre Julliard

Piotr Caban <piotr.caban(a)gmail.com> writes: > I'm not sure how to write tests for these functions. I see two > possibilities in case of functions returning "big" structures > (e.g. _Getctype). Should I write a test that calls the function in a > loop to make sure the tests are crashing if it corrupts the stack? Or > maybe it's better to write a test in assembler that checks %esp value > before and after calling the function? The %esp issue is probably hard to test in our test suite, but a simple test checking that the structure contents are valid would already be a good thing. > In case of _Getcoll (and _Getcvt) the structure should be returned in > %eax and %edx registers. Current implementation tries to pass hidden > argument. Is it acceptable to test this case by passing inaccessible > memory pointer so the test crashes if implementation tries to write to > it? Do you have any other idea of testing it? You can simply declare the function as returning ULONGLONG in the test and make sure you get sane values. You could also explicitly pass a broken first argument but that's probably not even necessary. -- Alexandre Julliard julliard(a)winehq.org

July 2, 2012

Re: Integer overflow problem in string::compare()

by Dan Kegel

On Mon, Jul 2, 2012 at 2:51 AM, Piotr Caban <piotr.caban(a)gmail.com> wrote: > This patch looks correct. It's also good to fix other functions with similar > bug. Great, I'll have a bigger patchset for review in a few days. Thanks, Dan

July 2, 2012

Re: msvcp90: Fix __cdecl functions definitions that returns structures

by Piotr Caban

On 06/29/12 19:33, Alexandre Julliard wrote: > Piotr Caban<piotr(a)codeweavers.com> writes: > >> In code produced by gcc callee removes hidden return argument. In code >> produced by MS Visual Studio caller is responsible for removing the >> hidden argument. > > That's only for structures larger than 8 bytes, which isn't the case at > least for _Getcoll. Some tests would probably be a good idea. I'm not sure how to write tests for these functions. I see two possibilities in case of functions returning "big" structures (e.g. _Getctype). Should I write a test that calls the function in a loop to make sure the tests are crashing if it corrupts the stack? Or maybe it's better to write a test in assembler that checks %esp value before and after calling the function? In case of _Getcoll (and _Getcvt) the structure should be returned in %eax and %edx registers. Current implementation tries to pass hidden argument. Is it acceptable to test this case by passing inaccessible memory pointer so the test crashes if implementation tries to write to it? Do you have any other idea of testing it? Cheers, Piotr

July 2, 2012

Re: [PATCH] wined3d: Add a switch to preserve vertex buffer copy in system memory.

by Stefan Dösinger

Am 01.07.2012 12:43 schrieb "Henri Verbeet" > In general we don't do hacks like this. The VBOs in question might be managed pool buffers, which would make keeping the sysmem around less hacky. The unforunate issue is that other games(namely Source Engine games, probably others too) allocate hundreds of megabytes in managed vertex and index buffers. Keeping two copies of those buffers around(one GL copy, one wined3d sysmem copy) makes them run out of address space. So pick your poison... Maybe we should at least try to contact the developers of the engine.

July 2, 2012

Re: user32: Add test for ComboBox repositioning behavior (try 2).

by Alexandre Julliard

Sergey Guralnik <serhio(a)etersoft.ru> writes: > @@ -5807,6 +5814,13 @@ static void test_combobox_messages(void) > log_all_parent_messages--; > ok_sequence(WmKeyDownComboSeq, "WM_KEYDOWN/VK_DOWN on a ComboBox", FALSE); > > + SetWindowLongPtr(combo, GWLP_WNDPROC, (LONG_PTR)combobox_hook_proc_2); > + SendMessage(combo, CB_SETCURSEL, 0, 0); > + SetWindowPos(combo, 0, 0, 0, 120, 130, SWP_NOZORDER|SWP_NOMOVE); > + ret = SendMessage(combo, CB_GETCURSEL, 0, 0); > +todo_wine > + ok(ret == 1, "expected 1, got %ld\n", ret); > + There's no reason to test just WM_SIZE when we have support for testing full sequences. Once again, what are you trying to test? -- Alexandre Julliard julliard(a)winehq.org

July 2, 2012