- wine-devel - winehq.org

Re: Strange wined3d crash
by Francois Gouget 29 Apr '15

29 Apr '15

On Wed, 29 Apr 2015, Henri Verbeet wrote: > On 29 April 2015 at 12:40, Francois Gouget <fgouget(a)free.fr> wrote: > > I am getting a strange wined3d crash during the d3d8:device test. > > > Is that a regression? We did touch the shader generation code recently. It is actually. This is the patch that introduced the crash: commit 28343db2083de7b4afe4079da090520f44b5544d Author: Matteo Bruni <mbruni(a)codeweavers.com> Date: Mon Apr 27 17:39:12 2015 +0200 wined3d: Don't use the builtin FFP uniforms for the lights. While at it, use D3D-like uniforms for the light parameters and (consequently) implement range and proper D3D spotlights support. I can test patches but I'm not sure I'll have time to debug this much further for a while :-( Note that this is with an Intel HD Graphics 4600 GPU. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ $live{free} || die "";

3 2

Re: ws2_32: Include inttypes.h for UINT32_MAX.
by Henri Verbeet 29 Apr '15

29 Apr '15

On 29 April 2015 at 11:34, Francois Gouget <fgouget(a)free.fr> wrote: > This fixes compilation on FreeBSD. > --- > > The only other files that use UINT32_MAX are: > * The .yy.c files. These are generated and always do an ifndef+define. > * dlls/mshtml/nsembed.c though it calls it PR_UINT32_MAX for some reason. > * dlls/jscript/string.c which simply defines it. > * dlls/winemac.drv/macdrv_cocoa.h which presumably gets it from the Mac > OS X headers. > > Maybe mshtml and jscript should use inttypes.h, or to the contrary, > maybe ws2_32 should use the ifndef+define approach. > Arguably it shouldn't be using UINT32_MAX at all, since it isn't actually used with uint32_t. I guess it should be using e.g. unsigned int with UINT_MAX instead.

4 6

USB Support
by Steve Kenton 29 Apr '15

29 Apr '15

USB Support has been on the list of possible release criteria basically forever. I've read through all the old threads and other discussions I could find and it boils down to "really hard to do right". If possible could someone knowledgeable comment briefly on what might be an acceptable architecture for a Wine USB stack? In particular I'm wondering about how much support for client/function drivers would be desirable. Should we stick to only unprivileged operations or would an optional kernel mode driver to support WDM or WDF (KMDF/UMDF) privileged interfaces be acceptable? Steve Kenton

5 11

Strange wined3d crash
by Francois Gouget 29 Apr '15

29 Apr '15

I am getting a strange wined3d crash during the d3d8:device test. It's annoying because it only happens with the 64 bit build, and disappears if I add traces (+d3d or +d3d_shader), and even if I add a FIXME() just before the crash. The crash happens in shader_glsl_ffp_vertex_lighting(): shader_addline(buffer, "gl_FrontSecondaryColor = %s * specular;\n", specular); According to the checks I've been able to do the specular pointer is still correct when this gets called. Here's the backtrace: http://pastebin.com/DKvXTVJn Any idea what's up? It almost feels like a compiler bug (gcc 4.9.2 (Debian 4.9.2-10) here). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

1 0

Re: [PATCH] wined3d: fix different level count while texture update
by Henri Verbeet 29 Apr '15

29 Apr '15

On 28 April 2015 at 20:18, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > Bug 38048 > According to MSDN > https://msdn.microsoft.com/en-us/library/windows/desktop/bb205858(v=vs.85) > source texture CAN have greater level count then destination > Current comparison "!=“ causes black textures as discussed in the bugzilla. > This may be correct, it may not be. This change needs tests, and I believe that was pointed out in the bug report already.

1 0

Re: [PATCH] wined3d: fix Unrecognized usage flags
by Henri Verbeet 29 Apr '15

29 Apr '15

Please use git send-email for sending patches. On 28 April 2015 at 09:18, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_TEXTURE); This is fine, but WINED3DUSAGE_OWNDC is missing here as well. Is "buf" still larger enough after you add these flags? > - if (usage) FIXME("Unrecognized usage flag(s) %#x\n", usage); > + if (usage & ~WINED3DUSAGE_QUERY_MASK) FIXME("Unrecognized usage flag(s) %#x\n", usage); I think it makes more sense to do this in the caller. It may make even more sense to just merge debug_d3dusage() and debug_d3dusagequery().

1 0

Re: [PATCH] comdlg32: Change "Borders" to "Margins".
by Alex Henrie 29 Apr '15

29 Apr '15

