September 2007 - Wine-Devel

Re: Recent BiDi changes

by Maarten Lankhorst

Shachar Shemesh schreef: > Alexandre Julliard wrote: > >> Actually the proper place would be libwine along with the rest of the >> Unicode support. >> >> > I've spent the past hour downloading 12% of the git repository, so I'm > unable to look at current Wine code for at least the next 24 hours :-(. > >From memory, libwine contains mostly tables and stuff, not actual > algorithms. Wouldn't it be better to place the tables at libwine, but > the algorithm at uniscribe, if only to follow Window's design of things? > > Also, I suspect it might be necessary, at some point in the extreme > distant future, to do some deviation from the Unicode algorithm. It's > pretty far away, as we're talking about nuances that are hard to pick if > you don't know your stuff, but there are places where Windows can be > said to be either implementing an old version of the standard, or > implementing its own idea altogether. > > My original plan was to import the fribidi code into a subdirectory of > the wine tree, and make the necessary changes there. > Actually dlls/gdi32/bidi.c now already has a full implementation of the bidirectional algorythm, you could easily take it out there and replace it by a (reverse)memcpy depending on which forced direction, since the force direction flag overrides all other flags that determine direction. It shouldn't be much of an effort to implement whatever uniscribe needs using bidi.c.. > On a related note - I haven't been able to get an answer to that one, > not even through experimentation. Does anyone know whether Windows' > Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates > is crucially important when reordering characters. > > Shachar > I'm guessing utf-16, not 100% sure though. Maarten

Sept. 25, 2007

Re: Recent BiDi changes

by Alexandre Julliard

Shachar Shemesh <shachar(a)shemesh.biz> writes: > I've spent the past hour downloading 12% of the git repository, so I'm > unable to look at current Wine code for at least the next 24 hours > :-(. You can always browse the code at http://source.winehq.org/git/wine.git >>From memory, libwine contains mostly tables and stuff, not actual > algorithms. Wouldn't it be better to place the tables at libwine, but > the algorithm at uniscribe, if only to follow Window's design of things? libwine certainly contains algorithms, but Uniscribe is a possibility too, if it provides everything we need. > Also, I suspect it might be necessary, at some point in the extreme > distant future, to do some deviation from the Unicode algorithm. It's > pretty far away, as we're talking about nuances that are hard to pick if > you don't know your stuff, but there are places where Windows can be > said to be either implementing an old version of the standard, or > implementing its own idea altogether. That's one more reason for having our own instead of using an external library. > My original plan was to import the fribidi code into a subdirectory of > the wine tree, and make the necessary changes there. I think Maarten's work shows that this is not necessary. > On a related note - I haven't been able to get an answer to that one, > not even through experimentation. Does anyone know whether Windows' > Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates > is crucially important when reordering characters. Recent Windows versions do support surrogates. -- Alexandre Julliard julliard(a)winehq.org

Sept. 25, 2007

Re: Recent BiDi changes

by Shachar Shemesh

Alexandre Julliard wrote: > > Actually the proper place would be libwine along with the rest of the > Unicode support. > I've spent the past hour downloading 12% of the git repository, so I'm unable to look at current Wine code for at least the next 24 hours :-(. >From memory, libwine contains mostly tables and stuff, not actual algorithms. Wouldn't it be better to place the tables at libwine, but the algorithm at uniscribe, if only to follow Window's design of things? Also, I suspect it might be necessary, at some point in the extreme distant future, to do some deviation from the Unicode algorithm. It's pretty far away, as we're talking about nuances that are hard to pick if you don't know your stuff, but there are places where Windows can be said to be either implementing an old version of the standard, or implementing its own idea altogether. My original plan was to import the fribidi code into a subdirectory of the wine tree, and make the necessary changes there. On a related note - I haven't been able to get an answer to that one, not even through experimentation. Does anyone know whether Windows' Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates is crucially important when reordering characters. Shachar

Sept. 25, 2007

Re: Recent BiDi changes

by Shachar Shemesh

Alexandre Julliard wrote: > > Actually the proper place would be libwine along with the rest of the > Unicode support. > I've spent the past hour downloading 12% of the git repository, so I'm unable to look at current Wine code for at least the next 24 hours :-(. >From memory, libwine contains mostly tables and stuff, not actual algorithms. Wouldn't it be better to place the tables at libwine, but the algorithm at uniscribe, if only to follow Window's design of things? Also, I suspect it might be necessary, at some point in the extreme distant future, to do some deviation from the Unicode algorithm. It's pretty far away, as we're talking about nuances that are hard to pick if you don't know your stuff, but there are places where Windows can be said to be either implementing an old version of the standard, or implementing its own idea altogether. My original plan was to import the fribidi code into a subdirectory of the wine tree, and make the necessary changes there. On a related note - I haven't been able to get an answer to that one, not even through experimentation. Does anyone know whether Windows' Unicode is UTF-16 or UCS-2? Whether it's necessary to handle aggregates is crucially important when reordering characters. Shachar

Sept. 25, 2007

Re: Recent BiDi changes

by Alexandre Julliard

Shachar Shemesh <shachar(a)shemesh.biz> writes: > Hi Maarten, > > Can you, please, explain the advantage of creating our own > implementation of the BiDi algorithm over using existing > implementations? I know ICU sucks (especially as far as linkage is > concerned), but there are other implementations, major among which is > fribidi, which are free, are C based, and have a compatible license. Is > there any need to Wine to be aware of the inside working of the algorithm? The algorithm is pretty simple, and since we need to have the character tables anyway there's no reason to add an external dependency for this. > Also, so long as you are picking up the BiDi glove I dropped oh so many > years ago, it seems to me that the proper place to implement BiDi would > be in unscribe, where it is for Windows. The GDI implementation Wine has > is a hack that reached it's useful end the moment you realize that > DrawText needs its own implementation, independent of ExtTextOut (mostly > due to line breaking code). Actually the proper place would be libwine along with the rest of the Unicode support. -- Alexandre Julliard julliard(a)winehq.org

Sept. 25, 2007

Recent BiDi changes

by Shachar Shemesh

Hi Maarten, Can you, please, explain the advantage of creating our own implementation of the BiDi algorithm over using existing implementations? I know ICU sucks (especially as far as linkage is concerned), but there are other implementations, major among which is fribidi, which are free, are C based, and have a compatible license. Is there any need to Wine to be aware of the inside working of the algorithm? Also, so long as you are picking up the BiDi glove I dropped oh so many years ago, it seems to me that the proper place to implement BiDi would be in unscribe, where it is for Windows. The GDI implementation Wine has is a hack that reached it's useful end the moment you realize that DrawText needs its own implementation, independent of ExtTextOut (mostly due to line breaking code). Thanks, Shachar

Sept. 25, 2007

Re: pdh: add tests for XP variant of api call

by Hans Leidekker

On Tuesday 25 September 2007 14:19:34 Jeff Latimer wrote: > I am happy with that though the tests I added relate to the following > paragraph where it says that XP requires the buffer parameter as well as > the size at all times and testing shows that it returns > PDH_INVALID_ARGUMENT. It also returns PDH_INSUFFICIENT_BUFFER instead > of PDH_MORE_DATA. Then I suggest to remove tests with a NULL buffer parameter and accept both PDH_INSUFFICIENT_BUFFER and PDH_MORE_DATA in tests where the specified buffer size is too small. -Hans

Sept. 25, 2007

Re: user32: Make message test pass cleanly under XP SP2

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> writes: > I added that changes because Microsoft compiler from latest Vista SDK > complains that variables might be used without being initialized. It sounds like that compiler is on crack. I don't think we want to sprinkle assignments all over the place just to work around that. -- Alexandre Julliard julliard(a)winehq.org

Sept. 25, 2007

Re: [5/5] winex11: Use an offscreen redirected window for child OpenGL rendering

by Alexandre Julliard

Chris Robinson <chris.kcat(a)gmail.com> writes: > With the child being parented to the main window, a BadWindow error sometimes > crops up on XDestroyWindow for the X11 child. I couldn't see why, but > parenting it to the root_window works. Would that be due to using gdi_display > for creating/destroying the child? Maybe, but in any case making it a child of the root window is wrong. > Is it safe to call XMoveResizeWindow even if the size didn't change, and have > X make it a no-op (or at least be negligible for processing time)? Calling to > resize the child window every time the hwnd simply moves (or whenever it > thinks it resized/moved) can cause it to be done unnecessarilly often. No, you have all the info you need in SetWindowPos, there's no reason to guess. -- Alexandre Julliard julliard(a)winehq.org

Sept. 25, 2007

Re: pdh: add tests for XP variant of api call

by Jeff Latimer

Hans Leidekker wrote: >> From this we should write tests to accept all values. It would seem >> that the wine dll still needs to implement the API accurately, so you >> are saying, code the API correctly but make the tests generic? >> > > Quote from MSDN on PdhLookupPerfNameByIndex: > > PDH_INVALID_ARGUMENT > A parameter is not valid or is incorrectly formatted. For example, > on some releases you could receive this error if the specified size > on input is greater than zero but less than the required size. > I am happy with that though the tests I added relate to the following paragraph where it says that XP requires the buffer parameter as well as the size at all times and testing shows that it returns PDH_INVALID_ARGUMENT. It also returns PDH_INSUFFICIENT_BUFFER instead of PDH_MORE_DATA. > So we should accept this return value too. Our implemention is fine > as-is because it still passes the test. > I am not sure that I follow. Each of the tests in the patch is there because they satisfied the returns from XP and failed on my platform. > Note that there is another problem with the tests which is that > performance counter names are localized but the tests assume that the > current locale is English. I intend to fix this in my next batch of > patches. Sounds good. BTW I can see that the tests could be merged into the existing tests so that the tests handle multiple situations. It means that in some ways it means that conformance to particular release will not be specifically tested in wine and hence conformance will not be assured. If that is the way ist done than thats ok. Jeff

Sept. 25, 2007

Re: [5/5] winex11: Use an offscreen redirected window for child OpenGL rendering

by Chris Robinson

On Tuesday 25 September 2007 04:31:04 am Alexandre Julliard wrote: > Chris Robinson <chris.kcat(a)gmail.com> writes: > > + if(w > 0 && h > 0) { > > + XFlush(gdi_display); > > + XCopyArea(gdi_display, physDev->gl_drawable, physDev->drawable, > > + physDev->gc, 0, 0, w, h, physDev->dc_rect.left, > > + physDev->dc_rect.top); > > Why do you need an XFlush here? Given the nature of glFlush/glFinish, I think it would probably be correct behavior to make sure the X copy command is flushed by the time the GL functions finish, too. Why it ended up before the copy though, I don't know. > > + if(data->whole_window && vis->visualid == > > XVisualIDFromVisual(visual)) + { > > + TRACE("Whole window available and visual match, rendering > > onscreen\n"); + goto done; > > + } > > + > > + if(!composite_gl) > > + goto done; > > There's no sense in having a config option for this since the > alternative doesn't work anyway, particularly since you removed the > scissor support. True. I guess I can use an option just for extra onscreen pixel formats being composited instead, in a seperate patch of course. > > + data->gl_drawable = XCreateWindow(gdi_display, root_window, -w, > > 0, w, h, + 0, vis->depth, > > InputOutput, + vis->visual, > > + CWColormap | > > CWOverrideRedirect, + &attrib); > > The window needs to be created on the thread display, and as a child > of the main window. With the child being parented to the main window, a BadWindow error sometimes crops up on XDestroyWindow for the X11 child. I couldn't see why, but parenting it to the root_window works. Would that be due to using gdi_display for creating/destroying the child? > > +static void update_gl_drawable(struct x11drv_win_data *data) > > +{ > > + unsigned int border, depth; > > + int x, y, w, h; > > + Window root_win; > > + > > + if(!data->gl_drawable) > > + return; > > + > > + wine_tsx11_lock(); > > + XGetGeometry(gdi_display, data->gl_drawable, &root_win, &x, &y, > > + (unsigned int*)&w, (unsigned int*)&h, &border, &depth); > > You must not use XGetGeometry, this incurs a server round-trip. Is it safe to call XMoveResizeWindow even if the size didn't change, and have X make it a no-op (or at least be negligible for processing time)? Calling to resize the child window every time the hwnd simply moves (or whenever it thinks it resized/moved) can cause it to be done unnecessarilly often.

Sept. 25, 2007

Re: user32: Make message test pass cleanly under XP SP2

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > >> /* posted message */ >> PostMessageA( hwnd, WM_CHAR, dbch[0], 0 ); >> + msg.message = 0xdeadbeef; >> ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); >> PostMessageA( hwnd, WM_CHAR, dbch[1], 0 ); >> ok( PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "no message\n" ); >> ok( msg.message == WM_CHAR, "unexpected message %x\n", msg.message ); >> ok( msg.wParam == wch, "bad wparam %lx/%x\n", msg.wParam, wch ); >> + msg.message = 0xdeadbeef; >> ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); >> >> /* posted thread message */ >> PostThreadMessageA( GetCurrentThreadId(), WM_CHAR, dbch[0], 0 ); >> + msg.message = 0xdeadbeef; >> ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); >> PostMessageA( hwnd, WM_CHAR, dbch[1], 0 ); >> ok( PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "no message\n" ); >> ok( msg.message == WM_CHAR, "unexpected message %x\n", msg.message ); >> ok( msg.wParam == wch, "bad wparam %lx/%x\n", msg.wParam, wch ); >> + msg.message = 0xdeadbeef; >> ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); > > I'm not sure I see the point of that change, since the message is not > tested when PeekMessage fails. I added that changes because Microsoft compiler from latest Vista SDK complains that variables might be used without being initialized. -- Dmitry.

Sept. 25, 2007

Re: user32: Make message test pass cleanly under XP SP2

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > /* posted message */ > PostMessageA( hwnd, WM_CHAR, dbch[0], 0 ); > + msg.message = 0xdeadbeef; > ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); > PostMessageA( hwnd, WM_CHAR, dbch[1], 0 ); > ok( PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "no message\n" ); > ok( msg.message == WM_CHAR, "unexpected message %x\n", msg.message ); > ok( msg.wParam == wch, "bad wparam %lx/%x\n", msg.wParam, wch ); > + msg.message = 0xdeadbeef; > ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); > > /* posted thread message */ > PostThreadMessageA( GetCurrentThreadId(), WM_CHAR, dbch[0], 0 ); > + msg.message = 0xdeadbeef; > ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); > PostMessageA( hwnd, WM_CHAR, dbch[1], 0 ); > ok( PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "no message\n" ); > ok( msg.message == WM_CHAR, "unexpected message %x\n", msg.message ); > ok( msg.wParam == wch, "bad wparam %lx/%x\n", msg.wParam, wch ); > + msg.message = 0xdeadbeef; > ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); I'm not sure I see the point of that change, since the message is not tested when PeekMessage fails. -- Alexandre Julliard julliard(a)winehq.org

