- wine-devel - winehq.org

Re: [PATCH v3] ucrtbase: Make the strtod implementation C99 compatible
by Martin Storsjö 02 Oct '15

02 Oct '15

On Tue, 29 Sep 2015, Martin Storsjo wrote: > Add a test for ucrtbase that verifies these aspects of the C99 > behaviour of strtod. > > Signed-off-by: Martin Storsjo <martin(a)martin.st> > --- > Changed the overflow checking to use base instead of 10, and added > more test cases, as suggested by Piotr. > --- > configure.ac | 1 + > dlls/msvcrt/string.c | 68 ++++++++++++++++++---- > dlls/ucrtbase/tests/Makefile.in | 5 ++ > dlls/ucrtbase/tests/string.c | 121 ++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 185 insertions(+), 10 deletions(-) > create mode 100644 dlls/ucrtbase/tests/Makefile.in > create mode 100644 dlls/ucrtbase/tests/string.c Any further comments on this? Afaik I've addressed all comments by Piotr so far. // Martin

2 1

Re: [1/2 v2] user32: Implement semi-stub for FlashWindowEx.
by Marvin 02 Oct '15

02 Oct '15

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=16936 Your paranoid android. === w8 (32 bit win) === win.c:3417: Test failed: hwnd 00030114 message 0118 === w864 (32 bit win) === win.c:3417: Test failed: hwnd 0006012C 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 win.c:8119: Test failed: msg.message = 31f win.c:8121: Test failed: pos = 008c0078 win.c:8138: Test failed: pos = 01400154 win.c:8140: Test failed: msg.message = 8000 win.c:8142: Test failed: pos = 014a015e win.c:8152: Test failed: msg.message = 8001 win.c:8154: Test failed: pos = 01540140 === w864 (64 bit win) === win.c:3417: Test failed: hwnd 0000000000060100 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

1 0

Re: ntdll: Return STATUS_INVALID_DEVICE_REQUEST when calling NtReadFile on directory.
by Alexandre Julliard 02 Oct '15

02 Oct '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > dlls/ntdll/file.c | 2 +- > dlls/ntdll/tests/file.c | 16 ++++++++++++++++ > 2 files changed, 17 insertions(+), 1 deletion(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index be6b591..e4370dc 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -444,7 +444,7 @@ NTSTATUS FILE_GetNtStatus(void) > case EACCES: return STATUS_ACCESS_DENIED; > case ENOTDIR: return STATUS_OBJECT_PATH_NOT_FOUND; > case ENOENT: return STATUS_OBJECT_NAME_NOT_FOUND; > - case EISDIR: return STATUS_FILE_IS_A_DIRECTORY; > + case EISDIR: return STATUS_INVALID_DEVICE_REQUEST; That's going to affect all file functions, not only NtReadFile. It would need more test cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 01/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX volumes
by Stefan Dösinger 01 Oct '15

01 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: > - HRESULT (__cdecl *volume_created)(struct wined3d_device_parent > *device_parent, void *container_parent, - struct > wined3d_volume *volume, void **parent, const struct > wined3d_parent_ops **parent_ops); + HRESULT (__cdecl > *volume_created)(struct wined3d_device_parent *device_parent, + > struct wined3d_texture *texture, unsigned int sub_resource_idx, + > void **parent, const struct wined3d_parent_ops **parent_ops); Is there a reason why you're passing the wined3d_texture container instead of the container parent? It doesn't matter too much because you can either do wined3d_resource_get_parent or d3d*_texture->wined3d_texture, but I think it is a needless change. It seems the patch is bigger than it needs to be. You could just add unsigned int sub_resource_idx and keep the rest in place. Through struct d3d8_texture *texture inside struct d3d8_volume you already have access to the wined3d texture. With the addition of the sub resource idx you can migrate the volume methods one by one, and in the last patch that removes access to wined3d_volume drop struct wined3d_volume *volume from the callback. For surfaces in d3d8 and d3d9 you have to make sure you're always creating a d3d8/9_texture struct for plain surfaces, but this is something you can change internally in d3d8/9. It doesn't matter too much for this patch because the volume API is pretty simple, but the next patch is pretty complicated because it changes all the stuff at once. It'll be terrible to bisect / fix if there are regressions. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAmguAAoJEN0/YqbEcdMwpecP/RqlgzxhIzYQikgOQHhMBuLr 1jOtBW2aAj8qRCPebkM5JAGK+93Y+r9jrkFbJn01ZHKR1fQCfWQteCoMRUIDJ6Iz TUf5IeuKsUMucU6XJ70kh/d8MQCauOKJizvROCg6F1qILF+W6higdGHC/6FjSqqb GiXmYAtqGgOP3BGAjM4W4r8+A7yoqssLhLYmJggn8PlX6yFfdIwl/rpOdRfSC+9T ADrncsPVPpyYFRnQI+atdQuMN5M/GvioqxFS24Fuq65tUqNaXC6D8BsGy0tk6bN2 nZAWkSkrx1bSi24U7RzHbq936Z+qnUp5UH/ZkView8dp5dXiqjmOLucWd4WJ/+0I rMjIduEPuLgDraKnE4vKtn5WpPmV/ITX6If5zI9fTuFBLwyIrC06lIeaGd5VOHiO 2/U00pyIQuS9F6Ir73J0hl5CJITYhmSdT9xsz2sIBbQheZu7OYLqqfIHM0d3DGBk tC3H9X4bJQh9nDzLy4IGVr2W2vqQgKIVGxyVcYFyvA448kP7/W2Z1i+ak9CevFGg fVBrwoPtTzPIoucC9cQ1vnskTITgzSNCuy3t+HBKsbm+0+7VsDnq8CL7wrGbs8uN hSXwpCA4qLsPyK+6XCuITB8rmkGVX3/2j6Ratf2lSgdZVexQfsK/+hWQYIwXzjki otAB34aWZl2+f/socndA =6ndo -----END PGP SIGNATURE-----

