Re: Glitch-free iTunes?

[Keith Curtis]

On Sun, Jul 3, 2011 at 1:37 AM, Damjan Jovanovic wrote:

>
> Hi Keith
>
> Having worked at Microsoft, you of all people should appreciate the
> size and complexity of the driver architecture on Windows. So I would
> say that "failure" is mostly from the scale of the problem to be
> solved.
>
> My attempts at adding USB support to Wine have been painful and slow.
>

Hi Damjan et al;

I don't know much about the USB architecture as my contributions to Windows
were via RichEdit. I just know that the Linux kernel has mature USB support,
WINE in general does many things, and you've got a big team now. Your
contributor list shows 1250 and you've got 2M lines of code. I'm amazed at
how many things work -- or almost work.

If you had a leaky roof in a house on fire, what would you work on first? It
appears from the outside that the answer for WINE would be random.

In general, people can work where they want, but it is better if some work
is prioritized. You don't need to use the buglist for this. When Linus finds
a bug he needs fixed before he can make a release, he posts to the LKML and
all the developers read it and the relevant ones respond. Typically he
reverts, but sometimes he requests help, and he gets it within hours. He
doesn't wait for someone to check in code that works.

You don't have to work like that. I am just pointing out that if you have
goals (do not ship without certain apps working) or priorities (certain bugs
are higher priority), or something, things will be better for the same
amount of effort.

Regards,

-Keith
http://keithcu.com/

WyldBOT 1 & 2 updated

[wylda]

Hi, 6 months passed so i updated images for these two machines
(Description + Windows update + nvidia drivers in case of WyldBOT1).

And this new nVidia v275.33 driver brings new failures in
dlls/ddraw/tests/visual.c:

visual.c:1503: Test failed: Got color 00d8, expected 0080 or
near
visual.c:1625: Test failed: Got color 00b000cf, expected 008000ff or
near
visual.c:1745: Test failed: Got color 00d8, expected 0080 or
near

The above is diff of the following links:

Old nVidia driver v260.99:
http://test.winehq.org/data/5758d748971d300f77b05ab245d870696c44132c/xp_WyldBOT1-wxp-32b-ie6/ddraw:visual.html

New nVidia driver v275.33:
http://test.winehq.org/data/5758d748971d300f77b05ab245d870696c44132c/xp_WyldBOT1-wxp-32b-ie6_1/ddraw:visual.html


Regards,
W.

Re: [6/6] wined3d: Don't apply and invalidate the framebuffer when clearing the device's fb

[Henri Verbeet]

On 2 July 2011 11:59, Stefan Dösinger  wrote:
> +if (isStateDirty(context, STATE_FRAMEBUFFER) || fb != &device->fb)
This is probably never an issue in practice, but you're ignoring rt_count here.

Re: Traces with threading

[Erich Hoover]

On Sun, Jul 3, 2011 at 10:58 AM, Alex Bradbury  wrote:

> On 3 July 2011 17:51, Erich Hoover  wrote:
> > Rather than rooting around for a while I figured I should ask first, is
> > there a quick and easy way to get all TRACE/FIXME commands to output the
> > thread id?  I'm trying to track down an issue where one of a pair of
> threads
> > locks up and it'd be really nice to quickly identify which one is doing
> > what.
>
> Unless I've totally misunderstood your question:
>
> http://wiki.winehq.org/DebugChannels
>
> WINEDEBUG=+tid
>

Thank you so much! I was aware of the list of "functionality" channels but
did not notice the "special" channels, I'll be more careful to read down the
page further next time.

Erich Hoover
ehoo...@mines.edu

Re: Traces with threading

[Alex Bradbury]

On 3 July 2011 17:51, Erich Hoover  wrote:
> Rather than rooting around for a while I figured I should ask first, is
> there a quick and easy way to get all TRACE/FIXME commands to output the
> thread id?  I'm trying to track down an issue where one of a pair of threads
> locks up and it'd be really nice to quickly identify which one is doing
> what.

Unless I've totally misunderstood your question:

http://wiki.winehq.org/DebugChannels

WINEDEBUG=+tid

Alex

Traces with threading

[Erich Hoover]