Sept. 25, 2007

Re: user32: Make message test pass cleanly under XP SP2

by Anatoly Lyutin

Dmitry Timoshkov wrote: > "Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > > As the subject of the patch says the tests pass absolutely cleanly for > me. > The failure you see above is a very minor thing in comparison to > current state. > Usually I'm monitoring test.winehq.org/data and trying to fix failures > reported > there. > Ok. I hope, that the general number of mistakes will decrease after this work. -- Best regards Anatoly Lyutin.

Sept. 25, 2007

Re: user32: Make message test pass cleanly under XP SP2

by Dmitry Timoshkov

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > Sorry! It falls in my Windows XP SP2 with: > msg.c:3267:expected 0009 - actual 0009 > msg.c:3267:expected 0008 - actual 0008 > msg.c:3267:expected 0281 - actual 0007 > msg.c:3267: Test failed: Child did not switch correctly: the msg 0x0281 > was expected, but got msg 0x0007 instead > msg.c:3268:end of test for switch maximized MDI children As the subject of the patch says the tests pass absolutely cleanly for me. The failure you see above is a very minor thing in comparison to current state. Usually I'm monitoring test.winehq.org/data and trying to fix failures reported there. -- Dmitry.

Sept. 25, 2007

Re: [5/5] winex11: Use an offscreen redirected window for child OpenGL rendering

