April 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 2/2] include/wincon.h: add some undocumented prototypes

by Hugh McMaster

On Tuesday, 19 April 2016 8:54 PM, Hugh McMaster wrote: >On Tuesday, 19 April 2016 11:25 AM UTC+10, Austin English wrote: > >> +/* Undocumented */ >> +WINBASEAPI DWORD WINAPI GetNumberOfConsoleFonts(void); >[...] >> +/* Undocumented */ >> +WINBASEAPI BOOL WINAPI SetConsoleFont(HANDLE, DWORD); >[...] >> +/* Undocumented */ >> +WINBASEAPI BOOL WINAPI SetConsoleIcon(HICON); >> +WINBASEAPI BOOL WINAPI SetConsoleMode(HANDLE,DWORD); > >As with your previous patch, these functions can only be called via GetModuleHandle >and GetProcAddress on Windows, so they shouldn't be included in wincon.h. With the exception of SetConsoleMode, of course. -- Hugh McMaster

April 19, 2016

Re: [PATCH 2/2] include/wincon.h: add some undocumented prototypes

by Hugh McMaster

On Tuesday, 19 April 2016 11:25 AM UTC+10, Austin English wrote: > +/* Undocumented */ > +WINBASEAPI DWORD WINAPI GetNumberOfConsoleFonts(void); [...] > +/* Undocumented */ > +WINBASEAPI BOOL WINAPI SetConsoleFont(HANDLE, DWORD); [...] > +/* Undocumented */ > +WINBASEAPI BOOL WINAPI SetConsoleIcon(HICON); > +WINBASEAPI BOOL WINAPI SetConsoleMode(HANDLE,DWORD); As with your previous patch, these functions can only be called via GetModuleHandle and GetProcAddress on Windows, so they shouldn't be included in wincon.h. -- Hugh McMaster

April 19, 2016

RE: [PATCH 1/2] kernel32: add GetConsoleFontInfo stub

by Hugh McMaster

On Tuesday, 19 April 2016 11:25 AM, Austin English wrote: >+BOOL WINAPI GetConsoleFontInfo(HANDLE hOutput, BOOL bMaximize, DWORD numFonts, CONSOLE_FONT *info) >+{ >+ FIXME("(%p %d %u %p): stub!\n", hOutput, bMaximize, numFonts, info); >+ SetLastError(ERROR_CALL_NOT_IMPLEMENTED); >+ return FALSE; >+} Please add this function after the GetConsoleFontSize function. We should keep the "Ex" functions in their own group at the bottom of console.c. Also, avoid Hungarian notation for bMaximize. That's okay for the HANLDE, although it should be hConsole. to match the surrounding code. >+/* Undocumented */ >+WINBASEAPI BOOL WINAPI GetConsoleFontInfo(HANDLE, BOOL, DWORD, CONSOLE_FONT *); I can't check right now, but I'm fairly certain GetConsoleFontInfo should not be included in wincon.h. IIRC, this function cannot be called directly from a console program, only via GetModuleHandle and GetProcAddress. -- Hugh McMaster

April 19, 2016

Re: [PATCH 05/10] wined3d: Try to avoid glGetTexImage() for 2D array textures.

by Józef Kucia

On Tue, Apr 19, 2016 at 11:24 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 19 April 2016 at 00:01, Józef Kucia <jkucia(a)codeweavers.com> wrote: >> Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> >> --- >> It's inefficient to download a complete miplevel to copy just a single layer from it. >> --- > Does this happen much in practice? Do you have performance numbers? > The patch doesn't really make sense in its current form. > surface_download_data() is meant for downloading the data from the > texture. If that's not what you want, don't call it. (Also, does this > actually work? It looks like it's just reading from the current > drawable.) > The issue is if we do not have ARB_get_texture_sub_image we use glGet[Compressed]TexImage() to download the data from texture. This type of download is implemented in the patch 6. I want to avoid glGet[Compressed]TexImage() for array textures because these functions don't allow to download the data for a single wined3d surface. They allow to download data for the whole miplevel slice. In the patch 6 a block of memory is allocated, the whole miplevel slice is downloaded and the data for a single layer is copied to the current wined3d surface. The idea in this patch is to simulate glGetTextureSubImage() using reads from the framebuffer. An array array texture is attached to framebuffer using glFramebufferTextureLayer() and the data for a single wined3d surface is downloaded using glReadPixels(). This works in my d3d11 tests which I plan to submit in the following patchset.

April 19, 2016

Re: [PATCH 05/10] wined3d: Try to avoid glGetTexImage() for 2D array textures.

by Henri Verbeet

On 19 April 2016 at 00:01, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > It's inefficient to download a complete miplevel to copy just a single layer from it. > --- Does this happen much in practice? Do you have performance numbers? The patch doesn't really make sense in its current form. surface_download_data() is meant for downloading the data from the texture. If that's not what you want, don't call it. (Also, does this actually work? It looks like it's just reading from the current drawable.)

April 19, 2016

Re: [PATCH 4/4] inetcomm/tests: Add IMimeMessage SetOption tests

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=22311 Your paranoid android. === wvistau64 (64 bit mimeole) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit mimeole) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit mimeole) === Found no trace of the test summary line or of a crash === w864 (64 bit mimeole) === Found no trace of the test summary line or of a crash === w1064 (64 bit mimeole) === Found no trace of the test summary line or of a crash

April 19, 2016

Re: ntdll: Ignore invalid exit_frame when exiting thread.

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Some versions of pthread indeed put internal structures at the top of the stack. > To solve that, the current Staging patchset allocates threads with a dummy pthread, > and then switches to the real stack, see: > https://github.com/wine-compholio/wine-staging/blob/master/patches/ntdll-Th… > Unless there is something weird going on, thanks to the CFI annotations in > wine_switch_to_stack() pthread should be able to unwind the stack correctly despite > the stack switch inbetween. At least I have not found any problems so far ;) For this specific stack switch, sure, but it can't unwind across Win32 code, which was the reason for the exit frame in the first place. > You are right that ignoring exit_frame might (under specific circumstances) > run language handlers, but I'm not yet aware of a better way to deal with this. > The only alternative would be to calculate it based on StackBase, but its also > far from perfect. I'd suggest to instead try to keep the initial stack around. -- Alexandre Julliard julliard(a)winehq.org

April 19, 2016

Re: ddraw/tests: A spelling fix for a d3d ok() message.

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=22306 Your paranoid android. === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

April 19, 2016

Re: advapi32/tests: Some spelling fixes for the security ok() messages.

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=22304 Your paranoid android. === w1064 (32 bit security) === security.c:3964: Test failed: MACHINE\Software owner SID (S-1-5-18) != Administrators SID (S-1-5-32-544). security.c:4005: Test failed: Builtin Users ACE has unexpected flags (0x12 != 0xa) security.c:4009: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4018: Test failed: Builtin Admins ACE has unexpected flags (0x12 != 0x0) === w1064 (64 bit security) === security.c:4005: Test failed: Builtin Users ACE has unexpected flags (0x2 != 0xa) security.c:4009: Test failed: Builtin Users ACE has unexpected mask (0x20019 != 0x80000000) security.c:4018: Test failed: Builtin Admins ACE has unexpected flags (0x2 != 0x0)

April 19, 2016

Re: [Tools] testbot/TestAgent: Better indicate the file transfer position/range in case of errors.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > Should I resend or change this patch? It's fine, I just forgot to push the tools repository. Sorry about that. -- Alexandre Julliard julliard(a)winehq.org

April 19, 2016