Rather than rooting around for a while I figured I should ask first, is
there a quick and easy way to get all TRACE/FIXME commands to output the
thread id?  I'm trying to track down an issue where one of a pair of threads
locks up and it'd be really nice to quickly identify which one is doing
what.

Erich Hoover
ehoo...@mines.edu

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

[Dylan Smith]

The latest ConvertPointRepsToAdjacency patches look good.

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

[Michael Mc Donnell]

On Sun, Jul 3, 2011 at 8:41 AM, Dylan Smith  wrote:
> On Sat, Jul 2, 2011 at 1:01 PM, Michael Mc Donnell  
> wrote:
>> +static HRESULT init_edge_face_map(struct edge_face_map *edge_face_map, 
>> CONST DWORD *index_buffer, CONST DWORD *point_reps, CONST DWORD num_faces)
>> +{
> ...
>> +    TRACE("(%p, %p, %p, %d)\n", edge_face_map, index_buffer, point_reps, 
>> num_faces);
>
> A TRACE call for an internal initialization function like this seems
> unnecessary. They are commonly provided for external functions since
> it captures application behavior.

Ok, I've removed them.

>> +    if (!point_reps) /* Identity point reps */
>> +    {
>> +        id_point_reps = generate_identity_point_reps(num_faces, 
>> num_vertices);
>> +        if (!id_point_reps)
>> +        {
>> +            hr = E_OUTOFMEMORY;
>> +            goto cleanup;
> ...
>> +    hr = iface->lpVtbl->LockIndexBuffer(iface, D3DLOCK_READONLY, &ib_ptr);
>> +    if (FAILED(hr)) goto cleanup;
> ...
>> +cleanup:
>> +    HeapFree(GetProcessHeap(), 0, id_point_reps);
>> +    if (indices_are_16_bit) HeapFree(GetProcessHeap(), 0, ib);
>> +    free_edge_face_map(&edge_face_map);
>> +    iface->lpVtbl->UnlockIndexBuffer(iface);
>> +    return hr;
>>  }
>
> The index buffer is unconditionally unlocked in the cleanup code, but
> goto cleanup can now be called before the index buffer is locked.

I've added a check to see if it's locked.

>> +static DWORD *generate_identity_point_reps(DWORD num_faces, DWORD 
>> num_vertices)
>> +{
>> +        DWORD *id_point_reps;
>> +        DWORD i;
>> +
>> +        TRACE("(%d, %d)\n", num_faces, num_vertices);
>> +
>> +        id_point_reps = HeapAlloc(GetProcessHeap(), 0, 3 * num_faces * 
>> sizeof(*id_point_reps));
>> +        if (!id_point_reps)
>> +            return NULL;
>> +
>> +        for (i = 0; i < num_vertices; i++)
>> +        {
>> +            id_point_reps[i] = i;
>> +        }
>> +        for (i = num_vertices; i < 3 * num_faces; i++)
>> +        {
>> +            id_point_reps[i] = -1;
>> +        }
>> +
>> +        return id_point_reps;
>> +}
>
> Why are there exra point reps allocated with -1 value?  Won't only
> num_vertices point_reps get used?

Yes that was a mistake. Only num_vertices are used and not
3*num_faces. I have also removed some unnecessary -1 checks.
From 629df56f46f72daf7e4731b406463ff46f5870a9 Mon Sep 17 00:00:00 2001
From: Michael Mc Donnell 
Date: Thu, 23 Jun 2011 17:46:51 +0200
Subject: d3dx9/test: Implemented ConvertPointRepsToAdjacency test.

Added shared vertices test.
Removed unused indices in point_rep9.
---
 dlls/d3dx9_36/tests/mesh.c |  548 
 1 files changed, 548 insertions(+), 0 deletions(-)

diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c
index 98d77d9..06b6111 100644
--- a/dlls/d3dx9_36/tests/mesh.c
+++ b/dlls/d3dx9_36/tests/mesh.c
@@ -4904,6 +4904,553 @@ static void test_create_skin_info(void)
 ok(hr == D3DERR_INVALIDCALL, "Expected D3DERR_INVALIDCALL, got %#x\n", hr);
 }
 
+static void test_convert_point_reps_to_adjacency(void)
+{
+HRESULT hr;
+struct test_context *test_context = NULL;
+const DWORD options = D3DXMESH_32BIT | D3DXMESH_SYSTEMMEM;
+const DWORD options_16bit = D3DXMESH_SYSTEMMEM;
+const D3DVERTEXELEMENT9 declaration[] =
+{
+{0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0},
+{0, 12, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0},
+{0, 24, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0},
+D3DDECL_END()
+};
+const unsigned int VERTS_PER_FACE = 3;
+void *vertex_buffer;
+void *index_buffer;
+DWORD *attributes_buffer;
+int i, j;
+enum color { RED = 0x, GREEN = 0xff00ff00, BLUE = 0xffff};
+struct vertex_pnc
+{
+D3DXVECTOR3 position;
+D3DXVECTOR3 normal;
+enum color color; /* In case of manual visual inspection */
+};
+D3DXVECTOR3 up = {0.0f, 0.0f, 1.0f};
+/* mesh0 (one face)
+ *
+ * 0--1
+ * | /
+ * |/
+ * 2
+ */
+const struct vertex_pnc vertices0[] =
+{
+{{ 0.0f,  3.0f,  0.f}, up, RED},
+{{ 2.0f,  3.0f,  0.f}, up, GREEN},
+{{ 0.0f,  0.0f,  0.f}, up, BLUE},
+};
+const DWORD indices0[] = {0, 1, 2};
+const unsigned int num_vertices0 = ARRAY_SIZE(vertices0);
+const unsigned int num_faces0 = num_vertices0 / VERTS_PER_FACE;
+const DWORD exp_adjacency0[] = {-1, -1, -1};
+const DWORD exp_id_adjacency0[] = {-1, -1, -1};
+const DWORD point_rep0[] = {0, 1, 2};
+/* mesh1 (right)
+ *
+ * 0--1 3
+ * | / /|
+ * |/ / |
+ * 2 5--4
+ */
+const struct vertex_pnc vertices1[] =
+{
+{{ 0.0f,  3.0f,  0.f}, up, RED},
+{{ 2.0f,  3.0f,  0.f}, up, GREEN},
+{{ 0.0f,  0.0f,  0.f}, up, BLUE},
+
+{{ 3.0f,  3.0f,  0.f}, up, GREEN},
+{{ 3.0f,  0.0f,  0.f}, up, RED},
+ 

Re: Updated Clang static analysis results / Valgrind update

[Vincas Miliūnas]

On 07/03/2011 04:33 PM, Frédéric Delanoy wrote:
> 2011/7/3 Vincas Miliūnas :
>>> On Sun, Jul 3, 2011 at 04:15, Austin English >> > wrote:
 / Web space usage was getting a bit high, so I've uploaded a tarball to
>>> />/ a file download service:
>>> />/ http://www.sendspace.com/file/5hot36
>>> />/
>>> />/ austin at aw21  ~ $ 
>>> sha1sum scan-build-2011-07-02.tar.bz2
>>> />/ ac3cb3920ef97641fff1f5376f8136cef01f15bf  scan-build-2011-07-02.tar.bz2
>>> /
>>> FWIW, you could use xz instead of bzip2 to further reduce the download
>>> size (54 MiB)
>>> I got the size down to 46 MiB using default settings, and 25 MiB using
>>> max compression (xz -9)
>>>
>>> Frédéric
>> I have heard about he xz compressor, so I was interested on how 7zip and xz 
>> perform maxed-out:
>>
>> 7z a -t7z -m0=lzma -mx=9 -mfb=255 -md=256m -ms=on scan-build-2011-07-02-1.7z 
>> scan-build-2011-07-02-1
>> 11.87MiB - 12445530 scan-build-2011-07-02-1.7z
>>
>> xz -zkc -Fxz -9e -M5GB --lzma2='dict=256Mi,nice=273,mf=bt4' 
>> scan-build-2011-07-02-1.tar > scan-build-2011-07-02-1.xz
>> 12.14MiB - 12726004 scan-build-2011-07-02-1.xz
>>
>> I didn't measure time, but it wasn't very long; xz took longer, because it 
>> doesn't support multithreading. Both required 3.5GB of memory at the peek.
> Well I didn't use all the xz options TBH... I only have 4 GiB of RAM, so...
> With "xz -9" it used like 600 MiB memory.
>
> Don't know about 7z, but xz manpage says it requires 5-20% RAM for
> decompression compared to compression, so it maybe a bit (too) high
> with your options for certain people.
>
> I once did a (quick) comparison between rzip/lrzip (which I think is
> in the same family as 7z) and xz, and had comparable results (give ot
> take 1% or 2), but xz was WAY quicker (something like 7-8x).
> xz was about a quick (or quicker) than bzip2 with better compression
> ratios/less memory usage, so it seemed a good compromise
>
> You probably have a monster machine if it didn't take very long for
> you though ;)
>
> Frédéric
>
No, I have an old E8400 w/ 8GiB of RAM.

I reran the 7z compression with time measurement. Decompression of the
previous 7z archive took ~3 seconds to a ram drive.

Looking at the exact numbers, I guess I overestimated :), it did take a
considerable amount of time and multithreading isn't very impressive:
real10m39.469s
user12m14.888s
sys0m3.839s

But I agree, from what I have seen, xz is certainly superior to bzip2.

Re: kernel32/tests: remove a few CloseHandle calls on a HMODULE that don't make any sense

[Louis Lenders]

Marvin  testbot.winehq.org> writes:


> Full results can be found at
> http://testbot.winehq.org/JobDetails.pl?Key=12163
> 
> Your paranoid android.
> 
> === WNT4WSSP6 (32 bit module) ===
> module.c:356: Test failed: Expected ERROR_FILE_NOT_FOUND, got 1006
> 


Hi, is there anyone who can tell me why the test now fails in WinNT? Maybe I'm
completely off and not understanding the tests for LoadLibraryEx, and the
CloseHandle calls _are_ needed? If someone could explain me why they are there
that would be great. 

regards louis

Re: Updated Clang static analysis results / Valgrind update

[Frédéric Delanoy]

2011/7/3 Vincas Miliūnas :
>> On Sun, Jul 3, 2011 at 04:15, Austin English > > wrote:
>> >/ Web space usage was getting a bit high, so I've uploaded a tarball to
>> />/ a file download service:
>> />/ http://www.sendspace.com/file/5hot36
>> />/
>> />/ austin at aw21  ~ $ 
>> sha1sum scan-build-2011-07-02.tar.bz2
>> />/ ac3cb3920ef97641fff1f5376f8136cef01f15bf  scan-build-2011-07-02.tar.bz2
>> /
>> FWIW, you could use xz instead of bzip2 to further reduce the download
>> size (54 MiB)
>> I got the size down to 46 MiB using default settings, and 25 MiB using
>> max compression (xz -9)
>>
>> Frédéric
> I have heard about he xz compressor, so I was interested on how 7zip and xz 
> perform maxed-out:
>
> 7z a -t7z -m0=lzma -mx=9 -mfb=255 -md=256m -ms=on scan-build-2011-07-02-1.7z 
> scan-build-2011-07-02-1
> 11.87MiB - 12445530 scan-build-2011-07-02-1.7z
>
> xz -zkc -Fxz -9e -M5GB --lzma2='dict=256Mi,nice=273,mf=bt4' 
> scan-build-2011-07-02-1.tar > scan-build-2011-07-02-1.xz
> 12.14MiB - 12726004 scan-build-2011-07-02-1.xz
>
> I didn't measure time, but it wasn't very long; xz took longer, because it 
> doesn't support multithreading. Both required 3.5GB of memory at the peek.

Well I didn't use all the xz options TBH... I only have 4 GiB of RAM, so...
With "xz -9" it used like 600 MiB memory.

Don't know about 7z, but xz manpage says it requires 5-20% RAM for
decompression compared to compression, so it maybe a bit (too) high
with your options for certain people.

I once did a (quick) comparison between rzip/lrzip (which I think is
in the same family as 7z) and xz, and had comparable results (give ot
take 1% or 2), but xz was WAY quicker (something like 7-8x).
xz was about a quick (or quicker) than bzip2 with better compression
ratios/less memory usage, so it seemed a good compromise

You probably have a monster machine if it didn't take very long for
you though ;)