by Alexandre Julliard

Chris Robinson <chris.kcat(a)gmail.com> writes: > + if(w > 0 && h > 0) { > + XFlush(gdi_display); > + XCopyArea(gdi_display, physDev->gl_drawable, physDev->drawable, > + physDev->gc, 0, 0, w, h, physDev->dc_rect.left, > + physDev->dc_rect.top); Why do you need an XFlush here? > + if(data->whole_window && vis->visualid == XVisualIDFromVisual(visual)) > + { > + TRACE("Whole window available and visual match, rendering onscreen\n"); > + goto done; > + } > + > + if(!composite_gl) > + goto done; There's no sense in having a config option for this since the alternative doesn't work anyway, particularly since you removed the scissor support. > + data->gl_drawable = XCreateWindow(gdi_display, root_window, -w, 0, w, h, > + 0, vis->depth, InputOutput, > + vis->visual, > + CWColormap | CWOverrideRedirect, > + &attrib); The window needs to be created on the thread display, and as a child of the main window. > +static void update_gl_drawable(struct x11drv_win_data *data) > +{ > + unsigned int border, depth; > + int x, y, w, h; > + Window root_win; > + > + if(!data->gl_drawable) > + return; > + > + wine_tsx11_lock(); > + XGetGeometry(gdi_display, data->gl_drawable, &root_win, &x, &y, > + (unsigned int*)&w, (unsigned int*)&h, &border, &depth); You must not use XGetGeometry, this incurs a server round-trip. -- Alexandre Julliard julliard(a)winehq.org

Sept. 25, 2007

Re: user32: Make message test pass cleanly under XP SP2

by Anatoly Lyutin

Dmitry Timoshkov wrote: > Hello, > > Changelog: > user32: Make message test pass cleanly under XP SP2. > > --- > dlls/user32/tests/msg.c | 142 +++++++++++++++++++++++++++++++++------------- > 1 files changed, 102 insertions(+), 40 deletions(-) > > > > @@ -224,51 +226,53 @@ static const struct message WmSwitchChild[] = { > /* Switch MDI child */ > { WM_MDIACTIVATE, sent },/* in the MDI client */ > { WM_WINDOWPOSCHANGING, sent|wparam,SWP_NOSIZE|SWP_NOMOVE },/* in the 1st MDI child */ > + { EVENT_OBJECT_REORDER, winevent_hook|wparam|lparam, OBJID_CLIENT, 0 }, > { WM_CHILDACTIVATE, sent },/* in the 1st MDI child */ > /* Deactivate 2nd MDI child */ > - { WM_NCACTIVATE, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_MDIACTIVATE, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_CREATE, hook }, > + { WM_NCACTIVATE, sent|wparam|defwinproc, 0 }, /* in the 2nd MDI child */ > + { WM_MDIACTIVATE, sent|defwinproc }, /* in the 2nd MDI child */ > + { HCBT_MINMAX, hook|lparam, 0, SW_MAXIMIZE }, > /* Preparing for maximize and maximaze the 1st MDI child */ > - { WM_GETMINMAXINFO, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, SWP_FRAMECHANGED|SWP_STATECHANGED },/* in the 1st MDI child */ > - { WM_GETMINMAXINFO, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_NCCALCSIZE, sent|wparam|defwinproc|optional, 1 },/* in the 1st MDI child */ > - { WM_CHILDACTIVATE, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_WINDOWPOSCHANGED, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_MOVE, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_SIZE, sent|defwinproc|optional },/* in the 1st MDI child */ > + { WM_GETMINMAXINFO, sent|defwinproc }, /* in the 1st MDI child */ > + { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc, SWP_FRAMECHANGED|SWP_STATECHANGED }, /* in the 1st MDI child */ > + { WM_NCCALCSIZE, sent|wparam|defwinproc, 1 }, /* in the 1st MDI child */ > + { WM_CHILDACTIVATE, sent|defwinproc }, /* in the 1st MDI child */ > + { WM_WINDOWPOSCHANGED, sent|wparam|defwinproc, SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE|0x8000 }, /* in the 1st MDI child */ > + { WM_SIZE, sent|defwinproc|wparam, SIZE_MAXIMIZED }, /* in the 1st MDI child */ > /* Lock redraw 2nd MDI child */ > - { WM_SETREDRAW, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, SWP_FRAMECHANGED|SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE },/* in the 2nd MDI child */ > - { WM_NCCALCSIZE, sent|wparam|defwinproc|optional, 1 },/* in the 2nd MDI child */ > - { WM_WINDOWPOSCHANGED, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_CREATE, hook }, > + { WM_SETREDRAW, sent|wparam|defwinproc, 0 }, /* in the 2nd MDI child */ > + { HCBT_MINMAX, hook|lparam, 0, SW_NORMALNA }, > /* Restore 2nd MDI child */ > - { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_SHOWWINDOW|SWP_STATECHANGED },/* in the 2nd MDI child */ > - { WM_GETMINMAXINFO, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_NCCALCSIZE, sent|wparam|defwinproc|optional, 1 },/* in the 2nd MDI child */ > - { WM_WINDOWPOSCHANGED, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_MOVE, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_SIZE, sent|defwinproc|optional },/* in the 2nd MDI child */ > + { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc, SWP_SHOWWINDOW|SWP_NOACTIVATE|SWP_FRAMECHANGED|0x8000 },/* in the 2nd MDI child */ > + { WM_NCCALCSIZE, sent|wparam|defwinproc, 1 },/* in the 2nd MDI child */ > + { EVENT_OBJECT_SHOW, winevent_hook|wparam|lparam, 0, 0 }, /* in the 2nd MDI child */ > + { WM_WINDOWPOSCHANGED, sent|wparam|defwinproc, SWP_SHOWWINDOW|SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE|0x8000 }, /* in the 2nd MDI child */ > + { WM_SIZE, sent|defwinproc|wparam, SIZE_RESTORED }, /* in the 2nd MDI child */ > + { EVENT_OBJECT_LOCATIONCHANGE, winevent_hook|wparam|lparam, 0, 0 }, /* in the 2nd MDI child */ > /* Redraw 2nd MDI child */ > - { WM_SETREDRAW, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_WINDOWPOSCHANGING, sent|wparam, SWP_NOACTIVATE|SWP_NOSIZE|SWP_FRAMECHANGED|SWP_NOMOVE },/* in the MDI frame */ > - { WM_NCCALCSIZE, sent|wparam, 1 },/* in the MDI frame */ > - { WM_WINDOWPOSCHANGED, sent},/* in the MDI frame */ > - { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE },/* in the 1st MDI child */ > - { WM_NCACTIVATE, sent|wparam|defwinproc|optional, 1 },/* in the 1st MDI child */ > - { WM_SETVISIBLE, hook }, > - { WM_KILLFOCUS, sent|defwinproc|optional }, /* in the 2nd MDI child */ > - { WM_IME_SETCONTEXT, sent|wparam|optional, 0 }, /* in MDI client */ > - { WM_IME_SETCONTEXT, sent|wparam|optional, 1 }, > + { WM_SETREDRAW, sent|wparam|defwinproc, 1 },/* in the 2nd MDI child */ > + /* Redraw MDI frame */ > + { WM_WINDOWPOSCHANGING, sent|wparam, SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE },/* in MDI frame */ > + { WM_NCCALCSIZE, sent|wparam, 1 },/* in MDI frame */ > + { WM_WINDOWPOSCHANGED, sent|wparam, SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE}, /* in MDI frame */ > + { EVENT_OBJECT_LOCATIONCHANGE, winevent_hook|wparam|lparam, 0, 0 }, /* in MDI frame */ > + { EVENT_OBJECT_LOCATIONCHANGE, winevent_hook|wparam|lparam, 0, 0 }, /* in the 1st MDI child */ > + { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc, SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE }, /* in the 1st MDI child */ > + { WM_NCACTIVATE, sent|wparam|defwinproc, 1 }, /* in the 1st MDI child */ > + { HCBT_SETFOCUS, hook }, > + { WM_KILLFOCUS, sent|defwinproc }, /* in the 2nd MDI child */ > + { WM_IME_SETCONTEXT, sent|wparam|defwinproc, 0 },/* in the 1st MDI child */ > + { WM_IME_SETCONTEXT, sent|wparam, 1 }, /* in MDI client */ > { EVENT_OBJECT_FOCUS, winevent_hook|wparam|lparam, OBJID_CLIENT, 0 }, > { WM_SETFOCUS, sent },/* in the MDI client */ > - { WM_SETVISIBLE, hook }, > + { HCBT_SETFOCUS, hook }, > { WM_KILLFOCUS, sent },/* in the MDI client */ > - { WM_SETFOCUS, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_MDIACTIVATE, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_WINDOWPOSCHANGED, sent },/* in the 1st MDI child */ > + { WM_IME_SETCONTEXT, sent|wparam, 0 }, /* in MDI client */ > + { WM_IME_SETCONTEXT, sent|wparam|defwinproc, 1 }, /* in the 1st MDI child */ > + { EVENT_OBJECT_FOCUS, winevent_hook|wparam|lparam, OBJID_CLIENT, 0 }, > + { WM_SETFOCUS, sent|defwinproc }, /* in the 1st MDI child */ > + { WM_MDIACTIVATE, sent|defwinproc },/* in the 1st MDI child */ > + { WM_WINDOWPOSCHANGED, sent|wparam, SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE }, /* in the 1st MDI child */ > { 0 } > }; > Sorry! It falls in my Windows XP SP2 with: msg.c:3267:expected 0009 - actual 0009 msg.c:3267:expected 0008 - actual 0008 msg.c:3267:expected 0281 - actual 0007 msg.c:3267: Test failed: Child did not switch correctly: the msg 0x0281 was expected, but got msg 0x0007 instead msg.c:3268:end of test for switch maximized MDI children -- Best regards Anatoly Lyutin.

Sept. 25, 2007

Re: widl [2/6]: Fix conformant array test failures

by Alexandre Julliard

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > This patch gets conformant arrays working in the tests. Currently, only > the address of some conformant arrays are being marshalled, and this wasn't > showing up in the tests because some storage was static. This patch fixes > the problem by writing pointers to conformant array types in the format > string. This also requires handling field pointer conformances, and > expression evaluation routines that expect the containing structure of a > conformant array at the top of the stack, rather than the conformant array > itself. With this patch, the tests still pass, but correctly this time. It breaks the ole32 tests: ../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so moniker.c && touch moniker.ok moniker.c:897: Test failed: IRunningObjectTable_EnumRunning hr=800703e6 wine: Unhandled page fault on read access to 0x00000000 at address 0x60527ff6 (thread 0010), starting debugger... WineDbg starting on pid 000f Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x60527ff6). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:60527ff6 ESP:0033fa90 EBP:0033fe58 EFLAGS:00010206( - 00 - RIP1) EAX:0033fe30 EBX:6054601c ECX:00000000 EDX:00000000 ESI:800703e6 EDI:6053e4ec Stack dump: 0x0033fa90: 00000000 6053e498 800703e6 60542308 0x0033faa0: 0033fe34 00000100 00000000 00000000 0x0033fab0: 60547478 60547474 6053cdc8 0033fe48 0x0033fac0: 0033fe44 0033fe40 0033fe38 0033fe20 0x0033fad0: 6053d190 60542308 0033fe14 6053e720 0x0033fae0: 6053e2dc 60539d74 6053e154 60539de8 Backtrace: =>1 0x60527ff6 func_moniker+0x15f6() [/home/julliard/wine/wine/dlls/ole32/tests/moniker.c:898] in ole32_test (0x0033fe58) 2 0x60538df8 run_test+0x128(name=0x1103ce) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:389] in ole32_test (0x0033fea8) 3 0x6053948d main+0x14d(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:437] in ole32_test (0x0033fed8) 4 0x6053955b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ole32_test (0x0033ff08) 5 0x7b87446e start_process+0xee(arg=0x0) [/home/julliard/wine/wine/dlls/kernel32/process.c:839] in kernel32 (0x0033ffe8) 6 0x600289a7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x60527ff6 func_moniker+0x15f6 [/home/julliard/wine/wine/dlls/ole32/tests/moniker.c:898] in ole32_test: movl 0x0(%edx),%ecx 898 hr = IEnumMoniker_QueryInterface(spEM1, &IID_IUnknown, (void*) &lpEM1); Wine-dbg> -- Alexandre Julliard julliard(a)winehq.org

Sept. 25, 2007

Re: mpr: Changes comparison of dwScope in WNetOpenEnum function

by Konstantin Kondratyuk

Hello, Juan! > Hi Konstantin, > > - providerTable->table[index].dwEnumScopes > & dwScope) > + providerTable->table[index].dwEnumScopes > & WNNC_ENUM_GLOBAL) > > This change looks correct, but it should be changed in the next block as > well: > > ret = providerTable->table[index].openEnum( > dwScope, dwType, dwUsage, lpNet, &handle); > > It also looks incorrect in _enumerateGlobalPassthroughW: > ret = providerTable->table[enumerator->providerIndex]. > openEnum(enumerator->dwScope, enumerator->dwType, > enumerator->dwUsage, enumerator->lpNet, > &enumerator->handle); > > In fact, all of these usages of dwScope look to confuse the two > meanings. (D'oh.) > --Juan Well, I have looked all code in mpr/wnet.c The following condition in _globalEnumeratorAdvance() looks incorrect: for (; enumerator->providerIndex < providerTable->numProviders && !(enumerator->dwScope & providerTable->table [enumerator->providerIndex].dwEnumScopes); enumerator->providerIndex++) Other conditions and parameters look correctly. For example, function NPOpenEnum() expects a dwScope, containing RESOURCE_CONNECTED, RESOURCE_GLOBALNET or RESOURCE_CONTEXT. Correct for me if I am not right. -- Best regards, Konstantin Kondratyuk.

Sept. 25, 2007

Re: mpr: Changes comparison of dwScope in WNetOpenEnum function

by Juan Lang

Hi Konstantin, - providerTable->table[index].dwEnumScopes & dwScope) + providerTable->table[index].dwEnumScopes & WNNC_ENUM_GLOBAL) This change looks correct, but it should be changed in the next block as well: ret = providerTable->table[index].openEnum( dwScope, dwType, dwUsage, lpNet, &handle); It also looks incorrect in _enumerateGlobalPassthroughW: ret = providerTable->table[enumerator->providerIndex]. openEnum(enumerator->dwScope, enumerator->dwType, enumerator->dwUsage, enumerator->lpNet, &enumerator->handle); In fact, all of these usages of dwScope look to confuse the two meanings. (D'oh.) --Juan

Sept. 24, 2007

Re: CryptAcquireContext Failure, default/Type 024 requested

by Rob Seger

Sweet! Thanks! I'll see what I can do and probably end up asking some more specific questions later ;) Rob On 9/24/07, Juan Lang <juan.lang(a)gmail.com> wrote: > > I found the wincrypt.h #define line that says what type 024 > > is: #define PROV_RSA_AES 24. > > In that case, it should be straightforward enough to add an AES > implementation to Wine's rsaenh.dll. There's free (as in speech) > source available for it. Take a look at rsaenh.c and implglue.c in > dlls/rsaenh; you'd want to add it as a new block cipher. > > --Juan >

Sept. 24, 2007

Re: CryptAcquireContext Failure, default/Type 024 requested

by Juan Lang

> I found the wincrypt.h #define line that says what type 024 > is: #define PROV_RSA_AES 24. In that case, it should be straightforward enough to add an AES implementation to Wine's rsaenh.dll. There's free (as in speech) source available for it. Take a look at rsaenh.c and implglue.c in dlls/rsaenh; you'd want to add it as a new block cipher. --Juan

Sept. 24, 2007

Re: wtsapi32: add stub for WTSRegisterSessionNotification

by Louis. Lenders

Anything wrong with these simple stubs? http://www.winehq.org/pipermail/wine-patches/2007-September/043944.html and http://www.winehq.org/pipermail/wine-patches/2007-September/043945.html ? --------------------------------- Yahoo! Answers - Get better answers from someone who knows. Tryit now.

Sept. 24, 2007

Re: mlang: fix memory leaks in error path (found by Smatch).

by Michael Stefaniuc

Tijl Coosemans wrote: > On Monday 24 September 2007 14:20:51 Lionel_Debroux wrote: >> ConvertINetString leaks some heap memory in an error path. Found in >> Michael Stefaniuc's list of Wine potential bugs detected by Smatch. >> >> 2007-09-24 Lionel Debroux <lionel_debroux(a)yahoo.fr> >> * dlls/mlang/mlang.c: >> mlang: fix memory leaks in error path (found by Smatch). >> >> diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c >> index eb14ad0..c6274c5 100644 >> --- a/dlls/mlang/mlang.c >> +++ b/dlls/mlang/mlang.c >> @@ -635,9 +635,10 @@ HRESULT WINAPI ConvertINetString( >> pDstStrW = HeapAlloc(GetProcessHeap(), 0, cDstSizeW * sizeof(WCHAR)); >> hr = ConvertINetMultiByteToUnicode(pdwMode, dwSrcEncoding, pSrcStr, pcSrcSize, pDstStrW, &cDstSizeW); >> if (hr != S_OK) >> - return hr; >> + goto cleanup; >> >> hr = ConvertINetUnicodeToMultiByte(pdwMode, dwDstEncoding, pDstStrW, &cDstSizeW, pDstStr, pcDstSize); >> +cleanup: >> HeapFree(GetProcessHeap(), 0, pDstStrW); >> return hr; >> } > > This is a bikeshed issue really, but I wonder what Wine's policy on > gotos like this is. Imo, it's better to add the HeapFree call to the if > block and let the compiler work it out. It really depends on the code. If you have a lot of error paths with a lot of cleanup to do in them then gotos are way cleaner and easier to read. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

Sept. 24, 2007

Re: Would like to contribute to wine

by Roderick Colenbrander

> > Correct but we don't have it in Wine. If we added the Drv functions, > > while I have the parts of the DIB engine unimplemented, I could > > forward back to the driver alot easier. There is maybe another way, > > but having Drv functions make sense in my mind. > > That would be perfect (IMHO), when our Drivers (winex11, wineps) use > DDI as API. > I dont know our Driver-Code in this Area good enough, but I expect that > this big change need a lot of testing. > > > > > Also, I wonder how your Eng* functions would integrate with the dib > > > > engine I'm writing > > > > > > The main Problem with the Rendering-API in Wine > > > (between GDI and our Drivers: winex11, wineps, mfdrv, enhmfdrv) > > > is more like win3x and far away from DDI (Device Driver Interface). > > > > > > > Do the Eng functions have to be based on DDI? Or can we use it with my > > DIB engine? > > The DIB-Engine on Windows are the main Part behind Eng* and Friends and > MS defined DDI as API for that. > I had no time yet to look in your DIB-Engine. Moving to DDI could mean huge changes. The DDI is documented (for a part on msdn) but for the rest I think in driver docs. Transgaming for instance also used the DDI for their DirectX support but at some stage they didn't continue with it because of changes in licensing. So I would watch out with it. Second if you are interested in this area, I would say skip DDI and start doing things the Vista-way. I'm not sure how DDI works there but in the end everything is layered on top of directx. (of course not the standard ddraw/d3d functions) I would check how Vista is doing things. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Sept. 24, 2007

Re: Does MWM_DECOR_BORDER really cause window to have caption?

by Kirill K. Smirnov

> > Anyway, what is the purpose of setting MWM_DECOR_BORDER to borderless > > window (style is WS_CLIPSIBLINGS only)? KDE, XFCE, fluxbox work OK > > without it. > > If you mean the following line in > dlls/winex11.drv/window.c,X11DRV_set_wm_hints() > > else if (!(style & (WS_CHILD|WS_POPUP))) mwm_hints.decorations |= > MWM_DECOR_BORDER; > > then you can always send a patch with an explanation why it's needed. Of course, I can send a patch, which just removes this line with some explanations (referring to winamp), but I'm afraid it may break something. Since original patch introduced this code, there is an application which depends on this. But that original patch does not contain any hint, so I ask the list in hope somebody might know the reason. -- Kirill

Sept. 24, 2007

Re: mlang: fix memory leaks in error path (found by Smatch).

by Dmitry Timoshkov

"Tijl Coosemans" <tijl(a)ulyssis.org> wrote: > > hr = ConvertINetMultiByteToUnicode(pdwMode, dwSrcEncoding, pSrcStr, pcSrcSize, pDstStrW, &cDstSizeW); > > if (hr != S_OK) > > - return hr; > > + goto cleanup; > > > > hr = ConvertINetUnicodeToMultiByte(pdwMode, dwDstEncoding, pDstStrW, &cDstSizeW, pDstStr, pcDstSize); > > +cleanup: > > HeapFree(GetProcessHeap(), 0, pDstStrW); > > return hr; > > } > > This is a bikeshed issue really, but I wonder what Wine's policy on > gotos like this is. Imo, it's better to add the HeapFree call to the if > block and let the compiler work it out. In this particular case goto should be avoided IMO by rewriting code snippet like below: if (hr == S_OK) hr = ConvertINetUnicodeToMultiByte(...); -- Dmitry.

