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

Re: Add a slight delay before testing the ddraw and d3d9 visual tests

by Maarten Lankhorst

Hi Dmitry, 2008/2/13, Dmitry Timoshkov <dmitry(a)codeweavers.com>: > "Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > > > This makes the tests pass on my pc. > > Perhaps there is something less hacky way like GdiFlush() which is more > appropriate for this. I tested GdiFlush to do an XSync and XFlush, and neither of them help any to pass the d3d9 visual tests, I still think I need to put in the Sleep(1000); Do you agree now? Or do you have another solution. Cheers, Maarten.

Feb. 25, 2008

Re: GSoC project ideas

by Scott Ritchie

Kai Blin wrote: > Feel free to add your own project ideas, maybe elaborate a bit on the > deliverables of the idea. > Here's my idea that I'm hoping someone will take up: Write a case insensitive FUSE filesystem for us to put the entire ~/.wine directory in. See http://wiki.winehq.org/CaseInsensitiveFilenames There are two main advantages to this: Sometimes applications break because users need to install a patch by hand into the filesystem (say, a zip file), and the files within have a different case then the files they're supposed to overwrite. This leads to multiples of the same file, and Wine sometimes chooses the older one, leading to weird breakages. More importantly, a FUSE filesystem like this would allow us to finally get some speedups by no longer having to prove case-insensitive files don't exist. This is a direct cause of some apps working very very slowly, including install shield (see http://bugs.winehq.org/show_bug.cgi?id=3817) Interestingly, this doesn't strictly have to be a Wine SOC project. It could fairly easily stand on its own. We'd probably be the only user though, so I mention it here. Thanks, Scott Ritchie

Feb. 25, 2008

Re: GSoC project ideas

by Eric Pouech

> * Implementing the ASIO audio infrastructure for Cubase > IIRC, we dropped it last year because of copyright in Steinberg license. Haven't heard it has changed. > * Implement the MS Wsock dll (dlls/mswsock), an enhanced winsocket > implementation > still lots to do, basic tests and very low fruits have been done in GSoC two years ago. there were some showstoppers linked to wine internals (mainly in server) which have been fixed. should be ripe for a second turn, however, the project won't be simple > * Valgrind and Wine integration (see: Wine_and_Valgrind) > the only interesting point would be to support MS debug info in valgrind, but I see it more as valgrind's gsoc rather than a wine's one other idea: - window less support in richedit: a couple of bugs are pending on this one (and incendally, lots of COM related code in richedit) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Feb. 25, 2008

Re: Do we need a forum?

by Tony Lambregts

Jeremy Newman wrote: > Tom Wickline wrote: >> http://forum.winehq.org/viewtopic.php?t=52 >> >> I sincerely wish you guys the best fighting off the spam assault :D > > Yeah, it has been difficult. Since I've never run a PHPbb board before, > I never know how well these bots had the registration system down. It > has really raised my blood pressure a bit this weekend. > > I think I've come up with a solution that will work for everybody. > First, I updated the "captcha" image validation to be more random and > harder to screen scrape. > > Second, I added a text validation field that asks you: "Who is the > current maintainer of the Wine project?" > > This should stop both bots and human spammers that don't know about our > forum. > > To be nice, I at least added a hint link, that takes you to the "About > Wine" page on WineHQ, so new users will at least have to read a little > bit of our history if they don't know. > > > I just tried to register and locked myself out. I don't know if it was the capcha or what I was putting in for Wine's maintainer (Alexandre Julliard) but one of them was wrong every time. I am pretty sure I got the name of Wine's maintainer right so I think it has to be the capcha but I have never had problems with them before. Just so's you know... -- Tony Lambregts

Feb. 25, 2008

Re: WGL: wglDeleteContext should fail on garbage handles [attempt2]