Frédéric

Re: Updated Clang static analysis results / Valgrind update

[Vincas Miliūnas]

> On Sun, Jul 3, 2011 at 04:15, Austin English  > wrote:
> >/ Web space usage was getting a bit high, so I've uploaded a tarball to
> />/ a file download service:
> />/ http://www.sendspace.com/file/5hot36
> />/
> />/ austin at aw21  ~ $ 
> sha1sum scan-build-2011-07-02.tar.bz2
> />/ ac3cb3920ef97641fff1f5376f8136cef01f15bf  scan-build-2011-07-02.tar.bz2
> /
> FWIW, you could use xz instead of bzip2 to further reduce the download
> size (54 MiB)
> I got the size down to 46 MiB using default settings, and 25 MiB using
> max compression (xz -9)
>
> Frédéric
I have heard about he xz compressor, so I was interested on how 7zip and xz 
perform maxed-out:

7z a -t7z -m0=lzma -mx=9 -mfb=255 -md=256m -ms=on scan-build-2011-07-02-1.7z 
scan-build-2011-07-02-1
11.87MiB - 12445530 scan-build-2011-07-02-1.7z

xz -zkc -Fxz -9e -M5GB --lzma2='dict=256Mi,nice=273,mf=bt4' 
scan-build-2011-07-02-1.tar > scan-build-2011-07-02-1.xz
12.14MiB - 12726004 scan-build-2011-07-02-1.xz