2015-04-28 8:03 GMT-06:00 Alexandre Julliard <julliard(a)winehq.org>: > Alex Henrie <alexhenrie24(a)gmail.com> writes: > >> Alexandre, >> >> What was wrong with this patch that you did not accept it? > > I'm concerned that you have been looking at Windows a bit too much. At first, I thought that Wine actually used this string. On closer look, it seems that Wine always replaces the dialog's string "Borders" with the string resource "Margins [inches]" or "Margins [mm]": https://source.winehq.org/git/wine.git/blob/abd673bde93b76a361ddf7342c538c2… https://source.winehq.org/git/wine.git/blob/abd673bde93b76a361ddf7342c538c2… The following test (run with `./wine dlls/comdlg32/tests/comdlg32_test.exe.so printdlg`) also supports the hypothesis that Wine always overrides the dialog's string: diff --git a/dlls/comdlg32/comdlg32.rc b/dlls/comdlg32/comdlg32.rc index d3deeab..9d37d69 100644 --- a/dlls/comdlg32/comdlg32.rc +++ b/dlls/comdlg32/comdlg32.rc @@ -438,7 +438,7 @@ BEGIN GROUPBOX "Orientation", grp1, 8, 156, 64, 56, BS_GROUPBOX AUTORADIOBUTTON "&Portrait", rad1, 16, 170, 52, 12, BS_AUTORADIOBUTTON AUTORADIOBUTTON "&Landscape", rad2, 16, 190, 52, 12, BS_AUTORADIOBUTTON - GROUPBOX "Borders", grp4, 80, 156, 152, 56, BS_GROUPBOX + GROUPBOX "foobar", grp4, 80, 156, 152, 56, BS_GROUPBOX LTEXT "L&eft:", stc15, 88, 172, 30, 8 EDITTEXT edt4, 119, 170, 36, 12, WS_TABSTOP|WS_GROUP|WS_BORDER LTEXT "&Right:", stc16, 159, 172, 30, 8 diff --git a/dlls/comdlg32/tests/printdlg.c b/dlls/comdlg32/tests/printdlg.c index 7e06c97..d6c7dff 100644 --- a/dlls/comdlg32/tests/printdlg.c +++ b/dlls/comdlg32/tests/printdlg.c @@ -88,7 +88,7 @@ static void test_PageSetupDlgA(void) ZeroMemory(pDlg, sizeof(PAGESETUPDLGA)); pDlg->lStructSize = sizeof(PAGESETUPDLGA); - pDlg->Flags = PSD_RETURNDEFAULT | PSD_NOWARNING; + pDlg->Flags = PSD_NOWARNING; SetLastError(0xdeadbeef); res = PageSetupDlgA(pDlg); ok( res || (CommDlgExtendedError() == PDERR_NODEFAULTPRN), If I am correct, it would be better to replace "Borders" with "" so that translators have one less string to worry about. Is that acceptable to you? -Alex

2 1

Re: [PATCH] comdlg32: Change "Borders" to "Margins".
by Alexandre Julliard 28 Apr '15

28 Apr '15

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Alexandre, > > What was wrong with this patch that you did not accept it? I'm concerned that you have been looking at Windows a bit too much. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: include: Added IShellFolderViewDual definition
by Marvin 28 Apr '15

28 Apr '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=13085 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: [PATCH 5/5] d3d9/tests: Add spotlight and light range tests.
by Henri Verbeet 28 Apr '15

28 Apr '15

On 27 April 2015 at 17:39, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + static const float pi = 3.141592654f; I guess you'll have to resubmit this for the testbot, but while you're at it, I think I prefer M_PI.

1 0

Re: [PATCH 3/6] dmloader: Add and use a generic IPersistStream_GetClassID.
by Marvin 27 Apr '15

27 Apr '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=13066 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 2/6] dmloader/tests: Add more DirectMusicCollection tests.
by Marvin 27 Apr '15

27 Apr '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=13065 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH 1/6] dmloader: Use the generic DirectMusicObject implementation for DMContainer.
by Marvin 27 Apr '15

27 Apr '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=13064 Your paranoid android. === build (build) === Make failed

1 0

Re: jscript: Date.parse: long date with '/' or '-'
by Stefan Dösinger 27 Apr '15

27 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-25 um 17:45 schrieb Thomas Faller: > This format is not documented under > > https://msdn.microsoft.com/en-us/library/k4w173wk%28v=vs.84%29.aspx > > but its implemented in the internet explorer and in the windows > script host. In this case a test would be very useful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVO8QzAAoJEN0/YqbEcdMwl4EP/1+xPW5sSLx86MPGq8e1eXCx 7ON4cSV1u0IIAnw1qMc/VuUxxHw3LN6VSrBN8Rbq6XxXx/1fLvaIz7+ckdBvOz3c QhregFjv7kBsRs3WCDuz8SujMMCeBL0FdeAg7xuWl61mHRKxkaeBNROHlfPxG7GE fYBdOTUPzdEj8eYTB48xozHPMV3EadpO7GL+742upv4qxJa3m7V2ZU3/+4O1atjE +yZyVKEwxKU6PLJNMMzva/TpQPxIEPsKg2L3hFAXnZXjn6lJeew6PWGQiR/OpNR0 HLQcdGk3xQlslefauJpJ6ffSyHl+wRrK7DUpUDsNAQuWQ4ALwHsjkFGG8ph8xRL4 aMnnA+afBU2VXnVpkmnjHlILIaWtCejMo4zveXjD1dk15CeOcs2ezasxhbbl9FUl HySkMNyX6gX07BfR6e9N5gwCzHdOj0GbvRtPMcRXWkPwgzj47xX4NbT0QT8ncg2a lsey/aE8aEscUwGROWm9xv7egKxdBM5kxccBxAMFY1Z5MBNbntlMVTwKERWAl1q9 sRjf77vuuD8LIyXpntqVOb96Hq+4mIo0VzAClFOqSIf6bv8fPz8oFD1elE6G3M4W cXH620URbzXsXg4ZBVRUP6t5sIy5jnSZG+I5h0BUxSizw5ekxbKWlfCicFSZStbu Ln6ptTTJVzUg3QpSR6jN =a7ty -----END PGP SIGNATURE-----