3 4

Re: [PATCH 1/2 v2] msvcp: Add _Dscale implementation
by Marvin 01 Oct '15

01 Oct '15

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=16924 Your paranoid android. === w2000pro (32 bit msvcp120) === The test timed out

2 1

opengl32: it does not compile well in CYGWIN and MINGW
by carlo.bramix＠libero.it 01 Oct '15

01 Oct '15

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

2 1

Wined3d wireframe rendering
by Bruno Jesus 01 Oct '15

01 Oct '15

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

5 9

Re: rsaenh/tests: Adjust length value to pass on Win 10 (try 2) (resend)
by Marvin 30 Sep '15

30 Sep '15

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

1 0

libosmesa bitness
by André Hentschel 30 Sep '15

30 Sep '15

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?

1 0

Re: [PATCH] usp10/tests: fix some tests on Hebrew and Arabic locales
by Marvin 30 Sep '15

30 Sep '15

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)

1 0

Re: [PATCH] secur32/tests: handle skip cleanup in negotiate more cleanly
by Nikolay Sivov 30 Sep '15

30 Sep '15

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?

2 1

Re: [PATCH] windowscodecs/tests: handle failure to create png decoder
by Nikolay Sivov 30 Sep '15

30 Sep '15

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.

3 2

Re: [2/2 v3] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION.
by Ken Thomases 30 Sep '15

30 Sep '15

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

2 2

Re: [PATCH 03/12] msvcp110: Add tr2_sys__Open_dir implementation.(resend)
by Piotr Caban 30 Sep '15

30 Sep '15

