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

Re: winspool.drv: Add stubs for IsValidDevmodeW and IsValidDevmodeA.
by Marvin May 9, 2011

May 9, 2011

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

1 0

Re: ddraw: Add tests for SetCooperativeLevel
by Marvin May 9, 2011

May 9, 2011

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

1 0

Re: [4/5] d3dx9: Implement D3DXMESHOPT_ATTRSORT vertex reordering.
by Matteo Bruni May 8, 2011

May 8, 2011

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.

2 2

Re: [2/5] d3dx9: Implement D3DXMESHOPT_COMPACT for ID3DXMesh::OptimizeInplace.
by Matteo Bruni May 8, 2011

May 8, 2011

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?

2 1

Re: [1/5] d3dx9: Implement ID3DXMesh::CloneMesh without vertex buffer conversion.
by Matteo Bruni May 8, 2011

May 8, 2011

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...

1 0

Re: tools: Upgrade the config.guess/config.sub scripts
by Austin English May 8, 2011

May 8, 2011

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

1 0

Re: riched20:tests Add conformance test for EM_FINDWORDBREAK function.
by André Hentschel May 8, 2011

May 8, 2011

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

2 1

Re: ntdll: Make RtlReAllocateHeap() preserve V-bit information when run under Valgrind
by Marcus Meissner May 8, 2011

May 8, 2011

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

1 0

RFC: doc for message contexts additions in PO files
by Frédéric Delanoy May 8, 2011

May 8, 2011

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. Could you please have a look and help proofread it? I'd like to ensure I didn't miss an important step. Thanks in advance. Frédéric Delanoy PS: BTW what is the reference version? en_US.po or en.po? ********* Adding one/more message contexts (ADD LINK TO EXTERNAL DOC) (QUICK MC EXPLANATION) Prerequisite: enable maintainer mode using ./configure --enable-maintainer-mode (you might have to add some development packages; check with your distribution for infos). 1. Locate strings to be "altered" Say you have in your localized po file: #: file1.rc:123 file2.rc:456 msgid "ambiguous word" msgstr "translation" and you want to disambiguate, you'd do the following 2. Find appropriate translations - check the respective rc entries (in file1.rc line 123) FOO "ambiguous word" (in file2.rc line 456) BAR "ambiguous word" and find their meaning/context (e.g. using some code browsing tools, like cscope to find references; running the program is recommanded, ...) 3. Add the messages contexts - The following syntax is used: "translation" -> "#msgctxt#your context#translation" - You end up with sthg like FOO "#msgctxt#context #ambiguous word#" Similarly BAR "#msgctxt#context 2#ambiguous word#" 3. Run 'make depend && make' 4. Edit your po file to add the new translations 5. Ideally, remove the "#, fuzzy" automatically inserted in the En_US.po reference file (and En.rc ). 6. Run 'make' again and test your changes.

2 1

Re: gdi32: Remove a set but unused variable
by Gerald Pfeifer May 7, 2011

May 7, 2011

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

1 0

Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.
by Francois Gouget May 7, 2011

May 7, 2011

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

4 4

Huge frustration
by Roland Kaeser May 7, 2011

May 7, 2011

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

5 4

Re: [1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo
by Damjan Jovanovic May 6, 2011

May 6, 2011

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

1 0

Re: [PATCH try4] wininet: Added support for persistent HTTP connections
by Alexandre Julliard May 6, 2011

May 6, 2011

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

2 1

Re: [PATCH try4] wininet: Added support for persistent HTTP connections
by Alexandre Julliard May 6, 2011

May 6, 2011

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

1 0

Re: [PATCH try4] wininet: Added support for persistent HTTP connections
by Marvin May 6, 2011

May 6, 2011

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

2 1

Re: po: Update French translation
by Nicolas Le Cam May 6, 2011

May 6, 2011

> #: 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

2 3

winscard/tests: Add test base functions of winscard.dll
by Joerg-Cyril.Hoehle＠t-systems.com May 6, 2011

May 6, 2011

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

1 0

avicap32: fix build with recent kernel headers
by Rafał Mużyło May 6, 2011

May 6, 2011

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.

2 1

Re: winscard/tests: Implement test for two functions of winscard.dll
by Marvin May 6, 2011

May 6, 2011

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

1 0

Re: winscard/tests: Implement test for two functions of winscard.dll
by Marvin May 6, 2011

May 6, 2011

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

1 0

Strange zero operation in dlls/riched20/tests/editor.c (Coverity)
by Marcus Meissner May 5, 2011

May 5, 2011

Hi Dylan, folks, Coverity sees following constructs in dlls/riched20/tests/editor.c introduced by your commit aa3b75f6b74fa87641b1f2b5912fbb82feb4c2da + SendMessage(hwndRichEdit, WM_CHAR, 22, + (MapVirtualKey('V', MAPVK_VK_TO_VSC) << 16) & 1); (several more of similar) The 4th argument is always 0 (because of (x<<16)&1). You added that Dylan, was perhaps |1 intended for a repeat count of 1? Ciao, Marcus

2 1

Re: [3/3] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load(). (try 2)
by Nikolay Sivov May 5, 2011

May 5, 2011

On 5/5/2011 00:38, Adam Martinson wrote: > > Fixes bugs 14864 + 16453. > --- > dlls/msxml3/domdoc.c | 27 +++++++++++++ > dlls/msxml3/tests/domdoc.c | 94 > +++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 120 insertions(+), 1 deletions(-) > + case VT_ARRAY|VT_UI1: > + { > + SAFEARRAY *psa = V_ARRAY(&source); > + xmlChar *str; > + LONG len; > + UINT dim = SafeArrayGetDim(psa); > + > + switch (dim) > + { > + case 0: > + ERR("SAFEARRAY == NULL\n"); > + hr = E_INVALIDARG; > + break; > + case 1: > + /* Only takes UTF8 strings. > + * NOT NULL-terminated. */ > + SafeArrayAccessData(psa, (void**)&str); > + SafeArrayGetUBound(psa, 1,&len); > + hr = load_utf8(This, str, ++len, isSuccessful); > + SafeArrayUnaccessData(psa); > + break; > + default: > + FIXME("unhandled SAFEARRAY dim: %d\n", dim); > + hr = E_NOTIMPL; > + } > + } This could be simplified. SafeArrayGetUBound will fail for case 0 for example, and unhandled dimension should be WARN, IMO.

2 3

Re: [2/3] msxml3/domdoc: Add an internal function to load from a UTF8 string.
by Nikolay Sivov May 5, 2011

May 5, 2011

On 5/5/2011 00:38, Adam Martinson wrote: > --- > dlls/msxml3/domdoc.c | 85 > +++++++++++++++++++++++++++++-------------------- > 1 files changed, 50 insertions(+), 35 deletions(-) You don't need a separate helper for that. doparse() should do fine with "UTF-8" encoding parameter to force encoding. Also will it preserve existing document or will really create empty one on error is a question.

2 3

Re: cmd: WCMD_delete: simplify logic, avoid assigning variable to i tself (try 2)
by Alexandre Julliard May 5, 2011

May 5, 2011

Dan Kegel <dank(a)kegel.com> writes: > Simpler version suggested by Henri. > I'm hoping this is enough of an improvement to be worth it. It would be better to build a simple mask and test against that, instead of all that silliness with booleans. -- Alexandre Julliard julliard(a)winehq.org

1 0