2 2

Re: [PATCH 2/2] winemac: Don't pump messages in ChangeDisplaySettings (v3).
by Ken Thomases 27 Apr '15

27 Apr '15

On Apr 27, 2015, at 2:54 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Version 3: Use SendNotifyMessage for sending WM_MACDRV_DISPLAYCHANGE. > Ken, I need your review again to make sure that this change doesn't > have any negative impact regarding the sync_window_position call that > is part of the WM_MACDRV_DISPLAYCHANGE message handling. Looks OK to me. It is not necessary for the sync_window_position() call to be made synchronously with respect to the sending code. -Ken

1 0

Re: [PATCH 5/5] d3d9/tests: Add spotlight and light range tests.
by Marvin 27 Apr '15

27 Apr '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=13061 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: shell32: Add Association Registry entries (resend)
by Marvin 27 Apr '15

27 Apr '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=13043 Your paranoid android. === w2000pro (32 bit assoc) === The test timed out

1 0

Re: [PATCH 1/2] winex11: Don't pump messages in ChangeDisplaySettings (v3).
by Marvin 27 Apr '15

27 Apr '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=13041 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2497: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2510: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

1 0

Re: [3/3] user32: Don't perform SetWindowPos synchronously.
by Marvin 27 Apr '15

27 Apr '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=13038 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0017014A msg.c:12252: Test failed: bad time 31267/31276

1 0

Re: [1/3] user32/tests: Add a test for calling SetWindowPos for other thread window.
by Marvin 27 Apr '15

27 Apr '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=13037 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 00150136 msg.c:12252: Test failed: bad time 31100/3111f

1 0

Re: [PATCH 4/5] wined3d: Don't use the builtin FFP uniforms for texture transformation matrices. (v3)
by Henri Verbeet 26 Apr '15

26 Apr '15