Hi, On 09/07/15 16:21, YongHao Hu wrote: > +/* ?_Open_dir@sys@tr2@std@@YAPAXAAY0BAE@DPBDAAHAAW4file_type@123@@Z */ > +/* ?_Open_dir@sys@tr2@std@@YAPEAXAEAY0BAE@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

2 2

Re: [1/2 resend] user32: Implement semi-stub for FlashWindowEx.
by Marvin 30 Sep '15

30 Sep '15

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

1 0

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible
by Piotr Caban 29 Sep '15

29 Sep '15

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

2 1

Re: [PATCH] gdi32: Antialias fake bold or italic fonts regardless of GASP table.
by Nikolay Sivov 29 Sep '15

29 Sep '15

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>

2 2

Migrating away from Sourceforge
by Austin English 29 Sep '15

29 Sep '15

Howdy all, I noticed there was some discussion of this on #winehackers a week or two ago, but I haven't seen any formal discussion about it. Given SourceForge's recent activities [1] [2] with taking over open source projects for their own gain, I propose that we migrate away from SourceForge. The main uses for SourceForge is for mirroring tarballs, wine-gecko/wine-mono installers, and the wine-gecko git repository. @Jeremy, would it be feasible for winehq's (existing) servers to handle the additional load? [1] http://www.extremetech.com/computing/206687-sourceforge-accused-of-hijackin… [2] http://www.extremetech.com/computing/206687-sourceforge-accused-of-hijackin… -- -Austin

14 22

Re: [PATCH 1/2] d3d8: Accept D3DSWAPEFFECT_COPY_VSYNC.
by Marvin 28 Sep '15

28 Sep '15

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.

1 0

Re: ieframe: add a better toolbar bitmap
by Jacek Caban 28 Sep '15

28 Sep '15

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

2 1

Re: ntdll: Reduce stack usage of virtual memory functions by storing sigset in static memory.
by Michael Müller 28 Sep '15

28 Sep '15

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.

2 1

Re: msadpcm32.acm: Stop converting data instead of crashing
by Andrew Eikum 28 Sep '15

28 Sep '15

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

3 3

Re: [PATCH] opengl32: use thunks for glDebugMessageCallback
by Matteo Bruni 28 Sep '15

28 Sep '15

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.

1 0

How to add the Signed-off-by field in the git patch
by Dmitry Timoshkov 28 Sep '15

28 Sep '15

Hi all, since I personally asked that question and investigated a bit the subject, here is some information that could be probably useful to someone else: http://stackoverflow.com/questions/13457203/how-to-add-the-signed-off-by-fi… http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… http://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-usin… http://git-scm.com/docs/git-format-patch (CONFIGURATION section) Personally I've chosen to add [format] signOff = true to git.config file. -- Dmitry.

5 4

Re: [PATCH] gdi32/freetype: Handle fonts with broken usWinDescent values
by Marvin 28 Sep '15

28 Sep '15

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)

2 1

Help building a DLL at run-time
by Hugh McMaster 28 Sep '15

28 Sep '15

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?

1 0

Re: [PATCH v2] comctl32: Fix sizing of edit window for listview icon view
by Nikolay Sivov 27 Sep '15

27 Sep '15

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.

1 0

Re: user32/tests: Allow tracing in menu test
by Dmitry Timoshkov 26 Sep '15

26 Sep '15

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. Also, what's the reason of this patch? There are several other similar disabled debug traces in that file, anything special about this one? And I'd suggest to simply replace if (0) by if (1) in the personal build if you really need to see the traces. -- Dmitry.

4 4

prelink (needed to compile wine) missing on Fedora 23
by Zhenbo Li 26 Sep '15

26 Sep '15

Hello, I installed Fedora 23 Alpha to my computer, and tried to compile wine today. After running "./configure", I got this in my terminal configure: WARNING: prelink not found, base address of core dlls won't be set correctly. The reason is that prelink has been obsoleted since Fedora 23[1] There is a successful build for wine on Fedora23[2], and it seems that that package has been affected by missing prelink too.[3] Is this a critical problem? Should I ignore this WARNING, or try to fix it? Thank you [1]: https://admin.fedoraproject.org/pkgdb/package/prelink/ [2]: http://koji.fedoraproject.org/koji/buildinfo?buildID=683683 [3]: https://kojipkgs.fedoraproject.org//packages/wine/1.7.51/1.fc23/data/logs/x… -- Have a nice day! Zhenbo Li

3 4

Re: ntdll: Fix for 64-bit builds (at least on OSX)
by Charles Davis 25 Sep '15

25 Sep '15

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

2 2

Re: [PATCH] usp10/tests: Catch case where enumerated font name is too long
by Marvin 25 Sep '15

25 Sep '15

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)

1 0

Dropping support for win2k in tests
by Jacek Caban 25 Sep '15

25 Sep '15

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

1 0

Wine and Buildroot
by André Hentschel 25 Sep '15

25 Sep '15

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

2 1

Wine Stable/Release Changes
by Michael Stefaniuc 25 Sep '15

25 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Release Process Changes - ----------------------- - - Switch to time based releases. - - Major releases once a year in autumn/fall. Code freeze starts around mid/end of September. - - Michael Stefaniuc will be the stable maintainer starting with 1.8.x. Other people are more than welcome to help out with Wine Stable. I'll document stuff and send out a request for help during the code freeze. - - The stable release will be supported in bugzilla. - - This changes take effect immediately. You can expect Alexandre to announce a code freeze in the next couple of weeks. - - We will revisit this changes should the need arise, e.g. reduce the time between two major stable releases. Discussion - ---------- The discussion was done based on slide 9 of Alexandre's keynote http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=winecon… At the start Alexandre and others noted that we do not hear from users for whom 1.6 is just working. We are getting reports only about the stuff that breaks. The discussion quickly geared to the changes accepted from above with the focus on implementation details: - - 6 months better? No, the 12-18 months stable release cadence prior to 1.8 was ok. Can be reduced later on should the need arise. - - Synchronize with (a) major distro? No, release dates can slip on both ends. Freeze should also not impact GSoC. - - Nobody else volunteered during the discussion for the stable maintainer role. For the more drastic proposal of removing the the Wine Stable version altogether, Alexandre made drafted a plan to follow a similar model to the Linux Kernel. One release for the risky stuff and every second release is for stabilization. He proposed also a two weeks "merge window" for risky stuff followed by two weeks for the fixes and the last two weeks of "freeze". This produced a loud outcry from most developers: it would be unworkable without a prior move to a git pull model to accept new features. This basically killed the proposal. (*) 1.6 released > 2 years ago and was latest updated 1.5 years ago. It doesn't compiles on a modern distribution anymore. bye michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFWAT4O0ei8kcpE1VERAprfAKC0x+Zb6zHGv095REWGGYy+L/qsBQCgpr1+ Z9VxsMM7J1/wdpAyC8DPJaE= =zhZ8 -----END PGP SIGNATURE-----

6 6

Re: [PATCH] [comctl32] Fix sizing of edit window for listview icon view
by Nikolay Sivov 25 Sep '15

25 Sep '15

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; >

1 0

Re: [2/2] kernel32: Implement Set/GetThreadGroupAffinity and add tests.
by Marvin 23 Sep '15

23 Sep '15

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=16838 Your paranoid android. === w1064 (32 bit thread) === thread.c:1087: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

2 1

Inconsistent argument type declaration in dinput.h: WriteEffectToFile()
by Elias Vanderstuyft 23 Sep '15

23 Sep '15

Hi everyone, The docs of IDirectInputDevice8::WriteEffectToFile() declare the third argument as LPCDIFILEEFFECT rgDiFileEft: https://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_… This is inconsistent with Microsoft's "dinput.h" file, they declare it as LPDIFILEEFFECT (thus, no "const"): ftp://sccn.ucsd.edu/pub/LSL/lsl-dependencies/external_libs/EmbarcaderoXE/sh… Wine's "dinput.h" follows the same mistake as Microsoft's: https://github.com/wine-mirror/wine/blob/master/include/dinput.h#L1866 Is there a particular reason for this? Best regards, Elias

3 4

Re: [PATCH 11/12] ddraw: cache active DCs
by Stefan Dösinger 23 Sep '15

23 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: > + sub_resource = wined3d_texture_get_sub_resource(surface_impl->wined3d_texture, surface_impl->sub_resource_idx); > + wined3d_surface = wined3d_surface_from_resource(sub_resource); > + if (FAILED(hr = wined3d_surface_getdc(wined3d_surface, &surface_dc))) I expect the getdc call to fail because the application already called GetDC. I think you can just add a HDC dc field to struct wined3d_surface and compare it to the dc passed to GetSurfaceFromDC. > + if (!hdc) > { > - TRACE("No surface found for dc %p.\n", hdc); > *Surface = NULL; > return DDERR_NOTFOUND; > } Personally I prefer to write a WARN if we return failure to the application. Note that this is just my personal choice though, the existing code is not consistent here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAnJqAAoJEN0/YqbEcdMwGTwP/3zCYpjVZYY0M3Mafxs7j3Dq WPDkiiRzshspPTLIx3kurk7lRd2JXa8GbXZ8bOjx6bOz9wZC1wtejQEwLGhENOgz bzX9tyYT2FdRXVXM0V0bEOAvd0rivgIeE0xcPWYZg289bHTx4bw/3Ql+uSsUY/8L lamfMT5xOKhZmr6T5mI3MpHjUnbIUtBrOHvAggNexfl+RcvlFgmsl1MqajBHO+O7 W1ws4F35MzbXiEKUNEX3yH1cr3WRW+9xcAi89YYTnOTIpYsJHGOOOXoAeF1G2W2c dvj131zQRdlIknLxxZPZXSQJJffdiDdnuJ6xeMfJ1f9SdH0PNPKhX08wH2Wz+Zr8 77zY0vK2iqnAl0HUcq4WrL4TLh60VU2UeyhAy8vqYjso60OvANAmYBljgO5Z4oI/ mypsa1sq11Vrp+DAIaxFyj15whgdV2tE/NvC4Kapx4OK8DTQ+9xHGJoED9AX/E+/ OvynPYd/r/WPYyIYJpSv/YOAN4OAusNpY7i4nlXu8RbphTFcNZTrtLU/EUJCfI6T LaEx3TX9/Dg4BNrwY72cPleLKSZbGK1/59q0XWbH5Oft8HS48jL7IEJkNsNtJpqf GOJr/EotzHpJC2QGKOZ19NhgcCb22GbF8jCniLMVUSj/DelDzKOJs+5VaRiFcNqo AVr5Gv4UMzGlq7CjMo4v =UoFu -----END PGP SIGNATURE-----

1 0

Re: [PATCH 11/12] ddraw: cache active DCs
by Jonas Maebe 23 Sep '15

23 Sep '15

Riccardo Bortolato wrote on Wed, 23 Sep 2015: Disclaimer: I'm everything but an expert on Wine internals, so I'm just asking in case I'm not missing something obvious. > - surface_impl = wined3d_surface_get_parent(wined3d_surface); > - *Surface = &surface_impl->IDirectDrawSurface7_iface; > - IDirectDrawSurface7_AddRef(*Surface); > - TRACE("Returning surface %p.\n", Surface); > - return DD_OK; > + wined3d_mutex_lock(); > + LIST_FOR_EACH_ENTRY(surface_impl, &ddraw->active_dcs, struct > ddraw_surface, active_dcs_entry) Here you get a mutex lock before iterating over the active_dcs. > + if (surface_dc == hdc) > + { > + wined3d_mutex_unlock(); > + *Surface = &surface_impl->IDirectDrawSurface7_iface; > + IDirectDrawSurface7_AddRef(*Surface); > + TRACE("Returning surface %p.\n", Surface); > + return DD_OK; > + } Here you free the lock before increasing the reference count. At first sight, it would seem that you either don't need the lock while iterating, or that you should increase the reference count before releasing the lock in order to avoid races (unless the lock is for a completely unrelated reason) > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -2176,7 +2176,9 @@ static HRESULT WINAPI > ddraw_surface7_GetDC(IDirectDrawSurface7 *iface, HDC *hdc) > if(hdc) *hdc = NULL; > return DDERR_INVALIDPARAMS; > > - default: return hr; > + default: > + list_add_head(&surface->ddraw->active_dcs, > &surface->active_dcs_entry); Here you add something to the actives_dcs list without locking, so this can race with the iterating (unless this is implicitly synchronised in another way I'm not aware of). > @@ -2246,6 +2248,8 @@ static HRESULT WINAPI > ddraw_surface7_ReleaseDC(IDirectDrawSurface7 *iface, HDC h > hr = ddraw_surface_update_frontbuffer(surface, NULL, FALSE); > wined3d_mutex_unlock(); > > + list_remove(&surface->active_dcs_entry); > + > return hr; > } Similarly, here you remove an item after releasing the lock, so it can race with both adding and iterating (same caveat). Jonas

2 1

Re: [PATCH 02/12] wined3d: store wined3d_texture and sub_resource_idx in d3dX surfaces
by Stefan Dösinger 23 Sep '15

23 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-09-23 um 10:27 schrieb Riccardo Bortolato: > wined3d_mutex_lock(); > + sub_resource = wined3d_texture_get_sub_resource(bitmap_impl->wined3d_texture, bitmap_impl->sub_resource_idx); > + wined3d_surface = wined3d_surface_from_resource(sub_resource); > hr = wined3d_device_set_cursor_properties(device->wined3d_device, > - hotspot_x, hotspot_y, bitmap_impl->wined3d_surface); > + hotspot_x, hotspot_y, wined3d_surface); > wined3d_mutex_unlock(); You may want to consider changing wined3d_device_set_cursor_properties to accept a wined3d_texture instead. Keep in mind though that this would be a bit of a side quest, as you'll have to find out if native accepts surfaces that are part of textures or just stand-alone surfaces created by CreateImageSurface. If it is the latter (which I suspect it is) then wined3d_texture alone is OK. Otherwise you need texture + idx. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAmlwAAoJEN0/YqbEcdMwGlkP/RfRVsceuPRGgVE0yJvhV26U ci6CDlrj4Lb2mFcH3IVlJKuJEOcT2TLrcx2hT3H2+0OjDBvAIJyLhzjxABaZsg0N OU4TJCvLfPiieF0npy7EBpUoe+E8a4046DRnLJsooco1Cp+Fk2LZO4B1OjMoaexl FaO9zoAO+3KlTNVwRKX65KnOsZB7PtP0soCS9Gsmvx1gwwVe42uQ8B5pSgQQzcgW UablqGdE0NnUGN2Bcj6vxPdW14FEaWC7Mp8fBl8olLO/FdlEoehzUMO7bPJNgGr2 wePB12qwmTfizcQ+Nmd5/HAGZMsn4vgfxu+kQSb0iaWxdgRtqKztlkLzAOFvGDTS x+yZ2pWTcNp41MzZI9yxRStI5eLq5ZBQ9vY64A85W3Zwj/wTb7eR6A/qWveOUYsG 6EtQ9F0pQ43hotiE9a/8AdvTlrwQ+lcK6W01Ngg2mh9xnZ8pcD1Zqugy7RYDoHiQ u+yd0BxvV3SjmjA0h4qZRVUh/ct5UMPCp6gJdHJFtSsKfoRAq96BzI3g3AFGH+Xv u0Tkjq7QbhtLPxdjdc8A61SbwRFqygrj3XsZi0ji6qar5tjW58u0PdRskb4NTUhu lEYUETpysaj29ktGURJ3s5/G1TKauDM9G4jx9puM8Kh0LilKshRwIsJaZf+4uHeW BBmwwFk8QMQpKffLOCie =W7On -----END PGP SIGNATURE-----

2 1

Re: kernel32: Create registry keys for available COM ports
by Austin English 22 Sep '15

22 Sep '15

On Tue, Sep 22, 2015 at 3:14 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > dlls/kernel32/kernel_private.h | 3 +++ > dlls/kernel32/oldconfig.c | 42 +++++++++++++++++++++++++++++++++++++++--- > dlls/kernel32/volume.c | 2 +- > 3 files changed, 43 insertions(+), 4 deletions(-) > > diff --git a/dlls/kernel32/kernel_private.h b/dlls/kernel32/kernel_private.h > index 76611d7..9f2db22 100644 > --- a/dlls/kernel32/kernel_private.h > +++ b/dlls/kernel32/kernel_private.h > @@ -107,6 +107,9 @@ extern void LOCALE_InitRegistry(void) DECLSPEC_HIDDEN; > /* oldconfig.c */ > extern void convert_old_config(void) DECLSPEC_HIDDEN; > > +/* volume.c */ > +extern char *get_dos_device_path(LPCWSTR) DECLSPEC_HIDDEN; > + > /* returns directory handle for named objects */ > extern HANDLE get_BaseNamedObjects_handle(void) DECLSPEC_HIDDEN; > > diff --git a/dlls/kernel32/oldconfig.c b/dlls/kernel32/oldconfig.c > index 2c8bc18..b7f6b97 100644 > --- a/dlls/kernel32/oldconfig.c > +++ b/dlls/kernel32/oldconfig.c > @@ -264,8 +264,8 @@ static int SCSI_getprocentry( FILE * procfile, struct LinuxProcScsiDevice * dev > } > > > -/* create the hardware registry branch */ > -static void create_hardware_branch(void) > +/* create the scsi registry branch */ > +static void create_scsi_branch(void) > { > /* The following mostly will work on Linux, but should not cause > * problems on other systems. */ > @@ -389,6 +389,41 @@ static void create_hardware_branch(void) > } > > > +/* create SERIALCOMM branch */ > +void create_serialcomm_branch(void) > +{ > + static WCHAR comW[] = {'C','O','M','1',0}; > + UNICODE_STRING nameU; > + DWORD disp; > + HANDLE key; > + int i; > + > + /* Ensure there is a SERIALCOMM key */ > + if (create_key( 0, "Machine\\HARDWARE\\DEVICEMAP\\SERIALCOMM", &key, &disp )) return; > + > + for (i = 1; i <= 9; i++) > + { > + char *link; > + int ret; > + > + comW[3] = 0x30 + i; > + link = get_dos_device_path( comW ); > + ret = access( link, R_OK | W_OK ); > + > + RtlCreateUnicodeString( &nameU, comW ); > + if (ret) > + NtDeleteValueKey( key, &nameU ); > + else > + NtSetValueKey( key, &nameU, 0, REG_SZ, (BYTE*)comW, sizeof(comW) ); > + RtlFreeUnicodeString( &nameU ); > + > + HeapFree(GetProcessHeap(), 0, link); > + } > + > + NtClose(key); > +} > + > + > /*********************************************************************** > * convert_old_config > */ > @@ -400,5 +435,6 @@ void convert_old_config(void) > /* create some hardware keys (FIXME: should not be done here) */ > if (create_key( 0, "Machine\\HARDWARE", &key, &disp )) return; > NtClose( key ); > - if (disp != REG_OPENED_EXISTING_KEY) create_hardware_branch(); > + if (disp != REG_OPENED_EXISTING_KEY) create_scsi_branch(); > + create_serialcomm_branch(); > } > diff --git a/dlls/kernel32/volume.c b/dlls/kernel32/volume.c > index 7a1dc11..43fbb7e 100644 > --- a/dlls/kernel32/volume.c > +++ b/dlls/kernel32/volume.c > @@ -99,7 +99,7 @@ static char *read_symlink( const char *path ) > } > > /* get the path of a dos device symlink in the $WINEPREFIX/dosdevices directory */ > -static char *get_dos_device_path( LPCWSTR name ) > +char *get_dos_device_path( LPCWSTR name ) > { > const char *config_dir = wine_get_config_dir(); > char *buffer, *dev; > -- > 1.9.1 Hi Andre, You forgot to sign off on this patch ;) -- -Austin