I didn't measure time, but it wasn't very long; xz took longer, because it 
doesn't support multithreading. Both required 3.5GB of memory at the peek.

Re: Random crashes while running (cmd) test runner [update backtrace]

[Frédéric Delanoy]

#0  0x7bc481f2 in HEAP_MakeInUseBlockFree (subheap=0x110014,
pArena=0x1106a8) at heap.c:640
#1  0x7bc4b7f5 in RtlFreeHeap (heap=0x11, flags=2, ptr=0x1106b0)
at heap.c:1757
#2  0x7bc38b12 in read_directory_stat (fd=13, io=0x33dbd0,
buffer=0x1116c8, length=8192,
single_entry=0 '\000', mask=0x1116ac, restart_scan=1 '\001',
class=FileBothDirectoryInformation) at directory.c:1936
#3  0x7bc38f3b in NtQueryDirectoryFile (handle=0x24, event=0x0, apc_routine=0,
apc_context=0x0, io=0x33dbd0, buffer=0x1116c8, length=8192,
info_class=FileBothDirectoryInformation, single_entry=0 '\000',
mask=0x1116ac,
restart_scan=1 '\001') at directory.c:2012
#4  0x7b8400aa in FindFirstFileExW (filename=0x33dccc,
level=FindExInfoStandard,
data=0x33e4cc, search_op=FindExSearchNameMatch, filter=0x0,
flags=0) at file.c:1864
#5  0x7b840a69 in FindFirstFileW (lpFileName=0x33dccc,
lpFindData=0x33e4cc) at file.c:2083
#6  0x7b859ba6 in GetLongPathNameW (shortpath=0x33ee68,
longpath=0x33e780, longlen=260)
at path.c:362
#7  0x7b861765 in create_startup_info (filename=0x33ee68,
cmdline=0x111348, cur_dir=0x0,
env=0x0, flags=0, startup=0x33f928, info_size=0x33ea40) at process.c:1595
#8  0x7b86256c in create_process (hFile=0x20, filename=0x33ee68,
cmd_line=0x111348, env=0x0,
cur_dir=0x0, psa=0x0, tsa=0x0, inherit=1, flags=0,
startup=0x33f928, info=0x33fa3c,
unixdir=0x111540
"/home/fred/.wine-tmp/dosdevices/z:/home/fred/sources/wine-git",
binary_info=0x33f070, exec_only=0) at process.c:1926
#9  0x7b8638b0 in create_process_impl (app_name=0x33f1a8, cmd_line=0x111348,
process_attr=0x0, thread_attr=0x0, inherit=1, flags=0, env=0x0,
cur_dir=0x0,
startup_info=0x33f928, info=0x33fa3c) at process.c:2274
#10 0x7b864175 in CreateProcessW (app_name=0x33f1a8,
cmd_line=0x111348, process_attr=0x0,
thread_attr=0x0, inherit=1, flags=0, env=0x0, cur_dir=0x0,
startup_info=0x33f928,
info=0x33fa3c) at process.c:2388
#11 0x7b862f95 in create_cmd_process (filename=0x33f628,
cmd_line=0x111328, env=0x0,
cur_dir=0x0, psa=0x0, tsa=0x0, inherit=1, flags=0,
startup=0x33f928, info=0x33fa3c)
at process.c:2100
#12 0x7b863c71 in create_process_impl (app_name=0x0,
cmd_line=0x111328, process_attr=0x0,
thread_attr=0x0, inherit=1, flags=0, env=0x0, cur_dir=0x0,
startup_info=0x33f928,
info=0x33fa3c) at process.c:2305
#13 0x7b864068 in CreateProcessA (app_name=0x0, cmd_line=0x33fa73 "test.cmd",
process_attr=0x0, thread_attr=0x0, inherit=1, flags=0, env=0x0,
cur_dir=0x0,
startup_info=0x33f9f8, info=0x33fa3c) at process.c:2368
#14 0x7effb19e in run_cmd (cmd_data=0x110688 "@echo off\necho should
fail\n\ndir\n\022",
cmd_size=33) at batch.c:95
#15 0x7effb9f4 in run_test (cmd_data=0x7efff52c "@echo off\necho
should fail\n\ndir\n\n",
cmd_size=28, exp_data=0x7efff548 "dir\n\n", exp_size=5) at batch.c:239
#16 0x7effbe46 in test_enum_proc (module=0x7eff, type=0x7effd4ab "TESTCMD",
name=0x110668 "TEST_BUILTINS.CMD", param=0) at batch.c:317
#17 0x7b86d748 in EnumResourceNamesA (hmod=0x7eff, type=0x7effd4ab
"TESTCMD",
lpfun=0x7effbd43 , lparam=0) at resource.c:345
#18 0x7effc008 in func_batch () at batch.c:353
#19 0x7effcc92 in run_test (name=0x7effd745 "batch") at
../../../include/wine/test.h:556
#20 0x7effd057 in main (argc=1, argv=0x1103e0) at
../../../include/wine/test.h:616
#21 0x7effd136 in __wine_spec_exe_entry (peb=0x7ffdf000) at exe_entry.c:36
#22 0x7b860008 in call_process_entry () at process.c:1035
#23 0x7b86014f in start_process (peb=0x7ffdf000) at process.c:1087
#24 0x7bc7f22c in call_thread_func () at signal_i386.c:2473
#25 0x7bc7f26a in call_thread_entry_point (entry=0x7b86000a
, arg=0x7ffdf000)
at signal_i386.c:2499
#26 0x7bc542cf in start_process (kernel_start=0x7b86000a) at loader.c:2612
#27 0xf75c0b95 in wine_call_on_stack () at port.c:60
#28 0xf75c0b73 in wine_switch_to_stack (func=0x7bc542a9
, arg=0x7b86000a,
stack=0x34) at port.c:59

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

