July 2010 - Wine-devel - list.winehq.org

Re: [PATCH 1/1] d3dx9: Complete test for D3DXCreateSphere. (try 5)
by Octavian Voicu 27 Jul '10

27 Jul '10

On Tue, Jul 27, 2010 at 1:30 AM, Misha Koshelev <misha680(a)gmail.com> wrote: > I have spent quite a bit of time with Henri on IRC re this patch (thank you so much) and it now has his blessing. > > Hopefully everyone else's as well :) Looks nice, but I have a question. When you're going to actually implement D3DXCreateSphere (probably applies to subsequent mesh functions too), aren't you going to need big chunks of this code, like the compute_sphere and *_sincos_table functions? Or are you going to use a different approach to compute the meshes in the actual implementation? Octavian

1 0

Re: [PATCH 07/11] d3d10: Implement D3D10GetInputAndOutputSignatureBlob().
by Henri Verbeet 26 Jul '10

26 Jul '10

2010/7/26 Rico Schüller <kgbricola(a)web.de>: > + /* 32 (DXBC header) + 2 * (1 * 4 (chunk index) + 2 * 4 (chunk header)) + data_size (chunk data) */ I'm probably missing something here, but: - I think that should be "2 * 4 (chunk index) + 2 * 4 (chunk header)" -> 48? - Aligning chunks on 16 byte / 128 bits offsets makes sense, but then you also need to actually write the chunks at those locations, and take it into account in the size calculation.

1 0

Re: [PATCH 05/11] d3d10: Implement D3D10GetInputSignatureBlob().
by Henri Verbeet 26 Jul '10

26 Jul '10

2010/7/26 Rico Schüller <kgbricola(a)web.de>: > +static HRESULT shader_singnature_handler(const char *data, DWORD data_size, DWORD tag, void *ctx) That's not how you write "signature". > + IUnknown_Release((IUnknown *)object); Is that cast needed?

1 0

Re: [PATCH] libs/wpp: Fixed bug in preventing add_text_to_macro from handling macros over 1 kb large
by Austin English 26 Jul '10

26 Jul '10

On Mon, Jul 26, 2010 at 12:38 PM, Travis Athougies <iammisc(a)gmail.com> wrote: > Resending patch with proper line wrapping You forgot the patch :-). -- -Austin

1 0

Re: Patch #63746 revisited: Add const qualifer after version check
by Octavian Voicu 26 Jul '10

26 Jul '10

On Mon, Jul 26, 2010 at 2:13 PM, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > +#else > +const SSL_METHOD *method; Also, you accidentally removed the "static" keyword instead of removing the "const" keyword for the #else branch (in both files). Octavian

1 0

Re: Patch #63746 revisited: Add const qualifer after version check
by Octavian Voicu 26 Jul '10

26 Jul '10

On Mon, Jul 26, 2010 at 2:13 PM, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > -static SSL_METHOD *meth; > +#if defined(OPENSSL_VERSION_NUMBER) && (OPENSSL_VERSION_NUMBER> 0x1000000) > +static const SSL_METHOD *meth; > +#else > +const SSL_METHOD *method; There's a typo here, last line should declare meth not method. Octavian

1 0

Re: [PATCH] const variables are not compile-time constants
by Octavian Voicu 26 Jul '10

26 Jul '10

On Sun, Jul 25, 2010 at 11:36 PM, Mikko Rasa <tdb(a)tdb.fi> wrote: > - static const DWORD user_flags = clip_flags | DCX_NORESETATTRS; /* flags that can be set by user */ > + static const DWORD user_flags = DCX_PARENTCLIP | DCX_CLIPSIBLINGS | DCX_CLIPCHILDREN | DCX_WINDOW > + | DCX_NORESETATTRS; /* flags that can be set by user */ This should be committed first thing tomorrow imho (in order to minimize the number of potential compile errors in case of a bisect). Octavian

4 4

Re: [PATCH 2/7] msvcp90/tests: Added allocator<char> tests (try3)
by Alexandre Julliard 26 Jul '10

