September 2015 - Wine-Devel

Re: rsaenh/tests: Adjust length value to pass on Win 10 (try 2) (resend)

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 https://testbot.winehq.org/JobDetails.pl?Key=16918 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

Sept. 30, 2015

libosmesa bitness

by André Hentschel

Hi, Does someone can tell which version of libosmesa Wine needs? You can build libosmesa for 8, 16 or 32 channel bits puk suspects we need the 42 bits version ;) 8 is the default and it seems to me we want that, so can someone confirm that?

Sept. 30, 2015

Re: [PATCH] usp10/tests: fix some tests on Hebrew and Arabic locales

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 https://testbot.winehq.org/JobDetails.pl?Key=16916 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1)

Sept. 30, 2015

Re: [PATCH] secur32/tests: handle skip cleanup in negotiate more cleanly

by Aric Stewart

On 9/30/15 11:07 AM, Nikolay Sivov wrote: > On 30.09.2015 19:04, Aric Stewart wrote: >> Signed-off-by: Aric Stewart <aric(a)codeweavers.com> >> --- >> dlls/secur32/tests/negotiate.c | 31 +++++++++++++++++++++++-------- >> 1 file changed, 23 insertions(+), 8 deletions(-) >> > > >> - status_c = pDeleteSecurityContext( &client.ctxt ); >> - ok( status_c == SEC_E_OK, "DeleteSecurityContext returned %08x\n", status_c ); >> + if (client.ctxt.dwLower || client.ctxt.dwUpper) >> + { >> + status_c = pDeleteSecurityContext( &client.ctxt ); >> + ok( status_c == SEC_E_OK, "DeleteSecurityContext returned %08x\n", status_c ); >> + } > > Why is this a problem only on macos? > > No idea, Again I was trying to turn a crash into a cleaner failure. -aric

Sept. 30, 2015

Re: [PATCH] windowscodecs/tests: handle failure to create png decoder

by Aric Stewart

On 9/30/15 11:08 AM, Vincent Povirk wrote: >> If this is about fixing macos failures, Vincent pointed out that there was a >> decision at some point to fix broken builds and not to workaround that in >> test code. > > AFAICT this patch won't actually prevent failures, just skip later > tests after the failure so they don't crash. > > Correct. I am leaving in the failures because I agree they are important. I just want to have it register as a failure and not as a crash. -aric

Sept. 30, 2015

Re: [PATCH] windowscodecs/tests: handle failure to create png decoder

by Vincent Povirk

> If this is about fixing macos failures, Vincent pointed out that there was a > decision at some point to fix broken builds and not to workaround that in > test code. AFAICT this patch won't actually prevent failures, just skip later tests after the failure so they don't crash.

Sept. 30, 2015

Re: [PATCH] secur32/tests: handle skip cleanup in negotiate more cleanly

by Nikolay Sivov

On 30.09.2015 19:04, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/secur32/tests/negotiate.c | 31 +++++++++++++++++++++++-------- > 1 file changed, 23 insertions(+), 8 deletions(-) > > - status_c = pDeleteSecurityContext( &client.ctxt ); > - ok( status_c == SEC_E_OK, "DeleteSecurityContext returned %08x\n", status_c ); > + if (client.ctxt.dwLower || client.ctxt.dwUpper) > + { > + status_c = pDeleteSecurityContext( &client.ctxt ); > + ok( status_c == SEC_E_OK, "DeleteSecurityContext returned %08x\n", status_c ); > + } Why is this a problem only on macos?

Sept. 30, 2015

Re: [PATCH] windowscodecs/tests: handle failure to create png decoder

by Nikolay Sivov

On 30.09.2015 18:54, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/windowscodecs/tests/pngformat.c | 4 ++++ > 1 file changed, 4 insertions(+) > If this is about fixing macos failures, Vincent pointed out that there was a decision at some point to fix broken builds and not to workaround that in test code.

Sept. 30, 2015

Re: [2/2 v3] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION.

by Ken Thomases

Hi, On Sep 30, 2015, at 9:04 AM, Jactry Zeng <jactry92(a)gmail.com> wrote: > 2015-09-30 17:05 GMT+08:00 Ken Thomases <ken(a)codeweavers.com>: > >> Since FlashWindowEx() is the more general function — that is, FlashWindow() could be fully implemented in terms of FlashWindowEx(), but not the other way around — shouldn't the driver entry point be FlashWindowEx()? Otherwise, when FlashWindowEx() is eventually implemented more completely, the driver entry will have to be changed. >> >> For now, since user32 implements FlashWindow() but FlashWindowEx() is a stub (or semi-stub after your next patch), FlashWindow() would have to create a FLASHWINFO structure, fill it in, and pass that along. I think that dwFlags would be either FLASHW_ALL or FLASHW_STOP, depending on bInvert. uCount would be 1, I guess. > Thanks for your review! You're welcome! > Yes, function() will be implemented by functionEx() commonly in Wine. > But I didn't find a perfect way to implement FlashWindowEx() and then implement FlashWindow() with FlashWindowEx(). I wasn't suggesting that you necessarily implement FlashWindow() in terms of FlashWindowEx(). Just that you model the driver entry function after FlashWindowEx() instead of FlashWindow(). If the driver doesn't implement the full semantics of FlashWindowEx(), that's OK. It's no worse than the semi-stub that FlashWindowEx() will be. > Because in X11, how many times will the window be flashed is depend on design of window manager/desktop environment.(For example, in XFCE, taskbar will always flashes when _NET_WM_STATE_DEMANDS_ATTENTION is sent until the user active the window again; In Ubuntu Unity, it'll only be flashed one time and then highlight taskbar until the user active the window again.) And I don't think it's necessary (and any possible?) to follow Window's design. > In this way, implementing uCount and other parameters may be useless, because all we need to do is sending _NET_WM_STATE_DEMANDS_ATTENTION to WM/DE one time when FlashWindow()/FlashWindowEx() is called. > > Similarly, Windows's FlashWindowEx() can decide which part it want to flash - only flash taskbar or only flash > caption or flash both. But it'll depend on WM/DE's design in X11. It's OK for the driver to implement just that subset of the functionality it's able to. It's not OK for the interface of the driver to prevent the implementation of the full functionality. Don't forget, there are other drivers than X11. The Mac driver may have greater flexibility to more fully implement the functionality (or it may have less). But if the entry point doesn't provide the information, there's no chance for it to do as much as it can. > So I implemented FlashWindowEx() by calling FlashWindow() simply. Again, the way the two functions are implemented at the user32 level is a different question than what the driver interface is. >> Why does FlashWindow() only call the driver entry point if the window is minimized? Shouldn't the driver get the opportunity to act for a non-minimized window, too? > > Same as above, different WM/DE may have different UI effect, that makes it hard to follow Windows's design. > In Windows, different UI effects will be showed when window is minimized and non-minimized. > And in my opinion, it is a little noisy if USER_Driver->pFlashWindow( hWnd, bInvert ) is called all the time. > So I'll prefer to only let the user notice new message when the window is minimized (it may hard to be noticed when > it's minimized). I have the same objection as above. The driver interface should not be designed based on the capabilities of one specific driver (or things like WM/DE behavior, which are specific to that driver). It has to be general enough for any driver. The choices about what the driver actually does should be left to the driver, not user32. You're making choices which unnecessarily limit what the driver can choose. -Ken

Sept. 30, 2015

Re: Videos or Slides from WineConf

by Jactry Zeng

2015-09-30 21:59 GMT+08:00 Stefan Dösinger <stefandoesinger(a)gmail.com>: > > Here they are: > > Alexandre: https://www.youtube.com/watch?v=GTN5ksxzFnE > Jeremy: https://www.youtube.com/watch?v=EzR9RPlWi7c > Michael: https://www.youtube.com/watch?v=QdcFNqWTja4 Cool! Thanks for your work! :) -- Regards, Jactry Zeng

Sept. 30, 2015

Re: [2/2 v3] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION.

by Jactry Zeng

Hi Ken, 2015-09-30 17:05 GMT+08:00 Ken Thomases <ken(a)codeweavers.com>: > > Since FlashWindowEx() is the more general function — that is, FlashWindow() could be fully implemented in terms of FlashWindowEx(), but not the other way around — shouldn't the driver entry point be FlashWindowEx()? Otherwise, when FlashWindowEx() is eventually implemented more completely, the driver entry will have to be changed. > > For now, since user32 implements FlashWindow() but FlashWindowEx() is a stub (or semi-stub after your next patch), FlashWindow() would have to create a FLASHWINFO structure, fill it in, and pass that along. I think that dwFlags would be either FLASHW_ALL or FLASHW_STOP, depending on bInvert. uCount would be 1, I guess. > Thanks for your review! Yes, function() will be implemented by functionEx() commonly in Wine. But I didn't find a perfect way to implement FlashWindowEx() and then implement FlashWindow() with FlashWindowEx(). Because in X11, how many times will the window be flashed is depend on design of window manager/desktop environment.(For example, in XFCE, taskbar will always flashes when _NET_WM_STATE_DEMANDS_ATTENTION is sent until the user active the window again; In Ubuntu Unity, it'll only be flashed one time and then highlight taskbar until the user active the window again.) And I don't think it's necessary (and any possible?) to follow Window's design. In this way, implementing uCount and other parameters may be useless, because all we need to do is sending _NET_WM_STATE_DEMANDS_ATTENTION to WM/DE one time when FlashWindow()/FlashWindowEx() is called. Similarly, Windows's FlashWindowEx() can decide which part it want to flash - only flash taskbar or only flash caption or flash both. But it'll depend on WM/DE's design in X11. So I implemented FlashWindowEx() by calling FlashWindow() simply. > Shouldn't pFlashWindow (or pFlashWindowEx) be added to the USER_DRIVER structure among the "windowing functions" (see the comments), in alphabetical order (after pDestroyWindow)? Of course, that affects the changes to driver.c in terms of where things are added. The order in winex11.drv.spec is less clear, but it seems to be mostly alphabetical after a certain point. I'd put it after EnumClipboardFormats() in that list. Agree. > > Why does FlashWindow() only call the driver entry point if the window is minimized? Shouldn't the driver get the opportunity to act for a non-minimized window, too? > Same as above, different WM/DE may have different UI effect, that makes it hard to follow Windows's design. In Windows, different UI effects will be showed when window is minimized and non-minimized. And in my opinion, it is a little noisy if USER_Driver->pFlashWindow( hWnd, bInvert ) is called all the time. So I'll prefer to only let the user notice new message when the window is minimized (it may hard to be noticed when it's minimized). > For the X11 implementation, shouldn't something potentially remove the _NET_WM_STATE_DEMANDS_ATTENTION state, presumably when bInvert is false (or when dwFlags doesn't include FLASHW_CAPTION or FLASHW_TRAY)? You are right. It seems flashing will be stopped when bInvert is false. I'll improve it for this case. Thanks again! :) -- Regards, Jactry Zeng

Sept. 30, 2015

Re: Videos or Slides from WineConf

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-28 um 16:06 schrieb Julian Rüger: >> Thanks Stefan, I'm really looking forward to watching. >> >> Joel > > +1 Here they are: Alexandre: https://www.youtube.com/watch?v=GTN5ksxzFnE Jeremy: https://www.youtube.com/watch?v=EzR9RPlWi7c Michael: https://www.youtube.com/watch?v=QdcFNqWTja4 I haven't yet worked on Aric's, André's and Qian's talks. Volunteers to work on those videos are welcome, it's a tedious task and after about one week of work I need a break for a while :-) . Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWC+qsAAoJEN0/YqbEcdMwUCQQAITSp51CVLfl4GeO1ILZdUsN MVq+SSRn7Z4YR9QcxDCe0LFY6z5qnDqFqt6WKpIIvxIMB/yJSOi66IwIT+gy9usA 7G1ONAmZJeWH3LWuJ1KvUP04lvzfxj4FM2L1/7fcxOoLANSpcN2C7tlYxvH+KzrN /d1hi6Ea4mjAEmSGhdD4Yx/aEsfd2bBh2adkoHiKMCVM+HmBD5n9Vbvciht0z2jJ vBdtXiuKt63Ojhu0nuo0YYfg7lfIeEchOlVvYDqR67ixoB7E5yMPoLwdIr22YdH2 f5JJ+0Ku13rVjczr9ZOIPAwYUyKTQLAEAjdbcl+8yR/3iwBLgfnv9eolXLJr+hWk BLVc4erJ/+/Cg1Sg1SNX5v8GmZL/crJDNQfCtybii2TUU11nitbn8Bk8AVuZHsZf xwM2xpBRe2nDFimrt0AUrtCtz2zszKnlWsFmen60h4i6GUGiiZxPwF3Uiu6sm/xv nmjsAcIErXT1bs3jC3gRX0wgOoFVAEX+egMfRywiuOV5JgfjshNhzO+SxrkFlxBO SxCQLbCQ/w41klzNj9NzqW0BZa7SMdQOEh1VIViChTsU6xrJEAhzguIXJn9vSxEi qSuhvwdTdv2yrWcLoqnFnYt8QjudNk7JVzVLkAXvG2S1p4sy5QmJQSJCSNrlnIpi r9devJTqQKH/q6C7NeM3 =Bb6a -----END PGP SIGNATURE-----

Sept. 30, 2015

Re: [2/2 v3] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION.

by Ken Thomases

On Sep 30, 2015, at 2:53 AM, Jactry Zeng <jzeng(a)codeweavers.com> wrote: > dlls/user32/driver.c | 16 ++++++++++++++-- > dlls/user32/user_private.h | 1 + > dlls/user32/win.c | 1 + > dlls/winex11.drv/window.c | 29 +++++++++++++++++++++++++++++ > dlls/winex11.drv/winex11.drv.spec | 1 + > dlls/winex11.drv/x11drv.h | 1 + > dlls/winex11.drv/x11drv_main.c | 1 + > 7 files changed, 48 insertions(+), 2 deletions(-) Since FlashWindowEx() is the more general function — that is, FlashWindow() could be fully implemented in terms of FlashWindowEx(), but not the other way around — shouldn't the driver entry point be FlashWindowEx()? Otherwise, when FlashWindowEx() is eventually implemented more completely, the driver entry will have to be changed. For now, since user32 implements FlashWindow() but FlashWindowEx() is a stub (or semi-stub after your next patch), FlashWindow() would have to create a FLASHWINFO structure, fill it in, and pass that along. I think that dwFlags would be either FLASHW_ALL or FLASHW_STOP, depending on bInvert. uCount would be 1, I guess. Shouldn't pFlashWindow (or pFlashWindowEx) be added to the USER_DRIVER structure among the "windowing functions" (see the comments), in alphabetical order (after pDestroyWindow)? Of course, that affects the changes to driver.c in terms of where things are added. The order in winex11.drv.spec is less clear, but it seems to be mostly alphabetical after a certain point. I'd put it after EnumClipboardFormats() in that list. Why does FlashWindow() only call the driver entry point if the window is minimized? Shouldn't the driver get the opportunity to act for a non-minimized window, too? For the X11 implementation, shouldn't something potentially remove the _NET_WM_STATE_DEMANDS_ATTENTION state, presumably when bInvert is false (or when dwFlags doesn't include FLASHW_CAPTION or FLASHW_TRAY)? -Ken

