May 2011 - Wine-Devel - list.winehq.org

Re: [PATCH] msi: Fixed check_flag_combo macro (Coverity)

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > The macro was always FALSE, as > x & y == ~y > is always FALSE. x& y == y was clearly intended. > CID 1448 It doesn't work here: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so action.c && touch action.ok action.c:5578: Test failed: Expected ERROR_SUCCESS, got 1627 action.c:5587: Test failed: Expected ERROR_FILE_NOT_FOUND, got 0 action.c:5599: Test failed: Expected ERROR_FILE_NOT_FOUND, got 0 action.c:5656: Test failed: key not created action.c:5660: Test failed: key not created action.c:5664: Test failed: key not created make: *** [action.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

May 9, 2011

Re: [2/2] urlmon: Honor E_ABORT for URLDownloadToFile status callbacks

by Alexandre Julliard

Thomas Mullaly <thomas.mullaly(a)gmail.com> writes: > --- > dlls/urlmon/download.c | 27 +++++++++++++++-- > dlls/urlmon/tests/url.c | 74 ++++++++++++++++++++++++++++++++++++++++++++-- > 2 files changed, 94 insertions(+), 7 deletions(-) > From de69f682d1b11c3b23969ad02756162232ea9403 Mon Sep 17 00:00:00 2001 > From: Thomas Mullaly <tmullaly(a)codeweavers.com> > Date: Sun, 1 May 2011 00:30:17 -0400 > Subject: urlmon: Honor E_ABORT for URLDownloadToFile status callbacks It doesn't work here: ../../../tools/runtest -q -P wine -M qmgr.dll -T ../../.. -p qmgr_test.exe.so job.c && touch job.ok job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 etc. -- Alexandre Julliard julliard(a)winehq.org

May 9, 2011