[Michael Mc Donnell]

On Fri, Jul 1, 2011 at 7:22 AM, Dylan Smith  wrote:
> On Thu, Jun 30, 2011 at 3:50 PM, Michael Mc Donnell
>  wrote:
>> I've implemented the look-up scheme that you described.
>
>> +    if (!point_reps) /* Indentity point reps */
>> +    {
>> +        memset(adjacency, -1, 3 * num_faces * sizeof(*adjacency));
>> +        return D3D_OK;
>> +    }
>
> I think you are missing the most common cases, where vertices are
> reused between triangles. For example:
>
> 0--1
> | /|
> |/ |
> 2--3
>
> If identity point reps are passed to your function it will find the
> adjacent edge, but if NULL is passed to the function for point reps,
> then it will find no adjacencies even though semantically they should
> be the same.

Ok, I've added that example to the test and fixed the implementation.

> Also, note the spelling error: Indentity -> Identity

Check :-)

>> +static void free_edge_face_map(struct edge_face_map *edge_face_map)
>> +{
>> +    if (!edge_face_map)
>> +        return;
>> +
>> +    HeapFree(GetProcessHeap(), 0, edge_face_map->lists);
>> +    HeapFree(GetProcessHeap(), 0, edge_face_map->entries);
>> +}
> ...
>>  static HRESULT WINAPI ID3DXMeshImpl_ConvertPointRepsToAdjacency(ID3DXMesh 
>> *iface, CONST DWORD *point_reps, DWORD *adjacency)
>>  {
>> +    struct edge_face_map *edge_face_map = NULL;
> ...
>> +    free_edge_face_map(edge_face_map);
>> +    iface->lpVtbl->UnlockIndexBuffer(iface);
>> +    return hr;
>>  }
>
> edge_face_map isn't freed. Also, it doesn't need to be allocated on the heap.

