- wine-devel - winehq.org

Re: [PATCH 5/6] wined3d: Use PBOs for dynamic volumes
by Henri Verbeet 23 Aug '13

23 Aug '13

On 22 August 2013 23:22, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -145,6 +158,9 @@ static DWORD volume_access_from_location(DWORD location) > case WINED3D_LOCATION_TEXTURE_RGB: > return WINED3D_RESOURCE_ACCESS_GPU; > > + case WINED3D_LOCATION_BUFFER: > + return WINED3D_RESOURCE_ACCESS_CPU | WINED3D_RESOURCE_ACCESS_GPU; > + Why does loading into a PBO require CPU access? > + case WINED3D_LOCATION_BUFFER: > + if (!volume->pbo || !(volume->flags & WINED3D_VFLAG_PBO)) > + { > + ERR("Trying to load WINED3D_LOCATION_BUFFER without setting it up first.\n"); > + return; > + } I think there should never be a PBO without WINED3D_VFLAG_PBO being set. There's also something to be said for leaving out the return, since that would at least in theory allow the compiler to drop the extra checks when compiled without debug messages. That probably applies to ERRs in general, since they're either never supposed to happen, or not supposed to be an ERR. > +/* Context activation is done by the caller. */ > +static void wined3d_volume_prepare_pbo(struct wined3d_volume *volume, struct wined3d_context *context) > +{ > + const struct wined3d_gl_info *gl_info = context->gl_info; > + > + if (volume->pbo) > + return; > + > + GL_EXTCALL(glGenBuffersARB(1, &volume->pbo)); > + checkGLcall("glGenBuffersARB(1, &volume->pbo)"); > + GL_EXTCALL(glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, volume->pbo)); > + checkGLcall("glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, volume->pbo)"); > + GL_EXTCALL(glBufferDataARB(GL_PIXEL_UNPACK_BUFFER_ARB, volume->resource.size, NULL, GL_STREAM_DRAW_ARB)); > + checkGLcall("glBufferDataARB(GL_PIXEL_UNPACK_BUFFER_ARB, volume->resource.size, NULL, GL_STREAM_DRAW_ARB"); > + GL_EXTCALL(glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, 0)); > + checkGLcall("glBindBufferARB(GL_PIXEL_UNPACK_BUFFER_ARB, 0)"); > + > + TRACE("Created PBO %u for volume %p.\n", volume->pbo, volume); > +} I think one checkGLcall() per function is enough in general. That's even more true these days with ARB_debug_output that will usually give more specific error messages than checkGLcall() anyway. Applies to a couple of other places as well.

2 5

Re: Permissions bug with Acrobat X Standard
by Alexey Loukianov 23 Aug '13

23 Aug '13

Neil, thanks for reporting. Could you please re-report this bug to a place where reports should be posted - i.e. to Wine's Bugzilla which could be found at http://bugs.winehq.com/ ? Thanks in advance. --- Best regards, Alexey Loukianov HPC support and maintenance engineer, RSC Technologies http://rscgroup.ru/en/

1 0

Re: comsvcs: Add dll comsvcs (try 3)
by Nikolay Sivov 23 Aug '13

23 Aug '13

On 8/23/2013 13:18, Alistair Leslie-Hughes wrote: > Hi, > Fix build issue > > +#include "rpcproxy.h" I don't think you need this. > +HINSTANCE COMSVCS_hInstance = NULL; This should be static (and without initializer after that).

1 0

Re: server: Store full sized completion information on the server side.
by Alexandre Julliard 23 Aug '13

23 Aug '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -152,7 +152,7 @@ struct completion *get_completion_obj( struct process *process, obj_handle_t han > } > > void add_completion( struct completion *completion, apc_param_t ckey, apc_param_t cvalue, > - unsigned int status, unsigned int information ) > + apc_param_t information, unsigned int status ) There's no reason to change the parameter order. That's only adding noise to the patch, and potential bugs. -- Alexandre Julliard julliard(a)winehq.org

1 0

Request to delete some attachments
by Ken Sharp 22 Aug '13

22 Aug '13

Could a Bugzilla admin please delete the attachments in http://bugs.winehq.org/show_bug.cgi?id=24867 ? I don't know if metatester.exe can be freely distributed.

2 1

Re: wined3d: Recognize Nvidia GeForce GTX 770
by Henri Verbeet 22 Aug '13

22 Aug '13

On 22 August 2013 03:31, Gediminas Jakutis <gediminas(a)varciai.lt> wrote: > + {"GTX 770", CARD_NVIDIA_GEFORCE_GTX770}, /* Geforce 700 - highend */ > {"GTX 770M", CARD_NVIDIA_GEFORCE_GTX770M}, /* Geforce 700 - midend high mobile */ That doesn't work, it will always match "GTX 770" now, and never "GTX 770M".

1 0

Re: [PATCH] winemac.drv: Support the public UTF-16 type for Unicode text. (try 2)
by Ken Thomases 22 Aug '13

22 Aug '13

On Aug 22, 2013, at 12:07 AM, Charles Davis wrote: > Try 2: Eliminiate dead store. Sort export functions by name. Looks OK to me. -Ken

1 0

Permissions bug with Acrobat X Standard
by Neil Hellfeldt 22 Aug '13

22 Aug '13

err:msi:cabinet_copy_file failed to create L"C:\\users\\Public\\Application Data\\Adobe\\Adobe PDF\\Settings\\Standard.joboptions" (error 3) err:msi:extract_cabinet FDICopy failed err:msi:ACTION_InstallFiles Failed to extract cabinet: L"Data1.cab" err:msi:ITERATE_Actions Execution halted, action L"InstallFiles" returned 1603 err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1603 Sysinfo: lubuntu 3.04 64bit WINEARCH=win32 When I go to the parent directory I find this location: ~/.local/share/wineprefixes/acrobatxstd/drive_c/users/Public/Application Data/Adobe drwxrwxr-x 3 hellfeldt hellfeldt 4.0K Aug 21 17:12 Acrobat/ dr-xr-xr-x 3 hellfeldt hellfeldt 4.0K Aug 21 17:12 Adobe PDF/ ~/.local/share/wineprefixes/acrobatxstd/drive_c/users/Public/Application Data/Adobe$ cd Adobe\ PDF/ ~/.local/share/wineprefixes/acrobatxstd/drive_c/users/Public/Application Data/Adobe/Adobe PDF$ mkdir Settings mkdir: cannot create directory ‘Settings’: Permission denied I tried changing the directory permissions and I tried creating the directory but acrobat delete the Adobe PDF directory and recreates it with the bad permissions again.

1 0

Re: [PATCH] winemac.drv: Support the public UTF-16 type for Unicode text.
by Ken Thomases 22 Aug '13

22 Aug '13