Re: [PATCH 9/9] mmdevapi/tests: Add tests for volume control interfaces

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > --- > dlls/mmdevapi/tests/capture.c | 389 > ++++++++++++++++++++++++++++++++++++++ > dlls/mmdevapi/tests/render.c | 414 > +++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 803 insertions(+), 0 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M mmdevapi.dll -T ../../.. -p mmdevapi_test.exe.so capture.c && touch capture.ok capture.c:648: Test failed: Activation failed with 80004005 wine: Unhandled page fault on read access to 0x00000000 at address 0x68677fb5 (thread 0033), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x68677fb5). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68677fb5 ESP:0032fc30 EBP:0032fd38 EFLAGS:00010206( R- -- I - -P- ) EAX:00000000 EBX:6868915c ECX:0032fbe0 EDX:0032fce4 ESI:6868399a EDI:0032fcf8 Stack dump: 0x0032fc30: 00000000 686839a4 80004005 00000000 0x0032fc40: 0032fd14 00000000 00000000 00124b60 0x0032fc50: 0032fce4 7bc9ed90 0032fc78 7bc68211 0x0032fc60: 3d4ccccd 00000040 0032fca8 80004005 0x0032fc70: 9999999a 3fd99999 00000001 0032fce4 0x0032fc80: 3d4ccccd 00000017 00000000 7ffdf044 Backtrace: =>0 0x68677fb5 func_capture+0x8a5() [/home/julliard/wine/wine/dlls/mmdevapi/tests/capture.c:650] in mmdevapi_test (0x0032fd38) 1 0x6868287e run_test+0x14d(name="capture.c") [/home/julliard/wine/wine/dlls/mmdevapi/tests/../../../include/wine/test.h:556] in mmdevapi_test (0x0032fd88) 2 0x68683347 main+0x156(argc=0, argv=0x68677fb5) [/home/julliard/wine/wine/dlls/mmdevapi/tests/../../../include/wine/test.h:624] in mmdevapi_test (0x0032fe48) 3 0x6868351c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in mmdevapi_test (0x0032fe90) 4 0x7b8596cc call_process_entry+0xb() in kernel32 (0x0032fea8) 5 0x7b85a2ff start_process+0x5e(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1086] in kernel32 (0x0032fee8) 6 0x7bc73808 call_thread_func+0xb() in ntdll (0x0032fef8) 7 0x7bc76f6e call_thread_entry_point+0x6d(entry=0x7b85a2a0, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffc8) 8 0x7bc4c15e start_process+0x1d(kernel_start=0x7b85a2a0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) 9 0x6802998d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 0x68677fb5 func_capture+0x8a5 [/home/julliard/wine/wine/dlls/mmdevapi/tests/capture.c:650] in mmdevapi_test: movl 0x0(%eax),%ecx 650 hr = IAudioClient_Initialize(ac2, AUDCLNT_SHAREMODE_SHARED, -- Alexandre Julliard julliard(a)winehq.org

May 9, 2011

Re: Assorted spelling and case fixes.

by 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=10800 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

May 9, 2011

Re: winspool.drv: Add stubs for IsValidDevmodeW and IsValidDevmodeA.

by 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=10796 Your paranoid android. === WINEBUILD (build) === Can't determine base name

May 9, 2011

Re: ddraw: Add tests for SetCooperativeLevel

by 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=10792 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

May 8, 2011

Re: [4/5] d3dx9: Implement D3DXMESHOPT_ATTRSORT vertex reordering.

by Matteo Bruni

2011/5/8 Dylan Smith <dylan.ah.smith(a)gmail.com>: > On Sun, May 8, 2011 at 3:18 PM, Matteo Bruni <matteo.mystral(a)gmail.com> > wrote: >> >> 2011/5/6 Dylan Smith <dylan.ah.smith(a)gmail.com>: >> > +struct vertex_attrib_duplication { >> > + DWORD attrib; >> > + DWORD vertex_index; >> > + struct vertex_attrib_duplication *ptr; >> > +}; >> ... >> > + struct vertex_attrib_duplication **heads = NULL; /* head of >> > list for each vertex */ >> >> You probably want to use Wine lists (from include/wine/list.h) instead >> of your own implementation. >> > I only wanted a singly linked list. The back links would be unused, but > would waste memory and update operations. The linked list also gets > invalidated by sorting, so the ptr field is actually also used to store the > original position in the array for performing a stable sort. I don't think > using include/wine/list.h would make the code clearer, since it would be > like trying to abstract the implementation details, when those details are > relevant to the implementation (see the answer to the next question for an > example). It is an ongoing effort (almost complete I think) to replace custom list implementations with the generic one through the Wine codebase. I don't think this case is so special to require a custom list. I don't have a strong opinion here, but, e.g., I don't find adding one or two fields to the structure a big drawback. >> >> > + heads = HeapAlloc(GetProcessHeap(), 0, This->numvertices * >> > sizeof(*heads) + max_entries * sizeof(*duplications)); >> > + duplications = (struct vertex_attrib_duplication *)(heads + >> > This->numvertices); >> >> I'm not sure why you are usually sticking together many arrays in a >> single allocation. Economizing on the number of HeapAllocs is not a >> great reason IMHO. > > Reducing memory allocations and keeping locality of memory references seemed > like a good idea, but in this case it actually affects the behaviour of the > sort. The pointer values are used in vertex_attrib_compare as a secondary > value, which largely affects the result since many vertices share the same > attribute value. Pointers into the heads array are used to keep the first > use of each vertex in the original order of the vertices, and duplications > of those vertices must be sorted using a stable sort, so their original > position in the array are compared where the attribute value is the same. I was referring to allocating "heads" and "duplications" from the same call, which, as far as I can see, is not required. Regarding the sorting requirements, those can also be addressed by adding another index field to the structure.

May 8, 2011

Re: [4/5] d3dx9: Implement D3DXMESHOPT_ATTRSORT vertex reordering.

by Dylan Smith

On Sun, May 8, 2011 at 3:18 PM, Matteo Bruni <matteo.mystral(a)gmail.com>wrote: > 2011/5/6 Dylan Smith <dylan.ah.smith(a)gmail.com>: > > +struct vertex_attrib_duplication { > > + DWORD attrib; > > + DWORD vertex_index; > > + struct vertex_attrib_duplication *ptr; > > +}; > ... > > + struct vertex_attrib_duplication **heads = NULL; /* head of > list for each vertex */ > > You probably want to use Wine lists (from include/wine/list.h) instead > of your own implementation. > > I only wanted a singly linked list. The back links would be unused, but would waste memory and update operations. The linked list also gets invalidated by sorting, so the ptr field is actually also used to store the original position in the array for performing a stable sort. I don't think using include/wine/list.h would make the code clearer, since it would be like trying to abstract the implementation details, when those details are relevant to the implementation (see the answer to the next question for an example). > + heads = HeapAlloc(GetProcessHeap(), 0, This->numvertices * > sizeof(*heads) + max_entries * sizeof(*duplications)); > > + duplications = (struct vertex_attrib_duplication *)(heads + > This->numvertices); > > I'm not sure why you are usually sticking together many arrays in a > single allocation. Economizing on the number of HeapAllocs is not a > great reason IMHO. > Reducing memory allocations and keeping locality of memory references seemed like a good idea, but in this case it actually affects the behaviour of the sort. The pointer values are used in vertex_attrib_compare as a secondary value, which largely affects the result since many vertices share the same attribute value. Pointers into the heads array are used to keep the first use of each vertex in the original order of the vertices, and duplications of those vertices must be sorted using a stable sort, so their original position in the array are compared where the attribute value is the same.

May 8, 2011

Re: [2/5] d3dx9: Implement D3DXMESHOPT_COMPACT for ID3DXMesh::OptimizeInplace.

by Dylan Smith

On Sun, May 8, 2011 at 3:17 PM, Matteo Bruni <matteo.mystral(a)gmail.com>wrote: > 2011/5/6 Dylan Smith <dylan.ah.smith(a)gmail.com>: > > ... > > + new_vertex_buffer_size = This->numvertices; > ... > > + new_vertex_buffer_size *= vertex_size; > > + hr = IDirect3DDevice9_CreateVertexBuffer(This->device, > new_vertex_buffer_size, > > + vertex_desc.Usage, This->fvf, vertex_desc.Pool, > &vertex_buffer, NULL); > ... > + for (i = 0; i < new_num_vertices; i++) > + CopyMemory(new_vertices + i * vertex_size, orig_vertices > + vertex_remap_ptr[i] * vertex_size, vertex_size); > > Is this correct, i.e. should the new vertex buffer be big as much as > the old one? I expected it to be just big enough to keep all the > remaining vertices (new_num_vertices). Maybe this is so to match some > native behavior? > Ya, I was just trying to match the native behaviour.

May 8, 2011

Re: [4/5] d3dx9: Implement D3DXMESHOPT_ATTRSORT vertex reordering.

by Matteo Bruni

2011/5/6 Dylan Smith <dylan.ah.smith(a)gmail.com>: > +struct vertex_attrib_duplication { > + DWORD attrib; > + DWORD vertex_index; > + struct vertex_attrib_duplication *ptr; > +}; ... > + struct vertex_attrib_duplication **heads = NULL; /* head of list for each vertex */ You probably want to use Wine lists (from include/wine/list.h) instead of your own implementation. > + heads = HeapAlloc(GetProcessHeap(), 0, This->numvertices * sizeof(*heads) + max_entries * sizeof(*duplications)); > + duplications = (struct vertex_attrib_duplication *)(heads + This->numvertices); I'm not sure why you are usually sticking together many arrays in a single allocation. Economizing on the number of HeapAllocs is not a great reason IMHO.

May 8, 2011

Re: [2/5] d3dx9: Implement D3DXMESHOPT_COMPACT for ID3DXMesh::OptimizeInplace.

by Matteo Bruni

2011/5/6 Dylan Smith <dylan.ah.smith(a)gmail.com>: ... > + new_vertex_buffer_size = This->numvertices; ... > + new_vertex_buffer_size *= vertex_size; > + hr = IDirect3DDevice9_CreateVertexBuffer(This->device, new_vertex_buffer_size, > + vertex_desc.Usage, This->fvf, vertex_desc.Pool, &vertex_buffer, NULL); ... + for (i = 0; i < new_num_vertices; i++) + CopyMemory(new_vertices + i * vertex_size, orig_vertices + vertex_remap_ptr[i] * vertex_size, vertex_size); Is this correct, i.e. should the new vertex buffer be big as much as the old one? I expected it to be just big enough to keep all the remaining vertices (new_num_vertices). Maybe this is so to match some native behavior?

May 8, 2011

Re: [1/5] d3dx9: Implement ID3DXMesh::CloneMesh without vertex buffer conversion.

by Matteo Bruni

2011/5/6 Dylan Smith <dylan.ah.smith(a)gmail.com>: > --- Just a couple of nitpicks: > + This->vertex_buffer->lpVtbl->AddRef(This->vertex_buffer); You should probably use the macros where they are around (D3D9 objects have them, as opposed to the mesh objects which don't for some strange reason). > + CopyMemory(data_out, data_in, This->numvertices * vertex_size); It's usually preferred to use memcpy(). I see that there are already a couple of uses of CopyMemory, in your previous patches, I didn't notice them...

May 8, 2011

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

by Michael Mc Donnell

My plans have changed a bit to avoid duplication of work. The updated plan is: Before May 23: * Read up on DirectX in general Week 1-3 (May 23rd-June 10th): * Implement test for UpdateSemantics function * Implement UpdateSemantics function Week 4-6 (June 13th-July 1st): * Implement test for ConvertPointRepsToAdjacency function * Implement test for ConvertAdjacencyToPointReps function * Implement ConvertPointRepsToAdjacency function * Implement ConvertAdjacencyToPointReps function Week 7-9 (July 4th-22th): * Implement test for D3DXWeldVertices * Implement D3DXWeldVertices Week 10-12 (July 25th-August 12th): * Improve clone function if possible * Improve implemented functions as needed. Week 13 (Auguest 15th-19th): * Make sure that all code has been integrated in the official tree. * Last code clean-up for code that has not already been accepted.

May 8, 2011

Re: tools: Upgrade the config.guess/config.sub scripts

by Austin English

2011/5/7 André Hentschel <nerv(a)dawncrow.de>: > from git://git.sv.gnu.org/config.git without the whitespace changes > --- > tools/config.guess | 17 ++++++++++------- > tools/config.sub | 49 +++++++++++++++++++++++++++++++++++-------------- > 2 files changed, 45 insertions(+), 21 deletions(-) > > diff --git a/tools/config.guess b/tools/config.guess > index 4c8f032..1f28e79 100755 > --- a/tools/config.guess > +++ b/tools/config.guess > @@ -92,7 +92,7 @@ if test $# != 0; then > exit 1 > fi > > -trap 'exit 1' HUP INT TERM > +trap 'exit 1' 1 2 15 > > # CC_FOR_BUILD -- compiler used by this script. Note that the use of a > # compiler to aid in system detection is discouraged as it requires > @@ -106,7 +106,7 @@ trap 'exit 1' HUP INT TERM > > set_cc_for_build=' > trap "exitcode=\$?; (rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null) && exit \$exitcode" 0 ; > -trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" HUP INT PIPE TERM ; > +trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" 1 2 13 15 ; > : ${TMPDIR=/tmp} ; > { tmp=`(umask 077 && mktemp -d "$TMPDIR/cgXXXXXX") 2>/dev/null` && test -n "$tmp" && test -d "$tmp" ; } || > { test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && mkdir $tmp) ; } || Looks like http://bugs.winehq.org/show_bug.cgi?id=16622 has re-emerged: http://git.savannah.gnu.org/gitweb/?p=config.git;a=commitdiff;h=2ec80f0dba7… -- -Austin

May 8, 2011

Re: riched20:tests Add conformance test for EM_FINDWORDBREAK function.

by James McKenzie

On 5/8/11 3:18 AM, André Hentschel wrote: > Am 08.05.2011 05:14, schrieb James McKenzie: >> >> + if (winetest_debug> 1) { >> test_WM_CHAR(); >> test_EM_FINDTEXT(); >> test_EM_GETLINE(); >> @@ -7090,6 +7368,8 @@ START_TEST( editor ) >> test_WM_GETDLGCODE(); >> test_zoom(); >> test_dialogmode(); >> + } >> + test_EM_FINDWORDBREAK(); >> > Hi, > i guess you didn't meant to include that in your patch. > Resending. Thanks for catching that from my tests. James McKenzie

May 8, 2011

Re: [1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo

by Damjan Jovanovic

On Fri, May 6, 2011 at 6:23 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Damjan, > > @@ -407,6 +441,20 @@ static MMSYSTEM_MapType MCI_UnMapMsg16To32W(WORD wMsg, DWORD dwFlags, DWORD_PTR > + mdsp16->dwCallback = mdsp32w->dwCallback; > + mdsp16->dwItem = mdsp32w->dwItem; > + mdsp16->dwTrack = mdsp32w->dwTrack; > This is superfluous. dwReturn is the only documented output. > This was different with your former MCI_WHERE patch, where a RECT is output. I'm aware it will be superfluous in the majority of cases, but are you convinced no MCI driver ever modifies fields it shouldn't, and no application depends on that exceptional behaviour? > I'd try hard not to turn one message call (Status) into 2 (GetDevCaps + Status). > I've seen logs of apps that continuously poll MCI_STATUS_POSITION. > Instead, I'd continue the path lead by winmm/mci.c:MCI_MapMsgAtoW: > Allocate the largest structure and fill it depending on dwFlags, e.g.: > case MCI_OPEN: > { /* MCI_ANIM_OPEN_PARMS is the largest known MCI_OPEN_PARMS > * structure, larger than MCI_WAVE_OPEN_PARMS */ > BTW, I've a note that MCI_INFO needs similar treatment, but never wrote the patch... > > Select the right set of flags to fill the slots, otherwise fallback to defaults like: > /* We don't know how many DWORD follow, as > * the structure depends on the device. */ > if (HIWORD(dwParam1)) > memcpy(&mci_openW->dwStyle, &mci_openA->dwStyle, sizeof(MCI_ANIM_OPEN_PARMSW) - sizeof(MCI_OPEN_PARMSW)); > > Of course, one may argue that this is a heuristic and can fail. Well, > GetDevCaps is a heuristic as well that only supports devtype_digital_video. What determines what subtype of MCI_STATUS_PARMS is passed to mciSendCommand() for an MCI_STATUS message? According to the API, "For VCR devices" uses one type, "For digital-video devices" uses another type, etc. But must the digital video MCI driver assume every MCI_STATUS lpStatus parameter points to MCI_DGV_STATUS_PARMS, or must it assume it got MCI_DGV_STATUS_PARMS only when it deals with a DGV-specific status request like MCI_DGV_STATUS_DISKSPACE and fall back to the generic MCI_STATUS_PARMS for all other cases? > An advantage IMHO of the existing approach is that > it does not invent within the same source code base > yet another mechanism to map 16 to 32 or A to W. I'd rather follow the > existing model until the time it proves unbearable, or immediately switch > the *whole* code base to another model, not the single MCI_STATUS function. > > For instance, you can argue that it makes sense for winmm > to cache the device type (winmm:MCI_Open has it in several cases). > It would arguably also make sense > to cache the MCI auto_open'ed property, but I digress. > > > Your MCI_get_device_type is bogus. MCI_GETDEVCAPS_DEVICE_TYPE > belongs into dwItem, not dwFlags. Let's finish this discussion, then I'll see whether to fix that bug or eliminate the entire function. > Regards, > Jörg Höhle > Regards Damjan Jovanovic

May 8, 2011

Re: ntdll: Make RtlReAllocateHeap() preserve V-bit information when run under Valgrind

by Marcus Meissner

On Sat, May 07, 2011 at 06:33:08PM +0200, Bart Van Assche wrote: > Hello, > > A patch I submitted about five weeks ago had the status "Pending" on the patch status page during about four weeks. I can't see this patch anymore on the patch status page today. Anyone who can tell me what happened or which steps I should take next ? > > The patch itself can be found here: http://www.winehq.org/pipermail/wine-patches/2011-April/100570.html If you got no reply or indication on a patch within a week, you can consider it lost ;) To do then: - Ask yourself if the patch is good (tm) - Ask by e-mail or in IRC (#winehackers) on what could be improved with it. >From a brief look ... I think your patch seems to be doing more than one thing at once. Please seperate multiple changes into multiple small patches. Ciao, Marcus

May 8, 2011

Re: RFC: doc for message contexts additions in PO files

by André Hentschel

Am 24.04.2011 11:03, schrieb Frédéric Delanoy: > Hi guys, > > I've put together the following doc for the introduction of message > contexts. It's still a bit raw but I'd improve it for the wiki > version. I'd say just put it on the wiki and we'll see what happens. It's better than getting forgotten on the mailinglist. -- Best Regards, André Hentschel

May 8, 2011

Re: riched20:tests Add conformance test for EM_FINDWORDBREAK function.

by André Hentschel

Am 08.05.2011 05:14, schrieb James McKenzie: > > + if (winetest_debug > 1) { > test_WM_CHAR(); > test_EM_FINDTEXT(); > test_EM_GETLINE(); > @@ -7090,6 +7368,8 @@ START_TEST( editor ) > test_WM_GETDLGCODE(); > test_zoom(); > test_dialogmode(); > + } > + test_EM_FINDWORDBREAK(); > Hi, i guess you didn't meant to include that in your patch. -- Best Regards, André Hentschel

May 8, 2011

Re: wineoss.drv: Add mmdevapi driver.

by Gerald Pfeifer

On Fri, 6 May 2011, Andrew Eikum wrote: > If Wine is trying to build wineoss.drv, then you must have oss_sysinfo. > If you have oss_sysinfo, then you have OSSv4. If you have OSSv4, then > you should have all of the above symbols, but apparently you don't. So I > suspect it's something amiss with your OSSv4 implementation, and that's > where I would begin investigating. > > Does that help you diagnose the problem? Yes, thanks a lot! Based on yours and Farncois' input, I did some research and found the following, among others http://manuals.opensound.com/developer/AFMT_S24_PACKED.html and consulting Google Code Search I find that also other applications do something like the following here (mplayer, for example). Suggested patch below. Gerald ChangeLog: Use AFMT_S24_LE instead of AFMT_S24_PACKED. diff --git a/dlls/wineoss.drv/mmdevdrv.c b/dlls/wineoss.drv/mmdevdrv.c index ff21cd6..789cb1e 100644 --- a/dlls/wineoss.drv/mmdevdrv.c +++ b/dlls/wineoss.drv/mmdevdrv.c @@ -500,7 +500,7 @@ static int get_oss_format(const WAVEFORMATEX *fmt) case 16: return AFMT_S16_LE; case 24: - return AFMT_S24_PACKED; + return AFMT_S24_LE; case 32: return AFMT_S32_LE; } @@ -953,7 +953,7 @@ static HRESULT WINAPI AudioClient_GetMixFormat(IAudioClient *iface, }else if(formats & AFMT_S32_LE){ fmt->Format.wBitsPerSample = 32; fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; - }else if(formats & AFMT_S24_PACKED){ + }else if(formats & AFMT_S24_LE){ fmt->Format.wBitsPerSample = 24; fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; }else{

May 7, 2011

Re: gdi32: Remove a set but unused variable

by Gerald Pfeifer

I admit I am surprised that Commit: 46988651d91fbea7f611287e5d8320239e72108d URL: http://source.winehq.org/git/wine.git/?a=commit;h=46988651d91fbea7f611287e5… Author: Nicolas Le Cam <niko.lecam at gmail.com> Date: Fri Apr 29 23:57:09 2011 +0200 gdi32: Remove a set but unused variable. has been applied, for I had proposed this very patch a year ago when Alexandre had rejected it with It seems pretty clear that it should be used, not removed. [ http://www.winehq.org/pipermail/wine-devel/2010-May/083517.html ] I tried to take that into account by updating the patch accordingly http://www.winehq.org/pipermail/wine-patches/2010-May/088317.html which, unexplicably to me, broke the tests so it was not applied: http://www.winehq.org/pipermail/wine-devel/2010-May/083850.html Now my original patch was re-submitted by Nicolas and applied. Was Alexandre's analysis incorrect in the original case, did he just fail to catch the mistake this time around, or is it something else? Gerald

May 7, 2011

Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.

by Scott Ritchie

A .desktop entry pointing to a nonexistant mime type is harmless, so I'd revert the change. Indeed only a year ago Wine's .desktop entry pointed to MANY non-existant mime types. -Scott Ritchie On 05/07/2011 05:27 AM, Jerome Leclanche wrote: > Odd, I'm on KDE but my shortcuts are all application/x-ms-shortcut (Natty). > > I had a quick search through the kde sources and it seems KDE might be > forcing x-win-lnk for some windows-specific behaviour. At least it's > there in a bunch of tests, but no app seems to actually use it. > > I'll file a bug with KDE and see what else references it. Should the > commit be reverted or is it a case of fix-it-upstream? > > > J. Leclanche > > > > 2011/5/7 Ozan Türkyılmaz <ozan.turkyilmaz(a)gmail.com>: >> On Sat, 7 May 2011, Francois Gouget wrote: >>> >>> I'm not sure this patch is correct: on my Debian Testing machine >>> application/x-win-lnk is defined in /usr/share/mime/packages/kde.xml which >>> comes from the kdelibs5-data. I also found a reference to this package in >>> the kdebase-runtime Fedora 11 runtime. >>> >> >> I found it on /usr/share/mime/packages/kde.xml on Slackware 13.37 as well. >> It's included in kdelibs package. >> >> -- >> Ozan, BSc, BEng >> >> >> > >

May 7, 2011

Re: Huge frustration

by André Hentschel

Am 07.05.2011 12:52, schrieb Roland Kaeser: > http://bugs.winehq.org/show_bug.cgi?id=11687 open (not even confirmed) since more than 3 years > http://bugs.winehq.org/show_bug.cgi?id=14123 open since 2008-06-25 > http://bugs.winehq.org/show_bug.cgi?id=3599 open (new) since 2005-10-15 > http://bugs.winehq.org/show_bug.cgi?id=3611 open (new) since 2005-10-17 After i read through the bugs, i think the activity wasn't that low. But e.g. no reply by you or the bug reporter on comments like http://bugs.winehq.org/show_bug.cgi?id=14123#c8 or http://bugs.winehq.org/show_bug.cgi?id=3611#c22 is also a reason. Further you can't motivate volunteers by attacking them. -- Best Regards, André Hentschel

May 7, 2011

Re: Huge frustration

by James McKenzie

On 5/7/11 3:52 AM, Roland Kaeser wrote: > Hello > > Please take the following not personal but the huge pent-up > frustration constrains me to say a few words. > > I've just tested one of my "longest waiting" apps to get working on > linux: CorelDraw X3/X4. And I had to see that > it fails already with the same errors. I tooke a short look into the > bug database to see all the related bugs: > > http://bugs.winehq.org/show_bug.cgi?id=11687 open (not even > confirmed) since more than 3 years > http://bugs.winehq.org/show_bug.cgi?id=14123 open since 2008-06-25 > http://bugs.winehq.org/show_bug.cgi?id=3599 open (new) since > 2005-10-15 > http://bugs.winehq.org/show_bug.cgi?id=3611 open (new) since > 2005-10-17 > > I know we had this discussion already a lot of times but after six acc. > Many bug fixes depend on fixing a six year old + bug (421). However, if you feel so strongly, then maybe YOU can take a stab at trying to fix a bug. It is NOT easy (6724 is one bug that I'm working on and it has been around for four+ years.) Also, not all developers are working on fixing and improving DirectX. Some are working on code improvements and long overdue code cleanups. James McKenzie

May 7, 2011

Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.

by Jerome Leclanche

Fixed in kdelibs 5552b1f68348ff5a5cc4a20b661a1ba3ad7bafe2: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/5552b1f6… After a little more search, turns out it was just registered as a helper for a kde 3.x plugin which hasn't been provided for quite a few major releases. It also seems to be where it originated from in the first place. J. Leclanche 2011/5/7 Jerome Leclanche <adys.wh(a)gmail.com>: > Odd, I'm on KDE but my shortcuts are all application/x-ms-shortcut (Natty). > > I had a quick search through the kde sources and it seems KDE might be > forcing x-win-lnk for some windows-specific behaviour. At least it's > there in a bunch of tests, but no app seems to actually use it. > > I'll file a bug with KDE and see what else references it. Should the > commit be reverted or is it a case of fix-it-upstream? > > > J. Leclanche > > > > 2011/5/7 Ozan Türkyılmaz <ozan.turkyilmaz(a)gmail.com>: >> On Sat, 7 May 2011, Francois Gouget wrote: >>> >>> I'm not sure this patch is correct: on my Debian Testing machine >>> application/x-win-lnk is defined in /usr/share/mime/packages/kde.xml which >>> comes from the kdelibs5-data. I also found a reference to this package in >>> the kdebase-runtime Fedora 11 runtime. >>> >> >> I found it on /usr/share/mime/packages/kde.xml on Slackware 13.37 as well. >> It's included in kdelibs package. >> >> -- >> Ozan, BSc, BEng >> >> >> >

May 7, 2011

Re: Huge frustration

by Lats

> > It would be understandeable to me if its written in the bug that the > fix of this bug will consume a lot of resources and its > impossible to fix this, but just to ignore it is not "the proper way > to behave". Most wine developers are just people sorting out problems that either affect them or have some intrinsic reason to work on the problem. Many of them get started because they want to resolve a bug to allow a Windows program to run. If the bugs you are experiencing are not getting traction then you can always have a look yourself.

May 7, 2011

Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.

by Jerome Leclanche

Odd, I'm on KDE but my shortcuts are all application/x-ms-shortcut (Natty). I had a quick search through the kde sources and it seems KDE might be forcing x-win-lnk for some windows-specific behaviour. At least it's there in a bunch of tests, but no app seems to actually use it. I'll file a bug with KDE and see what else references it. Should the commit be reverted or is it a case of fix-it-upstream? J. Leclanche 2011/5/7 Ozan Türkyılmaz <ozan.turkyilmaz(a)gmail.com>: > On Sat, 7 May 2011, Francois Gouget wrote: >> >> I'm not sure this patch is correct: on my Debian Testing machine >> application/x-win-lnk is defined in /usr/share/mime/packages/kde.xml which >> comes from the kdelibs5-data. I also found a reference to this package in >> the kdebase-runtime Fedora 11 runtime. >> > > I found it on /usr/share/mime/packages/kde.xml on Slackware 13.37 as well. > It's included in kdelibs package. > > -- > Ozan, BSc, BEng > > >

May 7, 2011

Re: Huge frustration

by Henri Verbeet

On 7 May 2011 12:52, Roland Kaeser <roli8200(a)yahoo.de> wrote: > I know also thats a lot more fun developing directx routines instead of > fixing old bugs but No, it isn't. Sorry. But you know, git is awesome. You can spend days doing all kinds of interesting things, like figuring out which people contribute to which areas of Wine, etc. I'll leave that as an exercise for the reader, but you'll probably find there aren't actually all the many people "developing directx routines" all day. Fortunately Wine, like any good Free Software project, has much more people that are good at complaining associated with it than, well, any of these nasty developers, so that makes it all ok.

May 7, 2011

Huge frustration

by Roland Kaeser

Hello Please take the following not personal but the huge pent-up frustration constrains me to say a few words. I've just tested one of my "longest waiting" apps to get working on linux: CorelDraw X3/X4. And I had to see that it fails already with the same errors. I tooke a short look into the bug database to see all the related bugs: http://bugs.winehq.org/show_bug.cgi?id=11687 open (not even confirmed) since more than 3 years http://bugs.winehq.org/show_bug.cgi?id=14123 open since 2008-06-25 http://bugs.winehq.org/show_bug.cgi?id=3599 open (new) since 2005-10-15 http://bugs.winehq.org/show_bug.cgi?id=3611 open (new) since 2005-10-17 I know we had this discussion already a lot of times but after six acc. three years its time for me to say something again. I know also thats a lot more fun developing directx routines instead of fixing old bugs but sometimes You should also think about the "other" generality which uses the computer not just to play games. It would be understandeable to me if its written in the bug that the fix of this bug will consume a lot of resources and its impossible to fix this, but just to ignore it is not "the proper way to behave". I'm sure that there are many more of the above bugs which nobody has has ever took seriously a lock at it. Has anybody ever imagined how many apps depending on such bugs which prevents them to get running on Linux? Maybe all of the above bugs are only related to CorelDraw but its also possible that dozens or hundrets of other apps also fail with the same problems but nobody has ever wrote a bug report or saw it in the bug database and thought that it will be fixed cause its already reported? Just take a look at: http://www.inside-it.ch/frontend/insideit?_d=_article&site=ic&news.id=22515 English version: http://arstechnica.com/civis/viewtopic.php?f=14&t=1122655 The most of their problems where related to special windows apps running only in goverment institutions and where not able to run on Linux (wine). How many of these problems whould not even ever have been occured if such small bugs like the above whoud be fixed which makes all of those apps runnable on linux. Sorry to say that but Your politics just to develop things which makes fun or are interesting is also part of the above problem. Regards Roland

May 7, 2011

Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.

by Ozan Türkyılmaz

On Sat, 7 May 2011, Francois Gouget wrote: > I'm not sure this patch is correct: on my Debian Testing machine > application/x-win-lnk is defined in /usr/share/mime/packages/kde.xml > which comes from the kdelibs5-data. I also found a reference to this > package in the kdebase-runtime Fedora 11 runtime. > I found it on /usr/share/mime/packages/kde.xml on Slackware 13.37 as well. It's included in kdelibs package. -- Ozan, BSc, BEng

May 7, 2011

Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.

by Francois Gouget

On Thu, 5 May 2011, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: db03d247158ee44c06935b5e23fbf37485d8c8bf > URL: http://source.winehq.org/git/wine.git/?a=commit;h=db03d247158ee44c06935b5e2… > > Author: Jerome Leclanche <adys.wh(a)gmail.com> > Date: Wed May 4 19:01:33 2011 +0100 > > wine.desktop: Remove the nonexistent application/x-win-lnk MIME type. I'm not sure this patch is correct: on my Debian Testing machine application/x-win-lnk is defined in /usr/share/mime/packages/kde.xml which comes from the kdelibs5-data. I also found a reference to this package in the kdebase-runtime Fedora 11 runtime. So this MIME type may not be standard (heck it has the 'x-' prefix anyway) but KDE seems to know / be using it. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Research is the transformation of money to knowledge. Innovation is the transformation of knowledge to money. -- Dr. Hans Meixner

May 7, 2011

Re: wineoss.drv: Add mmdevapi driver.

by Francois Gouget

On Fri, 6 May 2011, Andrew Eikum wrote: [...] > You might find some relevant information searching config.log for > "oss_sysinfo". The configure changes that Julliard added use the oss_sysinfo > structure to check that you have OSSv4 installed. > > If Wine is trying to build wineoss.drv, then you must have oss_sysinfo. If you > have oss_sysinfo, then you have OSSv4. If you have OSSv4, then you should have > all of the above symbols, but apparently you don't. So I suspect it's > something amiss with your OSSv4 implementation, and that's where I would begin > investigating. > > Does that help you diagnose the problem? My understanding (from a bit of Googling some time ago, hopefully someone more expert can chime in) is that FreeBSD does not implement OSSv4: their OSS evolved from OSSv3 independently and now has essentially the same feature set but is not 100% API compatible. That's probably the cause of this build error. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

May 7, 2011

[1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo

by Joerg-Cyril.Hoehle＠t-systems.com

Damjan, @@ -407,6 +441,20 @@ static MMSYSTEM_MapType MCI_UnMapMsg16To32W(WORD wMsg, DWORD dwFlags, DWORD_PTR + mdsp16->dwCallback = mdsp32w->dwCallback; + mdsp16->dwItem = mdsp32w->dwItem; + mdsp16->dwTrack = mdsp32w->dwTrack; This is superfluous. dwReturn is the only documented output. This was different with your former MCI_WHERE patch, where a RECT is output. I'd try hard not to turn one message call (Status) into 2 (GetDevCaps + Status). I've seen logs of apps that continuously poll MCI_STATUS_POSITION. Instead, I'd continue the path lead by winmm/mci.c:MCI_MapMsgAtoW: Allocate the largest structure and fill it depending on dwFlags, e.g.: case MCI_OPEN: { /* MCI_ANIM_OPEN_PARMS is the largest known MCI_OPEN_PARMS * structure, larger than MCI_WAVE_OPEN_PARMS */ BTW, I've a note that MCI_INFO needs similar treatment, but never wrote the patch... Select the right set of flags to fill the slots, otherwise fallback to defaults like: /* We don't know how many DWORD follow, as * the structure depends on the device. */ if (HIWORD(dwParam1)) memcpy(&mci_openW->dwStyle, &mci_openA->dwStyle, sizeof(MCI_ANIM_OPEN_PARMSW) - sizeof(MCI_OPEN_PARMSW)); Of course, one may argue that this is a heuristic and can fail. Well, GetDevCaps is a heuristic as well that only supports devtype_digital_video. An advantage IMHO of the existing approach is that it does not invent within the same source code base yet another mechanism to map 16 to 32 or A to W. I'd rather follow the existing model until the time it proves unbearable, or immediately switch the *whole* code base to another model, not the single MCI_STATUS function. For instance, you can argue that it makes sense for winmm to cache the device type (winmm:MCI_Open has it in several cases). It would arguably also make sense to cache the MCI auto_open'ed property, but I digress. Your MCI_get_device_type is bogus. MCI_GETDEVCAPS_DEVICE_TYPE belongs into dwItem, not dwFlags. Regards, Jörg Höhle

May 6, 2011

Re: [1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo

by Damjan Jovanovic

On Thu, May 5, 2011 at 9:23 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > Le 05/05/2011 15:30, Damjan Jovanovic a écrit : > > Changelog: > * mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo > > Damjan Jovanovic > > > Hi Damjan, > > I wonder if storing the device type (or at least information to select the > two types of mapping) in the allocated structure for mapping instead of > calling for the device type at each unmap operation wouldn't be a preferable > solution > A+ > > -- > Eric Pouech Hi Eric It might be even more preferable to store the device type in a local variable. The allocated structure is way too complex already. Damjan Jovanovic

May 6, 2011

Re: [PATCH try4] wininet: Added support for persistent HTTP connections

by Jacek Caban

On 05/06/11 13:17, Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > >> + /* FIXME: do the check also for SSL connections */ >> + if(!netconn->useSSL) { >> + res = NETCON_recv(netconn, &b, 1, MSG_PEEK|MSG_DONTWAIT, &len); >> + if((res == ERROR_SUCCESS && len == 1) || res == WSAEWOULDBLOCK) >> + break; > This doesn't build with winsock (MSG_DONTWAIT is not defined). I'm also > not sure what is the purpose of that check. If it's to check if remote > has closed the connection, you need to do that by handling the error on > the first send. Yes, the check is supposed to test for closed connections. It's inspired in how it's done in Gecko [1]. Handling error on the first send also should be fixed (it needs more investigation, send successes for me, it's later recv that fails and it's already too late to handle it well), but we should attempt to detect closed connection earlier because sending has side effects like callback notifications. Thanks, Jacek [1] http://wine.git.sourceforge.net/git/gitweb.cgi?p=wine/wine-gecko;a=blob;f=n…

May 6, 2011

Re: wineoss.drv: Add mmdevapi driver.

by Andrew Eikum

On 05/05/2011 10:22 PM, Gerald Pfeifer wrote: > On Fri, 29 Apr 2011, Gerald Pfeifer wrote: >> commit be332326ba8fc3def406c5f29adf04fbe9a83976 >> Author: Andrew Eikum<aeikum(a)codeweavers.com> >> Date: Wed Apr 27 09:12:36 2011 -0500 >> >> is causing the following build failures on my nightly FreeBSD testers: >> >> mmdevdrv.c:463:20: error: 'AFMT_S24_PACKED' undeclared (first use in this function) >> mmdevdrv.c:476:16: error: 'AFMT_FLOAT' undeclared (first use in this function) >> mmdevdrv.c:854:24: error: 'AFMT_FLOAT' undeclared (first use in this function) >> mmdevdrv.c:863:24: error: 'AFMT_S24_PACKED' undeclared (first use in this function) >> mmdevdrv.c:1084:24: error: 'SNDCTL_DSP_HALT' undeclared (first use in this function) >> >> Looks like some autoconfigury is not working or incomplete? > > This has now been broken for a week; when are you planning on fixing > this, Andrew? Bugs are much easier to keep track of than mailing list threads. > If not, any pointers on how to best approach this? > > I checked, and AFMT_FLOAT is not defined in /usr/include on either > my FreeBSD 8.2 tester nor my openSUSE 11.4 machine, whereas other > AFMT_ strings are. Similarly for AFMT_S24_PACKED and SNDCTL_DSP_HALT. Commit f60a0f5e565ab9ec5f13b6b489e03b6b22ebf8f7 was supposed to fix these issues. See bug 26975 for more background. You might find some relevant information searching config.log for "oss_sysinfo". The configure changes that Julliard added use the oss_sysinfo structure to check that you have OSSv4 installed. If Wine is trying to build wineoss.drv, then you must have oss_sysinfo. If you have oss_sysinfo, then you have OSSv4. If you have OSSv4, then you should have all of the above symbols, but apparently you don't. So I suspect it's something amiss with your OSSv4 implementation, and that's where I would begin investigating. Does that help you diagnose the problem? Andrew

May 6, 2011

Re: [PATCH try4] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > + /* FIXME: do the check also for SSL connections */ > + if(!netconn->useSSL) { > + res = NETCON_recv(netconn, &b, 1, MSG_PEEK|MSG_DONTWAIT, &len); > + if((res == ERROR_SUCCESS && len == 1) || res == WSAEWOULDBLOCK) > + break; This doesn't build with winsock (MSG_DONTWAIT is not defined). I'm also not sure what is the purpose of that check. If it's to check if remote has closed the connection, you need to do that by handling the error on the first send. -- Alexandre Julliard julliard(a)winehq.org

May 6, 2011

Re: [PATCH try4] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > try4: Check idle connection before using it in an attempt to catch > closed connection sooner, avoiding some request resends. It hopefully > fixes observed problem with tests. It does, but there's a new problem: it sometimes crashes in the collect_connections thread during the winhttp tests, because wininet has been unloaded while the thread is still running. Probably the thread needs to grab a library reference, though a collection mechanism that doesn't require a separate thread would be even better. I can still put the patch in for now, since the failure is not very frequent. -- Alexandre Julliard julliard(a)winehq.org

May 6, 2011

Re: [PATCH try4] wininet: Added support for persistent HTTP connections

by Jacek Caban

On 05/06/11 10:47, Marvin wrote: > 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=10757 > > Your paranoid android. > > > === W2K3R2SESP2 (32 bit protocol) === > protocol.c:972: Test failed: unexpected call ReportResult > protocol.c:977: Test failed: hrResult = 00000000, expected: 80004004 > protocol.c:2690: Test failed: Read failed: 00000001 This is not related to my patch. All I've changed in protocol.c was removing todo_wine, so it can't affect Windows runs. Jacek

May 6, 2011

Re: po: Update French translation

by Frédéric Delanoy

2011/5/6 Nicolas Le Cam <niko.lecam(a)gmail.com>: > Le 6 mai 2011 08:41, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : >> 2011/5/6 Nicolas Le Cam <niko.lecam(a)gmail.com>: >>>> #: regedit.rc:88 >>>> -#, fuzzy >>>> msgid "Modify Binary Data..." >>>> -msgstr "Modifier les données &binaires" >>>> +msgstr "Modifier les données &binaires..." >>> I'm not sure you can add a keyboard accelerator if there isn't one in >>> the original message. >> >> Well actually, it's more like an error/omission in the original En version. >> >> POPUP "" >> BEGIN >> MENUITEM "&Modify...", ID_EDIT_MODIFY >> MENUITEM "Modify Binary Data...", ID_EDIT_MODIFY_BIN >> MENUITEM SEPARATOR >> MENUITEM "&Delete\tDel", ID_EDIT_DELETE >> MENUITEM "&Rename", ID_EDIT_RENAME >> END >> >> As you can see, there's an accelerator on 3 out of 4 entries. For >> consistency sake, the remaining one should have one as well. >> I'll send a patch for this. >> >>> -- >>> Nicolas Le Cam >> >> Frédéric Delanoy >> > IMHO it isn't. It duplicates Windows behaviour : Modify / Delete and > Rename have accelerators, Modify Binary Data doesn't. Well if I want to be pedantic, the translations aren't also word-for-word equal with windows. Does that mean they should be discarded altogether? I agree that 100% code, bug-for-bug compatibility is wine ultimate objective, but for the GUI menu entries, I'm not so sure. Maybe Windows regedit should add an accelerator there as well? That would make sense IMHO. Frédéric

May 6, 2011

winscard/tests: Add test base functions of winscard.dll

by Joerg-Cyril.Hoehle＠t-systems.com

Sergey, >+ * Unit test suite for AVI Functions >+ * Copyright 2008 Detlef Riekenberg +#include "wingdi.h" >+#include "vfw.h" Please try and hide better the copy&paste origin of the code :-) >rezult result + ok(winscard_rezult != SCARD_F_INTERNAL_ERROR I recommend tests to be stricter, e.g. ok(result == SCARD_S_SUCCESS || result == SCARD_E_XYZ || broken(result == SCARD_E_...) Here's work done last year by Yauheni Baltouski and Aliaksei Hud. They are not working on winscard any more. I'd be pleased to eventually see winscard tests in Wine. Maybe you could merge this work? I *hope* I attached the latest version of the patch. If yes, it was verified last year to pass on: - native machines with and without card readers; - testbot, incl. w9x machines; - 64 bit? can't remember; - stock Linux (Ubuntu Lucid); - Linux with Mounir Idrassi's winscard dll (in which case the todo_wine succeed) and a card reader. It contains a good mixture of win_skip(), broken() and todo_wine to that effect. I had not submitted these tests in the past because IIRC there's still a resource leak (FreeLibrary following LoadLibrary; SCardFreeMemory following SCardListReaders AUTOALLOCATE) and some style issues (casts inside ok("%ld") formats) as well as IMHO too many redundant trace("testing X\n"), see $WINETEST_REPORT_SUCCESS. In their patch, LoadLibrary was necessary instead of a statically linked .exe because not all native systems provide winscard.dll Nowadays, successful tests on w9x are not considered important anymore, so this might be superfluous (but I don't know whether one can expect winscard on all machines since NT). +#ifndef SCARD_AUTOALLOCATE +#define SCARD_AUTOALLOCATE (DWORD)(-1) +#ifndef SCARD_SCOPE_USER +#define SCARD_SCOPE_USER 0x0000 was necessary because Wine's winscard.h does not yet provide enough definitions. -- Completing winscard.h would be a useful patch on its own. This test was considered the first of a series: small enough yet still doing something useful (ListReaders), but not yet depending on the presence of a chip card. Final comments on your initial patch: + mszReaders = malloc(cchReaders); HeapAlloc() is recommended in Wine, i.e. programming against the MS API. +START_TEST(winscard_api) Just name it winscard. Keep the name short because you use it on the command line. You don't initialize SCARD_READERSTATE as MSDN requires it for SCardGetStatusChange: "Important Each member of each structure in this array must be initialized to zero" and you don't check whether SCardListReaders returned at least one string in mszReaders for you to feed into SCardGetStatusChange. Regards, Jörg Höhle >From 3a936d8e0c100aee0da324d4d32e92368eefde88 Mon Sep 17 00:00:00 2001 From: Yauheni Baltouski <ybaltouski(a)gmail.com> Date: Tue, 29 Jun 2010 11:25:24 +0300 Subject: winscard/test: add initial test cases --- configure.ac | 1 + dlls/winscard/tests/Makefile.in | 11 +++ dlls/winscard/tests/scard.c | 180 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 192 insertions(+), 0 deletions(-) create mode 100644 dlls/winscard/tests/Makefile.in create mode 100644 dlls/winscard/tests/scard.c diff --git a/configure.ac b/configure.ac index 61f376e..0309abc 100644 --- a/configure.ac +++ b/configure.ac @@ -2661,6 +2661,7 @@ WINE_CONFIG_TEST(dlls/winmm/tests) WINE_CONFIG_DLL(winnls.dll16,enable_win16) WINE_CONFIG_DLL(winnls32,,[winnls32]) WINE_CONFIG_DLL(winscard,,[winscard]) +WINE_CONFIG_TEST(dlls/winscard/tests) WINE_CONFIG_DLL(winsock.dll16,enable_win16) WINE_CONFIG_DLL(winspool.drv,,[winspool]) WINE_CONFIG_TEST(dlls/winspool.drv/tests) diff --git a/dlls/winscard/tests/Makefile.in b/dlls/winscard/tests/Makefile.in new file mode 100644 index 0000000..879481b --- /dev/null +++ b/dlls/winscard/tests/Makefile.in @@ -0,0 +1,11 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +TESTDLL = winscard.dll +IMPORTS = kernel32 ntdll + +C_SRCS = \ + scard.c + +(a)MAKE_TEST_RULES@ diff --git a/dlls/winscard/tests/scard.c b/dlls/winscard/tests/scard.c new file mode 100644 index 0000000..fd751c8 --- /dev/null +++ b/dlls/winscard/tests/scard.c @@ -0,0 +1,180 @@ +/* + * Unit tests for winscard.dll functions + * + * Copyright 2010 Yauheni S Baltouski + * + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include <stdarg.h> +#include <stdio.h> + +#include "windef.h" +#include "winbase.h" +#include "winerror.h" +#include "winver.h" + +#include <winscard.h> +#include "wine/test.h" + +#ifndef SCARD_AUTOALLOCATE +#define SCARD_AUTOALLOCATE (DWORD)(-1) +#endif + +#ifndef SCARD_SCOPE_USER +#define SCARD_SCOPE_USER 0x0000 +#endif + +static const CHAR winscardDll[] = "winscard.dll"; + +static LONG (WINAPI *pSCardEstablishContext)(DWORD ,LPCVOID, LPCVOID, LPSCARDCONTEXT); +static LONG (WINAPI *pSCardReleaseContext)(SCARDCONTEXT); +static LONG (WINAPI *pSCardListReadersA)(SCARDCONTEXT,LPCSTR,LPSTR,LPDWORD); +static LONG (WINAPI *pSCardListReadersW)(SCARDCONTEXT,LPCSTR,LPSTR,LPDWORD); + +static SCARDCONTEXT hSC; +static LPTSTR szReaders; +static DWORD cchReaders = SCARD_AUTOALLOCATE; + +static void test_SCardEstablishContext(void) { + LONG lReturn; + + trace("testing SCardEstablishContext\n"); + + lReturn = pSCardEstablishContext(SCARD_SCOPE_USER, + NULL, + NULL, + &hSC); + todo_wine + { + ok((SCARD_S_SUCCESS==lReturn || broken(SCARD_E_NO_SERVICE==lReturn /*service disabled */)), + "can't execute SCardEstablishContext, SCardEstablishContext ptr = %p, return = %ld\n", + pSCardEstablishContext, + (long)lReturn); + } +} + +static void test_SCardReleaseContext(void) { + LONG lReturn; + + trace("testing SCardReleaseContext\n"); + if (hSC) { + + lReturn = pSCardReleaseContext(hSC); } + + todo_wine + { + ok(SCARD_S_SUCCESS==lReturn && hSC, + "can't execute SCardReleaseContext, SCardReleaseContext ptr = %p, SCARDCONTEXT=%lx, return=%ld\n", + pSCardReleaseContext, + (long int)hSC, + (long)lReturn); + } +} + +static void test_SCardListReadersA(void) { + LONG lReturn; + + trace("testing SCardListReadersA\n"); + if (hSC) { + + lReturn = pSCardListReadersA(hSC, + NULL, + (LPTSTR)&szReaders, + &cchReaders); } + + todo_wine + { + ok((lReturn == SCARD_S_SUCCESS || lReturn == SCARD_E_NO_READERS_AVAILABLE) && hSC, + "can't execute SCardListReadersA, SCardListReadersA ptr = %p, SCARDCONTEXT=%lx, return=%ld\n", + pSCardListReadersA, + (long int)hSC, + (long)lReturn); + } +} + +static void test_SCardListReadersW(void) { + LONG lReturn; + + trace("testing SCardListReadersW\n"); + if (hSC) { + + lReturn = pSCardListReadersW(hSC, + NULL, + (LPTSTR)&szReaders, + &cchReaders);} + + todo_wine + { + ok((lReturn == SCARD_S_SUCCESS || lReturn == SCARD_E_NO_READERS_AVAILABLE) && hSC, + "can't execute SCardListReadersW, SCardListReadersW ptr = %p, SCARDCONTEXT=%lx, return=%ld\n", + pSCardListReadersW, + (long int)hSC, + (long)lReturn); + } +} + +static BOOL init_winscard(void){ +#define GET_PROC(func) \ + (p ## func = (void *)GetProcAddress(module, #func)) + HMODULE module=NULL; + trace("testing winscard initialization\n"); + module = LoadLibraryA(winscardDll); + if (!module) + { + win_skip("No winscard.dll found - aborting"); + return FALSE; + } + else { + + trace("loading winscard SCardEstablishContext\n"); + GET_PROC(SCardEstablishContext); + todo_wine ok(pSCardEstablishContext!=NULL, "can't initialize winscard SCardEstablishContext, error=%lx\n", (long int)GetLastError()); + if (pSCardEstablishContext==NULL) return FALSE; + + trace("loading winscard SCardReleaseContext\n"); + GET_PROC(SCardReleaseContext); + todo_wine ok(pSCardReleaseContext!=NULL, "can't initialize winscard SCardReleaseContext, error=%lx\n", (long int)GetLastError()); + if (pSCardReleaseContext==NULL) return FALSE; + + trace("loading winscard SCardListReadersA\n"); + GET_PROC(SCardListReadersA); + todo_wine ok(pSCardListReadersA!=NULL, "can't initialize winscard SCardListReadersA, error=%lx\n", (long int)GetLastError()); + if (pSCardListReadersA==NULL) return FALSE; + + trace("loading winscard SCardListReadersW\n"); + GET_PROC(SCardListReadersW); + todo_wine ok(pSCardListReadersW!=NULL, "can't initialize winscard SCardListReadersW, error=%lx\n", (long int)GetLastError()); + if (pSCardListReadersW==NULL) return FALSE; + + return TRUE; + } +#undef GET_PROC +} + + +START_TEST(scard) +{ + if (init_winscard()) { + test_SCardEstablishContext(); + if (hSC) + { + test_SCardListReadersW(); + test_SCardListReadersA(); + test_SCardReleaseContext();/*must be at end of tests*/ + } + } +} -- 1.7.0.4

May 6, 2011

Re: [PATCH try4] wininet: Added support for persistent HTTP connections

by 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=10757 Your paranoid android. === W2K3R2SESP2 (32 bit protocol) === protocol.c:972: Test failed: unexpected call ReportResult protocol.c:977: Test failed: hrResult = 00000000, expected: 80004004 protocol.c:2690: Test failed: Read failed: 00000001

May 6, 2011

Re: avicap32: fix build with recent kernel headers

by Michael Stefaniuc

Hello Rafał, Rafał Mużyło wrote: > Attached patch seems to fix build problem with recent kernel headers, > where v4l1 was removed. I'm sending it here first (instead straight while the v4l1 API was removed from the kernel it wasn't removed from the userspace. libv4l1 will translate v4l1 to v4l2. > to wine-patches), as I have no real way of testing it - I only know it builds. A more correct fix would be to stop using directly the kernel headers and move to using the libv4l2 library. > As such, I haven't bothered yet with keeping consistant folding style. > > In case of any questions, CC me. > > PS.: qcap *might* need a similar, though far more complex fix. bye michael

May 6, 2011

Re: po: Update French translation

by Nicolas Le Cam

Le 6 mai 2011 08:41, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : > 2011/5/6 Nicolas Le Cam <niko.lecam(a)gmail.com>: >>> #: regedit.rc:88 >>> -#, fuzzy >>> msgid "Modify Binary Data..." >>> -msgstr "Modifier les données &binaires" >>> +msgstr "Modifier les données &binaires..." >> I'm not sure you can add a keyboard accelerator if there isn't one in >> the original message. > > Well actually, it's more like an error/omission in the original En version. > > POPUP "" > BEGIN > MENUITEM "&Modify...", ID_EDIT_MODIFY > MENUITEM "Modify Binary Data...", ID_EDIT_MODIFY_BIN > MENUITEM SEPARATOR > MENUITEM "&Delete\tDel", ID_EDIT_DELETE > MENUITEM "&Rename", ID_EDIT_RENAME > END > > As you can see, there's an accelerator on 3 out of 4 entries. For > consistency sake, the remaining one should have one as well. > I'll send a patch for this. > >> -- >> Nicolas Le Cam > > Frédéric Delanoy > IMHO it isn't. It duplicates Windows behaviour : Modify / Delete and Rename have accelerators, Modify Binary Data doesn't. -- Nicolas Le Cam

May 6, 2011

Re: winscard/tests: Implement test for two functions of winscard.dll

by 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=10750 Your paranoid android. === WXPPROSP3 (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === W2K3R2SESP2 (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === WVISTAADM (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === W2K8SE (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === W7PRO (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6

May 6, 2011

Re: winscard/tests: Implement test for two functions of winscard.dll

by 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=10749 Your paranoid android. === WXPPROSP3 (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === W2K3R2SESP2 (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === WVISTAADM (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === W2K8SE (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === W7PRO (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6

May 6, 2011

Re: po: Update French translation

by Frédéric Delanoy

2011/5/6 Nicolas Le Cam <niko.lecam(a)gmail.com>: >> #: regedit.rc:88 >> -#, fuzzy >> msgid "Modify Binary Data..." >> -msgstr "Modifier les données &binaires" >> +msgstr "Modifier les données &binaires..." > I'm not sure you can add a keyboard accelerator if there isn't one in > the original message. Well actually, it's more like an error/omission in the original En version. POPUP "" BEGIN MENUITEM "&Modify...", ID_EDIT_MODIFY MENUITEM "Modify Binary Data...", ID_EDIT_MODIFY_BIN MENUITEM SEPARATOR MENUITEM "&Delete\tDel", ID_EDIT_DELETE MENUITEM "&Rename", ID_EDIT_RENAME END As you can see, there's an accelerator on 3 out of 4 entries. For consistency sake, the remaining one should have one as well. I'll send a patch for this. > -- > Nicolas Le Cam Frédéric Delanoy

May 6, 2011

Re: wineoss.drv: Add mmdevapi driver.

by Gerald Pfeifer

On Fri, 29 Apr 2011, Gerald Pfeifer wrote: > commit be332326ba8fc3def406c5f29adf04fbe9a83976 > Author: Andrew Eikum <aeikum(a)codeweavers.com> > Date: Wed Apr 27 09:12:36 2011 -0500 > > is causing the following build failures on my nightly FreeBSD testers: > > mmdevdrv.c:463:20: error: 'AFMT_S24_PACKED' undeclared (first use in this function) > mmdevdrv.c:476:16: error: 'AFMT_FLOAT' undeclared (first use in this function) > mmdevdrv.c:854:24: error: 'AFMT_FLOAT' undeclared (first use in this function) > mmdevdrv.c:863:24: error: 'AFMT_S24_PACKED' undeclared (first use in this function) > mmdevdrv.c:1084:24: error: 'SNDCTL_DSP_HALT' undeclared (first use in this function) > > Looks like some autoconfigury is not working or incomplete? This has now been broken for a week; when are you planning on fixing this, Andrew? If not, any pointers on how to best approach this? I checked, and AFMT_FLOAT is not defined in /usr/include on either my FreeBSD 8.2 tester nor my openSUSE 11.4 machine, whereas other AFMT_ strings are. Similarly for AFMT_S24_PACKED and SNDCTL_DSP_HALT. Gerald

May 5, 2011

avicap32: fix build with recent kernel headers

by Rafał Mużyło

Attached patch seems to fix build problem with recent kernel headers, where v4l1 was removed. I'm sending it here first (instead straight to wine-patches), as I have no real way of testing it - I only know it builds. As such, I haven't bothered yet with keeping consistant folding style. In case of any questions, CC me. PS.: qcap *might* need a similar, though far more complex fix.

May 5, 2011

Re: po: Update French translation

by Nicolas Le Cam

> #: regedit.rc:88 > -#, fuzzy > msgid "Modify Binary Data..." > -msgstr "Modifier les données &binaires" > +msgstr "Modifier les données &binaires..." I'm not sure you can add a keyboard accelerator if there isn't one in the original message. -- Nicolas Le Cam

May 5, 2011