Sept. 24, 2007

Re: mlang: fix memory leaks in error paths (found by Smatch).

by Lionel_Debroux

Lionel_Debroux wrote: > EnumRfc1766_create leaks some heap memory in two error paths. Found in > Michael Stefaniuc's list of Wine potential bugs detected by Smatch. > > 2007-09-24 Lionel Debroux <lionel_debroux(a)yahoo.fr> > * dlls/mlang/mlang.c: > mlang: fix memory leaks in error paths (found by Smatch). > > > > ------------------------------------------------------------------------ > >>From 394f63633148d76fa322b726218e8a824e5a3930 Mon Sep 17 00:00:00 2001 > From: Lionel Debroux <lionel_debroux(a)yahoo.fr> > Date: Mon, 24 Sep 2007 14:12:10 +0200 > Subject: mlang: fix memory leaks in error paths (found by Smatch). > > --- > dlls/mlang/mlang.c | 13 +++++++++++-- > 1 files changed, 11 insertions(+), 2 deletions(-) > > diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c > index b5b8e0d..eb14ad0 100644 > --- a/dlls/mlang/mlang.c > +++ b/dlls/mlang/mlang.c > @@ -1885,7 +1885,11 @@ static HRESULT EnumRfc1766_create(MLang_impl* mlang, LANGID LangId, > data.total = 0; > data.allocated = 32; > data.info = HeapAlloc(GetProcessHeap(), 0, data.allocated * sizeof(RFC1766INFO)); > - if (!data.info) return S_FALSE; > + if (!data.info) > + { > + HeapFree(rfc); > + return S_FALSE; > + } > > TlsSetValue(MLANG_tls_index, &data); > EnumSystemLocalesW(enum_locales_proc, 0/*LOCALE_SUPPORTED*/); > @@ -1893,7 +1897,12 @@ static HRESULT EnumRfc1766_create(MLang_impl* mlang, LANGID LangId, > > TRACE("enumerated %d rfc1766 structures\n", data.total); > > - if (!data.total) return FALSE; > + if (!data.total) > + { > + HeapFree(data.info); > + HeapFree(rfc); > + return FALSE; > + } > > rfc->info = data.info; > rfc->total = data.total; Err, screw that. The two first parameters "GetProcessHeap(), 0, " of the three HeapFree calls are missing... I did not forget to launch a make process to check my modifications were correct, though. What happened was that everything was recompiled, and by the time the compiler complained, I had already sent the mails by mistake... Sorry. Lionel Debroux.