by Alexandre Julliard

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> writes: > Subject: [PATCH] wglDeleteContext should fail on a garbage hglrc. When > we receive garbage ctx->hdc is invalid which leads to a > crash. Retrieve a default DC and use it to pass hglrc to the display > driver. Luckily the opengl code maintains a list of valid opengl > contexts, so it can detect whether the hglrc is valid or not. :) If we are going to go in this direction, then the context should be made opaque in gdi32, and all calls should use the default DC. The alternative is to make the context a proper GDI handle, and have GDI check it for validity first. -- Alexandre Julliard julliard(a)winehq.org

Feb. 25, 2008

Anybody has a patch for implementing WriteFileGather Kernel32.dll

by Michel Jacques

Hello, I'm looking for an implementation of WriteFileGather in Kernel32.dll. Anybody has a candidate? Thanks in advance, Michel Jacques

Feb. 25, 2008

Re: winex11drv: Distinguish left and right keys for shift, ctrl and alt.

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > That is the point. Old win9x didn't have that. Everything starting from > win2k does. Without this change nothing else gets to see left/right buttons. > > Might need some changes further downstream but this level have to > distinguish between left and right keys. Then you need to do the downstream changes first to preserve the current behavior. You can't just change the vkey values everywhere. -- Alexandre Julliard julliard(a)winehq.org

Feb. 25, 2008

Re: winex11drv: Distinguish left and right keys for shift,ctrl and alt.

by Vitaliy Margolen

Alexandre Julliard wrote: > Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > >> --- a/dlls/winex11.drv/keyboard.c >> +++ b/dlls/winex11.drv/keyboard.c >> @@ -1022,9 +1022,9 @@ static const WORD nonchar_key_vkey[256] = >> 0, 0, 0, 0, 0, 0, 0, 0, /* FFD0 */ >> 0, 0, 0, 0, 0, 0, 0, 0, /* FFD8 */ >> /* modifier keys */ >> - 0, VK_SHIFT, VK_SHIFT, VK_CONTROL, /* FFE0 */ >> - VK_CONTROL, VK_CAPITAL, 0, VK_MENU, >> - VK_MENU, VK_MENU, VK_MENU, 0, 0, 0, 0, 0, /* FFE8 */ >> + 0, VK_LSHIFT, VK_RSHIFT, VK_LCONTROL, /* FFE0 */ >> + VK_RCONTROL, VK_CAPITAL, 0, VK_MENU, >> + VK_MENU, VK_LMENU, VK_RMENU, 0, 0, 0, 0, 0, /* FFE8 */ >> 0, 0, 0, 0, 0, 0, 0, 0, /* FFF0 */ >> 0, 0, 0, 0, 0, 0, 0, VK_DELETE /* FFF8 */ > > This is going to change the vkeys everywhere, I don't think that's > correct. Things like WM_KEYDOWN have to report VK_SHIFT, not VK_LSHIFT etc. > That is the point. Old win9x didn't have that. Everything starting from win2k does. Without this change nothing else gets to see left/right buttons. Might need some changes further downstream but this level have to distinguish between left and right keys. Vitaliy

Feb. 25, 2008

Re: winex11drv: Remove special treatment for caps-lock and num-lock keys. [try-2]