On 24 April 2015 at 22:25, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +static void shader_glsl_ffp_vertex_texmatrix_uniform(const struct wined3d_context *context, > + const struct wined3d_state *state, unsigned int tex, struct glsl_shader_prog_link *prog) > +{ > + const struct wined3d_gl_info *gl_info = context->gl_info; > + struct wined3d_matrix mat; > + > + if (tex >= MAX_TEXTURES) > + return; I think the patch is fine as it is, but as a style comment, arguably you aren't so much validating "tex" against MAX_TEXTURES here as against ARRAY_SIZE(texture_matrix_location).

1 0

Re: [PATCH] wined3d: fix wrong struct initialization
by Henri Verbeet 26 Apr '15

26 Apr '15

On 26 April 2015 at 12:22, Patrick Rudolph <siro(a)das-labor.org> wrote: > - static const struct wined3d_query_data_timestamp_disjoint > disjoint_data = {FALSE, 1000 * 1000 * 1000}; > + static const struct wined3d_query_data_timestamp_disjoint > disjoint_data = {1000 * 1000 * 1000, FALSE}; The change is fine like this, but unfortunately it looks like your MUA has wrapped the patch.

1 0

Re: advapi32/tests: Add tests for RegQueryInfoKey.
by Nikolay Sivov 26 Apr '15

26 Apr '15

On 04/25/2015 08:41 PM, Thomas Faber wrote: > + /* class name with buffer one char too small */ > + memset(classbuffer, 0x55, sizeof(classbuffer)); > + classlen = sizeof(subkey_class) - 1; > + ret = RegQueryInfoKeyA(subkey, classbuffer, &classlen, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); > + ok(ret == ERROR_MORE_DATA, "ret = %d\n", ret); > + todo_wine ok(classlen == sizeof(subkey_class) - 2, "classlen = %u\n", classlen); > + todo_wine ok(classbuffer[0] == 's', "classbuffer[0] = 0x%x\n", classbuffer[0]); > + todo_wine ok(classbuffer[1] == 'u', "classbuffer[1] = 0x%x\n", classbuffer[1]); > + todo_wine ok(classbuffer[10] == 's', "classbuffer[10] = 0x%x\n", classbuffer[10]); > + todo_wine ok(classbuffer[11] == 0, "classbuffer[11] = 0x%x\n", classbuffer[11]); > + ok(classbuffer[12] == 0x55, "classbuffer[12] = 0x%x\n", classbuffer[12]); I think it would be more readable if you tested it against a string. Also hardcoded offsets could be avoided in this case. > + memset(classbufferW, 0x55, sizeof(classbufferW)); > + classlen = sizeof(subkey_class) - 1; > + ret = RegQueryInfoKeyW(subkey, classbufferW, &classlen, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); > + todo_wine ok(ret == ERROR_INSUFFICIENT_BUFFER, "ret = %d\n", ret); > + ok(classlen == sizeof(subkey_class) - 2 /* win8 */ || > + classlen == strlen(subkey_class), "classlen = %u\n", classlen); > + ok(classbufferW[0] == 0x5555, "classbufferW[0] = 0x%x\n", classbufferW[0]); > + ok(classbufferW[1] == 0x5555, "classbufferW[1] = 0x%x\n", classbufferW[1]); > + ok(classbufferW[10] == 0x5555, "classbufferW[10] = 0x%x\n", classbufferW[10]); > + ok(classbufferW[11] == 0x5555, "classbufferW[11] = 0x%x\n", classbufferW[11]); > + ok(classbufferW[12] == 0x5555, "classbufferW[12] = 0x%x\n", classbufferW[12]); If first element is not changed, it's really unlikely that anything else did. > + ok(classbuffer[12] == 0, "classbuffer[12] = 0x%x\n", classbuffer[12]); > + ok(classbuffer[13] == 0x55, "classbuffer[13] = 0x%x\n", classbuffer[13]); ... > + ok(!lstrcmpW(classbufferW, subkey_classW), "classbufferW = %s\n", wine_dbgstr_w(classbufferW)); > + ok(classbufferW[12] == 0, "classbufferW[12] = 0x%x\n", classbufferW[12]); > + ok(classbufferW[13] == 0x5555, "classbufferW[13] = 0x%x\n", classbufferW[13]); Could you replace offsets with calculated string length instead so it still works for different strings.

2 1

Re: [PATCH] wined3d: fix wrong data order for D3DQUERYTYPE_TIMESTAMPDISJOINT
by Henri Verbeet 25 Apr '15

25 Apr '15

On 25 April 2015 at 14:26, Patrick Rudolph <siro(a)das-labor.org> wrote: > At the moment the querry D3DQUERYTYPE_TIMESTAMPDISJOINT returns TRUE instead > of FALSE due to wrong data order in struct > wined3d_query_data_timestamp_disjoint. > Please use "git send-email" for sending patches. (Or fix your MUA to inline them.) Unfortunately swapping the order of the fields will introduce a hole in the structure between "disjoint" and "frequency", and make it incompatible with the equivalent d3d10 structure (D3D10_QUERY_DATA_TIMESTAMP_DISJOINT). I think it would be much nicer to fix the initializer of "disjoint_data" in wined3d_timestamp_disjoint_query_ops_get_data() to match the structure layout instead.

1 0

Re: (resend)comctl32:TTM_SETTOOLINFO does not change subclassing
by Alexandre Julliard 24 Apr '15

24 Apr '15

Aric Stewart <aric(a)codeweavers.com> writes: > + toolInfo2.cbSize = TTTOOLINFOA_V1_SIZE; > + toolInfo2.hwnd = parent2; > + toolInfo2.uId = 0x1234ABCE; > + lResult = SendMessageA(hwndTip, TTM_GETTOOLINFOA, 0, (LPARAM)&toolInfo2); > + ok(lResult, "GetToolInfo failed\n"); > + ok(!(toolInfo2.uFlags & TTF_SUBCLASS), "uFlags has subclass\n"); > + wndProc = GetWindowLongPtrA(parent2, GWLP_WNDPROC); > + ok (wndProc == (DWORD)(&info_wnd_proc), "Window Proc is wrong\n"); > + > + toolInfo2.uFlags |= TTF_SUBCLASS; > + SendMessageA(hwndTip, TTM_SETTOOLINFOA, 0, (LPARAM)&toolInfo2); > + lResult = SendMessageA(hwndTip, TTM_GETTOOLINFOA, 0, (LPARAM)&toolInfo2); > + ok(lResult, "GetToolInfo failed\n"); > + ok(toolInfo2.uFlags & TTF_SUBCLASS, "uFlags does not have subclass\n"); > + ok (wndProc == (DWORD)(&info_wnd_proc), "Window Proc is wrong\n"); Please use the correct types for window function pointers. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 5/5] wined3d: Move volume DXTn handling to apply_format_fixups.
by Henri Verbeet 24 Apr '15

24 Apr '15

This fails the d3dx9_36 tests: ../../../tools/runtest -q -P wine -T ../../.. -M d3dx9_36.dll -p d3dx9_36_test.exe.so texture && touch texture.ok ... texture.c:1778: Test failed: D3DXCreateVolumeTextureFromFileInMemory returned 0x8876086c, expected 0

1 0

Re: [PATCH 6/6] wined3d: Introduce a scratch string buffers framework.
by Henri Verbeet 23 Apr '15

23 Apr '15