Sept. 24, 2007

Re: pdh: add tests for XP variant of api call

by Hans Leidekker

On Monday 24 September 2007 14:20:12 Jeff Latimer wrote: > > All tests succeed here on 2003 without your patch. > That means that they must be XP specific. I noticed some vista specfic > bugs bugs being reported. The failures on Vista are at least in part different from XPs because of insufficient privileges. > From this we should write tests to accept all values. It would seem > that the wine dll still needs to implement the API accurately, so you > are saying, code the API correctly but make the tests generic? Quote from MSDN on PdhLookupPerfNameByIndex: PDH_INVALID_ARGUMENT A parameter is not valid or is incorrectly formatted. For example, on some releases you could receive this error if the specified size on input is greater than zero but less than the required size. So we should accept this return value too. Our implemention is fine as-is because it still passes the test. Note that there is another problem with the tests which is that performance counter names are localized but the tests assume that the current locale is English. I intend to fix this in my next batch of patches. -Hans

Sept. 24, 2007

Re: Does MWM_DECOR_BORDER really cause window to have caption?

by Dmitry Timoshkov

"Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: >> There is a distinct MWM hint to add a caption to a window: MWM_DECOR_TITLE. >> If this is proved to be a KDE/XFCE bug it should be reported to an >> appropriate bug tracking system. > > It's better to write pure X11 app to demonstate it, but I am not familiar with > it :-( You can always take a simple X11 application as a base (I usually take xev.c from X11 sources :-) ) and add the code from winex11.drv. > Anyway, what is the purpose of setting MWM_DECOR_BORDER to borderless window > (style is WS_CLIPSIBLINGS only)? KDE, XFCE, fluxbox work OK without it. If you mean the following line in dlls/winex11.drv/window.c,X11DRV_set_wm_hints() else if (!(style & (WS_CHILD|WS_POPUP))) mwm_hints.decorations |= MWM_DECOR_BORDER; then you can always send a patch with an explanation why it's needed. -- Dmitry.