by Alexandre Julliard

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > - if (vkey) > - { > - switch (vkey & 0xff) > + if (!vkey) return; > + > + /* Adjust the NUMLOCK state if it has been changed outside wine */ > + if (!(key_state_table[VK_NUMLOCK] & 0x01) != !(event->state & NumLockMask)) > { > - case VK_NUMLOCK: > - KEYBOARD_GenerateMsg( VK_NUMLOCK, 0x45, event->type, event_time ); > - break; > - case VK_CAPITAL: > - TRACE("Caps Lock event. (type %d). State before : %#.2x\n",event->type,key_state_table[vkey]); > - KEYBOARD_GenerateMsg( VK_CAPITAL, 0x3A, event->type, event_time ); > - TRACE("State after : %#.2x\n",key_state_table[vkey]); > - break; > - default: > - /* Adjust the NUMLOCK state if it has been changed outside wine */ > - if (!(key_state_table[VK_NUMLOCK] & 0x01) != !(event->state & NumLockMask)) > - { > - TRACE("Adjusting NumLock state.\n"); > - KEYBOARD_GenerateMsg( VK_NUMLOCK, 0x45, KeyPress, event_time ); > - KEYBOARD_GenerateMsg( VK_NUMLOCK, 0x45, KeyRelease, event_time ); > - } > - /* Adjust the CAPSLOCK state if it has been changed outside wine */ > - if (!(key_state_table[VK_CAPITAL] & 0x01) != !(event->state & LockMask)) > - { > - TRACE("Adjusting Caps Lock state.\n"); > - KEYBOARD_GenerateMsg( VK_CAPITAL, 0x3A, KeyPress, event_time ); > - KEYBOARD_GenerateMsg( VK_CAPITAL, 0x3A, KeyRelease, event_time ); > - } > - /* Not Num nor Caps : end of intermediary states for both. */ > - NumState = FALSE; > - CapsState = FALSE; > + TRACE("Adjusting NumLock state (%#.2x).\n", key_state_table[VK_NUMLOCK]); > + X11DRV_send_keyboard_input( VK_NUMLOCK, 0x45, KEYEVENTF_EXTENDEDKEY, event_time, 0, 0 ); > + X11DRV_send_keyboard_input( VK_NUMLOCK, 0x45, KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP, event_time, 0, 0 ); > + } > + /* Adjust the CAPSLOCK state if it has been changed outside wine */ > + if (!(key_state_table[VK_CAPITAL] & 0x01) != !(event->state & LockMask)) > + { > + TRACE("Adjusting Caps Lock state (%#.2x).\n", key_state_table[VK_CAPITAL]); > + X11DRV_send_keyboard_input( VK_CAPITAL, 0x3A, 0, event_time, 0, 0 ); > + X11DRV_send_keyboard_input( VK_CAPITAL, 0x3A, KEYEVENTF_KEYUP, event_time, 0, 0 ); > + } You still need to handle the case of caps lock or num lock keys differently, otherwise you'll generate duplicate messages. -- Alexandre Julliard julliard(a)winehq.org

Feb. 25, 2008

Re: winex11drv: Distinguish left and right keys for shift, ctrl and alt.

by Alexandre Julliard

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > --- a/dlls/winex11.drv/keyboard.c > +++ b/dlls/winex11.drv/keyboard.c > @@ -1022,9 +1022,9 @@ static const WORD nonchar_key_vkey[256] = > 0, 0, 0, 0, 0, 0, 0, 0, /* FFD0 */ > 0, 0, 0, 0, 0, 0, 0, 0, /* FFD8 */ > /* modifier keys */ > - 0, VK_SHIFT, VK_SHIFT, VK_CONTROL, /* FFE0 */ > - VK_CONTROL, VK_CAPITAL, 0, VK_MENU, > - VK_MENU, VK_MENU, VK_MENU, 0, 0, 0, 0, 0, /* FFE8 */ > + 0, VK_LSHIFT, VK_RSHIFT, VK_LCONTROL, /* FFE0 */ > + VK_RCONTROL, VK_CAPITAL, 0, VK_MENU, > + VK_MENU, VK_LMENU, VK_RMENU, 0, 0, 0, 0, 0, /* FFE8 */ > 0, 0, 0, 0, 0, 0, 0, 0, /* FFF0 */ > 0, 0, 0, 0, 0, 0, 0, VK_DELETE /* FFF8 */ This is going to change the vkeys everywhere, I don't think that's correct. Things like WM_KEYDOWN have to report VK_SHIFT, not VK_LSHIFT etc. -- Alexandre Julliard julliard(a)winehq.org

Feb. 25, 2008