Ok, I've moved it to the stack.

>> +    hr = iface->lpVtbl->LockIndexBuffer(iface, 0, &ib_ptr);
>
> The LockIndexBuffer flags could be D3DLOCK_READONLY rather than 0
> (which seems to have read-write semantics).

Fixed.

Thank you for the good review.
From 7fda9efa017444a9c47071afec1c95b9ed6dbb79 Mon Sep 17 00:00:00 2001
From: Michael Mc Donnell 
Date: Thu, 23 Jun 2011 17:46:51 +0200
Subject: d3dx9/test: Implemented ConvertPointRepsToAdjacency test.

Added shared vertices test.
---
 dlls/d3dx9_36/tests/mesh.c |  548 
 1 files changed, 548 insertions(+), 0 deletions(-)

diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c
index 98d77d9..e7cb404 100644
--- a/dlls/d3dx9_36/tests/mesh.c
+++ b/dlls/d3dx9_36/tests/mesh.c
@@ -4904,6 +4904,553 @@ static void test_create_skin_info(void)
 ok(hr == D3DERR_INVALIDCALL, "Expected D3DERR_INVALIDCALL, got %#x\n", hr);
 }
 
+static void test_convert_point_reps_to_adjacency(void)
+{
+HRESULT hr;
+struct test_context *test_context = NULL;
+const DWORD options = D3DXMESH_32BIT | D3DXMESH_SYSTEMMEM;
+const DWORD options_16bit = D3DXMESH_SYSTEMMEM;
+const D3DVERTEXELEMENT9 declaration[] =
+{
+{0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0},
+{0, 12, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0},
+{0, 24, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0},
+D3DDECL_END()
+};
+const unsigned int VERTS_PER_FACE = 3;
+void *vertex_buffer;
+void *index_buffer;
+DWORD *attributes_buffer;
+int i, j;
+enum color { RED = 0x, GREEN = 0xff00ff00, BLUE = 0xffff};
+struct vertex_pnc
+{
+D3DXVECTOR3 position;
+D3DXVECTOR3 normal;
+enum color color; /* In case of manual visual inspection */
+};
+D3DXVECTOR3 up = {0.0f, 0.0f, 1.0f};
+/* mesh0 (one face)
+ *
+ * 0--1
+ * | /
+ * |/
+ * 2
+ */
+const struct vertex_pnc vertices0[] =
+{
+{{ 0.0f,  3.0f,  0.f}, up, RED},
+{{ 2.0f,  3.0f,  0.f}, up, GREEN},
+{{ 0.0f,  0.0f,  0.f}, up, BLUE},
+};
+const DWORD indices0[] = {0, 1, 2};
+const unsigned int num_vertices0 = ARRAY_SIZE(vertices0);
+const unsigned int num_faces0 = num_vertices0 / VERTS_PER_FACE;
+const DWORD exp_adjacency0[] = {-1, -1, -1};
+const DWORD exp_id_adjacency0[] = {-1, -1, -1};
+const DWORD point_rep0[] = {0, 1, 2};
+/* mesh1 (right)
+ *
+ * 0--1 3
+ * | / /|
+ * |/ / |
+ * 2 5--4
+ */
+const struct vertex_pnc vertices1[] =
+{
+{{ 0.0f,  3.0f,  0.f}, up, RED},
+{{ 2.0f,  3.0f,  0.f}, up, GREEN},
+{{ 0.0f,  0.0f,  0.f}, up, BLUE},
+
+{{ 3.0f,  3.0f,  0.f}, up, GREEN},
+{{ 3.0f,  0.0f,  0.f}, up, RED},
+{{ 1.0f,  0.0f,  0.f}, up, BLUE},
+};
+const DWORD indices1[] = {0, 1, 2, 3, 4, 5};
+const unsigned int num_vertices1 = ARRAY_SIZE(vertices1);
+const unsigned int num_faces1 = num_vertices1 / VERTS_PER_FACE;
+const DWORD exp_adjacency1[] = {-1, 1, -1, -1, -1, 0};
+const DWORD exp_id_adjacency1[] = {-1, -1, -1, -1, -1, -1};
+const DWORD point_rep1[] = {0, 1, 2, 1, 4, 2};
+/* mesh2 (left)
+ *
+ *3 0--1
+ *   /| | /
+ *  / | |/
+ * 5--4 2
+ */
+const struct vertex_pnc vertices2[] =
+{
+{{ 

Re: Glitch-free iTunes?

[Damjan Jovanovic]

On Sun, Jul 3, 2011 at 4:49 AM, Keith Curtis  wrote:
>
>> So: yeah, we know it's an important app.  But it's hard.
>> Feel free to help out.
>> - Dan
>
> Hi;
>
> I am glad to hear you say that iTunes is an "important" app, but I don't
> understand what you mean because it has never worked.
>
> You don't need my help. You've got a big group making many good fixes. It is
> just that priority is being ignored or something. Failure is not from lack
> of effort, but from planning.

Hi Keith

Having worked at Microsoft, you of all people should appreciate the
size and complexity of the driver architecture on Windows. So I would
say that "failure" is mostly from the scale of the problem to be
solved.

My attempts at adding USB support to Wine have been painful and slow.
In 2006 my first patches ever submitted to Wine dealt with some
SETUPAPI.DLL bugs. By around 2007 hacks I made to Wine and the Linux
kernel to emulate USBSCAN.SYS allowed my Windows-only user-space USB
scanner driver to work in Ubuntu 6.06. Some of those hacks were
eventually cleaned up and made their way into Wine's STI.DLL in 2009,
but my kernel patch never worked on any other kernel version, and I
doubt either Wine or the Linux kernel would accept the dodgy code I
had to use. I began investigating the option of implementing USBSCAN
in a user-space driver with something like CUSE, but then Wine got a
rudimentary NTOSKRNL.EXE and the ability to load Windows SYS files.
Since then the idea was to implement everything in Wine, and use
libusb for USB I/O.

In 2010 I added some USBD.SYS functions and some USB headers to Wine.
Later I tried to add libusb support, USB device monitoring, and basic
on-demand driver loading infrastructure, but none of that was accepted
into Wine for various reasons. Currently I am trying to gradually
generalize driver loading in Wine. Then I hope to add loading drivers
as USB devices are plugged in. Then add libusb support. Then actually
add basic USB I/O. Then get ReadFile/WriteFile working for drivers.
And even then, there's still higher-level drivers to write (eg.
USBSCAN.SYS), and many SETUPAPI.DLL bugs and features like support for
class installers that have to be added before drivers will even
install properly. And then we hope they don't start using too many of
the unimplemented functions in NTOSKRNL.EXE.

So it's slow going and there's a lot to do, and few Wine developers
seem to care. One can only hope that when some devices start working,
it will generate new interest in Wine (and Linux), and Wine will get
many more patches :-).

> Let's win!
>
> -Keith
> http://keithcu.com/
>
>
>
>
>

Damjan

Re: kernel32/tests: remove a few CloseHandle calls on a HMODULE that don't make any sense

[Marvin]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=12163

Your paranoid android.


=== WNT4WSSP6 (32 bit module) ===
module.c:356: Test failed: Expected ERROR_FILE_NOT_FOUND, got 1006

Re: Updated Clang static analysis results / Valgrind update

[Frédéric Delanoy]

On Sun, Jul 3, 2011 at 04:15, Austin English  wrote:
> Web space usage was getting a bit high, so I've uploaded a tarball to
> a file download service:
> http://www.sendspace.com/file/5hot36
>
> austin@aw21 ~ $ sha1sum scan-build-2011-07-02.tar.bz2
> ac3cb3920ef97641fff1f5376f8136cef01f15bf  scan-build-2011-07-02.tar.bz2

FWIW, you could use xz instead of bzip2 to further reduce the download
size (54 MiB)
I got the size down to 46 MiB using default settings, and 25 MiB using
max compression (xz -9)

Frédéric