Sept. 24, 2007

Re: The Spouse Test

by Tim Schmidt

On 9/24/07, Stephan Rose <kermos(a)somrek.net> wrote: > That reminds me, one of the things I personally would love to see Wine > support is Solidworks. It's about the only thing at work I still need to > boot into Windows for occasionally. Same here. > Solidworks actually installs now, it didn't earlier this year. And > actually, the most recent version of wine even allows it to run about 5 > seconds longer than the previous version, which is a definite > improvement. =) Which version(s) are you using? Could you please update the AppDB? --tim

Sept. 24, 2007

Re: mlang: fix memory leaks in error path (found by Smatch).

by Tijl Coosemans

On Monday 24 September 2007 14:20:51 Lionel_Debroux wrote: > ConvertINetString leaks some heap memory in an error path. Found in > Michael Stefaniuc's list of Wine potential bugs detected by Smatch. > > 2007-09-24 Lionel Debroux <lionel_debroux(a)yahoo.fr> > * dlls/mlang/mlang.c: > mlang: fix memory leaks in error path (found by Smatch). > > diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c > index eb14ad0..c6274c5 100644 > --- a/dlls/mlang/mlang.c > +++ b/dlls/mlang/mlang.c > @@ -635,9 +635,10 @@ HRESULT WINAPI ConvertINetString( > pDstStrW = HeapAlloc(GetProcessHeap(), 0, cDstSizeW * sizeof(WCHAR)); > hr = ConvertINetMultiByteToUnicode(pdwMode, dwSrcEncoding, pSrcStr, pcSrcSize, pDstStrW, &cDstSizeW); > if (hr != S_OK) > - return hr; > + goto cleanup; > > hr = ConvertINetUnicodeToMultiByte(pdwMode, dwDstEncoding, pDstStrW, &cDstSizeW, pDstStr, pcDstSize); > +cleanup: > HeapFree(GetProcessHeap(), 0, pDstStrW); > return hr; > } This is a bikeshed issue really, but I wonder what Wine's policy on gotos like this is. Imo, it's better to add the HeapFree call to the if block and let the compiler work it out.

Sept. 24, 2007

Re: Does MWM_DECOR_BORDER really cause window to have caption?

by Kirill K. Smirnov

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > > I'm trying to get winamp playlist window to be painted correctly (bug > > #8300). The problem is: > > 0) wine version is git-current. > > 1) winamp playlist window style is WS_CLIPSIBLINGS > > 2) winex11 driver converts it to MWM_DECOR_BORDER hint. (window.c:599) > > 3) This hint behaviour is WM-dependent: > > a) KDE - caption is painted; > > b) XFCE - ditto; > > c) fluxbox - correct (no caption). > > > > This situation confuses a little. I believe DECOR_BORDER does not add a > > caption to window, but it does under great WM such as KDE. Is this > > behaviour correct? If KDE/XFCE is a culprit, should we add a workaround > > into wine? > > There is a distinct MWM hint to add a caption to a window: MWM_DECOR_TITLE. > If this is proved to be a KDE/XFCE bug it should be reported to an > appropriate bug tracking system. It's better to write pure X11 app to demonstate it, but I am not familiar with it :-( Anyway, what is the purpose of setting MWM_DECOR_BORDER to borderless window (style is WS_CLIPSIBLINGS only)? KDE, XFCE, fluxbox work OK without it. -- Kirill

Sept. 24, 2007

Re: The Spouse Test

by Stephan Rose

On Sun, 2007-09-23 at 00:44 -0700, Dan Kegel wrote: > When will Wine be good enough for the average person to use? > One test is, "Is it good enough to let your spouse migrate to Linux > from Windows?". > My wife's must-have app list is roughly > > Microsoft Office '97 > Adobe Photoshop Elements 1 > Ulead PhotoImpact > Macromedia Dreamweaver 8 > Musicmatch Jukebox 8 > FamilyTreeMaker 2006 > > And you know what? All of those basically work > except for Photoshop Elements. They need some > cosmetic work, and a native DLL or two, and probably a few > obscure bugfixes, but I think that's it. > (I didn't test Office '97, since I expect she'll be using Crossover > for that, as Codeweavers tests that app pretty well.) > > It's possible that by this time next year Wine will pass this test for me. > - Dan That reminds me, one of the things I personally would love to see Wine support is Solidworks. It's about the only thing at work I still need to boot into Windows for occasionally. Solidworks actually installs now, it didn't earlier this year. And actually, the most recent version of wine even allows it to run about 5 seconds longer than the previous version, which is a definite improvement. =) Stephan

Sept. 24, 2007

Re: pdh: add tests for XP variant of api call

by Jeff Latimer

Hans Leidekker wrote: > On Monday 24 September 2007 12:13:50 Jeff Latimer wrote: > > All tests succeed here on 2003 without your patch. That means that they must be XP specific. I noticed some vista specfic bugs bugs being reported. > Even if APIs return > different values on different versions of Windows we should not add version > checks. Instead we should accept all possible return values or remove the > test altogether when it's clear that you cannot depend on specific return > values. > From this we should write tests to accept all values. It would seem that the wine dll still needs to implement the API accurately, so you are saying, code the API correctly but make the tests generic? Jeff

Sept. 24, 2007

Re: pdh: add tests for XP variant of api call

by Hans Leidekker

On Monday 24 September 2007 12:13:50 Jeff Latimer wrote: > This patch adds the variations to the api that XP implements. My > assumption is that these changes will, mostly, be reflected in 2003 and > Vista. I can't check them so if someone could give them a run and let > know, that would be fine. I will get on with adding the variations to pdh.c All tests succeed here on 2003 without your patch. Even if APIs return different values on different versions of Windows we should not add version checks. Instead we should accept all possible return values or remove the test altogether when it's clear that you cannot depend on specific return values. -Hans

Sept. 24, 2007

Re: pdh: add tests for XP variant of api call

by Jeff Latimer

Hans Leidekker wrote: > On Monday 24 September 2007 12:13:50 Jeff Latimer wrote: > >> I will get on with adding the variations to pdh.c >> > To prevent you doing any duplicate work, I have implementations > of PdhCalculateCounterFromRawValue, PdhCollectQueryDataEx and > PdhValidatePath{,Ex} in my tree, along with a range of tests That sounds good, I'll confine myself to implementing code for these tests. Jeff

Sept. 24, 2007

Re: pdh: add tests for XP variant of api call

by Hans Leidekker

On Monday 24 September 2007 12:13:50 Jeff Latimer wrote: > This patch adds the variations to the api that XP implements. My > assumption is that these changes will, mostly, be reflected in 2003 and > Vista. I can't check them so if someone could give them a run and let > know, that would be fine. I will get on with adding the variations to pdh.c To prevent you doing any duplicate work, I have implementations of PdhCalculateCounterFromRawValue, PdhCollectQueryDataEx and PdhValidatePath{,Ex} in my tree, along with a range of tests. -Hans

Sept. 24, 2007

Re: Would like to contribute to wine

by Detlef Riekenberg

On So, 2007-09-23 at 17:15 -0600, Jesse Allen wrote: > Correct but we don't have it in Wine. If we added the Drv functions, > while I have the parts of the DIB engine unimplemented, I could > forward back to the driver alot easier. There is maybe another way, > but having Drv functions make sense in my mind. That would be perfect (IMHO), when our Drivers (winex11, wineps) use DDI as API. I dont know our Driver-Code in this Area good enough, but I expect that this big change need a lot of testing. > > > Also, I wonder how your Eng* functions would integrate with the dib > > > engine I'm writing > > > > The main Problem with the Rendering-API in Wine > > (between GDI and our Drivers: winex11, wineps, mfdrv, enhmfdrv) > > is more like win3x and far away from DDI (Device Driver Interface). > > > > Do the Eng functions have to be based on DDI? Or can we use it with my > DIB engine? The DIB-Engine on Windows are the main Part behind Eng* and Friends and MS defined DDI as API for that. I had no time yet to look in your DIB-Engine. -- By by ... Detlef

Sept. 24, 2007

Re: Does MWM_DECOR_BORDER really cause window to have caption?

by Dmitry Timoshkov

"Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > I'm trying to get winamp playlist window to be painted correctly (bug #8300). > The problem is: > 0) wine version is git-current. > 1) winamp playlist window style is WS_CLIPSIBLINGS > 2) winex11 driver converts it to MWM_DECOR_BORDER hint. (window.c:599) > 3) This hint behaviour is WM-dependent: > a) KDE - caption is painted; > b) XFCE - ditto; > c) fluxbox - correct (no caption). > > This situation confuses a little. I believe DECOR_BORDER does not add a > caption to window, but it does under great WM such as KDE. Is this behaviour > correct? If KDE/XFCE is a culprit, should we add a workaround into wine? There is a distinct MWM hint to add a caption to a window: MWM_DECOR_TITLE. If this is proved to be a KDE/XFCE bug it should be reported to an appropriate bug tracking system. -- Dmitry.

Sept. 24, 2007

Re: Is ICU no longer a dependency of Wine?

by Maarten Lankhorst

Scott Ritchie schreef: > I stumbled across this patch while browsing recent commits: > > http://www.winehq.org/pipermail/wine-cvs/2007-September/036309.html > > Am I correct to say that we no longer need libicu when compiling Wine? > > > By the way, it would be nice if someone shot off an email to wine-devel > whenever the build dependencies change (either removing or adding a lib) > -- it makes it a lot easier on we package maintainers. > Yes. Next time I'll send a message to wine-devel if I change a build dependency. Cheers, Maarten

Sept. 24, 2007

Does MWM_DECOR_BORDER really cause window to have caption?

by Kirill K. Smirnov

Hi, I'm trying to get winamp playlist window to be painted correctly (bug #8300). The problem is: 0) wine version is git-current. 1) winamp playlist window style is WS_CLIPSIBLINGS 2) winex11 driver converts it to MWM_DECOR_BORDER hint. (window.c:599) 3) This hint behaviour is WM-dependent: a) KDE - caption is painted; b) XFCE - ditto; c) fluxbox - correct (no caption). This situation confuses a little. I believe DECOR_BORDER does not add a caption to window, but it does under great WM such as KDE. Is this behaviour correct? If KDE/XFCE is a culprit, should we add a workaround into wine? Thanks for attention -- Kirill

Sept. 24, 2007

Re: [2/5] WineD3D: Recompile glsl pixelshaders if the sampler format changes

by Stefan Dösinger