On 22 April 2015 at 19:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > It's somewhat of an RFC at this point. In particular I'd like some > feedback about the API. In general, I think it goes in the right direction. > An obvious variant would be to store the pointer to the parent > wined3d_shader_buffer structure right before the string and just > return the string itself (thus avoiding having to add ->buffer to > all the uses of the string). Personally, I don't particularly mind the couple of extra characters, and it seems like a good thing to explicitly distinguish between string buffers and regular strings. > + tex_reg_name = shader_sprintf_unsafe(&priv->string_buffers, "tex%u", stage); > shader_glsl_color_correction_ext(buffer, tex_reg_name, WINED3DSP_WRITEMASK_ALL, > settings->op[stage].color_fixup); The problem with this construction is that it is likely to break as soon as shader_glsl_color_correction_ext() does anything that ends up calling shader_get_buffer(). To make it worse, shader_glsl_color_correction_ext() isn't aware of this because it just gets a const char *, and shader_glsl_generate_ffp_fragment_shader() isn't supposed to care about the internals of shader_glsl_color_correction_ext(). > @@ -276,13 +276,17 @@ int shader_vaddline(struct wined3d_shader_buffer *buffer, const char *format, va > char *base = buffer->buffer + buffer->content_size; > int rc; > char *new_buffer; > + unsigned int new_buffer_size; > > while(1) > { > rc = vsnprintf(base, buffer->buffer_size - buffer->content_size, format, args); > if (rc < 0 /* C89 */ || (unsigned int)rc >= buffer->buffer_size - buffer->content_size /* C99 */) > { > - new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, buffer->buffer_size * 2); > + new_buffer_size = buffer->buffer_size * 2; > + while (rc > 0 && (unsigned int)rc >= new_buffer_size - buffer->content_size) > + new_buffer_size *= 2; > + new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, new_buffer_size); > if (!new_buffer) > { > ERR("The buffer allocated for the shader program string is too small at %d bytes.\n", buffer->buffer_size); > @@ -290,7 +294,7 @@ int shader_vaddline(struct wined3d_shader_buffer *buffer, const char *format, va > return -1; > } > buffer->buffer = new_buffer; > - buffer->buffer_size = buffer->buffer_size * 2; > + buffer->buffer_size = new_buffer_size; > base = buffer->buffer + buffer->content_size; > } > else This is a bit of an unrelated change, but probably the right thing to do. Note that I have an unsent patch that separates tracing the shader source from shader_vaddline() though, so it's going to look a bit different fairly soon. > +static char shader_empty_string[] = ""; This should be const, right? > +static void shader_sprintf_va_list(struct wined3d_shader_buffer *buffer, const char *format, va_list args) I probably would have called that vprintf/vsprintf instead of sprintf_va_list. > +{ > + int ret; > + char *new_buffer; > + unsigned int new_buffer_size; > + > + if (!buffer) > + return; > + while (1) > + { > + ret = vsnprintf(buffer->buffer, buffer->buffer_size, format, args); > + if (ret < 0 || (unsigned int)ret >= buffer->buffer_size) > + { > + new_buffer_size = buffer->buffer_size * 2; > + while (ret > 0 && (unsigned int)ret >= new_buffer_size) > + new_buffer_size *= 2; > + new_buffer = HeapReAlloc(GetProcessHeap(), 0, buffer->buffer, new_buffer_size); > + if (!new_buffer) > + { > + ERR("Couldn't allocate buffer for temporary string.\n"); > + buffer->buffer[0] = 0; > + return; > + } > + buffer->buffer = new_buffer; > + buffer->buffer_size = new_buffer_size; > + } > + else > + { > + break; > + } > + } > +} Once tracing the shader source is removed from shader_vaddline(), this comes down to a shader_buffer_clear() followed by shader_vaddline(). And arguably shader_get_buffer() should always shader_buffer_clear() the buffers it returns. > +/* This function immediately puts the buffer back into the free list (it's > + * intended to be used when the string is to be used and discarded immediately, > + * mostly useful to avoid having to move the string pointer out of the block). */ > +const char *shader_sprintf_unsafe(struct list *buffer_list, const char *format, ...) Not a fan, for the reasons mentioned at shader_glsl_generate_ffp_fragment_shader() above. > +void shader_release_buffer(struct list *list, struct wined3d_shader_buffer *buffer) > +{ > + if (!buffer) > + return; Can buffer ever legitimately be NULL? > +void shader_buffer_list_free(struct list *list) > +{ > + struct wined3d_shader_buffer *buffer, *buffer_next; > + > + LIST_FOR_EACH_ENTRY_SAFE(buffer, buffer_next, list, struct wined3d_shader_buffer, entry) > + { > + shader_buffer_free(buffer); > + HeapFree(GetProcessHeap(), 0, buffer); > + } > +} > + This doesn't actually remove the buffers from the list. There may also be an argument for wrapping the list itself in a structure, similar to struct wined3d_private_store. > struct wined3d_shader_buffer > { At some point we'll probably want to rename this to something like "wined3d_string_buffer".

2 2

Re: [PATCH 2/5] wined3d: Introduce resource-type specific format flags.
by Henri Verbeet 23 Apr '15

23 Apr '15

On 23 April 2015 at 11:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + /* Always check 2D textures here, we don't want to write this ERR when the app tried > + * to create a compressed volume texture but s3tc support is otherwise available. */ > if ((desc->format == WINED3DFMT_DXT1 || desc->format == WINED3DFMT_DXT2 || desc->format == WINED3DFMT_DXT3 > || desc->format == WINED3DFMT_DXT4 || desc->format == WINED3DFMT_DXT5) > - && !(format->flags & WINED3DFMT_FLAG_TEXTURE) && !once++) > + && !(format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_TEXTURE) && !once++) > ERR_(winediag)("The application tried to create a DXTn texture, but the driver does not support them.\n"); But now it's still going to write an ERR when it tries to create a volume texture and s3tc support is unavailable. Wouldn't it make more sense to just explicitly exclude volume textures by adding a "desc->resource_type != WINED3D_RTYPE_VOLUME_TEXTURE" condition?