On Aug 21, 2013, at 9:42 PM, Charles Davis wrote: > @@ -90,6 +93,9 @@ static CFDataRef export_hdrop_to_filenames(HANDLE data); > static CFDataRef export_oemtext_to_utf8(HANDLE data); > static CFDataRef export_text_to_utf8(HANDLE data); > static CFDataRef export_unicodetext_to_utf8(HANDLE data); > +static CFDataRef export_oemtext_to_utf16(HANDLE data); > +static CFDataRef export_text_to_utf16(HANDLE data); > +static CFDataRef export_unicodetext_to_utf16(HANDLE data); Please keep the export_* functions sorted (although I'm fine with utf8 coming before utf16). This applies to the function definitions, too. (Yes, this is an exceedingly minor issue. Sorry.) > +static HANDLE import_utf16_to_unicodetext(CFDataRef data) > +{ > + const WCHAR *src; > + unsigned long data_len; > + unsigned long new_lines = 0; > + LPWSTR dst; > + unsigned long i, j; > + HANDLE unicode_handle = NULL; This is an unnecessary initialization / dead store, which is frowned upon. Thanks! -Ken

2 2

Re: [PATCH 6/6] wined3d: Implement basic volume location management (try 2)
by Henri Verbeet 22 Aug '13

22 Aug '13

On 22 August 2013 14:57, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (volume->locations & WINED3D_LOCATION_DISCARDED) > + { > + TRACE("Volume previously discarded, nothing to do.\n"); > + wined3d_volume_invalidate_location(volume, WINED3D_LOCATION_DISCARDED); > + } I don't think the location invalidation here is strictly required, although it probably doesn't hurt much in practice. (I.e., consider the sequence DISCARD, load SYSMEM, load TEXTURE_RGB. There's no real reason the RGB load needs to do an upload from SYSMEM in that case, although it's perhaps not something that's going to happen much in practice either way.) > + wined3d_volume_validate_location(volume, WINED3D_LOCATION_SYSMEM); You could probably just have a wined3d_volume_validate_location(volume, location); at the end of the function and return from the default case instead. That's not something I feel strongly about though.

2 1

Re: oleaut32/tests: Some tests for LoadRegTypeLib() with activated context
by Alexandre Julliard 22 Aug '13

22 Aug '13

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Some tests for LoadRegTypeLib() with activated context > > From 1ea3d8c82dd77ac14f2cdec748c0284032958b2f Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <nsivov(a)codeweavers.com> > Date: Wed, 21 Aug 2013 12:34:47 +0400 > Subject: [PATCH 5/6] Some tests for LoadRegTypeLib() with activated context It doesn't work here: ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so tmarshal.c && touch tmarshal.ok tmarshal.c:999: Test failed: LoadRegTypeLib failed with error 0x8002801d tmarshal.c:1232: Test failed: IKindaEnumWidget_Next failed with error 0x8007000e wine: Unhandled page fault on read access to 0x00000000 at address 0x68640714 (thread 003a), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 5/5] wined3d: Implement basic volume location management
by Henri Verbeet 22 Aug '13

22 Aug '13

On 22 August 2013 00:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +const char *wined3d_debug_location(DWORD location) > +{ > + char buf[238]; That number looks a bit arbitrary, although I suppose it's at least large enough. > + if (volume->resource.pool == WINED3D_POOL_SYSTEM_MEM > + || volume->resource.pool == WINED3D_POOL_SCRATCH) > + { > + if (location & ~WINED3D_LOCATION_SYSMEM) > + { > + ERR("Trying to load a sysmem or scratch volume into %s.\n", > + wined3d_debug_location(location)); > + return; > + } > + } In principle we have resource_access_from_location() and the access_flags field in struct wined3d_resource for this. It's only a warning in surface_load_location() because we load e.g. default pool surfaces into sysmem for CPU fallbacks, but that doesn't apply to volumes. The right way for surfaces would probably be to use a staging resource for CPU fallbacks instead, or something along those lines. > + if (count_bits(location) > 1) > + FIXME("Implement loading two locations with one call\n"); > + I don't think we really want that. > +static void wined3d_volume_update_location(struct wined3d_volume *volume, DWORD location, BOOL keep) > +{ > + if (keep) > + { > + TRACE("Volume %p, invalidating %s.\n", volume, > + wined3d_debug_location(volume->locations & ~location)); > + volume->locations = location; > + } > + else > + { > + TRACE("Volume %p, invalidating %s.\n", volume, wined3d_debug_location(location)); > + volume->locations &= ~location; > + } > +} I'm a bit unhappy with the "persistent" flag to surface_modify_location(), and this is essentially the same thing. I think it would be better to just have two separate functions, wined3d_volume_invalidate_location() and wined3d_volume_validate_location(). Perhaps wined3d_volume_update_location() can work too, but in that case I think it should take two location masks, one to set and one to clear.

2 8

Re: [4/4] oledb32: A basic test for IRowPosition_Initialize()
by Marvin 22 Aug '13

22 Aug '13

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=26813 Your paranoid android. === WINEBUILD (build) === Make failed

2 1

Re: gdi32: some fix of errors writing Arabic on entry boxs
by Yaron Shahrabani 22 Aug '13

22 Aug '13

Ahlan Ya Mas3ab! How can I test it with Hebrew? Yaron Shahrabani <Hebrew translator> On Wed, Aug 21, 2013 at 11:19 PM, مصعب الزعبي <moceap(a)hotmail.com> wrote: > Written By Aric Stewart , fix about 50 percent of Bug 33794 > > --- > dlls/gdi32/font.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > > >

1 0

Re: msvcrt: _[w]access_s returns an error code.
by Marvin 21 Aug '13

21 Aug '13

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=26809 Your paranoid android. === WXPX64 (32 bit msvcr90) === No test summary line found

1 0

RFC: winedev guide multimedia chapter patch
by Frédéric Delanoy 21 Aug '13

21 Aug '13

Hi guys, I've been updating the wine multimedia paths of the wine dev guide, but I'm not really familiar with that area of Wine, so could you please have a look at the attached patch to check if it seems correct? I checked the code a bit but I'm not sure how outdated the guide is. For easier "testing", just clone http://source.winehq.org/git/docs.git, apply the patch and run ./configure, then 'make winedev-guide.html' in the "en/" subdirectory. Thanks, Frédéric Delanoy

2 1

Re: [PATCH] winemac.drv: Use the public UTF-16 type for Unicode text.
by Ken Thomases 21 Aug '13

21 Aug '13

On Aug 20, 2013, at 10:49 PM, Charles Davis wrote: > In the Windows world, "Unicode" almost universally means "UTF-16". So, > use the well-known UTF-16 type instead of making up our own. > > I have to wonder if there was a good reason Ken didn't use this > initially. Please hold this patch while I review it. I think there is a good reason why I didn't use it, but I have to figure it out again. :-/ It has to do with a promised pasteboard type (what Microsoft calls delayed rendering) and the conversions to the other text types. I think we need to use a custom type to distinguish between being asked for promised data vs. being asked for a conversion. -Ken

2 2

Re: mscoree: Attempt to load the assembly from the application directory (try 2)
by Vincent Povirk 21 Aug '13

21 Aug '13

+ /* Assume the namespace is the Assembly name */ Uh, what? We should only be passing an assembly name to get_file_from_strongname, not the class name. You shouldn't even have access to the class name. I think what you're actually doing here is skipping the assembly name and using the assembly version, which won't work.

1 0

Re: wined3d: Add a function for allocating aligned resource, memory (try 3)
by Alexandre Julliard 21 Aug '13

21 Aug '13

Stefan Dösinger <stefan(a)codeweavers.com> writes: > This supersedes patch 98009. It renames the allocation and free > functions as suggested by Henri. It doesn't work: ../../../tools/runtest -q -P wine -M d3dx9_36.dll -T ../../.. -p d3dx9_36_test.exe.so texture.c && touch texture.ok texture.c:555: Tests skipped: No D3DUSAGE_AUTOGENMIPMAP support for volume textures wine: Unhandled page fault on write access to 0x00000000 at address 0x7bc4a5cf (thread 003c), starting debugger... Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x7bc4a5cf). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7bc4a5cf ESP:0032f79c EBP:0032f898 EFLAGS:00010202( R- -- I - - - ) EAX:00000000 EBX:7bcbc474 ECX:00164268 EDX:68d795a0 ESI:00110014 EDI:001642c8 Stack dump: 0x0032f79c: 7bc37d5d 00000050 00000002 00164278 0x0032f7ac: 00000000 00000000 00000000 00000000 0x0032f7bc: 687c05d8 00000001 00000000 00000000 0x0032f7cc: 4d430003 00000000 00000000 00000000 0x0032f7dc: 00000000 00000000 4d430001 00164268 0x0032f7ec: 00000010 00000000 00000000 00000000 Backtrace: =>0 0x7bc4a5cf HEAP_CreateFreeBlock+0x36f(subheap=0x110014, ptr=0x164268, size=0x60) [/home/julliard/wine/wine/dlls/ntdll/../../include/wine/list.h:101] in ntdll (0x0032f898) 1 0x7bc4a878 HEAP_MakeInUseBlockFree+0x157(subheap=0x110014, pArena=<is not available>) [/home/julliard/wine/wine/dlls/ntdll/heap.c:656] in ntdll (0x0032f938) 2 0x7bc4b8e2 RtlFreeHeap+0xd1(heap=<couldn't compute location>, flags=<couldn't compute location>, ptr=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/heap.c:1771] in ntdll (0x0032f9a8) 3 0x68e0642e wined3d_resource_free_sysmem+0x2d(mem=0x1642c0) [/home/julliard/wine/wine/dlls/wined3d/resource.c:361] in wined3d (0x0032f9d8) 4 0x68e06503 resource_cleanup+0xc2(resource=0x1651e0) [/home/julliard/wine/wine/dlls/wined3d/resource.c:168] in wined3d (0x0032fa28) 5 0x68e6e671 wined3d_volume_decref+0xb0(volume=<couldn't compute location>) [/home/julliard/wine/wine/dlls/wined3d/volume.c:142] in wined3d (0x0032fa68) 6 0x68e5eb42 texture3d_sub_resource_cleanup+0x31(sub_resource=0x1651e0) [/home/julliard/wine/wine/dlls/wined3d/texture.c:1125] in wined3d (0x0032fa98) 7 0x68e5ea8e wined3d_texture_cleanup+0x4d(texture=0x164c70) [/home/julliard/wine/wine/dlls/wined3d/texture.c:126] in wined3d (0x0032fae8) 8 0x68e5fba9 wined3d_texture_decref+0x48(texture=<couldn't compute location>) [/home/julliard/wine/wine/dlls/wined3d/texture.c:449] in wined3d (0x0032fb28) 9 0x68d6701b d3d9_texture_3d_Release+0x5a() in d3d9 (0x0032fb88) 10 0x686a82ea func_texture+0x24d9() [/home/julliard/wine/wine/dlls/d3dx9_36/tests/texture.c:1595] in d3dx9_36_test (0x0032fd38) 11 0x6862c3d7 main+0x386(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/d3dx9_36/tests/../../../include/wine/test.h:570] in d3dx9_36_test (0x0032fe08) 12 0x686adcc0 __wine_spec_exe_entry+0x7f(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in d3dx9_36_test (0x0032fe58) 13 0x7b85eb8c call_process_entry+0xb() in kernel32 (0x0032fe78) 14 0x7b85fd6b start_process+0x6a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1084] in kernel32 (0x0032feb8) 15 0x7bc7a170 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 16 0x7bc7d07d call_thread_func+0x7c(entry=0x7b85fd00, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2602] in ntdll (0x0032ffa8) 17 0x7bc7a14e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 18 0x7bc4fade start_process+0x1d(kernel_start=0x7b85fd00) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2694] in ntdll (0x0032ffe8) 19 0x680311ad wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 20 0x6803126b wine_switch_to_stack+0x2a(func=0x7bc4fac0, arg=0x7b85fd00, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xffd46e68) 21 0x7bc55617 LdrInitializeThunk+0x3a6(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2750] in ntdll (0xffd46ed8) 22 0x7b8662e0 __wine_kernel_init+0xbbf() [/home/julliard/wine/wine/dlls/kernel32/process.c:1256] in kernel32 (0xffd47de8) 23 0x7bc55ce3 __wine_process_init+0x182() [/home/julliard/wine/wine/dlls/ntdll/loader.c:2959] in ntdll (0xffd47e78) 24 0x6802edf2 wine_init+0x2a1(argc=0x3, argv=0xffd483b4, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:847] in libwine.so.1 (0xffd47ed8) 25 0x7bf00d3b main+0x7a(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:237] in <wine-loader> (0xffd48318) 26 0x682518c5 __libc_start_main+0xf4() in libc.so.6 (0x00000000) 0x7bc4a5cf HEAP_CreateFreeBlock+0x36f [/home/julliard/wine/wine/dlls/ntdll/../../include/wine/list.h:101] in ntdll: movl %edx,0x0(%eax) 101 elem->prev->next = elem->next; -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: ieframe: Use winehq snapshot instead of the main page in tests.
by Marvin 21 Aug '13

21 Aug '13

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=26794 Your paranoid android. === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2631: Test failed: expected GetOverridesKeyPath webbrowser.c:2636: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2637: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3079: Test failed: doc_disp == NULL webbrowser: unhandled exception c0000005 at 004033D1 === WXPPROSP2 (32 bit webbrowser) === webbrowser.c:792: Test failed: ReadyState = 1, expected 4

1 0

Re: [PATCH 2/2] msvcrt: Fix lookahead buffer usage on pipes (try2)
by Piotr Caban 21 Aug '13

21 Aug '13

Please ignore this patch, I'll send a better version.

1 0

Re: [5/6] ntdll: Make NtReadFile always initialize a being returned IO_STATUS_BLOCK for regular files.
by Alexandre Julliard 21 Aug '13

21 Aug '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -748,6 +748,11 @@ err: > } > else > { > + if (type == FD_TYPE_FILE) > + { > + io_status->u.Status = status; > + io_status->Information = total; > + } I don't see why this would have to be specific to files. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 2/2] msvcrt: Fix lookahead buffer usage on pipes
by Alexandre Julliard 21 Aug '13

21 Aug '13

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/msvcrt/file.c | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) It doesn't work: ../../../tools/runtest -q -P wine -M msvcrt.dll -T ../../.. -p msvcrt_test.exe.so file.c && touch file.ok file.c:2042: Test failed: read returned 2, expected 1 make[1]: *** [file.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [6/6] server: Store full sized completion information on the server side.
by Marvin 21 Aug '13

21 Aug '13

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=26791 Your paranoid android. === W2KPROSP4 (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === WXPPROSP2 (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === WXPX64 (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === W2K3R2SESP2 (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === W2K8SE (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === WXPX64 (64 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011

1 0

Re: [5/6] ntdll: Make NtReadFile always initialize a being returned IO_STATUS_BLOCK for regular files.
by Marvin 21 Aug '13

21 Aug '13

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=26790 Your paranoid android. === W2KPROSP4 (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === WXPPROSP2 (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === WXPX64 (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === W2K3R2SESP2 (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === W2K8SE (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === WXPX64 (64 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011

1 0

Re: [4/6] ntdll/tests: Mark the NtReadFile call which returns STATUS_SUCCESS for an overlapped IO call as broken, and don't
by Marvin 21 Aug '13

21 Aug '13

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=26789 Your paranoid android. === W2KPROSP4 (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === WXPPROSP2 (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === WXPX64 (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === W2K3R2SESP2 (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === W2K8SE (32 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011 === WXPX64 (64 bit file) === file.c:785: Test failed: expected STATUS_PENDING, got 0xc0000011

1 0

Re: oledb32: Add IDataSourceLocator support (try 6)
by Nikolay Sivov 21 Aug '13

21 Aug '13

On 8/21/2013 10:33, Alistair Leslie-Hughes wrote: > +typedef struct DataSourceImpl > +{ > + IDataSourceLocator IDataSourceLocator_iface; > + LONG ref; > + > +} DataSourceImpl; All good, except this one.

1 0

Re: [4/6] kernel32: Make serial tests self-contained.
by Saulius Krasuckas 21 Aug '13

21 Aug '13

* On Thu, 15 Aug 2013, Dmitry Timoshkov wrote: > dlls/kernel32/tests/comm.c | 284 ++++++++++++++++++++++++++------------------- > 1 file changed, 167 insertions(+), 117 deletions(-) ... > --- a/dlls/kernel32/tests/comm.c > +++ b/dlls/kernel32/tests/comm.c > @@ -1486,7 +1588,7 @@ static void test_WaitRing(HANDLE hcom) > success, err, evtmask, after-before, after1-before); > > ok(evtmask & EV_RING, "Failed to detect EV_RING: 0x%08x, expected 0x%08x\n", > - evtmask, EV_RING); > + evtmask, EV_CTS); Is everything OK with the constants here? S.

1 0

Re: oledb32: Add IDataSourceLocator support (try 5)
by Nikolay Sivov 21 Aug '13

21 Aug '13

On 8/21/2013 10:16, Alistair Leslie-Hughes wrote: > Hi, > Updated naming. You updated method names only, what's left : > +typedef struct DataSourceImpl > +HRESULT create_data_source(IUnknown *outer, void **obj) > +static const IDataSourceLocatorVtbl DataSourceVtbl = Also you most likely don't need these: > +#include "wine/unicode.h" > +#include "wine/list.h" > > > Changelog: > oledb32: Add IDataSourceLocator support > > > Best Regards > Alistair Leslie-Hughes > > >

1 0

Re: oledb32: Add IDataSourceLocator support (try 4)
by Nikolay Sivov 21 Aug '13

21 Aug '13

On 8/21/2013 09:15, Alistair Leslie-Hughes wrote: > Hi, > Use helper functions for memory > > > Changelog: > oledb32: Add IDataSourceLocator support > > > Best Regards > Alistair Leslie-Hughes It looks okay, but I suggest to fix a naming: > +typedef struct DataSourceImpl > +{ > + IDataSourceLocator IDataSourceLocator_iface; > + LONG ref; > + > +} DataSourceImpl; > +static HRESULT WINAPI datasource_QueryInterface(IDataSourceLocator *iface, REFIID riid, void **ppvoid) etc. IDataSource is another interface, and it's confusing to name locator after it - dslocator_* naming used in CF is short enough and descriptive to use it everywhere.

1 0

Willing to join Wine
by Priyank Bhatt 20 Aug '13

20 Aug '13

I want to work for Wine . I'm a third year undergraduate Student , I have done my elimentary course on machine learning algorithm . I am also familiar with C/C++ and some what of Python . Please suggest what all do I need to learn or read so as to start contributing to the open source community of mlpack. As an amateur and as per your free slots what project form the idea's page should I work on ?

2 1

Re: winmm: fix WOD_Open() WAVE_MAPPER no-device case.
by Andrew Eikum 20 Aug '13

20 Aug '13

On Tue, Aug 20, 2013 at 05:57:34AM +0200, Fabrice Bauzac wrote: > Hello, > > This patch intends to fix the bug: > http://bugs.winehq.org/show_bug.cgi?id=34305 > > The bug: basically, when there is no sound device and the user tries > to WOD_Open() the WAVE_MAPPER pseudodevice, the code calls read_map() > with device index 0 without first checking whether the number of > devices is greater than 0. > Looks good to me, thanks. I tested on Windows 7, and the error code is correct. By the way, the waveIn path (WID_Open) has the same bug. Feel free to fix that, too, if you want. Or I'll submit a patch myself later. Andrew

2 2

Re: [PATCH 2/4] oleaut32: Implement ICreateTypeInfo::SetTypeDescAlias
by Piotr Caban 20 Aug '13

20 Aug '13

On 08/20/13 16:57, Andrew Eikum wrote: > @@ -10530,8 +10541,28 @@ static HRESULT WINAPI ICreateTypeInfo2_fnSetTypeDescAlias(ICreateTypeInfo2 *ifac > + This->cbSizeInstance = VARIANT_DataSize(This->tdescAlias->vt, This->pTypeLib->ptr_size); > + if(!This->cbSizeInstance){ > + FIXME("Wrong size for variant type! 0x%x\n", This->tdescAlias->vt); > + This->cbSizeInstance = 4; > + } > + > + This->cbAlignment = 4; The This->cbAlignment should be also depending on alias type (e.g. it's 1 for VT_I1).

1 0

Re: Sort the AUTHORS file by their last names.
by Ken Sharp 20 Aug '13

20 Aug '13

On 16/08/13 14:46, Tae Wong wrote:> The AUTHORS file have all developers from the GIT log which were > sorted on their first names. > > This patch will switch the sort order from first to last names. This isn't how the AUTHORS file is generated. http://source.winehq.org/git/wine.git/commit/5da31c8817293ff98b4defceb962f7…

5 14

Re: [PATCH 1/5] wined3d: Add a function for allocating aligned resource memory (try 2)
by Henri Verbeet 20 Aug '13

20 Aug '13

On 20 August 2013 12:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +void *wined3d_alloc_resource_mem(SIZE_T size) > +{ > + void **p; > + SIZE_T align = RESOURCE_ALIGNMENT - 1 + sizeof(*p); > + void *mem; > + > + if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size + align))) > + return NULL; > + > + p = (void **)(((ULONG_PTR)mem + align) & ~(RESOURCE_ALIGNMENT - 1)) - 1; > + *p = mem; > + > + return ++p; > +} I think this should either be called wined3d_resource_allocate_sysmem() and live in resource.c, or accept any np2 alignment and be called something along the lines of wined3d_memalign(). The former probably makes the most sense at this point. Somewhat related, I don't think there's really a reason to have both "allocatedMemory" and "heap_memory" anymore. It should probably just be called "sysmem". That's a cleanup that doesn't necessarily belong in this patch though.

2 2

Re: kernel32: Fix required buffer length for locale values from registry
by Alexandre Julliard 20 Aug '13

20 Aug '13

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > http://bugs.winehq.org/show_bug.cgi?id=32169 > > Locale info to override is stored as REG_SZ and supposed to be > null-terminated, They are supposed to, but it's not guaranteed. The code should be able to cope with non-terminated strings. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oledb32: Implement IErrorRecord AddErrorRecord
by Nikolay Sivov 20 Aug '13

20 Aug '13

On 8/20/2013 13:21, Alistair Leslie-Hughes wrote: > Hi, > Yes we do just take the pointer (pErrorInfo) passed in. MSDN states > that the caller responsible for this memory. It means caller could free it at any time (or it could be a stack variable), so you have to make a deep copy. > > > Changelog: > oledb32: Implement IErrorRecord AddErrorRecord > > > Best Regards > Alistair Leslie-Hughes > >

2 1

Re: riched20: Use \ulnone instead of \ul0 for no underline.
by Huw Davies 20 Aug '13

20 Aug '13

On Mon, Aug 19, 2013 at 05:38:13PM -0500, Vincent Povirk wrote: > Testing on Windows (by saving rtf documents with wordpad and viewing > them with notepad) shows that it uses \ulnone instead of \ul0 to end > underline. Wine and Windows are both able to read either one. I think these are symonyms and indeed Windows seems to use \ulnone, so this looks good to me. Huw.

1 0

Re: Could you update/rerun that report on bugs without AppDB links?
by Dan Kegel 19 Aug '13

19 Aug '13

I don't seem to have saved the (crappy) script. There is something similar at https://code.google.com/p/winezeug/source/browse/#svn%2Ftrunk%2Fappdb-mashup and it wouldn't be too hard to whip something up again for somebody who is motivated. Please do throttle the scraping script to avoid overloading the databases if you try. On Sun, Aug 18, 2013 at 12:11 PM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > Dan, > > I don't know if you've been following the "PLEASE add bug links!" thread on wine-devel, so I figured I'd just contact you directly. Do you remember that report on unlinked bugs you ran about 5 years ago? http://kegel.com/wine/unlinked.html > > Could you update/run it again against current bugzilla? If we post a link to the results on the forum, we could ask users to help clear the backlog. > > -- > Rosanne DiMesio <dimesio(a)earthlink.net>

2 1

Re: [website] Added templates/zh-cn/cvs.template translation
by Hin-Tak Leung 19 Aug '13

19 Aug '13

------------------------------ On Sat, Aug 17, 2013 09:02 BST Frédéric Delanoy wrote: >On Sat, Aug 17, 2013 at 5:57 AM, xulixin <xulixin1990(a)gmail.com> wrote: >> Should I change my name's spelling to Lixin Xu, or LiXin Xu, or other >> format? > >Not sure, most people (at least non-Chinese) use firstname lastname >convention, but I guess you should use the same convention as other >Chinese-speaking committers. > >Here's a list I extracted from AUTHORS file that *look* Chinese to me >(don't know if they're really Chinese, or Korean, or from another >Asian country): >Chae Jong Bin >Cheer Xiao >Chia-I Wu >Hwang YunSong (황윤성) >Jau-Horng Chen >Jay Yang >Qian Hong >Qingchuan Wang >Qingdoa Daoo >Shi Quan He >Wei-Lun Chao >Weisheng Li >Xiang Li >XueFeng Chang >Yong Chi >Yuxi Zhang >Zhangrong Huang >Zhan Jianyu > >Hope this helps, > >Frédéric Delanoy Many had replied but few had touched the _main_ issue: it is a matter of policy that patches of an anonymous origin to Wine are categorically rejected. The Linux kernel also has a similar policy. This policy is due to past threats of copyright/intellectual-property infringements and possible cause of contamination from people who may have privileged access to proprietary technology. So a "real name" is needed for any patches. As already discussed, "xulixin" is a real name - as it appears on official documents, passports, etc. Although for the benefit of Western custom, "Xu Li-Xin", or "Xu Lixin", or "Lixin Xu" or "Li-Xin Xu" might make it more obvious, and make some people happier. Ultimately it is Alexandre's call, what is considered a real name. Anyway, the git command to set a default user name for generating patches is, e.g. for mine: git config --global user.name "Hin-Tak Leung" (this writes to ~/.gitconfig, which is a text files that one can edit by hand as well). See "man git-config" for details. Without --global, these config's are set per repository. e.g. you may use different names and e-mail addresses for internal (job-wise) work and external (open) work. I also have a few other global configs of my own; the equivalent of these two are probably useful to most people: git config --global ui.color true and git config --global core.editor emacs (the former sets colorization on for "git log", "git diff", etc; I find it useful of having diff's colorized - that assumes that you do all your development work on a terminal that's color-capable (most recent linux consoles/terminals are); the latter sets the default editor to emacs, when composing commit messages. You may want to set it to your favorite editor, whichever that is.).

1 0

Re: [PATCH 2/5] wined3d: Wrap resource->heapMemory into a structure
by Henri Verbeet 19 Aug '13

19 Aug '13

On 19 August 2013 10:52, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +struct wined3d_heap_memory *wined3d_alloc_resource_mem(UINT size) > +{ > + struct wined3d_heap_memory *ret; > + > + ret = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*ret)); > + if (!ret) > + return NULL; > + > + ret->alloc_ptr = HeapAlloc(GetProcessHeap(), 0, size + RESOURCE_ALIGNMENT); > + if (!ret->alloc_ptr) > + { > + HeapFree(GetProcessHeap(), 0, ret); > + return NULL; > + } > + ret->ptr = (BYTE *)(((ULONG_PTR)ret->alloc_ptr > + + (RESOURCE_ALIGNMENT - 1)) & ~(RESOURCE_ALIGNMENT - 1)); > + return ret; > +} > + I don't think this is a good idea. How about something like the following? The corresponding free function would be trivial. void *wined3d_memalign(SIZE_T alignment, SIZE_T size) { SIZE_T align; void *mem; void **p; align = max(sizeof(*p), alignment - 1); if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size + align))) return NULL; p = (void **)(((ULONG_PTR)mem + align) & ~(alignment - 1)) - 1; *p = mem; return ++p; } (Untested, there's probably some room for improvement.)

3 6

Re: [PATCH 10/11] widl: Set pointer_size according to host's pointer-size.
by Alexandre Julliard 19 Aug '13

19 Aug '13

Kai Tietz <ktietz70(a)googlemail.com> writes: > diff --git a/tools/widl/widl.c b/tools/widl/widl.c > index 5df99fc..6d8ec87 100644 > --- a/tools/widl/widl.c > +++ b/tools/widl/widl.c > @@ -139,7 +139,7 @@ int line_number = 1; > > static FILE *idfile; > > -unsigned int pointer_size = 0; > +unsigned int pointer_size = sizeof(void*); > syskind_t typelib_kind = sizeof(void*) == 8 ? SYS_WIN64 : SYS_WIN32; This is wrong, the host pointer size shouldn't have any influence on the generated code. -- Alexandre Julliard julliard(a)winehq.org

2 3

re: open bugs / multi thread / recommendation on new system
by Dan Kegel 19 Aug '13

19 Aug '13

Damian wrote: > 1) ATI or nVidia for new GPU? Does SLI/Crossfire work with wine? Don't know. I just use nvidia cards I find in the trash :-) But then I don't actually play games, so I don't care about 3d performance. > 2) FX 8320 or intel same price class CPU? As the AMD has far inferior > single thread performance but far superior multi thread performance - > does wine run a win32 single thread app as multi thread? does wine > make use of multithread in general? For what it's worth, when I was paying attention to such things, the command for cpu in `seq 0 3` do; sudo cpufreq-set -g performance -c $cpu; done is needed to get reasonable performance on my A8, see http://comments.gmane.org/gmane.comp.emulators.wine.devel/86659 Perhaps this also applies to more capable amd chips and current linux. wine just maps threads one to one, there is no magic. If the game uses multiple threads, then wine uses multiple threads. Rather than ask abstract questions here, you should probably go ask for framerates on specific games on the wine forum.

1 0

Re: msxml3: Defer the conversion of XPath expressions to UTF-8. (try 4)
by Alexandre Julliard 19 Aug '13

19 Aug '13

John Chadwick <johnwchadwick(a)gmail.com> writes: > This patch was posted a bit ago without any objections, but seemingly > slipped through the cracks. Very slight revisions were made since try > 3 to improve the conciseness of code. > > From 8157b8a3d347c47f7f21e74d621632b4a9f50fd6 Mon Sep 17 00:00:00 2001 > From: John Chadwick <johnwchadwick(a)gmail.com> > Date: Sun, 21 Jul 2013 14:41:37 -0400 > Subject: msxml3: Defer the conversion of XPath expressions to UTF-8. > > This patch changes the create_selection interface to accept a wide string > instead of an xmlChar string. This is a transitional change, which will be > needed as libxml2's XPath parser is phased out. > > The implementation of tagName_to_XPath also had to be changed as it was using > libxml2's UTF-8 string API. libxml2 contained a strcat that performed > reallocation, so it was replaced with a new function that does the same with > heap_realloc and wide strings (heap_strcatW in msxml_private.h.) That's a very inefficient way to build a string. Adding this as a helper is even worse since it will encourage other places to use it too. Please try to allocate a large enough buffer from the start, or if not possible grow it quadratically. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] wined3d: Store the mipmap level in the volume
by Henri Verbeet 19 Aug '13

19 Aug '13

On 19 August 2013 10:52, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +void wined3d_volume_set_texture_level(struct wined3d_volume *volume, GLint level) > +{ > + volume->texture_level = level; > +} > I think that's a step in the wrong direction. I think this should be set on volume creation. We do have a construction like this for surfaces, but the reasons for that don't apply to volumes, and I'd like to get rid of it for surfaces as well if at all possible.

2 2

Re: [PATCH 3/5] wined3d: Properly allocate heap memory for volumes
by Henri Verbeet 19 Aug '13

19 Aug '13

On 19 August 2013 10:52, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -184,7 +184,16 @@ HRESULT CDECL wined3d_volume_map(struct wined3d_volume *volume, > volume, map_desc, box, flags); > > if (!volume->resource.allocatedMemory) > - volume->resource.allocatedMemory = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, volume->resource.size); Can this ever happen?

2 1

Re: [PATCH 4/5] wined3d: Move volume booleans into a flags field
by Henri Verbeet 19 Aug '13

19 Aug '13

On 19 August 2013 10:52, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + volume->flags |= WINED3D_VFLAG_LOCKABLE; /* FIXME */ You'll probably want to fix that :-) I think you can just leave the flag out until you rename it to WINED3D_VFLAG_MAPPABLE in one of the later patches.

1 0

Re: [PATCH 1/5] wined3d: Keep GL_UNPACK_CLIENT_STORAGE_APPLE off by default
by Stefan Dösinger 19 Aug '13

19 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henri, Matteo, When reviewing those patches, please have a look at the attached archive. It contains the rest of the volume cleanup patches and some tests. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSEd58AAoJEN0/YqbEcdMwGygP/3UsMheQPv6ZmMMGdX+QXltj 0LfSKw7wJiNFFc2+rR/NAP8s1+iGtXKvABLvTINv5ZXwngPxUc10g/5MveV1MRzQ lgU2ebRjFnFFCv0ytcSeb5dutH5EMnIplxYQEDvPR+ojkjwS5bvRENtdh4/BZPGc gh0KoKk4YwsBl3GyWwM6hM8NlEFrwvtWeEU3UdXzZiIYg3WfT5CaXGR3A4o4/G+i WBYar5nGocKHs+5Wgfe4BMC4XNuFD/RFT9R7gB7nrIYQgPJ6j+J46Zkt4ux0ivtH eBHQ5QQNB4SdVoCwPf9H56cBYhtmC6iEFYJg4wEGukZPIhaZ0Je2KHUIXuXumVfB ciesPUN+7DhuZCLSFm5eJUO7aTF+WHOD+uyQKZkLN1oK3JkXy2wflE2d8O2BQKTo qCZPtcA8vmE0DIvk9Q6j8Xt2nAmTnnqIh26ZCsCsj9vZvPn+pNlXT1lduwoF3x2H oKZufHdCdgRKLmRLpVnmPdwKTqwmlSZa9u1RVhDAypLVv20VqykOLAh6mDJC9zl7 k/2ozgsfYsl0kYMTVw5o6dx3f3pJGfgGjsw4vuJHN08aeZmVl1EFY8nMlqzrT8Wa cRjSHKxqk+W3BxTsQz9Zi1u0J3v8nE4KM79IpLgfjm8M9Rk6eTaLkwCe5XpFuiSw MJbpYdZZGZfZuP71LMmm =gRPu -----END PGP SIGNATURE-----

1 0

Re: [website] Added templates/zh-cn/cvs.template translation
by Frédéric Delanoy 19 Aug '13

19 Aug '13

On Sat, Aug 17, 2013 at 5:57 AM, xulixin <xulixin1990(a)gmail.com> wrote: > Should I change my name's spelling to Lixin Xu, or LiXin Xu, or other > format? Not sure, most people (at least non-Chinese) use firstname lastname convention, but I guess you should use the same convention as other Chinese-speaking committers. Here's a list I extracted from AUTHORS file that *look* Chinese to me (don't know if they're really Chinese, or Korean, or from another Asian country): Chae Jong Bin Cheer Xiao Chia-I Wu Hwang YunSong (황윤성) Jau-Horng Chen Jay Yang Qian Hong Qingchuan Wang Qingdoa Daoo Shi Quan He Wei-Lun Chao Weisheng Li Xiang Li XueFeng Chang Yong Chi Yuxi Zhang Zhangrong Huang Zhan Jianyu Hope this helps, Frédéric Delanoy

2 2

PLEASE add bug links!
by Ken Sharp 18 Aug '13

18 Aug '13

There's little point in my continually asking users to add bug links to the AppDB if maintainers and/or administrators don't bother themselves. It takes longer to create a bug report than it does to link it to the database. It really isn't that hard. I've added hundreds over the past few weeks and this is not the first time I have said it, nor am I the first one to do so. It's even on the Wiki. http://wiki.winehq.org/Bugs

8 20

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