Am Sonntag, 23. September 2007 22:23:06 schrieb Vitaliy Margolen: > Stefan Dösinger wrote: > > ------------------------------------------------------------------------ > > This patch causes noticeable slowdown in Counter Strike Source stress test > in the first part of it (rotating panels). Testing in dxlevel 80, 1024x768 > fbo, cl_monitors 0. I'm getting ~33 fps in that area before patch and > around 7 fps with this patch. > > Vitaliy. Vitaliy did some more testing on IRC, and it turned out that hl2 switches between D3DFMT_V8U8 and D3DFMT_X8R8G8B8 bump maps. I don't know what hl2 intends with a X8R8G8B8 bump map. I think the best thing to do is to ignore the blue channel difference in V8U8 and put it into the D3DFMT_UNKNOWN conversion group until we find a game that depends on blue = 1.0 If we find a game that runs into problems because of constant recompiling which cannot be avoided, we should keep multiple gl shaders, for each possible setting. I don't want to do this until we need it because managing multiple shaders means overhead too.

Sept. 24, 2007

Re: strange pixel format

by Stefan Dösinger

Am Sonntag, 23. September 2007 05:20:06 schrieb Jose Osvaldo: > The No-CD crack for "The Sims" calls to "IDirectDrawImpl_CreateSurface" > (ddls/ddraw.c) which calls to "IDirectDrawImpl_CreateNewSurface". Is this behavior added by the nocd crack? > The abnormal value is this: > > dwFlags = 0x00000000 > dwSize = 32 > dwFourCC = 0x00000000 > u1 = 0x00000000 > u2 = 0x00000000 > u3 = 0x00000000 > u4 = 0x00000000 > u5 = 0x00000000 > > I do not know what is the expected behaviour in real Windows. The original > executable file crashes with other error, but I think that is caused by the > anticopy protection. Can check the full surface description the game passes? Perhaps there are some settings in there that should implicitly provie a pixel format

Sept. 24, 2007

Is ICU no longer a dependency of Wine?

by Scott Ritchie

I stumbled across this patch while browsing recent commits: http://www.winehq.org/pipermail/wine-cvs/2007-September/036309.html Am I correct to say that we no longer need libicu when compiling Wine? By the way, it would be nice if someone shot off an email to wine-devel whenever the build dependencies change (either removing or adding a lib) -- it makes it a lot easier on we package maintainers. Thanks, Scott Ritchie

Sept. 24, 2007

Re: Would like to contribute to wine

by Jesse Allen

On 9/23/07, Detlef Riekenberg <wine.dev(a)web.de> wrote: > On Mo, 2007-09-10 at 10:06 -0600, Jesse Allen wrote: > > > What about the Drv* functions? > > Drv* are implemented by the Driver, while Eng* and Friends are > the Graphic Rendering Engine (on windows in win32k.sys). > The Exports in GDI are parts of the GRE for Usermode Printer Drivers. > Correct but we don't have it in Wine. If we added the Drv functions, while I have the parts of the DIB engine unimplemented, I could forward back to the driver alot easier. There is maybe another way, but having Drv functions make sense in my mind. > > Also, I wonder how your Eng* functions would integrate with the dib > > engine I'm writing > > The main Problem with the Rendering-API in Wine > (between GDI and our Drivers: winex11, wineps, mfdrv, enhmfdrv) > is more like win3x and far away from DDI (Device Driver Interface). > Do the Eng functions have to be based on DDI? Or can we use it with my DIB engine? Jesse

Sept. 23, 2007

Re: WineD3D surface management cleanup

by Stefan Dösinger

Am Sonntag, 23. September 2007 00:34:56 schrieb Roderick Colenbrander: > > Hi, > > > > This mail is mainly addressed at Henri and Roderick, but I'll send it > > here to > > allow others to read it too. > > > > These patches contain some cleanups of the d3d surface loading code. It's > > main > > aim is to put the code that copies the surface between system memory, > > texture > > and drawable into a centralized place, make LockRect simpler and pbo > > creation > > and surface memory allocation in one place(surface allocation is not > > completely there yet). It also makes other parts of the code simpler, > > avoids > > playing with the surface flags in other places, and it will allow us to > > centralize the logic that in the case of fbo offscreen rendering the > > drawable > > is the same as the texture(This is also not implemented yet). > > > > The patches don't aim at fixing any bugs themselves, and I hardly tested > > them, > > so there may be a truckload of regressions. I'm mainly showing them to > > show > > the general direction I'm heading into. > > I have taken a quick look at it. I think it looks ok (I don't fully > understand all changes though but that's because I didn't know the old code > that well yet). > > What I have been wondering why remove flush_to_framebuffer_texture? In > ddraw opengl it is a very useful mode. From what I have seen on modern > cards textures seem to outperform drawpixels. Ah, sorry for not explaining this. It is temporarily removed to make the move easier. There is a comment in LockRect explaining how two RequestLocation calls can be used to get the same thing flush_to_framebuffer_texture does, but this requires the last of the 6 copy types(texture->drawable) to be implemented, either using the code from drawprim.c, blt_to_drawable or the flush_to_framebuffer_texture code.

Sept. 23, 2007

Re: WineD3D surface management cleanup

by Stefan Dösinger

Am Sonntag, 23. September 2007 01:29:32 schrieb H. Verbeet: > The general direction of the patches seems ok, although I'm not sure > if RequestLocation / ModifyLocation is optimal from a naming point of > view. (Ie, RequestLocation typically moves data rather than returning > a location for the caller to read/write to, while ModifyLocation just > flips a flag rather than modifying the location of the actual data) Does LoadLocation sound better? I'm open to suggestions :-) > OT(?): Wrt. regressions, I would like to mention that I think that in > general more care should be taken to verify a patch is correct when > *writing* the patch. I do sometimes get the feeling that the general > approach taken is one of "Throw some patches at it, see what sticks" I admit that sometimes I am toying with the "see what sticks" approach, especially if I do not have access to the application the issue is about(e.g. Pirates! with the alpha fix in unlockrect). Otherwise I'm doing my best to make sure that the patch is correct when writing it, and often I write a regression test for it too. However, some areas are a bit too complex to proove that a patch is correct. Like in the surface code, where we have the interactions of FBOs, PBOs, apple_client_storage, various known driver bugs, surface conversion, performance considerations, etc(*). It's plainly impossible to make sure there are no regressions. So my "there will be tons of regressions" note was meant as a "I think the patches are correct, but I feel uncomfortable to send them in without testing" rather than "I have no idea if that works". FWIW, I have found only one problem so far, an issue in Battlefield 1942, which interestingly shows up in my Vista installation too. Usually our continuously growing test suit does a good job in catching most problems. (*): Before someone(ohsix ;-) ) suggests to use DDI with its perfectly defined resource management: Feel free to suggest a redesign that abstracts all this(including the driver bugs), I'd be thankful for one. But please describe it in your own words, a link to the DDI docs doesn't count(there are license issues too, propably).

Sept. 23, 2007

Re: [4/5] WGL: Remove GL scissors/viewport override

by Chris Robinson

On Sunday 23 September 2007 03:00:24 pm Vitaliy Margolen wrote: > Chris Robinson wrote: > > ------------------------------------------------------------------------ > > This patch causes crash with virtual desktop. Crash attached. > > Vitaliy. Duh, I see what app (very observant, am I). I don't know, it works for me.. both winecfg, switching through the tabs, and the other app I tested. Are you sure you properly recompiled everything? Don't forget to run autoconf and autoheader.

Sept. 23, 2007

Re: [4/5] WGL: Remove GL scissors/viewport override

by Chris Robinson

On Sunday 23 September 2007 03:00:24 pm Vitaliy Margolen wrote: > Chris Robinson wrote: > > ------------------------------------------------------------------------ > > This patch causes crash with virtual desktop. Crash attached. What app? I reverted back to that commit and ran an app with virtual desktop enabled that uses a gl child, and it ran as expected (no crash, bad GL display).

Sept. 23, 2007