2 2

Favor / heads up - wine tasks in a hackathon
by Jeremy White 23 Apr '15

23 Apr '15

My alma mater is putting on a hackathon for college students in our region. http://carlhacks.io/ As an experiment, I'm wanted to see if I could get any of these students interested in Wine hacking. So we've sponsored prize money for any students that can fix a bug in Wine or fix a test. I have no idea if any students are going to take it on or not, but if you see an influx of urgent requests on #winehackers or here, starting Saturday and ending Sunday, you'll know why :-/. And if any such student does actually succeed in contributing a clearly useful or even promising patch, please let me know, so I can make a point to award the prize money during the closing ceremonies. Cheers, Jeremy

1 0

Re: [PATCH 4/5] wined3d: Query info for each resource type from ARB_internalformat_query2.
by Henri Verbeet 23 Apr '15

23 Apr '15

On 23 April 2015 at 11:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static GLenum wined3d_gl_type_to_enum(enum wined3d_gl_resource_type type) > +{ > + switch (type) > + { > + case WINED3D_GL_RES_TYPE_TEX_1D: > + return GL_TEXTURE_1D; > + case WINED3D_GL_RES_TYPE_TEX_2D: > + return GL_TEXTURE_2D; > + case WINED3D_GL_RES_TYPE_TEX_3D: > + return GL_TEXTURE_3D; > + case WINED3D_GL_RES_TYPE_TEX_CUBE: > + return GL_TEXTURE_CUBE_MAP_ARB; > + case WINED3D_GL_RES_TYPE_TEX_RECT: > + return GL_TEXTURE_RECTANGLE_ARB; > + case WINED3D_GL_RES_TYPE_BUFFER: > + return GL_TEXTURE_2D; /* TODO: GL_TEXTURE_BUFFER. */ > + case WINED3D_GL_RES_TYPE_COUNT: > + break; > + } > + ERR("Unexpected GL resource type %u.\n", type); > + return 0; > +} > + > + You have an extra newline here. > + for (type = 0; type < sizeof(format->flags) / sizeof(*format->flags); ++type) This isn't wrong as such, but you can use ARRAY_SIZE for this now. > { > - TRACE("Format %s doesn't support %s.\n", debug_d3dformat(format->id), string); > - format_clear_flag(format, flag); > + gl_info->gl_ops.ext.p_glGetInternalformativ(wined3d_gl_type_to_enum(type), internal, pname, 1, &value); > + if (value == GL_FULL_SUPPORT) > + { > + TRACE("Format %s supports %s.\n", debug_d3dformat(format->id), string); It would probably be helpful if this mentioned the resource type as well.

1 0

Re: [PATCH 5/6] d3d9/tests: Add a specular lighting test.
by Henri Verbeet 23 Apr '15

23 Apr '15

On 22 April 2015 at 19:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +#define VERTICES_SIDE 5 > +#define INDICES_COUNT ((VERTICES_SIDE - 1) * (VERTICES_SIDE - 1) * 2 * 3) > + I don't think you really need to #define these, but if you do you should probably #undef them once you're done with them.

1 0

Re: [PATCH 3/6] wined3d: Introduce D3D7+ normal matrix computation.
by Henri Verbeet 23 Apr '15

23 Apr '15

On 22 April 2015 at 19:30, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +#define SWAP_ROWS(a, b) { float *tmp = a; a = b; b = tmp; } > + I assume this is mostly borrowed from Mesa like invert_matrix_3d(), but unfortunately Mesa isn't particularly good at writing macros, even though they have more than enough of them. This one happens to more or less work for the cases you have here, but consider the following in particular: if (...) SWAP_ROWS(a, b); else SWAP_ROWS(c, d); Please just use the standard "do { ... } while(0)" construction when you need to define a macro like that. In this particular case there's of course no reason you need a macro in the first place.

1 0

Re: [PATCH 2/2] ntdll: Add support for FileFsFullSizeInformation class in NtQueryVolumeInformationFile(try 2)
by Alexandre Julliard 23 Apr '15

23 Apr '15