26 Jul '10

Piotr Caban <piotr(a)codeweavers.com> writes: > try3: Don't skip all tests on 64bit You should be able to run all tests on 64-bit, which would also have the advantage of making sure the function prototypes are correct (since the call macros on i386 prevent checking). -- Alexandre Julliard julliard(a)winehq.org

1 0

How to handle Wrapper(?) Dlls
by Uwe Bonnes 26 Jul '10

26 Jul '10

Hello, there are several hardware related libraries, like libusb and libftd2xx which exist on Windows and at least linux. I tried already to add libftd2xx, but with silent reject. What is the preferred way to handle it? I feel including in wine is favorable, as this gives a good user impression, as some hardware device connected to the machine with the windows software installed has good chances to work out of the box. Another possibility, but much less favourable i.m.h.o. would be to build an add-on dll, distributed at either some place at winehq or else. This however requires user intervention and some way to let the user know about the translation dll. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 3

Re: [PATCH 1/1] d3dx9: Complete test for D3DXCreateSphere. (try 4)
by Henri Verbeet 26 Jul '10

26 Jul '10

On 26 July 2010 01:20, Misha Koshelev <misha680(a)gmail.com> wrote: > I kept some macros in, although I know you guys don't like that too much. > > Like sphere_vertex. I think it makes the code clearer. compare_vertex and compare_face are probably ok, but there's no reason sphere_vertex can't be an inline function. Note that macros are much trickier to get right than inline functions. E.g. unless you carefully control where a macro is used you usually need to at least wrap it inside "do {} while (0)", add braces around arguments, and make sure arguments are only used once to avoid unintended side-effects. >+ HeapFree(GetProcessHeap(), 0, (LPVOID)mesh->vertices); >+ mesh->vertices = (struct vertex *)HeapAlloc(GetProcessHeap(), 0, number_of_vertices * sizeof(struct vertex)); Are you used to programming in C++ by any chance? Assignments to/from void don't require an explicit cast in C. Also, you can use "sizeof(*mesh->vertices)" to ensure the type in the HeapAlloc() matches what you assign it to. > +struct mesh *new_mesh(DWORD number_of_vertices, DWORD number_of_faces) This should be static. > + struct mesh* mesh = NULL; This is redundant, you assign to mesh a few lines further down. I know this is mostly a style preference, but *please* just write "struct mesh *mesh". I guess the idea behind that convention is that you're declaring "mesh" as a "pointer to struct mesh", but declarations simply don't work that way in C. I suppose that's a flaw in the language, but either way it'll break down when you want to do something like "const char* p, q". In the long term you're probably better of properly learning C declaration syntax anyway. > + /* validate parameters */ > + assert(number_of_vertices); > + assert(number_of_faces); You don't need these. There are cases where assert() is appropriate, but that's rarely in the tests, and I don't think any of the ones in this patch qualify. > + /* new mesh */ > + mesh = (struct mesh *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct mesh)); > + if (!mesh) > + { > + return NULL; > + } You don't have to allocate "mesh" on the heap, you can just use a stack variable and pass a pointer to that. > + if (*sine) > + { > + HeapFree(GetProcessHeap(), 0, (LPVOID)*sine); > + *sine = NULL; > + } Checking for NULL before HeapFree() is redundant. > +static BOOL compute_circle_table(FLOAT **sine, FLOAT **cosine, FLOAT angle_start, FLOAT angle_step, int n) I think a "struct sincos_table" would be nicer. In the rest of the code you'd then have have e.g. "theta[stack].sin" instead of "sin_theta[stack]", but I think that's ok. You'd also avoid passing "FLOAT **sine" and "FLOAT **cosine" to free_circle_table(). Please just use "float" instead of "FLOAT". > + if (!compute_circle_table(&sin_theta, &cos_theta, theta_start, theta_step, stacks)) > + { > + free_circle_table(&sin_theta, &cos_theta); That's redundant again, compute_circle_table() already cleans those up itself on failure.

1 0