Sept. 30, 2015

Re: [PATCH 03/12] msvcp110: Add tr2_sys__Open_dir implementation.(resend)

by Piotr Caban

On 09/29/15 18:03, YongHao Hu wrote: > Hi, > > On 15/9/28 下午7:51, Piotr Caban wrote: >> Hi, >> >> On 09/07/15 16:21, YongHao Hu wrote: >>> +/* ?_Open_dir(a)sys@tr2(a)std@@YAPAXAAY0BAE(a)DPBDAAHAAW4file_type@123@@Z */ >>> +/* >>> ?_Open_dir(a)sys@tr2(a)std@@YAPEAXAEAY0BAE(a)DPEBDAEAHAEAW4file_type@123@@Z */ >>> +void* __cdecl tr2_sys__Open_dir(char* target, char const* dest, int* >>> err_code, enum file_type* type) >>> +{ >>> + HANDLE handle; >>> + WIN32_FIND_DATAA data; >>> + char temppath[MAX_PATH]; >>> + TRACE("(%s %s %p %p)\n", debugstr_a(target), debugstr_a(dest), >>> err_code, type); >>> + strcpy(temppath, dest); >>> + strcat(temppath, "\\*.*"); >> Is native limiting the path to MAX_PATH characters? What happens if >> longer path is passed? >> > As far as I know, we can not create a file or directory when their path > longer than MAX_PATH on Windows, so it is impossible to pass a longer > valid path to tr2_sys__Open_dir. > If we pass a longer invalid path, I think that it's err_code would be > ERROR_PATH_NOT_FOUND( GetLastError() ) You can specify a longer path by prepending it with "\\?\" prefix. Even if longer paths are not supported you should probably detect that case instead of possibly crashing in strcpy call. Thanks, Piotr

Sept. 30, 2015

Re: [1/2 resend] user32: Implement semi-stub for FlashWindowEx.

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 https://testbot.winehq.org/JobDetails.pl?Key=16898 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 000601B0 message 0118 === w1064 (32 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w864 (64 bit win) === win.c:3417: Test failed: hwnd 000000000003012C message 0118 === w1064 (64 bit win) === win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6658: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6658: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6680: Test failed: 0x80/0x1410000: window rect 0,0-1024,768

Sept. 30, 2015

Re: Wined3d wireframe rendering

by Aaryaman Vasishta

On Wed, Sep 30, 2015 at 2:47 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > > Am 29.09.2015 um 18:12 schrieb Aaryaman Vasishta < > jem456.vasishta(a)gmail.com>: > > While you have a point, but (theoretically, judging from Bruno's > experience in the game X-moto) texture mapping might be more exacting than > rendering all vertices together without texture mapping in some cases. > Though I'm not sure about it myself. > Note that wireframe rendering doesn't disable texture mapping. It just > assembles the vertices to geometry in a different way. Instead of filling > the entire triangle defined by the vertices it just fills the lines between > the vertices. The lines that are drawn still have the normal fragment > processing (including shaders and textures) applied. > Right, my bad, I forgot to mention that.

Sept. 30, 2015

Re: Wined3d wireframe rendering

by Matt Durgavich

Yeah this really won’t work well if the goal is to speed up games on older hardware. As noted, if you are GPU bound then reducing the resolution should help. -Matt > On Sep 29, 2015, at 11:50 AM, Gediminas Jakutis <gediminas(a)varciai.lt> wrote: > > On 2015.09.29 17:15, Stefan Dösinger wrote: > [...] >> Re performance: Wireframe mode will only fix games that are limited by fragment processing. If you're CPU bound (which is the case in Wine most of the time without CSMT) you'll gain absolutely nothing. Also vertex processing limted setups won't improve, but those are fairly rare. If you're truly fragment processing limited lowering the resolution should help... >> >> Cheers, >> Stefan > > I experimented with making some games run in wireframe under wine around a year ago and can say the results can be quite disappointing in some cases, with performance dropping by an order of magnitude. In some cases, objects that normally get culled due to being occluded by other objects suddenly become visible in wireframe, and thus, get rendered. Since this can lead to processing *a lot* of objects that don't get processed otherwise, it can choke the CPU up badly. > > note: I'm no expert; just writing from experience. > > -- > Gediminas Jakutis > LDK Varčiai www.varciai.lt > >

Sept. 29, 2015

Re: Wined3d wireframe rendering

by Stefan Dösinger

Am 29.09.2015 um 18:12 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > While you have a point, but (theoretically, judging from Bruno's experience in the game X-moto) texture mapping might be more exacting than rendering all vertices together without texture mapping in some cases. Though I'm not sure about it myself. Note that wireframe rendering doesn't disable texture mapping. It just assembles the vertices to geometry in a different way. Instead of filling the entire triangle defined by the vertices it just fills the lines between the vertices. The lines that are drawn still have the normal fragment processing (including shaders and textures) applied.

Sept. 29, 2015

Re: Wined3d wireframe rendering

by Matt Durgavich

Yeah this really won’t work well if the goal is to speed up games on older hardware. As noted, if you are GPU bound then reducing the resolution should help. -Matt > On Sep 29, 2015, at 11:50 AM, Gediminas Jakutis <gediminas(a)varciai.lt> wrote: > > On 2015.09.29 17:15, Stefan Dösinger wrote: > [...] >> Re performance: Wireframe mode will only fix games that are limited by fragment processing. If you're CPU bound (which is the case in Wine most of the time without CSMT) you'll gain absolutely nothing. Also vertex processing limted setups won't improve, but those are fairly rare. If you're truly fragment processing limited lowering the resolution should help... >> >> Cheers, >> Stefan > > I experimented with making some games run in wireframe under wine around a year ago and can say the results can be quite disappointing in some cases, with performance dropping by an order of magnitude. In some cases, objects that normally get culled due to being occluded by other objects suddenly become visible in wireframe, and thus, get rendered. Since this can lead to processing *a lot* of objects that don't get processed otherwise, it can choke the CPU up badly. > > note: I'm no expert; just writing from experience. > > -- > Gediminas Jakutis > LDK Varčiai www.varciai.lt > >

Sept. 29, 2015

Re: Wined3d wireframe rendering

by Aaryaman Vasishta

On Tue, Sep 29, 2015 at 9:20 PM, Gediminas Jakutis <gediminas(a)varciai.lt> wrote: > On 2015.09.29 17:15, Stefan Dösinger wrote: > [...] > > Re performance: Wireframe mode will only fix games that are limited by > fragment processing. If you're CPU bound (which is the case in Wine most of > the time without CSMT) you'll gain absolutely nothing. Also vertex > processing limted setups won't improve, but those are fairly rare. If > you're truly fragment processing limited lowering the resolution should > help... > > > > Cheers, > > Stefan > > I experimented with making some games run in wireframe under wine around a > year ago and can say the results can be quite disappointing in some cases, > with performance dropping by an order of magnitude. In some cases, objects > that normally get culled due to being occluded by other objects suddenly > become visible in wireframe, and thus, get rendered. Since this can lead to > processing *a lot* of objects that don't get processed otherwise, it can > choke the CPU up badly. > > note: I'm no expert; just writing from experience. > > -- > Gediminas Jakutis > LDK Varčiai www.varciai.lt > > While you have a point, but (theoretically, judging from Bruno's experience in the game X-moto) texture mapping might be more exacting than rendering all vertices together without texture mapping in some cases. Though I'm not sure about it myself. Cheers, Aaryaman

Sept. 29, 2015

Re: [PATCH 03/12] msvcp110: Add tr2_sys__Open_dir implementation.(resend)

by YongHao Hu

Hi, On 15/9/28 下午7:51, Piotr Caban wrote: > Hi, > > On 09/07/15 16:21, YongHao Hu wrote: >> +/* ?_Open_dir(a)sys@tr2(a)std@@YAPAXAAY0BAE(a)DPBDAAHAAW4file_type@123@@Z */ >> +/* >> ?_Open_dir(a)sys@tr2(a)std@@YAPEAXAEAY0BAE(a)DPEBDAEAHAEAW4file_type@123@@Z */ >> +void* __cdecl tr2_sys__Open_dir(char* target, char const* dest, int* >> err_code, enum file_type* type) >> +{ >> + HANDLE handle; >> + WIN32_FIND_DATAA data; >> + char temppath[MAX_PATH]; >> + TRACE("(%s %s %p %p)\n", debugstr_a(target), debugstr_a(dest), >> err_code, type); >> + strcpy(temppath, dest); >> + strcat(temppath, "\\*.*"); > Is native limiting the path to MAX_PATH characters? What happens if > longer path is passed? > As far as I know, we can not create a file or directory when their path longer than MAX_PATH on Windows, so it is impossible to pass a longer valid path to tr2_sys__Open_dir. If we pass a longer invalid path, I think that it's err_code would be ERROR_PATH_NOT_FOUND( GetLastError() ) Thank you very much. :)

Sept. 29, 2015

Re: Wined3d wireframe rendering

by Gediminas Jakutis

On 2015.09.29 17:15, Stefan Dösinger wrote: [...] > Re performance: Wireframe mode will only fix games that are limited by fragment processing. If you're CPU bound (which is the case in Wine most of the time without CSMT) you'll gain absolutely nothing. Also vertex processing limted setups won't improve, but those are fairly rare. If you're truly fragment processing limited lowering the resolution should help... > > Cheers, > Stefan I experimented with making some games run in wireframe under wine around a year ago and can say the results can be quite disappointing in some cases, with performance dropping by an order of magnitude. In some cases, objects that normally get culled due to being occluded by other objects suddenly become visible in wireframe, and thus, get rendered. Since this can lead to processing *a lot* of objects that don't get processed otherwise, it can choke the CPU up badly. note: I'm no expert; just writing from experience. -- Gediminas Jakutis LDK Varčiai www.varciai.lt

Sept. 29, 2015

Re: Wined3d wireframe rendering

by Stefan Dösinger

Have a look at dlls/wined3d/state.c, state_fillmode(). However, you're likely to run into two problems: 1) The game doesn't necessarily clear the color buffer and just re-render every pixel. You'll have to change swapchain_present to clear the back buffer, otherwise you'll just get a colorful mess of old lines and new lines. 2) Render-to-texture: In modern games it is common to render everything to one or more textures, and then draw the texture onto the back buffer with one or more post-processing draws. You'll somehow have to figure out the post processing draws and make them non-wireframe, otherwise you'll end up with a mostly empty screen. Point 2 also makes point 1 more difficult to solve. You'll have to find the intermediate render targets, clear them, and also find a proper clear color that produces a "good" result with the post processing shaders. Also, Aaryaman's information is also pretty accurate: There may be external programs, and if you are dealing with an online game expect to be booted from the game pretty quickly because of attempted cheating... Re performance: Wireframe mode will only fix games that are limited by fragment processing. If you're CPU bound (which is the case in Wine most of the time without CSMT) you'll gain absolutely nothing. Also vertex processing limted setups won't improve, but those are fairly rare. If you're truly fragment processing limited lowering the resolution should help... Cheers, Stefan Am 29.09.2015 um 15:52 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > You'd probably have to hack into the game to change the rasterizer state to wireframe mode. Many game trainers (basically memory hacks which are used for cheating) offer D3D hooks which allow you to *switch on* wireframe mode, but that depends on the DX version too. AFAIK many DX9 onwards games have trainers like this available. Anyways, wined3d as it is right now can't decide the rasterizer state of any game by itself. wined3d will merely do what the game tells it to do, so you'll have to modify the game itself (via methods like the one described above), or if you have the source-code of the game, then change its default rasterizer state. fwiw, I don't advocate the former method as it's basically cheating in-game. > > > Cheers, > Aaryaman > > On Tue, Sep 29, 2015 at 7:01 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Hi all, I know it may sound idiot as I have zero knowledge on 3d > graphics but is it possible to make wined3d to not add textures to > things resulting in a sort of wireframe renderer? > > The long and uninteresting background: > I used to play a game called X-moto in 300Mhz Celeron Linux computer, > in its standard rendering mode it was impossible to play the game due > to low fps, but it had an awesome wireframe mode that played smoothly. > So if this could be achieved globally by wined3d we could play new > games on old computers (my overly noob conclusion about all this). > > Thanks in advance for any reply, > Bruno > > > >

Sept. 29, 2015

Re: Wined3d wireframe rendering

by Aaryaman Vasishta

You'd probably have to hack into the game to change the rasterizer state to wireframe mode. Many game trainers (basically memory hacks which are used for cheating) offer D3D hooks which allow you to *switch on* wireframe mode, but that depends on the DX version too. AFAIK many DX9 onwards games have trainers like this available. Anyways, wined3d as it is right now can't decide the rasterizer state of any game by itself. wined3d will merely do what the game tells it to do, so you'll have to modify the game itself (via methods like the one described above), or if you have the source-code of the game, then change its default rasterizer state. fwiw, I don't advocate the former method as it's basically cheating in-game. Cheers, Aaryaman On Tue, Sep 29, 2015 at 7:01 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Hi all, I know it may sound idiot as I have zero knowledge on 3d > graphics but is it possible to make wined3d to not add textures to > things resulting in a sort of wireframe renderer? > > The long and uninteresting background: > I used to play a game called X-moto in 300Mhz Celeron Linux computer, > in its standard rendering mode it was impossible to play the game due > to low fps, but it had an awesome wireframe mode that played smoothly. > So if this could be achieved globally by wined3d we could play new > games on old computers (my overly noob conclusion about all this). > > Thanks in advance for any reply, > Bruno > > >

Sept. 29, 2015

Wined3d wireframe rendering

by Bruno Jesus

Hi all, I know it may sound idiot as I have zero knowledge on 3d graphics but is it possible to make wined3d to not add textures to things resulting in a sort of wireframe renderer? The long and uninteresting background: I used to play a game called X-moto in 300Mhz Celeron Linux computer, in its standard rendering mode it was impossible to play the game due to low fps, but it had an awesome wireframe mode that played smoothly. So if this could be achieved globally by wined3d we could play new games on old computers (my overly noob conclusion about all this). Thanks in advance for any reply, Bruno

Sept. 29, 2015

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible

by Martin Storsjö

On Tue, 29 Sep 2015, Piotr Caban wrote: > On 09/21/15 15:08, Martin Storsjo wrote: >> if(d>MSVCRT_UI64_MAX/10 || hlp<d) { > Please also update overflow checking rules (use base instead of 10). > >> +static void test_strtod(void) >> +{ >> + test_strtod_str("infinity", INFINITY, 8); >> + test_strtod_str("INFINITY", INFINITY, 8); >> + test_strtod_str("InFiNiTy", INFINITY, 8); >> + test_strtod_str("INF", INFINITY, 3); >> + test_strtod_str("-inf", -INFINITY, 4); >> + test_strtod_str("inf42", INFINITY, 3); >> + test_strtod_str("inffoo", INFINITY, 3); >> + test_strtod_str("infini", INFINITY, 3); >> + >> + test_strtod_str("NAN", NAN, 3); >> + test_strtod_str("nan", NAN, 3); >> + test_strtod_str("NaN", NAN, 3); >> + >> + test_strtod_str("0x42", 66, 4); >> + test_strtod_str("0X42", 66, 4); >> + test_strtod_str("-0x42", -66, 5); >> + test_strtod_str("0x1p1", 2, 5); >> + test_strtod_str("0x1P1", 2, 5); >> + test_strtod_str("0x1p+1", 2, 6); >> + test_strtod_str("0x2p-1", 1, 6); >> + test_strtod_str("0xA", 10, 3); >> + test_strtod_str("0xa", 10, 3); >> + test_strtod_str("0xABCDEF", 11259375, 8); >> + test_strtod_str("0Xabcdef", 11259375, 8); >> + >> + test_strtod_str("0x1.1", 1.0625, 5); >> + test_strtod_str("0x1.1p1", 2.125, 7); > Could you please also add few more tests, like: > test_strtod_str("0x1.A", ...); /*to show that part after decimal point is > correctly handling hexadecimal digits */ > test_strtod_str("0x1p1a", ...); /* to show that exponential part is not > handling hexadecimal digits */ Thanks, updated patch sent. (Although I missed to add your comments at the end of the test lines, which I only notice now when replying.) // Martin

Sept. 29, 2015

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible

by Piotr Caban

On 09/21/15 15:08, Martin Storsjo wrote: > if(d>MSVCRT_UI64_MAX/10 || hlp<d) { Please also update overflow checking rules (use base instead of 10). > +static void test_strtod(void) > +{ > + test_strtod_str("infinity", INFINITY, 8); > + test_strtod_str("INFINITY", INFINITY, 8); > + test_strtod_str("InFiNiTy", INFINITY, 8); > + test_strtod_str("INF", INFINITY, 3); > + test_strtod_str("-inf", -INFINITY, 4); > + test_strtod_str("inf42", INFINITY, 3); > + test_strtod_str("inffoo", INFINITY, 3); > + test_strtod_str("infini", INFINITY, 3); > + > + test_strtod_str("NAN", NAN, 3); > + test_strtod_str("nan", NAN, 3); > + test_strtod_str("NaN", NAN, 3); > + > + test_strtod_str("0x42", 66, 4); > + test_strtod_str("0X42", 66, 4); > + test_strtod_str("-0x42", -66, 5); > + test_strtod_str("0x1p1", 2, 5); > + test_strtod_str("0x1P1", 2, 5); > + test_strtod_str("0x1p+1", 2, 6); > + test_strtod_str("0x2p-1", 1, 6); > + test_strtod_str("0xA", 10, 3); > + test_strtod_str("0xa", 10, 3); > + test_strtod_str("0xABCDEF", 11259375, 8); > + test_strtod_str("0Xabcdef", 11259375, 8); > + > + test_strtod_str("0x1.1", 1.0625, 5); > + test_strtod_str("0x1.1p1", 2.125, 7); Could you please also add few more tests, like: test_strtod_str("0x1.A", ...); /*to show that part after decimal point is correctly handling hexadecimal digits */ test_strtod_str("0x1p1a", ...); /* to show that exponential part is not handling hexadecimal digits */ Thanks, Piotr

Sept. 29, 2015

Re: [PATCH] gdi32: Antialias fake bold or italic fonts regardless of GASP table.

by Nikolay Sivov

On 29.09.2015 12:40, Ken Thomases wrote: > On Sep 29, 2015, at 4:21 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >> I think in some cases it makes sense to disable emboldening entirely, because as you said rendered images are ruined, but not only by moving outline points around. Some fonts, I think it applies to CJK fonts more than others, have prerendered embedded bitmaps to improve legibility in small sizes, but when we fake bold or oblique styles we disable bitmaps explicitly, and this goes against the idea font designer had in mind. Enabling AA could probably help, but not necessary as well as using bitmaps. Of course this has to be tested on windows using fonts that provide bitmaps, to see if they respond to bold simulation at all at sizes that are supposed to use bitmaps. > > Well, in general, I think Windows simulates bold using an entirely different technique. I haven't tested in any thorough fashion, but I did look briefly at one point. It looks like Windows just draws the glyph twice with the second time being shifted right by one pixel. > Interesting, that could explain test results we have, where advances are adjusted by one pixel only. >>> There is a new registry setting to disable this and revert to the previous >>> behavior: >>> >>> [HKEY_CURRENT_USER\Software\Wine\Fonts] >>> "AntialiasFakeBoldOrItalic"="n" >> >> What's a problem of ignoring GASP and following global AA settings in such cases? I mean are you aware of any problems that could potentially need such switch? > > No specific problems other than people are picky about their fonts. It's conceivable that some people would prefer the old way to the new. In the CodeWeavers bug tracker where I first proposed this patch (bug 12270, if you care), I got pushback about the lack of a registry setting to turn this off. So, I added a registry setting. > Ok. > -Ken >

Sept. 29, 2015

Re: [PATCH] gdi32: Antialias fake bold or italic fonts regardless of GASP table.

by Ken Thomases

On Sep 29, 2015, at 4:21 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > I think in some cases it makes sense to disable emboldening entirely, because as you said rendered images are ruined, but not only by moving outline points around. Some fonts, I think it applies to CJK fonts more than others, have prerendered embedded bitmaps to improve legibility in small sizes, but when we fake bold or oblique styles we disable bitmaps explicitly, and this goes against the idea font designer had in mind. Enabling AA could probably help, but not necessary as well as using bitmaps. Of course this has to be tested on windows using fonts that provide bitmaps, to see if they respond to bold simulation at all at sizes that are supposed to use bitmaps. Well, in general, I think Windows simulates bold using an entirely different technique. I haven't tested in any thorough fashion, but I did look briefly at one point. It looks like Windows just draws the glyph twice with the second time being shifted right by one pixel. >> There is a new registry setting to disable this and revert to the previous >> behavior: >> >> [HKEY_CURRENT_USER\Software\Wine\Fonts] >> "AntialiasFakeBoldOrItalic"="n" > > What's a problem of ignoring GASP and following global AA settings in such cases? I mean are you aware of any problems that could potentially need such switch? No specific problems other than people are picky about their fonts. It's conceivable that some people would prefer the old way to the new. In the CodeWeavers bug tracker where I first proposed this patch (bug 12270, if you care), I got pushback about the lack of a registry setting to turn this off. So, I added a registry setting. -Ken

Sept. 29, 2015

Re: [PATCH] gdi32: Antialias fake bold or italic fonts regardless of GASP table.

by Nikolay Sivov

On 29.09.2015 10:27, Ken Thomases wrote: > If the client requests a bold typeface of a font which doesn't actually provide > a bold typeface, Wine fakes it using FT_Outline_Embolden(). Likewise, it fakes > italic by apply a shear transform. > > These techniques work passably when antialiasing is in effect. However, when > antialiasing is disabled at small sizes by the font's GASP table, the results > are horrible. The glyphs have many spurs or appear furry. > > On the theory that fonts disable antialiasing via the GASP table at small sizes > because hinting should produce pixel-perfect results and that that rationale is > voided by the application of procedural bolding or italicizing, we ignore the > GASP table and always antialias for fake bold or italic fonts. Hi. I think in some cases it makes sense to disable emboldening entirely, because as you said rendered images are ruined, but not only by moving outline points around. Some fonts, I think it applies to CJK fonts more than others, have prerendered embedded bitmaps to improve legibility in small sizes, but when we fake bold or oblique styles we disable bitmaps explicitly, and this goes against the idea font designer had in mind. Enabling AA could probably help, but not necessary as well as using bitmaps. Of course this has to be tested on windows using fonts that provide bitmaps, to see if they respond to bold simulation at all at sizes that are supposed to use bitmaps. P.S. unrelated but still, since faked styles effectively invalidate the job hinting does, maybe it makes sense to try to load with FT_LOAD_NO_HINTING in such cases as it's supposed to be faster, and I think we disable outline caching for simulated fonts. Just a thought, I haven't tried it myself. > > There is a new registry setting to disable this and revert to the previous > behavior: > > [HKEY_CURRENT_USER\Software\Wine\Fonts] > "AntialiasFakeBoldOrItalic"="n" What's a problem of ignoring GASP and following global AA settings in such cases? I mean are you aware of any problems that could potentially need such switch? > > Signed-off-by: Ken Thomases <ken(a)codeweavers.com>

Sept. 29, 2015

Re: Migrating away from Sourceforge

by Aaryaman Vasishta

+1. That's great news :D It would be a great silver lining if the bandwidth does get over once we start providing binary packages ;) Cheers, Aaryaman On Tue, Sep 29, 2015 at 2:32 AM, Austin English <austinenglish(a)gmail.com> wrote: > On Mon, Sep 28, 2015 at 3:58 PM, Jeremy White <jwhite(a)codeweavers.com> > wrote: > >>> As an update, I did email the Conservancy. They've gotten this same > >> question from a number of member projects, and are doing some > >> research/thinking about this. > >>> > >>> So it's not forgotten, but in progress. > > > > Just in case folks have missed it, we are getting sponsorship from > > Fastly. Jeremy Newman is working out the details now. > > > > It's not clear how much bandwidth we'll need vs how much they are > > donating. It looks like we'll be getting at least 8.5 TB/month, which > > should be enough to cover the move away from Sourceforge. > > > > But we were also hoping to provide binary downloads; we may need to do > > some wiggling to cover that as well. Of course, that depends on how > > much demand there is for the binary downloads; if the demand is modest, > > it won't be an issue. > > > > Cheers, > > > > Jeremy > > Huzzah! Thanks Jeremy. > > -- > -Austin > > >

Sept. 29, 2015

Re: Migrating away from Sourceforge

by Austin English

On Mon, Sep 28, 2015 at 3:58 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: >>> As an update, I did email the Conservancy. They've gotten this same >> question from a number of member projects, and are doing some >> research/thinking about this. >>> >>> So it's not forgotten, but in progress. > > Just in case folks have missed it, we are getting sponsorship from > Fastly. Jeremy Newman is working out the details now. > > It's not clear how much bandwidth we'll need vs how much they are > donating. It looks like we'll be getting at least 8.5 TB/month, which > should be enough to cover the move away from Sourceforge. > > But we were also hoping to provide binary downloads; we may need to do > some wiggling to cover that as well. Of course, that depends on how > much demand there is for the binary downloads; if the demand is modest, > it won't be an issue. > > Cheers, > > Jeremy Huzzah! Thanks Jeremy. -- -Austin

Sept. 28, 2015

Re: Migrating away from Sourceforge

by Jeremy White

>> As an update, I did email the Conservancy. They've gotten this same > question from a number of member projects, and are doing some > research/thinking about this. >> >> So it's not forgotten, but in progress. Just in case folks have missed it, we are getting sponsorship from Fastly. Jeremy Newman is working out the details now. It's not clear how much bandwidth we'll need vs how much they are donating. It looks like we'll be getting at least 8.5 TB/month, which should be enough to cover the move away from Sourceforge. But we were also hoping to provide binary downloads; we may need to do some wiggling to cover that as well. Of course, that depends on how much demand there is for the binary downloads; if the demand is modest, it won't be an issue. Cheers, Jeremy

Sept. 28, 2015

Re: [PATCH 1/2] d3d8: Accept D3DSWAPEFFECT_COPY_VSYNC.

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 https://testbot.winehq.org/JobDetails.pl?Key=16895 Your paranoid android. === w1064 (32 bit device) === device.c:2612: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2617: Test failed: The focus window is active. device.c:2625: Test failed: Got unexpected hr 0x88760869. device.c:2631: Test failed: Got unexpect screen size 1152x870. device.c:2646: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=2. device.c:2655: Test failed: Got unexpect screen size 1152x870. device.c:2668: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2676: Test failed: Got unexpect width 1152. device.c:2677: Test failed: Got unexpect height 864.

Sept. 28, 2015

Re: Bugzilla changes

by Sebastian Lackner

On 28.09.2015 19:02, Theodore Dubois wrote: >> * New wine-staging product: This should be used for bugs caused by >> patches that are in wine-staging, but that do not occur in >> wine-development (i.e., wine-staging patch regressions) > > There should also be a place for bugs that only show up in wine > staging, but can't be considered regressions because the program > wouldn't even run in wine. For example, Life is Strange (I've tested > episode 1) doesn't work at all in wine. In wine staging, though, it > does run, but after a few minutes the performance drops to about 2 > FPS. I have no idea if the bug is in wine staging, or it's in wine > and you can only notice it when the wine staging patches are applied > and the game actually runs. > > ~Theodore > There is no need to keep them separate, Bugzilla already supports a way to mark bugs as "blocked by a different bug". You would just mention this information, then the Staging patchset can be bisected to find out which other fixes are required, and the bug dependencies can be set accordingly.

Sept. 28, 2015

Re: Bugzilla changes

by Austin English

On Mon, Sep 28, 2015 at 12:02 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: >> * New wine-staging product: This should be used for bugs caused by >> patches that are in wine-staging, but that do not occur in >> wine-development (i.e., wine-staging patch regressions) > > There should also be a place for bugs that only show up in wine staging, but can't be considered regressions because the program wouldn't even run in wine. For example, Life is Strange (I've tested episode 1) doesn't work at all in wine. In wine staging, though, it does run, but after a few minutes the performance drops to about 2 FPS. I have no idea if the bug is in wine staging, or it's in wine and you can only notice it when the wine staging patches are applied and the game actually runs. > > ~Theodore File it as a bug in wine. -- -Austin

Sept. 28, 2015

Re: Bugzilla changes

by Theodore Dubois

> * New wine-staging product: This should be used for bugs caused by > patches that are in wine-staging, but that do not occur in > wine-development (i.e., wine-staging patch regressions) There should also be a place for bugs that only show up in wine staging, but can't be considered regressions because the program wouldn't even run in wine. For example, Life is Strange (I've tested episode 1) doesn't work at all in wine. In wine staging, though, it does run, but after a few minutes the performance drops to about 2 FPS. I have no idea if the bug is in wine staging, or it's in wine and you can only notice it when the wine staging patches are applied and the game actually runs. ~Theodore

Sept. 28, 2015

Re: Bugzilla changes

by Austin English

On Mon, Sep 28, 2015 at 7:00 AM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > On 28.09.2015 08:56, Austin English wrote: >> Howdy all, >> >> As Alexandre mentioned [1], at WineConf we made several decisions to >> modify bugzilla in a few ways. I've now implemented those changes, >> which are outlined below: > > Hi Austin, > > thanks for doing these changes. :) > >> >> * New wine-staging product: This should be used for bugs caused by >> patches that are in wine-staging, but that do not occur in >> wine-development (i.e., wine-staging patch regressions) > > As far as I know there were some concerns to call it "wine-staging", and > it was preferred to call it just "staging". Did you use the original name > to avoid ordering problems? Yes, and consistency. >> * New STAGED resolution: This is to differentiate bugs that are FIXED >> (in wine-development) from bugs that are not present in wine-staging >> because of one or more patches. The anticipated workflow is: >> UNCONFIRMED > bug confirmed, NEW > patch written and sent to >> wine-patches, if it's accepted, FIXED. If not, and the patch is >> integrated into wine-staging, then the bug is STAGED. When the patch >> is revised and eventually integrated into wine-development, the bug >> should move to FIXED. > > Wasn't the idea to add it as a non-RESOLVED status? I personally do not > care that much about the difference, but we should probably decide before > we use it everywhere. Also it would be nice to have a field to keep track > of the staged patchset, without writing it in a comment. What about an > additional field which is only present when this status is selected? > (similar to the Regression SHA field for example) I wasn't aware that distinction was made, but I think that makes sense, I've changed NEEDINFO / STAGED to be statuses rather than resolutions. I've also added a 'Staged patchset' field to Bugzilla. >> >> * New NEEDINFO resolution: There's a lot of confusion and different >> handling by triagers for what to do with bug reports that are >> incomplete (i.e., leaving it open versus closing invalid). To mitigate >> this, I've added a NEEDINFO resolution. If a bug report lacks needed >> information, set it to this status. Bug that have been open NEEDINFO >> for more than 1 year can be closed. > > Similar to the staging status, why is this a RESOLVED status? Its not > really a final status, so a non-RESOLVED status would make more sense maybe. Changed. >> >> * Renamed UPSTREAM to NOTOURBUG: This is more in line with what other >> projects do, and eliminates confusion about the upstream/downstream >> distinction. >> >> Please let me know if there are any questions or ideas for further enhancements. >> >> [1] https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html >> > > Regards, > Sebastian -- -Austin

Sept. 28, 2015

Re: ieframe: add a better toolbar bitmap

by Joel Holdsworth

On 28/09/15 12:58, Jacek Caban wrote: > Hi Jared, > > On 09/26/15 20:02, Jared Smudde wrote: >> --- >> dlls/ieframe/ietoolbar.bmp | Bin 24698 -> 24630 bytes >> 1 files changed, 0 insertions(+), 0 deletions(-) > Also - what's "better" about this toolbar image? I applied the patch and for me it appears identical to the old one. Joel

Sept. 28, 2015

Re: ntdll: Reduce stack usage of virtual memory functions by storing sigset in static memory.

by Grazvydas Ignotas

On Sun, Sep 27, 2015 at 6:05 PM, Michael Müller <michael(a)fds-team.de> wrote: > Am 27.09.2015 um 00:07 schrieb Sebastian Lackner: >> From: Michael Müller <michael(a)fds-team.de> >> >> For https://bugs.winehq.org/show_bug.cgi?id=34558 >> >> Depending on the compiler optimization flags there is still no guarantee that >> everything will fit into the available stack space, no matter if its declared >> as static or not. > > As suspected the idea does not work for all optimization levels. At > least GCC merges the content of the functions when using -O2 and > therefore reintroduces the problem - even __attribute__ ((noinline)) is > not sufficient. Try __attribute__ ((noclone,noinline)) Gražvydas

Sept. 28, 2015

Re: Bugzilla changes

by Wojtek “arab” Arabczyk

> On 28.09.2015 16:54, Benjamin Shadwick wrote: >> Wait, "UNCONFIRMED" means confirmed, or do you mean that confirmation is >> not captured as a state between UNCONFIRMED and NEW? > > No, the NEW status means confirmed. However, most people do not really make > a difference between UNCONFIRMED and NEW. The more important part was the > description of the process afterwards. ;) Make it user-friendly and rename UNCONFIRMED -> INCOMING (or NEW but this will add to the confusion for long time bugzilla users afterwards), and NEW -> CONFIRMED thus eliminating the confusion. P.S. I’m a confused user ;)

Sept. 28, 2015

Re: Bugzilla changes

by Sebastian Lackner

On 28.09.2015 16:54, Benjamin Shadwick wrote: > Wait, "UNCONFIRMED" means confirmed, or do you mean that confirmation is > not captured as a state between UNCONFIRMED and NEW? No, the NEW status means confirmed. However, most people do not really make a difference between UNCONFIRMED and NEW. The more important part was the description of the process afterwards. ;) > > Is there any accountability to the bug submitter that the submitted patch > addresses the issue in a satisfactory manner (i.e. a verification step), or > is that arbitrated behind the scenes as part of the review process, or does > the bug submitter have no formal voice in the process after submitting? The status will be changed as soon as patch which is supposed to fix the issue has been added to Wine Staging. In most cases developers have already confirmed that the patch works as expected at this point, and no additional testing is required. (Testing usually happens before the patch is submitted/added anywhere.) If a bug submitter notices that the bug status does not correctly reflect his test results, it is highly recommended to report that of course (in the corresponding bug report, or to a bugzilla admin). It could for example mean that a proposed patch is not complete, which is a very useful information for the patch author, or that a proposed fix is no longer necessary. To simplify the synchronization of the bug status it might also be useful to automate part of the process, however I would first like to ensure that the way it is implemented right now (as a RESOLVED-status) is really the final decision. > > On Mon, Sep 28, 2015 at 5:59 AM, Sebastian Lackner <sebastian(a)fds-team.de> > wrote: > >> Dmitry just pointed out, that there are no versions yet in the Wine >> Staging product: >> https://bugs.winehq.org/show_bug.cgi?id=39353 >> >> Would also be nice to get this fixed soon. ;) Ancient versions are not >> really necessary, >> but at least versions >= 1.7.30 would be nice to have. >> >> Currently the oldest bug report on our bugtracker was filed with 1.7.32. >> >> On 28.09.2015 14:00, Sebastian Lackner wrote: >>> On 28.09.2015 08:56, Austin English wrote: >>>> Howdy all, >>>> >>>> As Alexandre mentioned [1], at WineConf we made several decisions to >>>> modify bugzilla in a few ways. I've now implemented those changes, >>>> which are outlined below: >>> >>> Hi Austin, >>> >>> thanks for doing these changes. :) >>> >>>> >>>> * New wine-staging product: This should be used for bugs caused by >>>> patches that are in wine-staging, but that do not occur in >>>> wine-development (i.e., wine-staging patch regressions) >>> >>> As far as I know there were some concerns to call it "wine-staging", and >>> it was preferred to call it just "staging". Did you use the original name >>> to avoid ordering problems? >>> >>>> >>>> * New STAGED resolution: This is to differentiate bugs that are FIXED >>>> (in wine-development) from bugs that are not present in wine-staging >>>> because of one or more patches. The anticipated workflow is: >>>> UNCONFIRMED > bug confirmed, NEW > patch written and sent to >>>> wine-patches, if it's accepted, FIXED. If not, and the patch is >>>> integrated into wine-staging, then the bug is STAGED. When the patch >>>> is revised and eventually integrated into wine-development, the bug >>>> should move to FIXED. >>> >>> Wasn't the idea to add it as a non-RESOLVED status? I personally do not >>> care that much about the difference, but we should probably decide before >>> we use it everywhere. Also it would be nice to have a field to keep track >>> of the staged patchset, without writing it in a comment. What about an >>> additional field which is only present when this status is selected? >>> (similar to the Regression SHA field for example) >>> >>>> >>>> * New NEEDINFO resolution: There's a lot of confusion and different >>>> handling by triagers for what to do with bug reports that are >>>> incomplete (i.e., leaving it open versus closing invalid). To mitigate >>>> this, I've added a NEEDINFO resolution. If a bug report lacks needed >>>> information, set it to this status. Bug that have been open NEEDINFO >>>> for more than 1 year can be closed. >>> >>> Similar to the staging status, why is this a RESOLVED status? Its not >>> really a final status, so a non-RESOLVED status would make more sense >> maybe. >>> >>>> >>>> * Renamed UPSTREAM to NOTOURBUG: This is more in line with what other >>>> projects do, and eliminates confusion about the upstream/downstream >>>> distinction. >>>> >>>> Please let me know if there are any questions or ideas for further >> enhancements. >>>> >>>> [1] >> https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html >>>> >>> >>> Regards, >>> Sebastian >>> >> >> >> >> >

Sept. 28, 2015

Re: Bugzilla changes

by Benjamin Shadwick

Wait, "UNCONFIRMED" means confirmed, or do you mean that confirmation is not captured as a state between UNCONFIRMED and NEW? Is there any accountability to the bug submitter that the submitted patch addresses the issue in a satisfactory manner (i.e. a verification step), or is that arbitrated behind the scenes as part of the review process, or does the bug submitter have no formal voice in the process after submitting? On Mon, Sep 28, 2015 at 5:59 AM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Dmitry just pointed out, that there are no versions yet in the Wine > Staging product: > https://bugs.winehq.org/show_bug.cgi?id=39353 > > Would also be nice to get this fixed soon. ;) Ancient versions are not > really necessary, > but at least versions >= 1.7.30 would be nice to have. > > Currently the oldest bug report on our bugtracker was filed with 1.7.32. > > On 28.09.2015 14:00, Sebastian Lackner wrote: > > On 28.09.2015 08:56, Austin English wrote: > >> Howdy all, > >> > >> As Alexandre mentioned [1], at WineConf we made several decisions to > >> modify bugzilla in a few ways. I've now implemented those changes, > >> which are outlined below: > > > > Hi Austin, > > > > thanks for doing these changes. :) > > > >> > >> * New wine-staging product: This should be used for bugs caused by > >> patches that are in wine-staging, but that do not occur in > >> wine-development (i.e., wine-staging patch regressions) > > > > As far as I know there were some concerns to call it "wine-staging", and > > it was preferred to call it just "staging". Did you use the original name > > to avoid ordering problems? > > > >> > >> * New STAGED resolution: This is to differentiate bugs that are FIXED > >> (in wine-development) from bugs that are not present in wine-staging > >> because of one or more patches. The anticipated workflow is: > >> UNCONFIRMED > bug confirmed, NEW > patch written and sent to > >> wine-patches, if it's accepted, FIXED. If not, and the patch is > >> integrated into wine-staging, then the bug is STAGED. When the patch > >> is revised and eventually integrated into wine-development, the bug > >> should move to FIXED. > > > > Wasn't the idea to add it as a non-RESOLVED status? I personally do not > > care that much about the difference, but we should probably decide before > > we use it everywhere. Also it would be nice to have a field to keep track > > of the staged patchset, without writing it in a comment. What about an > > additional field which is only present when this status is selected? > > (similar to the Regression SHA field for example) > > > >> > >> * New NEEDINFO resolution: There's a lot of confusion and different > >> handling by triagers for what to do with bug reports that are > >> incomplete (i.e., leaving it open versus closing invalid). To mitigate > >> this, I've added a NEEDINFO resolution. If a bug report lacks needed > >> information, set it to this status. Bug that have been open NEEDINFO > >> for more than 1 year can be closed. > > > > Similar to the staging status, why is this a RESOLVED status? Its not > > really a final status, so a non-RESOLVED status would make more sense > maybe. > > > >> > >> * Renamed UPSTREAM to NOTOURBUG: This is more in line with what other > >> projects do, and eliminates confusion about the upstream/downstream > >> distinction. > >> > >> Please let me know if there are any questions or ideas for further > enhancements. > >> > >> [1] > https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html > >> > > > > Regards, > > Sebastian > > > > > >

Sept. 28, 2015

Re: Videos or Slides from WineConf

by Julian Rüger

> Thanks Stefan, I'm really looking forward to watching. > > Joel +1 > On 24/09/15 20:09, Stefan Dösinger wrote: > > I am still working on the videos (done with the keynote and Jeremy White's talk, halfway done with Michael Stefanuic's), I expect that they're ready at the beginning of the next week. > > > > Cheers, > > Stefan > > > >> Am 24.09.2015 um 18:19 schrieb André Hentschel <nerv(a)dawncrow.de>: > >> > >> I attached my slides on "The other Architectures" > >>

Sept. 28, 2015

Re: msadpcm32.acm: Stop converting data instead of crashing

by Sebastian Lackner

On 28.09.2015 15:42, Andrew Eikum wrote: > On Mon, Sep 28, 2015 at 09:38:38PM +0800, Bruno Jesus wrote: >> Will do, thanks for the review. Does this mean I should add a Signed-off-by >> with your name too? Or that is not related to patch reviewing. > > I'm not 100% sure, but I think I should add the S-o-b as a reply to > your email to wine-patches. Unless it's for sharing authorship, I > don't think you can add my S-o-b, since you are not me. > > Andrew > > Was just about to answer the same. Do not add S-o-b yourself, unless you use it to track multiple authors, or you are 100% sure that Andrew is _really_ fine with it. In this case, when you are doing additional modifications, you can never be sure that this is the case. ;) At WineConf there was also the decision that an answer like "the patch looks good" is not equivalent to a S-o-b. The latter is more strong because it implies that the person is also taking responsibility for it, and that it was a full review including running the tests, not just a quick look. Regards, Sebastian

Sept. 28, 2015

Re: msadpcm32.acm: Stop converting data instead of crashing

by Andrew Eikum

On Mon, Sep 28, 2015 at 09:38:38PM +0800, Bruno Jesus wrote: > Will do, thanks for the review. Does this mean I should add a Signed-off-by > with your name too? Or that is not related to patch reviewing. I'm not 100% sure, but I think I should add the S-o-b as a reply to your email to wine-patches. Unless it's for sharing authorship, I don't think you can add my S-o-b, since you are not me. Andrew

Sept. 28, 2015

Re: msadpcm32.acm: Stop converting data instead of crashing

by Bruno Jesus

On Monday, September 28, 2015, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Sun, Sep 27, 2015 at 12:42:42AM +0800, Bruno Jesus wrote: > > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com <javascript:;>> > > > > Tomb Raider 3 uses a single archive with all wav files inside, when > > playing some specific sounds it passes incorrect lengths of data that > > reach the next wav file header. This causes an assert in the code that > > is now gracefully handled. > > > > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=21000 > ... > > Looks reasonable, thanks. I think you should change that message to a > WARN. Audio methods are often called thousands of times per second, so > spamming an ERR can be very obnoxious. > > Will do, thanks for the review. Does this mean I should add a Signed-off-by with your name too? Or that is not related to patch reviewing.

Sept. 28, 2015

Re: msadpcm32.acm: Stop converting data instead of crashing

by Andrew Eikum

On Sun, Sep 27, 2015 at 12:42:42AM +0800, Bruno Jesus wrote: > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > > Tomb Raider 3 uses a single archive with all wav files inside, when > playing some specific sounds it passes incorrect lengths of data that > reach the next wav file header. This causes an assert in the code that > is now gracefully handled. > > Fixes bug https://bugs.winehq.org/show_bug.cgi?id=21000 > diff --git a/dlls/msadp32.acm/msadp32.c b/dlls/msadp32.acm/msadp32.c > index 2c61575..0924163 100644 > --- a/dlls/msadp32.acm/msadp32.c > +++ b/dlls/msadp32.acm/msadp32.c > @@ -249,9 +249,17 @@ static void cvtSSms16K(const ACMDRVSTREAMINSTANCE *adsi, > { > const unsigned char* in_src = src; > > - assert(*src <= 6); > + /* Catch a problem from Tomb Raider III (bug 21000) where it passes > + * invalid data after a valid sequence of blocks */ > + if (*src > 6 || *(src + 1) > 6) > + { > + /* Recalculate the amount of used output buffer. We are not changing > + * nsrc, let's assume the bad data was parsed */ > + *ndst -= nblock * nsamp_blk * adsi->pwfxDst->nBlockAlign; > + ERR("Invalid ADPCM data, stopping conversion\n"); Looks reasonable, thanks. I think you should change that message to a WARN. Audio methods are often called thousands of times per second, so spamming an ERR can be very obnoxious. Andrew

Sept. 28, 2015

Re: Bugzilla changes

by Sebastian Lackner

Dmitry just pointed out, that there are no versions yet in the Wine Staging product: https://bugs.winehq.org/show_bug.cgi?id=39353 Would also be nice to get this fixed soon. ;) Ancient versions are not really necessary, but at least versions >= 1.7.30 would be nice to have. Currently the oldest bug report on our bugtracker was filed with 1.7.32. On 28.09.2015 14:00, Sebastian Lackner wrote: > On 28.09.2015 08:56, Austin English wrote: >> Howdy all, >> >> As Alexandre mentioned [1], at WineConf we made several decisions to >> modify bugzilla in a few ways. I've now implemented those changes, >> which are outlined below: > > Hi Austin, > > thanks for doing these changes. :) > >> >> * New wine-staging product: This should be used for bugs caused by >> patches that are in wine-staging, but that do not occur in >> wine-development (i.e., wine-staging patch regressions) > > As far as I know there were some concerns to call it "wine-staging", and > it was preferred to call it just "staging". Did you use the original name > to avoid ordering problems? > >> >> * New STAGED resolution: This is to differentiate bugs that are FIXED >> (in wine-development) from bugs that are not present in wine-staging >> because of one or more patches. The anticipated workflow is: >> UNCONFIRMED > bug confirmed, NEW > patch written and sent to >> wine-patches, if it's accepted, FIXED. If not, and the patch is >> integrated into wine-staging, then the bug is STAGED. When the patch >> is revised and eventually integrated into wine-development, the bug >> should move to FIXED. > > Wasn't the idea to add it as a non-RESOLVED status? I personally do not > care that much about the difference, but we should probably decide before > we use it everywhere. Also it would be nice to have a field to keep track > of the staged patchset, without writing it in a comment. What about an > additional field which is only present when this status is selected? > (similar to the Regression SHA field for example) > >> >> * New NEEDINFO resolution: There's a lot of confusion and different >> handling by triagers for what to do with bug reports that are >> incomplete (i.e., leaving it open versus closing invalid). To mitigate >> this, I've added a NEEDINFO resolution. If a bug report lacks needed >> information, set it to this status. Bug that have been open NEEDINFO >> for more than 1 year can be closed. > > Similar to the staging status, why is this a RESOLVED status? Its not > really a final status, so a non-RESOLVED status would make more sense maybe. > >> >> * Renamed UPSTREAM to NOTOURBUG: This is more in line with what other >> projects do, and eliminates confusion about the upstream/downstream >> distinction. >> >> Please let me know if there are any questions or ideas for further enhancements. >> >> [1] https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html >> > > Regards, > Sebastian >

Sept. 28, 2015

Re: [PATCH] opengl32: use thunks for glDebugMessageCallback

by Matteo Bruni

2015-09-27 21:00 GMT+02:00 Marcus Meissner <marcus(a)jet.franken.de>: > Also regenerated opengl files, to exclude the glDebugMessageCallback functions. > > Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de> > --- > dlls/opengl32/make_opengl | 6 + > dlls/opengl32/opengl_ext.c | 343 +++++++++++++++++++++++++++++++++++++++---- > dlls/opengl32/opengl_ext.h | 5 + > dlls/opengl32/opengl_norm.c | 90 +++++++++++- > dlls/opengl32/tests/opengl.c | 96 +++++++++++- > dlls/opengl32/wgl.c | 52 +++++++ > include/wine/wgl.h | 100 +++++++++++++ > include/wine/wgl_driver.h | 47 +++++- > include/winternl.h | 5 +- > 9 files changed, 708 insertions(+), 36 deletions(-) > diff --git a/include/winternl.h b/include/winternl.h > index 2fe2a2d..8e85eb4 100644 > --- a/include/winternl.h > +++ b/include/winternl.h > @@ -341,7 +341,10 @@ typedef struct _TEB > PVOID GdiThreadLocaleInfo; /* 6fc/0870 */ > ULONG UserReserved[5]; /* 700/0878 */ > PVOID glDispachTable[280]; /* 714/0890 */ > - PVOID glReserved1[26]; /* b74/1150 */ > + PVOID glDebugCallback; /* b74/1150 */ > + PVOID glDebugCallbackAMD; /* b78/1158 */ > + PVOID glDebugCallbackARB; /* b7c/1160 */ > + PVOID glReserved1[23]; /* b80/1164 */ > PVOID glReserved2; /* bdc/1220 */ > PVOID glSectionInfo; /* be0/1228 */ > PVOID glSection; /* be4/1230 */ The callbacks should be per-GL context, that's why I mentioned the struct opengl_context as a possibly suitable place to store the application-provided callbacks. The test should actually test something. You probably need to create a debug context (the extension specifies that "For performance reasons it is recommended, but not required, that implementations restrict supporting this extension only to contexts created using the debug flag as provided by WGL_create_context or GLX_create_context") and enable the DEBUG_OUTPUT_SYNCHRONOUS_ARB flag. Also it would be definitely nicer if the test is implemented in a separate function, instead of stuffing it into START_TEST(opengl). For the records, you can find the relevant extension spec at https://www.opengl.org/registry/specs/ARB/debug_output.txt. GL_KHR_debug specifies some further related bits but I think you can mostly ignore that for this patch.

Sept. 28, 2015

Re: Bugzilla changes

by Rosanne DiMesio

On Mon, 28 Sep 2015 14:00:37 +0200 Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Wasn't the idea to add it as a non-RESOLVED status? I personally do not > care that much about the difference, but we should probably decide before > we use it everywhere. > > FYI, links to RESOLVED bugs don't show up by default in the AppDB; the user has to click "Show all bugs" to see them, though that's probably something that should be fixed in the AppDB. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Sept. 28, 2015

Re: Bugzilla changes

by Sebastian Lackner

On 28.09.2015 08:56, Austin English wrote: > Howdy all, > > As Alexandre mentioned [1], at WineConf we made several decisions to > modify bugzilla in a few ways. I've now implemented those changes, > which are outlined below: Hi Austin, thanks for doing these changes. :) > > * New wine-staging product: This should be used for bugs caused by > patches that are in wine-staging, but that do not occur in > wine-development (i.e., wine-staging patch regressions) As far as I know there were some concerns to call it "wine-staging", and it was preferred to call it just "staging". Did you use the original name to avoid ordering problems? > > * New STAGED resolution: This is to differentiate bugs that are FIXED > (in wine-development) from bugs that are not present in wine-staging > because of one or more patches. The anticipated workflow is: > UNCONFIRMED > bug confirmed, NEW > patch written and sent to > wine-patches, if it's accepted, FIXED. If not, and the patch is > integrated into wine-staging, then the bug is STAGED. When the patch > is revised and eventually integrated into wine-development, the bug > should move to FIXED. Wasn't the idea to add it as a non-RESOLVED status? I personally do not care that much about the difference, but we should probably decide before we use it everywhere. Also it would be nice to have a field to keep track of the staged patchset, without writing it in a comment. What about an additional field which is only present when this status is selected? (similar to the Regression SHA field for example) > > * New NEEDINFO resolution: There's a lot of confusion and different > handling by triagers for what to do with bug reports that are > incomplete (i.e., leaving it open versus closing invalid). To mitigate > this, I've added a NEEDINFO resolution. If a bug report lacks needed > information, set it to this status. Bug that have been open NEEDINFO > for more than 1 year can be closed. Similar to the staging status, why is this a RESOLVED status? Its not really a final status, so a non-RESOLVED status would make more sense maybe. > > * Renamed UPSTREAM to NOTOURBUG: This is more in line with what other > projects do, and eliminates confusion about the upstream/downstream > distinction. > > Please let me know if there are any questions or ideas for further enhancements. > > [1] https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html > Regards, Sebastian

Sept. 28, 2015

Re: ieframe: add a better toolbar bitmap

by Jacek Caban

Hi Jared, On 09/26/15 20:02, Jared Smudde wrote: > --- > dlls/ieframe/ietoolbar.bmp | Bin 24698 -> 24630 bytes > 1 files changed, 0 insertions(+), 0 deletions(-) That file is generated from ietoolbar.svg, so it's the SVG file that should be changed. You may enable generating those file in your build with --enable-maintainer-mode configure option. Thanks, Jacek

Sept. 28, 2015

Re: [PATCH 03/12] msvcp110: Add tr2_sys__Open_dir implementation.(resend)

by Piotr Caban

Hi, On 09/07/15 16:21, YongHao Hu wrote: > +/* ?_Open_dir(a)sys@tr2(a)std@@YAPAXAAY0BAE(a)DPBDAAHAAW4file_type@123@@Z */ > +/* ?_Open_dir(a)sys@tr2(a)std@@YAPEAXAEAY0BAE(a)DPEBDAEAHAEAW4file_type@123@@Z */ > +void* __cdecl tr2_sys__Open_dir(char* target, char const* dest, int* err_code, enum file_type* type) > +{ > + HANDLE handle; > + WIN32_FIND_DATAA data; > + char temppath[MAX_PATH]; > + TRACE("(%s %s %p %p)\n", debugstr_a(target), debugstr_a(dest), err_code, type); > + strcpy(temppath, dest); > + strcat(temppath, "\\*.*"); Is native limiting the path to MAX_PATH characters? What happens if longer path is passed? > + handle = FindFirstFileA(temppath, &data); > + if(handle == INVALID_HANDLE_VALUE) { > + if(GetLastError() == ERROR_PATH_NOT_FOUND) > + *err_code = ERROR_BAD_PATHNAME; > + else > + *err_code = GetLastError(); This doesn't look right. Probably some other function is returning different error on windows and on wine (or different function is used internally). Anyway I don't think we need to be compatible here (at least as long as there's no application that depends on it). > + while(!strcmp(data.cFileName, ".") || !strcmp(data.cFileName, "..")) { > + if(!FindNextFileA(handle, &data)) { > + *err_code = ERROR_SUCCESS; > + *type = status_unknown; > + return NULL; You're leaking handle here. Thanks, Piotr

Sept. 28, 2015

Re: How to add the Signed-off-by field in the git patch

by Michael Stefaniuc

On 09/28/2015 12:46 PM, Frédéric Delanoy wrote: > On Tue, Sep 22, 2015 at 5:02 PM, Alex Henrie <alexhenrie24(a)gmail.com> wrote: >> I just updated http://wiki.winehq.org/SubmittingPatches with >> instructions on how to include the Signed-off-by line. I will update >> the GitWine page soon. Please feel free to improve the wiki further. >> >> -Alex > > In the SubmittingPatches page, you say one should sign-off one's own > patches. Isn't that rather redundant when you are the author? Not redundant at all. The author signing-off just signals that the patch is ready for upstream and that the author takes responsibility for it. Without a sign-off it might be just a hack or a RFC or what not. > I believe Signed-off is for patch reviewers, not main authors. It is for both author(s) and reviewers. bye michael

Sept. 28, 2015

Re: How to add the Signed-off-by field in the git patch

by Frédéric Delanoy

On Tue, Sep 22, 2015 at 5:02 PM, Alex Henrie <alexhenrie24(a)gmail.com> wrote: > I just updated http://wiki.winehq.org/SubmittingPatches with > instructions on how to include the Signed-off-by line. I will update > the GitWine page soon. Please feel free to improve the wiki further. > > -Alex In the SubmittingPatches page, you say one should sign-off one's own patches. Isn't that rather redundant when you are the author? I believe Signed-off is for patch reviewers, not main authors. Frédéric

Sept. 28, 2015

Re: [PATCH] gdi32/freetype: Handle fonts with broken usWinDescent values

by Nikolay Sivov

On 27.09.2015 23:05, Marvin wrote: > 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 > https://testbot.winehq.org/JobDetails.pl?Key=16891 > > Your paranoid android. > > > === wvistau64 (32 bit font) === > Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) This one is called 'boterror' on job status, so I guess it's safe to ignore.

Sept. 28, 2015

Bugzilla changes

by Austin English

Howdy all, As Alexandre mentioned [1], at WineConf we made several decisions to modify bugzilla in a few ways. I've now implemented those changes, which are outlined below: * New wine-staging product: This should be used for bugs caused by patches that are in wine-staging, but that do not occur in wine-development (i.e., wine-staging patch regressions) * New STAGED resolution: This is to differentiate bugs that are FIXED (in wine-development) from bugs that are not present in wine-staging because of one or more patches. The anticipated workflow is: UNCONFIRMED > bug confirmed, NEW > patch written and sent to wine-patches, if it's accepted, FIXED. If not, and the patch is integrated into wine-staging, then the bug is STAGED. When the patch is revised and eventually integrated into wine-development, the bug should move to FIXED. * New NEEDINFO resolution: There's a lot of confusion and different handling by triagers for what to do with bug reports that are incomplete (i.e., leaving it open versus closing invalid). To mitigate this, I've added a NEEDINFO resolution. If a bug report lacks needed information, set it to this status. Bug that have been open NEEDINFO for more than 1 year can be closed. * Renamed UPSTREAM to NOTOURBUG: This is more in line with what other projects do, and eliminates confusion about the upstream/downstream distinction. Please let me know if there are any questions or ideas for further enhancements. [1] https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html -- -Austin

Sept. 28, 2015

Help building a DLL at run-time

by Hugh McMaster

Does anyone know a way to build DLLs at runtime? Testing regsvr32.exe requires one or more DLLs, so I compiled a test DLL for use with the tests. Apparently, the tests should be self-contained, meaning the DLL is produced at run-time. I'm assuming this is done for anyone using the winetest program. I thought I could write the DLL manually, using IMAGE_NT_HEADERS and other structures. Unfortunately, I'm unable to write the required functions to the file. For one thing, functions have no size. Another method would be to build the DLL and use the linker to convert the DLL to an object file, link the binary in, and then output it at run-time. Alternatively, I can leave the tests out of the source tree. Opinions?

Sept. 28, 2015

Re: [PATCH] gdi32/freetype: Handle fonts with broken usWinDescent values

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 https://testbot.winehq.org/JobDetails.pl?Key=16891 Your paranoid android. === wvistau64 (32 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

Sept. 27, 2015

Re: ntdll: Reduce stack usage of virtual memory functions by storing sigset in static memory.

by Michael Müller

Am 27.09.2015 um 00:07 schrieb Sebastian Lackner: > From: Michael Müller <michael(a)fds-team.de> > > For https://bugs.winehq.org/show_bug.cgi?id=34558 > > Depending on the compiler optimization flags there is still no guarantee that > everything will fit into the available stack space, no matter if its declared > as static or not. As suspected the idea does not work for all optimization levels. At least GCC merges the content of the functions when using -O2 and therefore reintroduces the problem - even __attribute__ ((noinline)) is not sufficient. As most distributions compile Wine with -02, I would suggest to ignore the patch for now. Maybe we can come up with a more general solution.

Sept. 27, 2015

Re: [PATCH v2] comctl32: Fix sizing of edit window for listview icon view

by Nikolay Sivov

On 26.09.2015 22:11, Barrett Karish wrote: > Test Program: https://bugs.winehq.org/attachment.cgi?id=35473 > --- By test I meant a test integrated into wine tests, in this case it should go to comctl32/tests/listview.c. Test should basically create Listview of particular style, enable item text edit control and check its style. I think I tried that long time ago and test didn't confirm what appeared to be obvious fix, but I might be wrong.

Sept. 27, 2015

opengl32: it does not compile well in CYGWIN and MINGW

by carlo.bramix＠libero.it

Hello, I'm writing here for asking a suggestion about a patch that I have sent one month ago. The fix attached in this email: https://www.winehq.org/pipermail/wine-patches/2015-August/141811.html is required because, when compiling opengl32 on Windows (CYGWIN or MINGW), the compiler complains that the exported functions are redeclared without dllimport attribute, while they should be declared with dllexport from beginning. This error can be fixed by adding the definition of _GDI32_ so that WINGDIAPI macro is declared correctly. This fix already exists for example in /dlls/gdi32/Makefile.in as you can see here: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/gdi32/Makefile.in I hope that it could be committed because perhaps it does not make difference on platforms without dllexport/dllimport attribute support, but it does on real Windows. Thank you. Sincerely, Carlo

Sept. 27, 2015

Re: WineConf 2015 decisions

by Aaryaman Vasishta

That's largely just because Python has become my go-to language over the > past few years, but it also seemed like Django is relatively good at > sitting on top of independent components (or at least Google actually > returned pages with advice on doing that; the docs for frameworks like > Rails or CakePHP were vaguer). That way we shouldn't have to python-ize > everything, but could just start with the views and account management, > then make changes incrementally from there. > > +1 for python. I have basic experience with django. I can try to contribute on the backend of things, if needed. Cheers, Aaryaman

Sept. 27, 2015

Re: WineConf 2015 decisions

by Kyle Auble

On 09/25/2015 03:16 AM, Alexandre Julliard wrote: > Over the last few months there have been a lot of discussions about how > to improve our development process. I've been gathering feedback, and > last week at WineConf I summarized the suggestions in my keynote > presentation.... > > ... > > I'm hoping that this will make the development process more pleasant for > everybody, and enable us to better respond to users' needs. > > Once these changes are in place, I'll also encourage everybody who had > given up in disgust to give us another chance; and if things are still > not satisfactory, please send us feedback. This is a work in progress, > and we will continue to listen and work on making things better. I just wanted to say that beyond all of these ideas sounding good, I think the simple fact that everyone's discussing them is a very encouraging sign. I get the feeling a lot of problems that cropped up recently aren't anyone's personal fault so much as growing pains, natural feedback from the project's advance (and the popularity and heightened expectations that come with that). After all, how long did it take before the first stable release was ready? Then compare that, in the past few years for example, to Pipelight or Andre H. being able to port everything to ARM64 in under a week. So the old approach actually made a lot of progress, until it started hitting new ceilings. At this point, my involvement with Wine mainly consists of technical writing and simple web-design, but before I take another hiatus, I'd like to toss out a couple thoughts based on what I've seen from that POV, digging through old docs and emails scattered across WineHQ. On 09/25/2015 03:16 AM, Alexandre Julliard wrote: > - Wine-staging is now considered an integral part of the Wine > development process, and will be used as a mechanism to enable more > patches to meet the requirements for inclusion in the main tree. We > will all be working together as a team. Regarding wine-staging, I haven't had any direct interaction with the branch, but I think nurturing it and bringing it back into the fold upstream is great. I know there was some concern that it would cause the code quality to start declining, but I could see the opposite happening too. Bugs either pop up for local reasons or subtler, structural ones; usually eyeballs (or maybe tools) can catch the former, but often only testing by a lot of users ultimately teases apart the the latter. And wine-staging seems to have hit on a way to attract more contributors, eyeballs and all. Involving more people in the project would also really help on the support side of things too (documentation, forums, bug triage, etc.) My one concern isn't that wine-staging will harm anything, but that it isn't a panacea for other issues... On 09/25/2015 03:16 AM, Alexandre Julliard wrote: > - We will switch to a time-based stable release, on a yearly > schedule. The code freeze will start every year in the fall. Michael > Stefaniuc will be maintaining the stable branch starting with 1.8. > > - We will start enforcing a Signed-Off-By header on patches, to make it > possible to better distribute reviewing responsibility, and to allow > multiple authors to cooperate on a patch. > > - We will keep a list of maintainer contact information for the various > submodules; developers will be encouraged to go through the respective > maintainer before submitting to wine-patches. ... but in combination with these changes, it could pay extra dividends down the road. I don't know if it's ever been suggested, but on top of just doing releases on a time-line, what if every subsystem's maintainer submitted their queue of signed-off patches at fixed times, in rotating order? If every patch within, say the past few days, is from one subsystem, and a regular tester or prompt bug-reporter finds a regression, we would already know where the bug lives, or at least where it vacations. Also, I was thinking that if every developer knows there are regular submission periods for the components they're interested in, they might feel like working more on things like refactoring, documentation, & bug-hunts during the rest periods. I'm biased because the wiki has partly become my baby in the project, but I think if there's one thing that might nudge more power-users/testers into becoming developers, it would be making the code-base easier to navigate. Refactoring and clear, up-to-date technical documentation (both specs like on WineAPI and implementation details) would be two immediate ways of accomplishing that, but both usually require the active developers' knowledge. On 09/26/2015 12:11 PM, Rosanne DiMesio wrote: > On Sat, 26 Sep 2015 09:07:56 -0700 > Ben Shadwick <benshadwick(a)gmail.com> wrote: >> I know this is the devel list, but what does this mean for AppDB? You >> mentioned being able to report bugs against wine-staging in the bug >> tacker, but nothing about being able to submit compatibility reports >> against it in the AppDB. These are currently rejected, which just >> happened to me. > They should be accepted, but getting the word out to all maintainers about that is going to be a problem. > > I've processed your report that was rejected. Now for all of the user-facing parts of the project, I think if there's one smart investment we could make, it would be migrating WineHQ to a web-framework. With that, it should become much simpler to update static pages, coordinate AppDB, Bugzilla, the source, & the docs, give users a streamlined view of the whole project (and managing their account), and even cooler things hitherto unimagined. I would be happy to try, but I really haven't had the time or energy to focus on that involved a project these past few years. If nobody else jumps on it first though, maybe I'll be available for that a year or two from now. I did do a little preliminary research, and was leaning away from the CMS-es (too restrictive and probably too much cruft) and towards Django actually. That's largely just because Python has become my go-to language over the past few years, but it also seemed like Django is relatively good at sitting on top of independent components (or at least Google actually returned pages with advice on doing that; the docs for frameworks like Rails or CakePHP were vaguer). That way we shouldn't have to python-ize everything, but could just start with the views and account management, then make changes incrementally from there. On 09/25/2015 04:45 PM, Tom Wickline wrote: > Was a overhaul of winehq.org <http://winehq.org> discussed? The site > really needs to be mobile friendly if you want the site to remain > relevant in the future. :) I could be wrong, but I expect this would be much simpler to do coming from a framework (with mobile helper packages) than the separate HTML/CSS for each sub-site we have now. - Kyle

Sept. 27, 2015

Re: WineConf 2015 decisions

by Benjamin Shadwick

That was unexpected, thanks. Maybe putting a banner at the top of the AppDB area of the site for a while would help? On Sat, Sep 26, 2015 at 11:11 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > On Sat, 26 Sep 2015 09:07:56 -0700 > Ben Shadwick <benshadwick(a)gmail.com> wrote: > > > > > I know this is the devel list, but what does this mean for AppDB? You > > mentioned being able to report bugs against wine-staging in the bug > > tacker, but nothing about being able to submit compatibility reports > > against it in the AppDB. These are currently rejected, which just > > happened to me. > > > > They should be accepted, but getting the word out to all maintainers about > that is going to be a problem. > > I've processed your report that was rejected. > > > -- > Rosanne DiMesio <dimesio(a)earthlink.net> > > >

Sept. 26, 2015

Re: WineConf 2015 decisions

by Rosanne DiMesio

On Sat, 26 Sep 2015 13:11:59 -0500 Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > > They should be accepted, but getting the word out to all maintainers about that is going to be a problem. > I found an "Email all maintainers" link on the Maintainers list, and just sent an email informing maintainers of the change. I don't know how well that will work. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Sept. 26, 2015

Re: WineConf 2015 decisions

by Rosanne DiMesio

On Sat, 26 Sep 2015 09:07:56 -0700 Ben Shadwick <benshadwick(a)gmail.com> wrote: > > I know this is the devel list, but what does this mean for AppDB? You > mentioned being able to report bugs against wine-staging in the bug > tacker, but nothing about being able to submit compatibility reports > against it in the AppDB. These are currently rejected, which just > happened to me. > They should be accepted, but getting the word out to all maintainers about that is going to be a problem. I've processed your report that was rejected. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Sept. 26, 2015

Re: WineConf 2015 decisions

by Ben Shadwick

Alexandre, I know this is the devel list, but what does this mean for AppDB? You mentioned being able to report bugs against wine-staging in the bug tacker, but nothing about being able to submit compatibility reports against it in the AppDB. These are currently rejected, which just happened to me. Thanks, - Ben S.

Sept. 26, 2015

Re: user32/tests: Allow tracing in menu test

by André Hentschel

Am 25.09.2015 um 10:45 schrieb Francois Gouget: > On Thu, 24 Sep 2015, André Hentschel wrote: > [...] >> The sense behind this patch is that I have a task from wineconf to send AJ >> a trace log of what happens before: >> Test failed: id 205: wID should be equal to hSubMenu >> on w2k8 systems. >> Strange enough is that I can't reproduce it by manually testbot runs anymore. > > Sometimes a test does not fail when run on its own but does when > run as part of WineTest because previous tests changed something. > Typically they left a window open or something like it. > > But if you managed to reproduce the issue by running the test on its own > before it may be something else. > It's suddenly gone: https://test.winehq.org/data/tests/user32:menu.html And I was able to reproduce it back in July, see attachment

Sept. 26, 2015

Re: WineConf 2015 decisions

by Tom Wickline

You are correct, I don't anymore! Or file bugs, or post here very often... -Tom On Sep 26, 2015 7:46 PM, "Rosanne DiMesio" <dimesio(a)earthlink.net> wrote: > On Sat, 26 Sep 2015 15:28:46 +0800 > Tom Wickline <twickline(a)gmail.com> wrote: > > > It's inclusion with options, but if *YOU* are against it, be prepared > to > > ask end users if they are having issues or praise with what branch on a > > continues basis. > > > > Because to most end users it will just be referred to simply as Wine. > > > > I guess you don't read the forum much, or you'd know that I already have > to ask most users what Wine version they're using, and Wine-staging users > have been posting there all along. The difference now is that I won't have > to tell them to go away. > > > -- > Rosanne DiMesio <dimesio(a)earthlink.net> >

Sept. 26, 2015

Re: WineConf 2015 decisions

by Tom Wickline

What if someone is interested in one version and not the other? -Tom On Sep 26, 2015 7:35 PM, "Alexandre Julliard" <julliard(a)winehq.org> wrote: > Tom Wickline <twickline(a)gmail.com> writes: > > > Would it be possible to have a wine-staging dev mailing list setup? > > A wine-staging patches mailing list setup? > > A wine-staging announce list setup? > > > > A new section in the forums for wine-staging added? > > > > Will the wine-staging releases be listed in the latest releases on > > winehg.org? > > > > Will wine-staging releases be run in the news section of winehq.org? > > We haven't discussed all the implementation details yet, but the point > is to treat wine-staging as just another Wine version. So there > shouldn't be any reason to have separate mailing lists, announce > channels, download pages, etc. It's all just Wine. > > -- > Alexandre Julliard > julliard(a)winehq.org >

Sept. 26, 2015

Re: WineConf 2015 decisions

by Rosanne DiMesio

On Sat, 26 Sep 2015 15:28:46 +0800 Tom Wickline <twickline(a)gmail.com> wrote: > It's inclusion with options, but if *YOU* are against it, be prepared to > ask end users if they are having issues or praise with what branch on a > continues basis. > > Because to most end users it will just be referred to simply as Wine. > I guess you don't read the forum much, or you'd know that I already have to ask most users what Wine version they're using, and Wine-staging users have been posting there all along. The difference now is that I won't have to tell them to go away. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Sept. 26, 2015

Re: WineConf 2015 decisions

by Alexandre Julliard

Tom Wickline <twickline(a)gmail.com> writes: > Would it be possible to have a wine-staging dev mailing list setup? > A wine-staging patches mailing list setup? > A wine-staging announce list setup? > > A new section in the forums for wine-staging added? > > Will the wine-staging releases be listed in the latest releases on > winehg.org? > > Will wine-staging releases be run in the news section of winehq.org? We haven't discussed all the implementation details yet, but the point is to treat wine-staging as just another Wine version. So there shouldn't be any reason to have separate mailing lists, announce channels, download pages, etc. It's all just Wine. -- Alexandre Julliard julliard(a)winehq.org

Sept. 26, 2015

Re: prelink (needed to compile wine) missing on Fedora 23

by Marcus Meissner

On Tue, Sep 22, 2015 at 11:54:39AM +0200, Sebastian Lackner wrote: > On 22.09.2015 10:44, Zhenbo Li wrote: > > Thanks, Sebastian > > > > 2015-09-22 1:55 GMT+08:00 Sebastian Lackner <sebastian(a)fds-team.de>: > >> > >> You might need it for some apps, especially older ones. The official Fedora > >> packages fix this issue by applying a patch to use compiler features instead of > >> prelink: > >> > >> http://pkgs.fedoraproject.org/cgit/wine.git/plain/wine-relocate-base.patch?… > > > > > > So I have this question: Do I need to apply this patch to wine-git > > before I'm working on wine? > > If I don't, will I face the risk that my patch may behave differently > > on other developers/users' computers and mine? > > > > For most parts of Wine it will make no difference. You should only keep > it in mind, when you want to reproduce bugs. There is a small chance that > you might run into a different issue without prelink or the patch applied. FWIW, I asked the Redhat maintainer to forward this patch to us, he said he needs to do some cleanups first. Ciao, Marcus

Sept. 26, 2015

Re: WineConf 2015 decisions

by Tom Wickline

It's inclusion with options, but if *YOU* are against it, be prepared to ask end users if they are having issues or praise with what branch on a continues basis. Because to most end users it will just be referred to simply as Wine. On Sep 26, 2015 8:57 AM, "Rosanne DiMesio" <dimesio(a)earthlink.net> wrote: > On Sat, 26 Sep 2015 06:45:53 +0800 > Tom Wickline <twickline(a)gmail.com> wrote: > > > > > A new section in the forums for wine-staging added? > > > > Why? We don't have separate sections for stable and development. The point > is to integrate wine-staging users, not separate them. Linux users should > post in the Linux subforum, Mac users in the MacOSX subforum. > > -- > Rosanne DiMesio <dimesio(a)earthlink.net> > > >

Sept. 26, 2015

Re: WineConf 2015 decisions

by Aaryaman Vasishta

Hi, Who will be the primary maintainer of wine-staging? Or list of maintainers > if multiple people have commit privileges... > The same guys who maintained wine-staging before will now be maintaining it as a part of winehq. AFAIK Sebastian Lackner and Michael Müller are the current maintainers. > Wine-staging currently has Mac OSX binary builds, does winehq plan to > have Mac OSX binary builds in the future? > Yes, we had discussed the possibility of using the build scripts for OSX too. Their build scripts have the option to build vanilla wine without the staging patches, so why not? :) I'll notify the maintainers on IRC, hopefully they should answer the rest of your questions :) Cheers, Aaryaman

Sept. 26, 2015

Re: WineConf 2015 decisions

by Rosanne DiMesio

On Sat, 26 Sep 2015 06:45:53 +0800 Tom Wickline <twickline(a)gmail.com> wrote: > > A new section in the forums for wine-staging added? > Why? We don't have separate sections for stable and development. The point is to integrate wine-staging users, not separate them. Linux users should post in the Linux subforum, Mac users in the MacOSX subforum. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Sept. 26, 2015

Re: WineConf 2015 decisions

by Tom Wickline

Hello Everyone, Due to prior commitments I was not available to attend this years conference. I have a few questions and suggestions maybe you guys can help me and others better understand the forthcoming changes. I as well as others are not totally aware of the changes, see. : http://wine-staging.com/news/2015-09-25-winehq-integration.html Would it be possible to have a wine-staging dev mailing list setup? A wine-staging patches mailing list setup? A wine-staging announce list setup? A new section in the forums for wine-staging added? Will the wine-staging releases be listed in the latest releases on winehg.org? Will wine-staging releases be run in the news section of winehq.org? Who will be the primary maintainer of wine-staging? Or list of maintainers if multiple people have commit privileges... Was a overhaul of winehq.org discussed? The site really needs to be mobile friendly if you want the site to remain relevant in the future. :) Wine-staging currently has Mac OSX binary builds, does winehq plan to have Mac OSX binary builds in the future? Cheers, Tom On Sep 25, 2015 5:17 PM, "Alexandre Julliard" <julliard(a)winehq.org> wrote: > Over the last few months there have been a lot of discussions about how > to improve our development process. I've been gathering feedback, and > last week at WineConf I summarized the suggestions in my keynote > presentation; the slides can be viewed at > > http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=winecon… > > We've then had a lot of constructive discussions about the various > points. The major decisions we've agreed on are: > > - Wine-staging is now considered an integral part of the Wine > development process, and will be used as a mechanism to enable more > patches to meet the requirements for inclusion in the main tree. We > will all be working together as a team. > > - Bugs reported against wine-staging will be accepted in the WineHQ bug > tracker; there will be a way to distinguish bugs specific to Staging, > and bugs that are fixed in Staging but not yet in main Wine. The > Staging bug tracker will be retired. Austin English is in charge of > implementing the necessary changes in Bugzilla. > > - We will switch to a time-based stable release, on a yearly > schedule. The code freeze will start every year in the fall. Michael > Stefaniuc will be maintaining the stable branch starting with 1.8. > > - We will start enforcing a Signed-Off-By header on patches, to make it > possible to better distribute reviewing responsibility, and to allow > multiple authors to cooperate on a patch. > > - We will keep a list of maintainer contact information for the various > submodules; developers will be encouraged to go through the respective > maintainer before submitting to wine-patches. > > - There will be a group of people who volunteer to be assigned patches > to review, to make sure that no patch goes unreviewed. Going through > Staging first will also be encouraged for unfinished or risky patches. > > - The patch tracker will send automated emails when a patch status > changes; this will also serve to encourage discussion rather than > despair when a patch is not approved. > > - We will start building and distributing binary packages for all > distros that don't have readily available packages. The packaging > scripts and control files will be maintained in git, so that people > can review them and submit improvements. > > These changes will be implemented over the next few weeks. > > I'm hoping that this will make the development process more pleasant for > everybody, and enable us to better respond to users' needs. > > Once these changes are in place, I'll also encourage everybody who had > given up in disgust to give us another chance; and if things are still > not satisfactory, please send us feedback. This is a work in progress, > and we will continue to listen and work on making things better. > > -- > Alexandre Julliard > julliard(a)winehq.org > > >

Sept. 25, 2015

Re: ntdll: Fix for 64-bit builds (at least on OSX)

by Charles Davis

> On Sep 25, 2015, at 2:46 PM, Matt Durgavich <mattdurgavich(a)gmail.com> wrote: > > Gotcha. Why rewrite vsscanf? Because vswscanf(3) works with wide-character strings (i.e. wchar_t). Also, none of the *scanf(3) functions in the system libc (libSystem on Mac OS) support Microsoft-style va_lists. Chip > > >> On Sep 25, 2015, at 2:21 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: >> >> Hang on; I have a better patch. (I wanted to send it earlier, but the SMTP connection kept unexpectedly closing.) >> >> Chip >> >

Sept. 25, 2015

Re: ntdll: Fix for 64-bit builds (at least on OSX)

by Matt Durgavich

Gotcha. Why rewrite vsscanf? > On Sep 25, 2015, at 2:21 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > > Hang on; I have a better patch. (I wanted to send it earlier, but the SMTP connection kept unexpectedly closing.) > > Chip >

Sept. 25, 2015

Re: [PATCH] usp10/tests: Catch case where enumerated font name is too long

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 https://testbot.winehq.org/JobDetails.pl?Key=16855 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1)

Sept. 25, 2015

Re: ntdll: Fix for 64-bit builds (at least on OSX)

by Charles Davis

Hang on; I have a better patch. (I wanted to send it earlier, but the SMTP connection kept unexpectedly closing.) Chip

Sept. 25, 2015

Dropping support for win2k in tests

by Jacek Caban

Hi all, I mentioned the concern on WineConf already and we quickly decided to not care about win2k during WineConf test session. But there is more to that: do we want to drop win2k support in our tests. I think we do. We have extra code to handle it all over tests codebase. Those are mostly skip()s + broken()s because, well, we don't care about win2k results. And if we don't care, then what's the point to bother and do the extra work. Stefan mentioned that ddraw has differences between win2k and newer version. That's true for other libraries as well. I don't think that's enough for the reason to keep win2k supported. A real case where test results on win2k was useful lately would be. Do we have an example of a real (not theoretical) use of win2k tests in recent Wine development? Thanks, Jacek

Sept. 25, 2015

Re: Wine and Buildroot

by Alex Henrie

2015-09-24 22:07 GMT+02:00 André Hentschel <nerv(a)dawncrow.de>: > For those interested, I just add an introduction of Buildroot to our Wine-Wiki: > > http://wiki.winehq.org/Buildroot > > See also my slides from WineConf2015: > http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=otherar… > > And a short WWN article from March 2015: > https://www.winehq.org/wwn/387#Wine%20in%20Buildroot Very nice, thank you! -Alex

Sept. 25, 2015

Re: Wine Stable/Release Changes

by Aaryaman Vasishta

On Fri, Sep 25, 2015 at 6:18 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: > So I don't think there's one right answer on this matter. It's more >>> about where to put the cursor between user-friendliness and development >>> speed / ease; and figuring out what will work best in the end for Wine. >>> >> For me "user-friendliness" in the context of Wine Stable means: >> "No regressions". >> > > I strongly agree. If I choose to use the stable version of Wine, I do not > want any surprises when I do an apt-get upgrade. Particularly if I > deliberately chose stable over the other two options. > > Cheers, > > Jeremy > > +1 I agree with Michael's points on wine stable. Also I guess this would work well with the code-freeze, where IIRC there should be enough time for regression checks on patches which have potential to go on wine stable. But I guess it all comes down to how it all goes during the first couple releases. Cheers, Aaryaman Cheers, Aaryaman

Sept. 25, 2015

Re: Wine Stable/Release Changes

by Rosanne DiMesio

On Fri, 25 Sep 2015 07:48:40 -0500 Jeremy White <jwhite(a)codeweavers.com> wrote: > I strongly agree. If I choose to use the stable version of Wine, I do > not want any surprises when I do an apt-get upgrade. Particularly if I > deliberately chose stable over the other two options. > +1 -- Rosanne DiMesio <dimesio(a)earthlink.net>

Sept. 25, 2015

Re: Wine Stable/Release Changes

by Jeremy White

>> So I don't think there's one right answer on this matter. It's more >> about where to put the cursor between user-friendliness and development >> speed / ease; and figuring out what will work best in the end for Wine. > For me "user-friendliness" in the context of Wine Stable means: > "No regressions". I strongly agree. If I choose to use the stable version of Wine, I do not want any surprises when I do an apt-get upgrade. Particularly if I deliberately chose stable over the other two options. Cheers, Jeremy

Sept. 25, 2015

Re: Wine Stable/Release Changes

by Michael Stefaniuc

On 09/25/2015 12:45 PM, Francois Gouget wrote: > On Tue, 22 Sep 2015, Michael Stefaniuc wrote: >> at WineConf we had a fairly uncontroversial discussion about the Wine >> Stable release process. As the current process of feature based Wine >> releases isn't working(*) following changes were agreed upon. > > I tried to make it a bit more controversial by suggesting that some Wine > Staging patches should maybe go into the Wine Stable release. But that > did not get very far. > > > The rationale is that Wine Stable is targeted at end users, not > developers. End users don't care that a patch is ugly and should not go > into mainline Wine for various reasons. All they care about is that > their applications work. So it could make sense to include carefully > selected Wine Staging patches that have been around for some time and > have not caused regressions. Only for regression fixes that are hard to do right and where reverting the original patch would regress a different set of applications. For the rest the patch needs to go through the development branch. > The main drawback is that it would make comparing Wine Stable with plain > Wine a bit harder: normally we would ask Wine Stable users to test their I see Wine Stable primary used for all those 20+K applications that just work today. For the users from whom we do not hear anything because Wine just works. For the others we will provide development and staging binaries, no need to hack up stable for that. > broken application in plain Wine to see if it's fixed. But now the > application may not even start due to the lack of one of these extra > patches (rather than a simple regression). > > > So I don't think there's one right answer on this matter. It's more > about where to put the cursor between user-friendliness and development > speed / ease; and figuring out what will work best in the end for Wine. For me "user-friendliness" in the context of Wine Stable means: "No regressions". bye michael

Sept. 25, 2015

Re: Wine Stable/Release Changes

by Francois Gouget

On Tue, 22 Sep 2015, Michael Stefaniuc wrote: > > Hello, > > at WineConf we had a fairly uncontroversial discussion about the Wine > Stable release process. As the current process of feature based Wine > releases isn't working(*) following changes were agreed upon. I tried to make it a bit more controversial by suggesting that some Wine Staging patches should maybe go into the Wine Stable release. But that did not get very far. The rationale is that Wine Stable is targeted at end users, not developers. End users don't care that a patch is ugly and should not go into mainline Wine for various reasons. All they care about is that their applications work. So it could make sense to include carefully selected Wine Staging patches that have been around for some time and have not caused regressions. The main drawback is that it would make comparing Wine Stable with plain Wine a bit harder: normally we would ask Wine Stable users to test their broken application in plain Wine to see if it's fixed. But now the application may not even start due to the lack of one of these extra patches (rather than a simple regression). So I don't think there's one right answer on this matter. It's more about where to put the cursor between user-friendliness and development speed / ease; and figuring out what will work best in the end for Wine. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A man can fail many times, but he isn't a failure until he begins to blame somebody else. -- John Burroughs

Sept. 25, 2015

WineConf 2015 decisions

by Alexandre Julliard

Over the last few months there have been a lot of discussions about how to improve our development process. I've been gathering feedback, and last week at WineConf I summarized the suggestions in my keynote presentation; the slides can be viewed at http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=winecon… We've then had a lot of constructive discussions about the various points. The major decisions we've agreed on are: - Wine-staging is now considered an integral part of the Wine development process, and will be used as a mechanism to enable more patches to meet the requirements for inclusion in the main tree. We will all be working together as a team. - Bugs reported against wine-staging will be accepted in the WineHQ bug tracker; there will be a way to distinguish bugs specific to Staging, and bugs that are fixed in Staging but not yet in main Wine. The Staging bug tracker will be retired. Austin English is in charge of implementing the necessary changes in Bugzilla. - We will switch to a time-based stable release, on a yearly schedule. The code freeze will start every year in the fall. Michael Stefaniuc will be maintaining the stable branch starting with 1.8. - We will start enforcing a Signed-Off-By header on patches, to make it possible to better distribute reviewing responsibility, and to allow multiple authors to cooperate on a patch. - We will keep a list of maintainer contact information for the various submodules; developers will be encouraged to go through the respective maintainer before submitting to wine-patches. - There will be a group of people who volunteer to be assigned patches to review, to make sure that no patch goes unreviewed. Going through Staging first will also be encouraged for unfinished or risky patches. - The patch tracker will send automated emails when a patch status changes; this will also serve to encourage discussion rather than despair when a patch is not approved. - We will start building and distributing binary packages for all distros that don't have readily available packages. The packaging scripts and control files will be maintained in git, so that people can review them and submit improvements. These changes will be implemented over the next few weeks. I'm hoping that this will make the development process more pleasant for everybody, and enable us to better respond to users' needs. Once these changes are in place, I'll also encourage everybody who had given up in disgust to give us another chance; and if things are still not satisfactory, please send us feedback. This is a work in progress, and we will continue to listen and work on making things better. -- Alexandre Julliard julliard(a)winehq.org

Sept. 25, 2015

Re: user32/tests: Allow tracing in menu test

by Francois Gouget

On Thu, 24 Sep 2015, André Hentschel wrote: [...] > The sense behind this patch is that I have a task from wineconf to send AJ > a trace log of what happens before: > Test failed: id 205: wID should be equal to hSubMenu > on w2k8 systems. > Strange enough is that I can't reproduce it by manually testbot runs anymore. Sometimes a test does not fail when run on its own but does when run as part of WineTest because previous tests changed something. Typically they left a window open or something like it. But if you managed to reproduce the issue by running the test on its own before it may be something else. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ All generalizations are false, including this one. -- Mark Twain

Sept. 25, 2015

Re: [PATCH] [comctl32] Fix sizing of edit window for listview icon view

by Nikolay Sivov

On 25.09.2015 4:33, Barrett Karish wrote: > --- > dlls/comctl32/listview.c | 42 +++++++++++++++++++++++++----------------- > 1 file changed, 25 insertions(+), 17 deletions(-) > > diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c > index e3fad51..ba227a7 100644 > --- a/dlls/comctl32/listview.c > +++ b/dlls/comctl32/listview.c > @@ -6048,12 +6048,15 @@ static LRESULT CALLBACK EditLblWndProcA(HWND hwnd, UINT uMsg, WPARAM wParam, LPA > */ > static HWND CreateEditLabelT(LISTVIEW_INFO *infoPtr, LPCWSTR text, BOOL isW) > { > - static const DWORD style = WS_CHILDWINDOW|WS_CLIPSIBLINGS|ES_LEFT|ES_AUTOHSCROLL|WS_BORDER|WS_VISIBLE; > - HINSTANCE hinst = (HINSTANCE)GetWindowLongPtrW(infoPtr->hwndSelf, GWLP_HINSTANCE); > + DWORD style = WS_CHILDWINDOW | WS_CLIPSIBLINGS | ES_LEFT | ES_AUTOHSCROLL | WS_BORDER | WS_VISIBLE | ES_MULTILINE; > + HINSTANCE hinst = (HINSTANCE)GetWindowLongPtrW(infoPtr->hwndSelf, GWLP_HINSTANCE); Hi, Barrett. Please use existing 4 space formatting and avoid unnecessary changes. > HWND hedit; > > TRACE("(%p, text=%s, isW=%d)\n", infoPtr, debugtext_t(text, isW), isW); > > + if (infoPtr->uView == LV_VIEW_ICON) > + style |= ES_CENTER; We need a test that proves that Edit gets centered style on icon view. > + > /* window will be resized and positioned after LVN_BEGINLABELEDIT */ > if (isW) > hedit = CreateWindowW(WC_EDITW, text, style, 0, 0, 0, 0, infoPtr->hwndSelf, 0, hinst, 0); > @@ -6093,7 +6096,6 @@ static HWND LISTVIEW_EditLabelT(LISTVIEW_INFO *infoPtr, INT nItem, BOOL isW) > HFONT hOldFont = NULL; > TEXTMETRICW tm; > RECT rect; > - SIZE sz; > HDC hdc; > > TRACE("(nItem=%d, isW=%d)\n", nItem, isW); > @@ -6152,24 +6154,30 @@ static HWND LISTVIEW_EditLabelT(LISTVIEW_INFO *infoPtr, INT nItem, BOOL isW) > GetWindowTextW(infoPtr->hwndEdit, disptextW, DISP_TEXT_SIZE); > TRACE("edit box text=%s\n", debugstr_w(disptextW)); > > - /* get string length in pixels */ > - GetTextExtentPoint32W(hdc, disptextW, lstrlenW(disptextW), &sz); > + DrawTextW(hdc, disptextW, -1, &rect, infoPtr->uView == LV_VIEW_ICON ? LV_FL_DT_FLAGS : LV_SL_DT_FLAGS | DT_CALCRECT); > > - /* add extra spacing for the next character */ > - GetTextMetricsW(hdc, &tm); > - sz.cx += tm.tmMaxCharWidth * 2; > + if (infoPtr->uView != LV_VIEW_ICON) > + { > + /* add extra spacing for the next character */ > + GetTextMetricsW(hdc, &tm); > + rect.right += tm.tmMaxCharWidth; > + rect.left -= 2; > + rect.top -= 1; > + rect.bottom += 2; > + } > + else > + { > + rect.bottom += 3; > + } > This should ideally use some font metrics instead of hardcoded magic, but I know we do it this way already. > - if (infoPtr->hFont) > - SelectObject(hdc, hOldFont); > + if (infoPtr->hFont) > + SelectObject(hdc, hOldFont); > > - ReleaseDC(infoPtr->hwndSelf, hdc); > + ReleaseDC(infoPtr->hwndSelf, hdc); > > - sz.cy = rect.bottom - rect.top + 2; > - rect.left -= 2; > - rect.top -= 1; > - TRACE("moving edit=(%d,%d)-(%d,%d)\n", rect.left, rect.top, sz.cx, sz.cy); > - MoveWindow(infoPtr->hwndEdit, rect.left, rect.top, sz.cx, sz.cy, FALSE); > - ShowWindow(infoPtr->hwndEdit, SW_NORMAL); > + TRACE("moving edit=(%d,%d)-(%d,%d)\n", rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top); > + MoveWindow(infoPtr->hwndEdit, rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top, FALSE); > + ShowWindow(infoPtr->hwndEdit, SW_NORMAL); > SetFocus(infoPtr->hwndEdit); > SendMessageW(infoPtr->hwndEdit, EM_SETSEL, 0, -1); > return infoPtr->hwndEdit; >

Sept. 25, 2015

Wine and Buildroot

by André Hentschel

Hi, For those interested, I just add an introduction of Buildroot to our Wine-Wiki: http://wiki.winehq.org/Buildroot See also my slides from WineConf2015: http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=otherar… And a short WWN article from March 2015: https://www.winehq.org/wwn/387#Wine%20in%20Buildroot

Sept. 24, 2015

Re: Videos or Slides from WineConf

by Joel Holdsworth

Thanks Stefan, I'm really looking forward to watching. Joel On 24/09/15 20:09, Stefan Dösinger wrote: > I am still working on the videos (done with the keynote and Jeremy White's talk, halfway done with Michael Stefanuic's), I expect that they're ready at the beginning of the next week. > > Cheers, > Stefan > >> Am 24.09.2015 um 18:19 schrieb André Hentschel <nerv(a)dawncrow.de>: >> >> I attached my slides on "The other Architectures" >> >> > > > >

Sept. 24, 2015

Re: Videos or Slides from WineConf

by Stefan Dösinger

I am still working on the videos (done with the keynote and Jeremy White's talk, halfway done with Michael Stefanuic's), I expect that they're ready at the beginning of the next week. Cheers, Stefan > Am 24.09.2015 um 18:19 schrieb André Hentschel <nerv(a)dawncrow.de>: > > I attached my slides on "The other Architectures" > >

Sept. 24, 2015

Re: user32/tests: Allow tracing in menu test

by Aaryaman Vasishta

On Thu, Sep 24, 2015 at 11:36 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > Strange enough is that I can't reproduce it by manually testbot runs > anymore. > That's kinda odd. Could it be some kinda regression in the testbot itself? Cheers, Aaryaman

Sept. 24, 2015

Re: user32/tests: Allow tracing in menu test

by André Hentschel

Am 23.09.2015 um 05:54 schrieb Dmitry Timoshkov: > André Hentschel <nerv(a)dawncrow.de> wrote: > >> + if (winetest_debug > 1) >> + trace("item #%u: fType %04x, fState %04x, wID %u, hSubMenu %p\n", >> + i, mii.fType, mii.fState, mii.wID, mii.hSubMenu); > > Please use 4 spaces for indentation after 'if ()', not 8. Oops, done. > Also, what's the reason of this patch? There are several other similar > disabled debug traces in that file, anything special about this one? True, I fixed that. > And I'd suggest to simply replace if (0) by if (1) in the personal build > if you really need to see the traces. We have the feature of enabling it based on winetest_debug, so we should use that. The sense behind this patch is that I have a task from wineconf to send AJ a trace log of what happens before: Test failed: id 205: wID should be equal to hSubMenu on w2k8 systems. Strange enough is that I can't reproduce it by manually testbot runs anymore.

Sept. 24, 2015

Re: Videos or Slides from WineConf

by André Hentschel

I attached my slides on "The other Architectures"

Sept. 24, 2015

Re: Videos or Slides from WineConf

by Aric Stewart

I have attached the slides from my HID presentation for anyone who is interested. -aric

Sept. 24, 2015