"Jianqiu Zhang" <zhangjianqiu_133(a)yeah.net> writes: > + if(!S_ISREG(st.st_mode) && !S_ISDIR(st.st_mode)) > + { > + io->u.Status = STATUS_INVALID_DEVICE_REQUEST; > + } > + else > + { > + ULONGLONG bsize; > +#if !defined(linux) || !defined(HAVE_FSTATFS) > + struct statvfs stfs; > + > + if(fstatvfs( fd, &stfs ) < 0) > + { > + io->u.Status = FILE_GetNtStatus(); > + break; > + } > + bsize = stfs.f_frsize; > +#else > + struct statfs stfs; > + if(fstatfs( fd, &stfs ) < 0) > + { > + io->u.Status = FILE_GetNtStatus(); > + break; > + } > + bsize = stfs.f_bsize; > +#endif Please avoid duplicating all that code. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ws2_32/tests: Add a trailing '\n' to an ok() call.
by Marvin 23 Apr '15

23 Apr '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=12975 Your paranoid android. === w2008s64 (64 bit sock) === No test summary line found

1 0

Re: user32: After handling an internal message give a chance to real message to arrive.
by Marvin 23 Apr '15

23 Apr '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=12973 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 00150136 msg.c:12252: Test failed: bad time 315f0/315ff

1 0

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
by Alexandre Julliard 23 Apr '15

23 Apr '15

Qian Hong <qhong(a)codeweavers.com> writes: > --- > dlls/user32/tests/winstation.c | 57 > ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 57 insertions(+) Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html -- Alexandre Julliard julliard(a)winehq.org

3 8

Re: [PATCH 2/2] krnl386: Invalid console handles should translate into real handles when creating a new process.
by Alexandre Julliard 23 Apr '15

23 Apr '15

"Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > This patch fixes an issue exposed by the fix in patch 1. The current > mechanism for initializing the DOS handles for a process uses > DuplicateHandle, which converts INVALID_HANDLE_VALUE into a usable > handle (but not 0). Without this fix the Caesar III demo installer > crashes with an unhandled page fault, though it may be more desirable > to allocate new handles than to replicate the behavior we used to have > prior to patch 1. Proper handles would be better, simply open the null device or something like that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/5] wined3d: Shadow format flags in wined3d_rendertarget_view.
by Henri Verbeet 22 Apr '15

22 Apr '15

On 22 April 2015 at 11:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -101,6 +101,7 @@ static void wined3d_rendertarget_view_init(struct wined3d_rendertarget_view *vie > view->parent_ops = parent_ops; > > view->format = wined3d_get_format(gl_info, desc->format_id); > + view->format_flags = resource->format_flags; That's wrong. We won't be able to do much with this until we support ARB_texture_view, but the view format is mostly independent of the resource format, other than that they have to be from the same compatibility class. I guess you'd want something like "view->format_flags = view->format->flags[resource->gl_type];".

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 9)
by Stefan Dösinger 22 Apr '15

22 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-22 um 05:30 schrieb Alistair Leslie-Hughes: > + if(*pdwBufferSize < entry->size || *pdwNameLen < namesize) > + { > + *pdwNameLen = namesize + 1; > + *pdwBufferSize = entry->size; > + return DPNERR_BUFFERTOOSMALL; > + } > + > + if((*pdwNameLen && !pwszName) || (*pdwBufferSize && !pvBuffer)) > + return E_POINTER; This check suggests that a NULL pwszName is ok if *pdwNameLen is 0. However, the above check fails in this situation. Depending on how you want this to behave there's either an error in your logic or you have some redundant checks in there. Are you sure *pdwDataType is not set in the BUFFERTOOSMALL case? I mentioned pdwDataType in the last feedback already, please take a bit more care and check if some things I point out apply in a similar way to other places, and re-read the feedback you get after you think you have implemented all the changes to see if there's anything you missed. > + case DPNA_DATATYPE_DWORD: > + *(DWORD*)pvBuffer = entry->data.value ; The extra space in front of the semicolon looks weird. > hr = IDirectPlay8Address_GetComponentByIndex(localaddr, 100, NULL, NULL, NULL, &bufflen, &type); > - todo_wine ok(hr == E_POINTER, "got 0x%08x\n", hr); > + ok(hr == DPNERR_INVALIDPOINTER, "got 0x%08x\n", hr); In the code you return E_POINTER. DPNERR_INVALIDPOINTER is defined as E_POINTER, but please try to be consistent. > hr = IDirectPlay8Address_GetComponentByIndex(localaddr, i, NULL, &namelen, NULL, &bufflen, &type); > - todo_wine ok(hr == DPNERR_BUFFERTOOSMALL, "got 0x%08x\n", hr); > + ok(hr == DPNERR_BUFFERTOOSMALL, "got 0x%08x\n", hr); > + ok(namelen > 0, "namelen length is 0\n"); > + ok(bufflen > 0, "bufflen length is 0\n"); Please check the exact length, not just > 0. Please also check the name string, and the string and lengths in the success case (e.g. if you pass a length > than the necessary size does dpnet change the size?). Also, as pointed out above -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVN25ZAAoJEN0/YqbEcdMwf1cP/jXMXUuyMNzg5JAVG6YMMKgJ yIac4X5zxnmcPrJMjMRKIr2xU3u6ZDki/Kk5/GulDCCd4NQGlDJP0QY9WuuZ9eIN YiAipjXLpO4DPVi6eTRlDIbfCSDfpNJnjSWdDGbjpF/dpUkJOOZzwWvkJKZr598O kZohPT1kwTs12sU3yQyT8N3NGQer+AaWHcfohMW5f0UeZ+whviwjg3CGavrR65mH Q2fWn92mgw8KPTu+zvJ5oBbWQLf24o+lBp/vQ6zeOIA2lxXVLoMfg5q8QRWvKge9 IiPIG8BEOfrTXXSEZSUauif97fdq23JGQJOOGYUyZ+YLg/4Pqj2nWZBOmFM+3gVy E5FgFPT4EdE1vpyn7cnWGufzNtnctTZGOJ4F7AKxdMoBPqXxDEgdjmMFqN0yeTH8 Pm6NGVJP7uR8+wqXApHoGN2S7ceZLuEhMhdGYHbFakx9McPzCEayWMGQ/CIlbjHt YRB5aaxOAk896Fmb+PMuv3G9d4+y4409iLB+/Jrda20VOFfAp1qzNa33R9rhWXN7 sSdCale2KKYwStnzSWAcH4Mn7L+i1B/Dl7Md83HqPumAPfwlSK8VZVeqF0ZVjLaR KlokPcmQnIuS/ia6gPdGVbmAHnpoIIn0CNtgstKBqXkvGUlasXsKhy2ofWkWoaiW lO+hrwausmSORbzMGVaW =fTwv -----END PGP SIGNATURE-----

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 9)
by Marvin 22 Apr '15

22 Apr '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=12940 Your paranoid android. === w8 (32 bit address) === The test timed out

1 0

Re: comctl32:TTM_SETTOOLINFO does not change subclassing
by Nikolay Sivov 21 Apr '15

21 Apr '15

On 21.04.2015 17:40, Aric Stewart wrote: > > Prevents crashes when a subclassed window is unsubclassed and then destroyed. > > As per information found at: > https://support.microsoft.com/en-us/kb/kbview/154122 > --- > dlls/comctl32/tooltips.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > We definitely need a test for that.

2 1

Re: [PATCH 5/5] ddraw/tests: Port the lighting test to the previous d3d versions.
by Marvin 21 Apr '15

21 Apr '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=12921 Your paranoid android. === wvistau64 (32 bit ddraw1) === ddraw1.c:2488: Test failed: Expected message 0x46, but didn't receive it. ddraw1.c:2490: Test failed: Expected screen size 1024x768, got 0x0. ddraw1.c:2496: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2527: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2535: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2562: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2582: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2606: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2633: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2650: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2687: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2698: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2725: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2745: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2762: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2789: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2806: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2844: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}.

1 0

Re: [PATCH 4/5] ddraw/tests: Add more d3d7 lighting tests.
by Marvin 21 Apr '15

21 Apr '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=12920 Your paranoid android. === w8 (32 bit visual) === visual.c:1494: Test failed: unexpected colortable on offscreen surface

1 0

Re: iexplore: Update version to 9.0.8112.16421.
by Nikolay Sivov 21 Apr '15

21 Apr '15

On 21.04.2015 12:19, Hans Leidekker wrote: > --- > programs/iexplore/iexplore.inf | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > Maybe ieframe/mshtml versions should be updated as well?

2 1

Re: [2/2] server: GetQueueStatus should clear only checked queue changed bits.
by Marvin 21 Apr '15

21 Apr '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=12902 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 00080150 msg.c:12252: Test failed: bad time 30c10/30c20

1 0

Re: [1/2] user32/tests: Add PeekMessage(PM_NOREMOVE) call to inter-thread messages test.
by Marvin 21 Apr '15

21 Apr '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=12901 Your paranoid android. === wvistau64 (32 bit msg) === msg.c:10471: Test failed: expected PeekMessage to return FALSE, got 1 === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0014013C msg.c:12252: Test failed: bad time 30fa9/30fb8

1 0

Re: (resend)server: Do not replace focus and active windows with NULL on thread_attach_input
by Marvin 20 Apr '15

20 Apr '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=12890 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 00080150 msg.c:12252: Test failed: bad time 30f1c/30f2c

1 0

Re: server: Do not replace focus and active windows with NULL on thread_attach_input
by Marvin 20 Apr '15

20 Apr '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=12889 Your paranoid android. === w7u (32 bit msg) === msg.c:12230: Test failed: unexpected hwnd 0014013E msg.c:12252: Test failed: bad time 3200d/3201d

1 0

Re: user32/tests: Add a test for sending inter-thread messages.
by Marvin 20 Apr '15

20 Apr '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=12880 Your paranoid android. === w7u (32 bit msg) === msg.c:6957: Test failed: destroy child on thread exit: 0: the msg 0x0082 was expected, but got msg 0x0014 instead msg.c:6957: Test failed: destroy child on thread exit: 1: the msg 0x000f was expected, but got msg 0x0082 instead msg.c:6957: Test failed: destroy child on thread exit: 2: the msg 0x0014 was expected, but got msg 0x000f instead msg.c:6957: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 0014 msg.c:12230: Test failed: unexpected hwnd 00060150 msg.c:12252: Test failed: bad time 31cc3/31cd2

1 0

GSoC 2015 Application
by lijianwei 20 Apr '15

20 Apr '15

Hi I'm a graduate student in NorthWestern Polytenical University.I have been study Parelism promraming,especially GPU programming for two year.So I want to accept task Implement OpenMP. But now,what should I do to begin my work. Watting for your answer! Than you! Best Regard

2 1

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