1 0

Re: msi: Set the PrimaryVolumeSpaceRequired and PrimaryVolumeSpaceRemaining properties.
by Marvin 22 Sep '15

22 Sep '15

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=16820 Your paranoid android. === w7u (32 bit install) === The test timed out === wvistau64 (64 bit install) === Failure running script in VM: timed out waiting for the child process

1 0

Re: [2/2] wininet/tests: Fix a couple of test failures.
by Marvin 22 Sep '15

22 Sep '15

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=16819 Your paranoid android. === w2000pro (32 bit http) === http.c:2400: Test failed: InternetReadFile failed 12030 http.c:2401: Test failed: count was wrong === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2401: Test failed: count was wrong http.c:2402: Test failed: http data wrong, got: Garbage: Header http.c:3046: Test failed: HttpAddRequestHeaders succeeded http.c:3047: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w1064 (64 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2401: Test failed: count was wrong http.c:2402: Test failed: http data wrong, got: Garbage: Header http.c:3046: Test failed: HttpAddRequestHeaders succeeded http.c:3047: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: code = 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:3052: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

1 0

Re: [1/2] wininet/tests: Never use a proxy for connections to localhost.
by Marvin 22 Sep '15

22 Sep '15

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=16818 Your paranoid android. === w7u (32 bit http) === http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 http.c:2399: Test failed: count was wrong http.c:2400: Test failed: http data wrong, got: Garbage: Header http.c:3044: Test failed: HttpAddRequestHeaders succeeded http.c:3045: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w7pro64 (64 bit http) === http.c:5813: Test failed: HttpAddRequestHeadersA failed 12019 http.c:5819: Test failed: HttpQueryInfoA failed 12019 http.c:5820: Test failed: header missing === w1064 (64 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2891: Test failed: HttpSendRequest failed: 12031 http.c:2896: Test failed: HttpQueryInfo failed http.c:2897: Test failed: got status 0, expected 200 http.c:2399: Test failed: count was wrong http.c:2400: Test failed: http data wrong, got: Garbage: Header http.c:3044: Test failed: HttpAddRequestHeaders succeeded http.c:3045: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: code = 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:3050: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

1 0

Re: How to add the Signed-off-by field in the git patch
by Hin-Tak Leung 22 Sep '15

22 Sep '15

You don't need to edit git's config by hand - 'git config --global ... ' can do that for you. read the documentation for git-config, and particularly the --global option. I also have colorised diff and a few other useful thing configured. ------------------------------ On Tue, Sep 22, 2015 3:21 PM BST Aaryaman Vasishta wrote: >Hi Dimitry, > >Thanks! this will definitely help if this info is added to the wiki too. >Though it seems to be down right now. There's a discussion going on about >it on IRC right now. > >Cheers, >Aaryaman > >On Tue, Sep 22, 2015 at 4:10 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > >> Hi all, >> >> since I personally asked that question and investigated a bit the subject, >> here is some information that could be probably useful to someone else: >> >> >> http://stackoverflow.com/questions/13457203/how-to-add-the-signed-off-by-fi… >> >> http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… >> >> http://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-usin… >> http://git-scm.com/docs/git-format-patch (CONFIGURATION section) >> >> Personally I've chosen to add >> [format] >> signOff = true >> to git.config file. >> >> -- >> Dmitry. >> >> >>

1 0

Re: [PATCH] dinput: WriteEffectToFIle dieffects parameter is const
by Nikolay Sivov 22 Sep '15

22 Sep '15

On 22.09.2015 0:06, Marcus Meissner wrote: > Signed-Off-By: Marcus Meissner <marcus(a)jet.franken.de> > --- > dlls/dinput/device.c | 4 ++-- > dlls/dinput/device_private.h | 4 ++-- > include/dinput.h | 8 ++++---- > 3 files changed, 8 insertions(+), 8 deletions(-) > PSDK header doesn't use const for that argument, I checked with Win10 SDK. Does it really make sense to diverge from it in this case?

4 3

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible
by Marvin 21 Sep '15

21 Sep '15

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=16808 Your paranoid android. === w2003std (32 bit string) === Unable to set the VM system time: the "nc -q0 '10.42.42.140' '4242'" command returned 1 === w7u (32 bit string) === Failure running script in VM: timed out waiting for the child process

2 1

Re: [PATCH 2/2] ucrtbase: Make the strtod implementation C99 compatible
by Piotr Caban 21 Sep '15

21 Sep '15

On 08/30/15 22:47, Martin Storsjo wrote: > @@ -339,6 +341,38 @@ static double strtod_helper(const char *str, char **end, MSVCRT__locale_t locale > } else if(*p == '+') > p++; > > +#if _MSVCR_VER >= 140 > + if(p[0] == '0' && tolower(p[1]) == 'x') { > + char *e; > + MSVCRT_long val = sign*MSVCRT_strtol(p, &e, 16); This will not work for doubles > LONG_MAX. It will also not work if specified hexadecimal value has dot, e.g.: strtod("0x1.1p+1") = 2.125 Thanks, Piotr

2 1

Re: [1/2] [website] Add up-to-date download page for Debian
by Jens Reyer 20 Sep '15

20 Sep '15

Hi On 09/20/2015 05:00 AM, Kyle Auble wrote: > I know the old page was removed just a few months ago, but I wrote a new > one (modeled on the Ubuntu page). It explains the differences between > "wine" vs. "wine-development" and has instructions for those that want > the Backports version. Also, per the suggestion at the end of the Debian > bug report, the links to Debian package info are for both packages, and > each lists all available versions. Great! Just a few things: > > --- > templates/en/download/debian.template | 133 ++++++++++++++++++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 templates/en/download/debian.template > > diff --git a/templates/en/download/debian.template b/templates/en/download/debian.template > new file mode 100644 > index 0000000..eff7d88 > --- /dev/null > +++ b/templates/en/download/debian.template > @@ -0,0 +1,133 @@ > + > + > + > +<h1 class="title"><a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a> > +Wine on Debian > +<a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a></h1> > + > +You can directly install software for Debian from .deb package > +files, but using the APT package manager (or a front-end such as > +Aptitude or Synaptic) to get software from the official Debian repos is > +much safer and cleaner. This page explains how to install your preferred > +version of Wine this way. > + > +<h2>Apt-Get Basics (for 32-Bit Debian)</h2> Drop "Apt-Get" from the heading. The explanations at the end of this section are not apt-get related. > + > +So long as your package system is configured correctly and > +up-to-date, grabbing Wine should be simple, whether you use Debian > +stable, testing, or unstable. On 32-bit > +Debian, you can install a stable release of Wine with a single > +apt-get command: > + > +<pre>sudo apt-get install wine</pre> > + > +Starting with Debian Jessie (release 8.0), there is also a package of > +Wine's development release that can be installed alongside the stable > +release: > + > +<pre>sudo apt-get install wine-development</pre> > + > +Note that you currently need to use the command > +'wine-development' instead of 'wine' to run the > +development version from the command-line. > + > +Also, while the "wine-development" package on Debian unstable > +should closely track upstream, the version on Debian stable will > +only upgrade with each new release of Debian. Similarly, the version on > +Debian testing will track upstream except while Debian is in its > +biennial code-freeze. When Debian is in freeze, the packages aren't updated in unstable either. Instead last time they were updated in the "experimental" suite. Furthermore you might mention Backports already here. Finally I'd suggest "major release" to make it more distinct from point releases. I'd suggest something like: ~~~ The "wine-development" package on Debian should closely track upstream. The version on Debian stable will only upgrade with each new major release of Debian, but current packages should be available from Debian Backports (see below). While Debian is in its biennial code-freeze the packages aren't updated in testing and unstable. Instead you should find current versions in experimental. ~~~ Note: I hope to update Backports from experimental during the freeze. But it's too early to know, yet. I don't think we need to mention this aspect in any way here, yet. > + > +<h2>On 64-Bit Debian</h2> > + > +Even if your system uses 64-bit Debian, you probably still > +want a Wine installation that can run 32-bit Windows applications. To > +install 32-bit application support, just make sure your system is > +configured to pull in 32-bit packages and the index is updated > +first: > + > +<pre> > +sudo dpkg --add-architecture i386 > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +Starting with Debian Stretch, you can also install Wine on 64-bit > +ARM systems: > + > +<pre> > +sudo dpkg --add-architecture armhf > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +<h2>Debian Backports</h2> > + > +If you are on Debian stable and want a newer version of > +"wine-development", starting with Debian Jessie, you can grab a version > +in sync with upstream from Debian backports. To install it, you *Backports (capital B) > +need to > +<a href="http://backports.debian.org/Instructions/" target="_new"> > +enable the Backports repo > +</a> > +first by adding the following line to one of your sources.list > +files (replace xx with an appropriate country code): > + > +<pre> > +deb ftp://ftp.xx.debian.org/debian/ jessie-backports main contrib > +</pre> Nowadays you can use httpredir.debian.org (formerly http.debian.net), a redirector to the best nearby Debian mirror: ~~~ [...] by adding the following line to one of your sources.list files: <pre> deb http://httpredir.debian.org/debian/ jessie-backports main </pre> ~ > + > +You can do this either through Synaptic > +(Settings -> Repositories -> Other Software -> Add) > +or by editing the sources.list file directly > +('sudo nano /etc/apt/sources.list'). Nitpick: s/nano/editor/ In Debian you have /usr/bin/editor pointing to your favourite text editor (per default nano) > +Once you've added your sources, update your package index > +(Reload in Synaptic or 'sudo apt-get update' on the > + command-line). > + > +If you don't mind possibly upgrading other dependencies to > +backports versions too, you can install everything in one *Backports (capital B) > +swoop: > + > +<pre>sudo apt-get install -t jessie-backports wine-development</pre> > + > +If you want to be more selective about keeping stable > +dependencies though, you can use the form: > + > +<pre>sudo apt-get install wine-development/jessie-backports</pre> > + > +However, if any other packages need to be installed or updated, this > +method will abort with a list of such packages. You can selectively > +install those from either stable or backports, then repeat > +the command to install "wine-development/jessie-backports". > + > +<h2>More Information</h2> > + > +For more info, you can see the Debian package site: > + > +<ul><li> > +<a href="https://packages.debian.org/search?keywords=wine" > + target="_new"> > +wine > +</a> (stable release)</li> > + > +<li> > +<a href="https://packages.debian.org/search?keywords=wine-development" > + target="_new"> > +wine-development > +</a> (development release)</li></ul> Nitpick: I'd drop the "search?keywords=". https://packages.debian.org/wine-development is easier to read/memorize and redirects to the form that you used. Minor display issue: the underlining of the links "wine" and "wine-development" is too long. It spans over the space up to the bracket here. Maybe pull the "</a>" to the same line. This looks ugly in the source, but fixes the display here. > + > +There are also useful wiki pages out there too: > + > +<ul><li> > +<a href="http://wiki.winehq.org/Debian" target="_new"> > +Debian on the Wine Wiki > +</a></li> > + > +<li> > +<a href="https://wiki.debian.org/Wine" target="_new"> > +Wine on the Debian Wiki > +</a></li></ul> > Greets jre

1 0

Re: [1/2] [website] Add up-to-date download page for Debian
by Jens Reyer 20 Sep '15

20 Sep '15

Hi On 09/20/2015 05:00 AM, Kyle Auble wrote: > I know the old page was removed just a few months ago, but I wrote a new > one (modeled on the Ubuntu page). It explains the differences between > "wine" vs. "wine-development" and has instructions for those that want > the Backports version. Also, per the suggestion at the end of the Debian > bug report, the links to Debian package info are for both packages, and > each lists all available versions. Great! Just a few things: > > --- > templates/en/download/debian.template | 133 ++++++++++++++++++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 templates/en/download/debian.template > > diff --git a/templates/en/download/debian.template b/templates/en/download/debian.template > new file mode 100644 > index 0000000..eff7d88 > --- /dev/null > +++ b/templates/en/download/debian.template > @@ -0,0 +1,133 @@ > + > + > + > +<h1 class="title"><a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a> > +Wine on Debian > +<a href="https://www.debian.org/" target="_new"> > +<img src="{$root}/images/distro/debian.png" width="50" height="50" > + alt="Debian Logo" border="0"></a></h1> > + > +You can directly install software for Debian from .deb package > +files, but using the APT package manager (or a front-end such as > +Aptitude or Synaptic) to get software from the official Debian repos is > +much safer and cleaner. This page explains how to install your preferred > +version of Wine this way. > + > +<h2>Apt-Get Basics (for 32-Bit Debian)</h2> Drop "Apt-Get" from the heading. The explanations at the end of this section are not apt-get related. > + > +So long as your package system is configured correctly and > +up-to-date, grabbing Wine should be simple, whether you use Debian > +stable, testing, or unstable. On 32-bit > +Debian, you can install a stable release of Wine with a single > +apt-get command: > + > +<pre>sudo apt-get install wine</pre> > + > +Starting with Debian Jessie (release 8.0), there is also a package of > +Wine's development release that can be installed alongside the stable > +release: > + > +<pre>sudo apt-get install wine-development</pre> > + > +Note that you currently need to use the command > +'wine-development' instead of 'wine' to run the > +development version from the command-line. > + > +Also, while the "wine-development" package on Debian unstable > +should closely track upstream, the version on Debian stable will > +only upgrade with each new release of Debian. Similarly, the version on > +Debian testing will track upstream except while Debian is in its > +biennial code-freeze. When Debian is in freeze, the packages aren't updated in unstable either. Instead last time they were updated in the "experimental" suite. Furthermore you might mention Backports already here. Finally I'd suggest "major release" to make it more distinct from point releases. I'd suggest something like: ~~~ The "wine-development" package on Debian should closely track upstream. The version on Debian stable will only upgrade with each new major release of Debian, but current packages should be available from Debian Backports (see below). While Debian is in its biennial code-freeze the packages aren't updated in testing and unstable. Instead you should find current versions in experimental. ~~~ Note: I hope to update Backports from experimental during the freeze. But it's too early to know, yet. I don't think we need to mention this aspect in any way here, yet. > + > +<h2>On 64-Bit Debian</h2> > + > +Even if your system uses 64-bit Debian, you probably still > +want a Wine installation that can run 32-bit Windows applications. To > +install 32-bit application support, just make sure your system is > +configured to pull in 32-bit packages and the index is updated > +first: > + > +<pre> > +sudo dpkg --add-architecture i386 > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +Starting with Debian Stretch, you can also install Wine on 64-bit > +ARM systems: > + > +<pre> > +sudo dpkg --add-architecture armhf > +sudo apt-get update > +sudo apt-get install wine-development > +</pre> > + > +<h2>Debian Backports</h2> > + > +If you are on Debian stable and want a newer version of > +"wine-development", starting with Debian Jessie, you can grab a version > +in sync with upstream from Debian backports. To install it, you *Backports (capital B) > +need to > +<a href="http://backports.debian.org/Instructions/" target="_new"> > +enable the Backports repo > +</a> > +first by adding the following line to one of your sources.list > +files (replace xx with an appropriate country code): > + > +<pre> > +deb ftp://ftp.xx.debian.org/debian/ jessie-backports main contrib > +</pre> Nowadays you can use httpredir.debian.org (formerly http.debian.net), a redirector to the best nearby Debian mirror: ~~~ [...] by adding the following line to one of your sources.list files: <pre> deb http://httpredir.debian.org/debian/ jessie-backports main </pre> ~ > + > +You can do this either through Synaptic > +(Settings -> Repositories -> Other Software -> Add) > +or by editing the sources.list file directly > +('sudo nano /etc/apt/sources.list'). Nitpick: s/nano/editor/ In Debian you have /usr/bin/editor pointing to your favourite text editor (per default nano) > +Once you've added your sources, update your package index > +(Reload in Synaptic or 'sudo apt-get update' on the > + command-line). > + > +If you don't mind possibly upgrading other dependencies to > +backports versions too, you can install everything in one *Backports (capital B) > +swoop: > + > +<pre>sudo apt-get install -t jessie-backports wine-development</pre> > + > +If you want to be more selective about keeping stable > +dependencies though, you can use the form: > + > +<pre>sudo apt-get install wine-development/jessie-backports</pre> > + > +However, if any other packages need to be installed or updated, this > +method will abort with a list of such packages. You can selectively > +install those from either stable or backports, then repeat > +the command to install "wine-development/jessie-backports". > + > +<h2>More Information</h2> > + > +For more info, you can see the Debian package site: > + > +<ul><li> > +<a href="https://packages.debian.org/search?keywords=wine" > + target="_new"> > +wine > +</a> (stable release)</li> > + > +<li> > +<a href="https://packages.debian.org/search?keywords=wine-development" > + target="_new"> > +wine-development > +</a> (development release)</li></ul> Nitpick: I'd drop the "search?keywords=". https://packages.debian.org/wine-development is easier to read/memorize and redirects to the form that you used. Minor display issue: the underlining of the links "wine" and "wine-development" is too long. It spans over the space up to the bracket here. Maybe pull the "</a>" to the same line. This looks ugly in the source, but fixes the display here. > + > +There are also useful wiki pages out there too: > + > +<ul><li> > +<a href="http://wiki.winehq.org/Debian" target="_new"> > +Debian on the Wine Wiki > +</a></li> > + > +<li> > +<a href="https://wiki.debian.org/Wine" target="_new"> > +Wine on the Debian Wiki > +</a></li></ul> > Greets jre

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel