Re: winscard/tests: Add the tests file (try 3)
On Mon, Oct 31, 2011 at 23:27, Bruno Jesus <00cp...@gmail.com> wrote: > try 3 - avoid magic constants by using winscard.h defines > try 2 - split the patches and fix win2000 error > > This is the starting point for the winscard implementation. I'll add > dozens of tests and I would like all of them to pass in windows before > we start using pcsclite. > Testbot will probably be useless since it does not have a smartcard > reader connected so I'll ensure all tests succeed in my local machine > before submitting them to wine (i'll append the test results on the patch > email) > > In the next days I'll be updating the test file constantly by adding a > new tested function per patch. > Hi, I would like to know if there is anything wrong with this patch? It is currently working on testbot and introduces the tests file for the winscard dll. http://source.winehq.org/patches/data/80485 I really would like to get smart cards working until the wine l337 release. Thanks in advance, Bruno
Re: winscard/tests: Add the tests file
On Wed, Oct 26, 2011 at 11:38, Marvin wrote: > === W2KPROSP4 (32 bit winscard) === > winscard.c:53: Test failed: SCardIsValidContext expected > SCARD_E_INVALID_HANDLE, received 0006 > winscard.c:64: Test failed: SCardReleaseContext expected > SCARD_E_INVALID_HANDLE, received 0006 > It looks like Win2000 didn't have the SCARD_E_INVALID_HANDLE and instead return the win error INVALID_HANDLE (error 6). If possible and if no one finds any problem with the patch I would ask for it to be commited as is because I'll fix this in a newer patch using broken. Best wishes, Bruno
Re: winscard/tests: Add the tests file
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=15123 Your paranoid android. === W2KPROSP4 (32 bit winscard) === winscard.c:53: Test failed: SCardIsValidContext expected SCARD_E_INVALID_HANDLE, received 0006 winscard.c:64: Test failed: SCardReleaseContext expected SCARD_E_INVALID_HANDLE, received 0006
Re: [1/4] winscard: implementation
Am Donnerstag 06 Oktober 2011, 16:07:29 schrieb Bruno Jesus: > 2011/10/3 André Hentschel : > > Am 03.10.2011 09:31, schrieb Vincent Hardy: > >> First submitted on wine-devel and modified following comments from Marcus > >> Meissner (MAX_ATR_SIZE / bytecount). > >> > > > > OK, some notes: > > "winscard: implementation" is a very bad name for a patch, especially for 4. > > Splitting the patches is a good idea, but you need to split it different > > (you are adding dead code). > > In the first patch you might want to add the configure.ac and library > > loading stuff together with only the things needed for e.g. > > SCardListReadersA (why no SCardListReadersW?) and then e.g. a patch for > > every new function. > > I didn't looked at the code, but i want to remember you to read > > http://wiki.winehq.org/SubmittingPatches > > Hi to all, I would like to help Vincent to get this patches in. But we > need more objective help. The comments in this email and in previous > Vincent email differ. One says "send small patch" the other says "send > full functionality patch series". I would like to restart this thread > because otherwise it will be forgotten together with the patches. > > This is a whole new feature, in my short period into wine developing > this is the first time I see a completely new thing being introduced. > Hi, have a look at http://www.winehq.org/pipermail/wine-devel/2007-May/057057.html . There you find the reason why the patches did not go in the first time. Bye Stefan
Re: [1/4] winscard: implementation
On Thu, Oct 6, 2011 at 8:07 AM, Bruno Jesus <00cp...@gmail.com> wrote: > ... > This is a whole new feature, in my short period into wine developing > this is the first time I see a completely new thing being introduced. I'd take a look at usbd.sys, as it was introduced relatively recently. Generally for the first patch everything is just stubs: http://www.winehq.org/pipermail/wine-cvs/2010-March/065163.html I'm not sure about your other questions, but I figured that commit would at least help you get started. Erich Hoover ehoo...@mines.edu
Re: [1/4] winscard: implementation
2011/10/3 André Hentschel : > Am 03.10.2011 09:31, schrieb Vincent Hardy: >> First submitted on wine-devel and modified following comments from Marcus >> Meissner (MAX_ATR_SIZE / bytecount). >> > > OK, some notes: > "winscard: implementation" is a very bad name for a patch, especially for 4. > Splitting the patches is a good idea, but you need to split it different (you > are adding dead code). > In the first patch you might want to add the configure.ac and library loading > stuff together with only the things needed for e.g. SCardListReadersA (why no > SCardListReadersW?) and then e.g. a patch for every new function. > I didn't looked at the code, but i want to remember you to read > http://wiki.winehq.org/SubmittingPatches Hi to all, I would like to help Vincent to get this patches in. But we need more objective help. The comments in this email and in previous Vincent email differ. One says "send small patch" the other says "send full functionality patch series". I would like to restart this thread because otherwise it will be forgotten together with the patches. This is a whole new feature, in my short period into wine developing this is the first time I see a completely new thing being introduced. The first Vincent patch seems ok to me, it adds the pcsclite to configure system and loads the library. I think this first patch should be commited after the next release cycle tomorrow so we will have two weeks to implement the rest of the functions, I talked to Vincent and he agreed with me that we can send one patch per function filled with tests that probably only he and me will be able to test since we have supported readers. Is this reasonable? In the order there would be patches for ScardEstablishContext, SCardListReaders, SCardGetStatus, SCardConnect, SCardTransmit. All of them with a series os tests and skips if the reader is not available or if the card is not available avoiding failures to other users. Non-users of smart cards may think this feature is not useful but I say it's a very important step and worth a line in the news when it gets implemented. Please, help us. Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...
Re: [1/4] winscard: implementation
Am 03.10.2011 09:31, schrieb Vincent Hardy: > First submitted on wine-devel and modified following comments from Marcus > Meissner (MAX_ATR_SIZE / bytecount). > OK, some notes: "winscard: implementation" is a very bad name for a patch, especially for 4. Splitting the patches is a good idea, but you need to split it different (you are adding dead code). In the first patch you might want to add the configure.ac and library loading stuff together with only the things needed for e.g. SCardListReadersA (why no SCardListReadersW?) and then e.g. a patch for every new function. I didn't looked at the code, but i want to remember you to read http://wiki.winehq.org/SubmittingPatches -- Best Regards, André Hentschel
Re: winscard
On 9/30/2011 4:47 PM, Marcus Meissner wrote: +State = pStates[i].dwEventState& (~SCARD_STATE_CHANGED); > +rgReaderStates[i].cbAtr = pStates[i].cbAtr; > +memcpy(rgReaderStates[i].rgbAtr, pStates[i].rgbAtr, MAX_ATR_SIZE); The "MAX_ATR_SIZE" size looks wrong. Should it be perhaps pStates[i].cbAtr which seems to be the bytecount? I'll answer this since these patches are taken from my original big patch: copying cbAtr bytes makes more sens but copying MAX_ATR_SIZE is not wrong since the two buffers are of the same size and here we are just transferring all bytes from pcsclite side to the WIN32 side. That being said, maybe putting pStates[i].cbAtr will help the patches be accepted. By the way, I want to thank Vincent for taking the time to try to incorporate the winscard code into Wine. Without his dedication, this could languish for many years more! Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr
Re: winscard
On Fri, Sep 30, 2011 at 11:42:26AM +0200, Vincent Hardy wrote: > Hi all, > > Here are four patches that are a partial but functional > implementation of winscard. > > I installed "Belgian Electronic Identity Card MiddleWare" > (http://eid-mw.googlecode.com/files/BeidMW35-6995.msi) > > I tested winscard by starting beid35gui.exe and I can see my > identity card data. > > Moreover, this should help to solve this bug > http://bugs.winehq.org/show_bug.cgi?id=26978. > > Are these 4 patches good enough to be sent to wine-patch ? Patch looks largely good to me. 1 comment I have on quick review below. It is probably hard to write testcases that work without hardware, but if you can think of any, they would be welcome. > +State = pStates[i].dwEventState & (~SCARD_STATE_CHANGED); > +rgReaderStates[i].cbAtr = pStates[i].cbAtr; > +memcpy(rgReaderStates[i].rgbAtr, pStates[i].rgbAtr, > MAX_ATR_SIZE); The "MAX_ATR_SIZE" size looks wrong. Should it be perhaps pStates[i].cbAtr which seems to be the bytecount? With that clarified you could already send them to wine-patches as-is. Ciao, Marcus
Re: winscard
On 30/09/11 19:42, Vincent Hardy wrote: > > Are these 4 patches good enough to be sent to wine-patch ? Vincent, normally you would start by adding tests that can confirm the same behaviour in Windows. If you can do that and get the test accepted then you are a long closer to get your patches accepted too. As you start with the tests you need to code the tests for functions you have not implemented in the same patch as a todo wine so that the test will not break the wine test suite.
Re: winscard
On Fri, Sep 30, 2011 at 06:42, Vincent Hardy wrote: > Hi all, > > Here are four patches that are a partial but functional implementation of > winscard. Congratulations =) > I installed "Belgian Electronic Identity Card MiddleWare" > (http://eid-mw.googlecode.com/files/BeidMW35-6995.msi) > > I tested winscard by starting beid35gui.exe and I can see my identity card > data. I can help you test this (although currently I'm lacking the time to), I have 8 different contact and contactless readers and dozens of different card types. And several demo applications and full fledged hsm applications that run with over 200 smartcards at the same time =) > Moreover, this should help to solve this bug > http://bugs.winehq.org/show_bug.cgi?id=26978. > > Are these 4 patches good enough to be sent to wine-patch ? > > winscard is really useful for me and probably for other people too. I'm not used to patch reviewing but here are my comments: You don't need to check for invalid parameters on the functions, at least in most of them. pcsclite should do that by itself and for example in the SCardListreaders you don't need to interpret AUTOALLOCATE because pcsclite handles that [1]. In SCardConnect you are also checking and returning the invalid parameters error but pcsclite checks that [1]. Again with SCardStatus, I guess it should be as simple as a forward to pcsclite. You're defining MAX_ATR_SIZE 36 but the standard ISO 7816 value is 33 bytes and both pcsclite and windows winscard use 33. At least once you do HeapAlloc + memset zero, usually this can be done by passing a flag HEAP_ZERO_MEMORY to HeapAlloc. > > Vincent > [1] = http://pcsclite.alioth.debian.org/api/winscard__clnt_8c_source.html Best wishes, Bruno
winscard
Hi all,
Here are four patches that are a partial but functional implementation
of winscard.
I installed "Belgian Electronic Identity Card MiddleWare"
(http://eid-mw.googlecode.com/files/BeidMW35-6995.msi)
I tested winscard by starting beid35gui.exe and I can see my identity
card data.
Moreover, this should help to solve this bug
http://bugs.winehq.org/show_bug.cgi?id=26978.
Are these 4 patches good enough to be sent to wine-patch ?
winscard is really useful for me and probably for other people too.
Vincent
>From 28e9922180f6124c0387d853fecf5cf3a6c841ba Mon Sep 17 00:00:00 2001
From: Vincent Hardy
Date: Fri, 30 Sep 2011 09:57:36 +0200
Subject: [PATCH 1/4] winscard implementation (1/4)
---
configure.ac | 3 ++
dlls/winscard/winscard.c | 67 ++
2 files changed, 70 insertions(+), 0 deletions(-)
mode change 100644 => 100755 configure.ac
mode change 100644 => 100755 dlls/winscard/winscard.c
diff --git a/configure.ac b/configure.ac
old mode 100644
new mode 100755
index 1401072..4b02330
--- a/configure.ac
+++ b/configure.ac
@@ -1643,6 +1643,9 @@ fi
dnl Check for libodbc
WINE_CHECK_SONAME(odbc,SQLConnect,,[AC_DEFINE_UNQUOTED(SONAME_LIBODBC,["libodbc.$LIBEXT"])])
+dnl Check for libpcsclite
+WINE_CHECK_SONAME(pcsclite,SCardEstablishContext,,[AC_DEFINE_UNQUOTED(SONAME_LIBPCSCLITE,["libpcsclite.$LIBEXT"])])
+
dnl Disable unsupported winmm drivers
test -n "$ALSALIBS" || enable_winealsa_drv=${enable_winealsa_drv:-no}
test -n "$COREAUDIO" || enable_winecoreaudio_drv=${enable_winecoreaudio_drv:-no}
diff --git a/dlls/winscard/winscard.c b/dlls/winscard/winscard.c
old mode 100644
new mode 100755
index 412299c..6d07890
--- a/dlls/winscard/winscard.c
+++ b/dlls/winscard/winscard.c
@@ -17,16 +17,36 @@
*/
#include "config.h"
+#include "wine/port.h"
#include
#include "windef.h"
#include "winbase.h"
#include "wine/debug.h"
+#include "wine/library.h"
#include "winscard.h"
#include "winternl.h"
+static BOOL PCSCLite_loadlib(void);
+static void PCSCLite_loadfunctions(void);
+
WINE_DEFAULT_DEBUG_CHANNEL(winscard);
+static LONG (*pSCardEstablishContext)(DWORD dwScope, LPCVOID pvReserved1, LPCVOID pvReserved2, LPSCARDCONTEXT phContext);
+static LONG (*pSCardIsValidContext)(SCARDCONTEXT hContext);
+static LONG (*pSCardReleaseContext)(SCARDCONTEXT hContext);
+static LONG (*pSCardListReaders)(SCARDCONTEXT hContext, LPCSTR mszGroups, LPSTR mszReaders, LPDWORD pcchReaders);
+static LONG (*pSCardCancel)(SCARDCONTEXT hContext);
+static LONG (*pSCardGetStatusChange)(SCARDCONTEXT hContext, DWORD dwTimeout, LPSCARD_READERSTATEA rgReaderStates, DWORD cReaders);
+static LONG (*pSCardStatus)(SCARDHANDLE hCard, LPSTR mszReaderNames, LPDWORD pcchReaderLen, LPDWORD pdwState, LPDWORD pdwProtocol, BYTE* pbAtr, LPDWORD pcbAtrLen);
+static LONG (*pSCardGetAttrib)(SCARDHANDLE hCard, DWORD dwAttrId, BYTE* pbAttr, LPDWORD pcbAttrLen);
+static LONG (*pSCardConnect)(SCARDCONTEXT hContext, LPCSTR szReader, DWORD dwShareMode, DWORD dwPreferredProtocols, LPSCARDHANDLE phCard, LPDWORD pdwActiveProtocol);
+static LONG (*pSCardDisconnect)(SCARDHANDLE hCard, DWORD dwDisposition);
+static LONG (*pSCardBeginTransaction)(SCARDHANDLE hCard);
+static LONG (*pSCardTransmit)(SCARDHANDLE hCard, LPCSCARD_IO_REQUEST pioSendPci, const BYTE* pbSendBuffer, DWORD cbSendLength, LPSCARD_IO_REQUEST pioRecvPci, BYTE* pbRecvBuffer, LPDWORD pcbRecvLength);
+static LONG (*pSCardEndTransaction)(SCARDHANDLE hCard, DWORD disposition);
+
static HMODULE WINSCARD_hModule;
+static void *g_pcscliteHandle;
static HANDLE g_startedEvent = NULL;
const SCARD_IO_REQUEST g_rgSCardT0Pci = { SCARD_PROTOCOL_T0, 8 };
@@ -44,6 +64,10 @@ BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
DisableThreadLibraryCalls(hinstDLL);
WINSCARD_hModule = hinstDLL;
+
+if (PCSCLite_loadlib())
+PCSCLite_loadfunctions();
+
/* FIXME: for now, we act as if the pcsc daemon is always started */
g_startedEvent = CreateEventA(NULL,TRUE,TRUE,NULL);
break;
@@ -51,6 +75,10 @@ BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
case DLL_PROCESS_DETACH:
{
CloseHandle(g_startedEvent);
+
+ if (g_pcscliteHandle)
+wine_dlclose(g_pcscliteHandle, NULL, 0);
+
break;
}
}
@@ -58,6 +86,45 @@ BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
return TRUE;
}
+static BOOL PCSCLite_loadlib(void)
+{
+char error[256];
+
+g_pcscliteHandle = wine_dlopen(SONAME_LIBPCSCLITE, RTLD_LAZY | RTLD_GLOBAL, error, sizeof(error));
+if (g_pcscliteHandle)
+return TRUE;
+else
+
Re: winscard: Implement some functions of winscard.dll
Sergey Stepanov writes:
> @@ -33,6 +35,24 @@ const SCARD_IO_REQUEST g_rgSCardT0Pci = {
> SCARD_PROTOCOL_T0, 8 };
> const SCARD_IO_REQUEST g_rgSCardT1Pci = { SCARD_PROTOCOL_T1, 8 };
> const SCARD_IO_REQUEST g_rgSCardRawPci = { SCARD_PROTOCOL_RAW, 8 };
>
> +#define MAKE_FUNCPTR(f) static typeof(f) * p##f = NULL
> +MAKE_FUNCPTR(SCardEstablishContext);
> +MAKE_FUNCPTR(SCardReleaseContext);
> +#undef MAKE_FUNCPTR
This can't work. You need to use the Unix headers (with appropriate
configure checks), declare pointers to the Unix functions, and convert
any types that need it before calling them.
--
Alexandre Julliard
julli...@winehq.org
winscard: Implement some functions of winscard.dll
Hi Sergey, #include "config.h" +#include #include This change will cause compile failures on systems without this header. You need to add a configure check for the header, and include it conditionally. Thanks, --Juan
winscard/tests: Add test base functions of winscard.dll
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 0x
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
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 000..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
+
+@MAKE_TEST_RULES@
diff --git a/dlls/winscard/tests/scard.c b/dlls/winscard/tests/scard.c
new file mode 100644
index 000..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
Re: winscard/tests: Implement test for two functions of winscard.dll
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
Re: winscard/tests: Implement test for two functions of winscard.dll
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
Re: winscard/tests: Add test base functions of winscard.dll
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=10722 Your paranoid android. === WINEBUILD (build) === Make failed
Re: winscard
Am 21.01.2011 09:53, schrieb vince: > Hi all, > > I'm back with a smaller and reworked winscard patch. > > In respond to Vitaly Margolen > (http://www.winehq.org/pipermail/wine-devel/2010-September/087017.html) > 1. I used configure to get the so name of the library. > 2. I removed trailing spaces. > 3. When this patch is approved, I will make a new patch for SCardListReadersA. > > Is this patch ready for wine-patch ? > > Thanks for your help. > > Vincent. > > > > Doesn't look bad, but have a look at whitespace adding. -- Best Regards, André Hentschel
winscard
Hi all,
I'm back with a smaller and reworked winscard patch.
In respond to Vitaly Margolen
(http://www.winehq.org/pipermail/wine-devel/2010-September/087017.html)
1. I used configure to get the so name of the library.
2. I removed trailing spaces.
3. When this patch is approved, I will make a new patch for
SCardListReadersA.
Is this patch ready for wine-patch ?
Thanks for your help.
Vincent.
>From 5045344418419168536fcea320115ee45618fa77 Mon Sep 17 00:00:00 2001
From: Vincent Hardy
Date: Fri, 21 Jan 2011 09:36:29 +0100
Subject: Loading PCSC-Lite library
---
configure.ac |3 +++
dlls/winscard/winscard.c | 42 ++
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4d049b6..c6a1714 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1638,6 +1638,9 @@ fi
dnl Check for libodbc
WINE_CHECK_SONAME(odbc,SQLConnect,,[AC_DEFINE_UNQUOTED(SONAME_LIBODBC,["libodbc.$LIBEXT"])])
+dnl Check for libpcsclite
+WINE_CHECK_SONAME(pcsclite,SCardEstablishContext,,[AC_DEFINE_UNQUOTED(SONAME_LIBPCSCLITE,["libpcsclite.$LIBEXT"])])
+
dnl Check for any sound system
if test "x$ALSALIBS$COREAUDIO$NASLIBS$ESDLIBS$ac_cv_lib_soname_jack" = "x" -a \
"$ac_cv_header_sys_soundcard_h" != "yes" -a \
diff --git a/dlls/winscard/winscard.c b/dlls/winscard/winscard.c
index 412299c..4dac49e 100644
--- a/dlls/winscard/winscard.c
+++ b/dlls/winscard/winscard.c
@@ -17,16 +17,22 @@
*/
#include "config.h"
+#include "wine/port.h"
#include
#include "windef.h"
#include "winbase.h"
#include "wine/debug.h"
+#include "wine/library.h"
#include "winscard.h"
#include "winternl.h"
+static BOOL PCSCLite_loadlib(void);
+static BOOL PCSCLite_loadfunctions(void);
+
WINE_DEFAULT_DEBUG_CHANNEL(winscard);
static HMODULE WINSCARD_hModule;
+static void *g_pcscliteHandle = NULL;
static HANDLE g_startedEvent = NULL;
const SCARD_IO_REQUEST g_rgSCardT0Pci = { SCARD_PROTOCOL_T0, 8 };
@@ -44,13 +50,24 @@ BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
DisableThreadLibraryCalls(hinstDLL);
WINSCARD_hModule = hinstDLL;
+
+if (PCSCLite_loadlib())
+PCSCLite_loadfunctions();
+
/* FIXME: for now, we act as if the pcsc daemon is always started */
g_startedEvent = CreateEventA(NULL,TRUE,TRUE,NULL);
+
break;
}
case DLL_PROCESS_DETACH:
{
CloseHandle(g_startedEvent);
+
+if (g_pcscliteHandle)
+{
+wine_dlclose(g_pcscliteHandle,NULL,0);
+g_pcscliteHandle = NULL;
+}
break;
}
}
@@ -58,6 +75,31 @@ BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
return TRUE;
}
+static BOOL PCSCLite_loadlib(void)
+{
+char error[256];
+
+if (g_pcscliteHandle)
+return TRUE; /*already loaded*/
+else
+{
+g_pcscliteHandle = wine_dlopen(SONAME_LIBPCSCLITE, RTLD_LAZY | RTLD_GLOBAL, error, sizeof(error));
+if (g_pcscliteHandle)
+return TRUE;
+else
+{
+WARN("Failed to open library %s : %s\n", debugstr_a(SONAME_LIBPCSCLITE), error);
+return FALSE;
+}
+}
+}
+
+static BOOL PCSCLite_loadfunctions(void)
+{
+FIXME("%s\n", SONAME_LIBPCSCLITE);
+return TRUE;
+}
+
HANDLE WINAPI SCardAccessStartedEvent(void)
{
return g_startedEvent;
--
1.7.3.4
Re: winscard: add pcsc-lite helpers for upcoming(?) implementation
> To my knowledge the integration of the patches by Mounir IDRASSI has been > rejected due to missing automated tests. This is a problem since for a full > test someone has to write/provide an IFD handler which emulates some stuff. IIRC, there was also a problem with the way it integration was done. It assumed the types between the Windows scard API and the Linux one were compatible, but in fact they may not be. I don't recall that this was ever addressed. --Juan
Re: winscard: add pcsc-lite helpers for upcoming(?) implementation
To my knowledge the integration of the patches by Mounir IDRASSI has been rejected due to missing automated tests. This is a problem since for a full test someone has to write/provide an IFD handler which emulates some stuff. So far I haven't found some kind of virtual card reader - maybe attached to a virtual USB hub. Regards Heiko Am Freitag, 13. November 2009 09:32:24 schrieb viny: > joerg-cyril.hoe...@t-systems.com a écrit : > > Hi, > > > > looking for PCSC-card-reader support in Wine, I came across old mails > > from 2007. > > http://www.winehq.org/pipermail/wine-devel/2007-May/057052.html > > > > What's the current state of PCSC support in Wine? When I recently looked, > > winscard seemed full of stubs. > > > > OTOH, there's a company > > http://www.starmoney.de/index.php?id=243 > > that seems to use Wine (and Darwine?) with card readers to make > > its software available for Linux & Mac. Also seems ~2007. > > > > I believe that a winscard<->PCSC<->PCSC-Lite bridge would be much > > easier to achieve than USB support in Wine. > > > > Thanks for your help, > > Jörg Höhle > > Hi, > > There is a working binary winscard.dll for wine here : > > http://www.idrix.fr/Root/SCard4Wine/winscard.tar.gz > > But I'm waiting for official wine winscard too !
Re: winscard: add pcsc-lite helpers for upcoming(?) implementation
joerg-cyril.hoe...@t-systems.com a écrit : Hi, looking for PCSC-card-reader support in Wine, I came across old mails from 2007. http://www.winehq.org/pipermail/wine-devel/2007-May/057052.html What's the current state of PCSC support in Wine? When I recently looked, winscard seemed full of stubs. OTOH, there's a company http://www.starmoney.de/index.php?id=243 that seems to use Wine (and Darwine?) with card readers to make its software available for Linux & Mac. Also seems ~2007. I believe that a winscard<->PCSC<->PCSC-Lite bridge would be much easier to achieve than USB support in Wine. Thanks for your help, Jörg Höhle Hi, There is a working binary winscard.dll for wine here : http://www.idrix.fr/Root/SCard4Wine/winscard.tar.gz But I'm waiting for official wine winscard too !
winscard: add pcsc-lite helpers for upcoming(?) implementation
Hi, looking for PCSC-card-reader support in Wine, I came across old mails from 2007. http://www.winehq.org/pipermail/wine-devel/2007-May/057052.html What's the current state of PCSC support in Wine? When I recently looked, winscard seemed full of stubs. OTOH, there's a company http://www.starmoney.de/index.php?id=243 that seems to use Wine (and Darwine?) with card readers to make its software available for Linux & Mac. Also seems ~2007. I believe that a winscard<->PCSC<->PCSC-Lite bridge would be much easier to achieve than USB support in Wine. Thanks for your help, Jörg Höhle
Re: integration of winscard patches: ideas for implementing test cases?
On Fri, Nov 7, 2008 at 10:27 AM, frechdachs69 <[EMAIL PROTECTED]> wrote: > I am currently wondering which test cases make sense after an integration of > winscard patches. So far most API calls are directly related to pcsc-lite > behaviour and therefore we need a result from pcsc-lite which is comparable > with what Win/winscard.dll would return to us. But this is almost always > depending on the smartcard reader setup at the local machine. As a result I > see a problem to automate such tests without having underlying assumptions > concerning the attached smartcard readers and maybe inserted (or not) You might test whether a card is present, and skip tests if it's not. > smartcards (i.e. specific hardware is necessary). Any ideas? Does anyone know > whether someone has written a virtual card reader which can be accessed using > pcsc-lite (i.e. an IFD handler exists which simulates reader behaviour)? http://lists.drizzle.com/pipermail/muscle/2007-July/006635.html says it points to the source code for one... - Dan
integration of winscard patches: ideas for implementing test cases?
Hi together! I am currently wondering which test cases make sense after an integration of winscard patches. So far most API calls are directly related to pcsc-lite behaviour and therefore we need a result from pcsc-lite which is comparable with what Win/winscard.dll would return to us. But this is almost always depending on the smartcard reader setup at the local machine. As a result I see a problem to automate such tests without having underlying assumptions concerning the attached smartcard readers and maybe inserted (or not) smartcards (i.e. specific hardware is necessary). Any ideas? Does anyone know whether someone has written a virtual card reader which can be accessed using pcsc-lite (i.e. an IFD handler exists which simulates reader behaviour)? Maybe together with the option to insert a virtual card? If not then I am going to subscribe to the pcsc-lite maling list and ask this question there, too. Any other ideas how to automate winscard tests to be able to add such tests to the regression test suite? Regards Heiko
Re: Winscard: Correct the declaration of SCardReleaseStartedEvent to match MSDN
Hi, You're right: I have done a small test and MSDN is indeed wrong on the definition of this function. Sorry for my erroneous patch. -- Mounir IDRASSI IDRIX http://www.idrix.fr On Wed, August 27, 2008 4:43 am, Dmitry Timoshkov wrote: > "Mounir IDRASSI" <[EMAIL PROTECTED]> wrote: > >> This patch corrects the declaration of the function >> SCardReleaseStartedEvent of Winscard to match its definition in MSDN >> found >> in the following link : >> >> http://msdn.microsoft.com/en-us/library/aa379799(VS.85).aspx > >> -voidWINAPI SCardReleaseStartedEvent(void); >> +voidWINAPI SCardReleaseStartedEvent(HANDLE); > > This doesn't match an actual declaration used by PSDK. It's better to > use PSDK for a reference, not an online documentation since the latter > one is proved to have many typos. > > -- > Dmitry. >
Re: Winscard: Correct the declaration of SCardReleaseStartedEvent to match MSDN
"Mounir IDRASSI" <[EMAIL PROTECTED]> wrote: > This patch corrects the declaration of the function > SCardReleaseStartedEvent of Winscard to match its definition in MSDN found > in the following link : > > http://msdn.microsoft.com/en-us/library/aa379799(VS.85).aspx > -voidWINAPI SCardReleaseStartedEvent(void); > +voidWINAPI SCardReleaseStartedEvent(HANDLE); This doesn't match an actual declaration used by PSDK. It's better to use PSDK for a reference, not an online documentation since the latter one is proved to have many typos. -- Dmitry.
Re: winscard: add pcsc-lite helpers for upcoming implementation (try 2)
Mounir IDRASSI <[EMAIL PROTECTED]> writes: > Actually, pcsc-lite defines the same headers from PSDK with the same > types for 32bit architecture. Including pcsclite headers will clash with > wine's headers. The only possible modification is to redefine pcsclite > types with different names but this is useless as they are the same as > the ones in winscard. Unfortunately they aren't, the pcsclite headers use unsigned long instead of DWORD for instance. This won't have the same size on 64-bit. -- Alexandre Julliard [EMAIL PROTECTED]
Re: winscard: add pcsc-lite helpers for upcoming implementation (try 2)
Actually, pcsc-lite defines the same headers from PSDK with the same types for 32bit architecture. Including pcsclite headers will clash with wine's headers. The only possible modification is to redefine pcsclite types with different names but this is useless as they are the same as the ones in winscard. The only exception is for winscard handles: in pcsclite they are always defined as "long", whereas in PSDK they are defined as ULONG_PTR. So, for me, the only thing to do is convert those handles back and forth from long to ULONG_PTR. Another possible issue is when wine is running under a 64bit host and pcsclite is compiled on 64bit mode...but I think this is a more global issue. Am I missing something? Please advise. Thanks. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Alexandre Julliard wrote: > I don't think the pcsc-lite library is guaranteed to be binary > compatible with the Windows definitions. You'll need to include the > correct headers and convert data types between Windows and Unix > definitions. >
Re: winscard: add pcsc-lite helpers for upcoming implementation (try 2)
Mounir IDRASSI <[EMAIL PROTECTED]> writes: > +/* > + * pcsc-lite functions pointers > + */ > +typedef LONG (*SCardEstablishContextPtr)(DWORD dwScope,LPCVOID pvReserved1, > +LPCVOID pvReserved2, LPSCARDCONTEXT phContext); > +typedef LONG (*SCardReleaseContextPtr)(SCARDCONTEXT hContext); > +typedef LONG (*SCardIsValidContextPtr)(SCARDCONTEXT hContext); > +typedef LONG (*SCardSetTimeoutPtr)(SCARDCONTEXT hContext, DWORD dwTimeout); > +typedef LONG (*SCardConnectPtr)(SCARDCONTEXT hContext,LPCSTR szReader,DWORD > dwShareMode, > +DWORD dwPreferredProtocols,LPSCARDHANDLE phCard, LPDWORD > pdwActiveProtocol); > +typedef LONG (*SCardReconnectPtr)(SCARDHANDLE hCard,DWORD dwShareMode, > +DWORD dwPreferredProtocols,DWORD dwInitialization, LPDWORD > pdwActiveProtocol); > +typedef LONG (*SCardDisconnectPtr)(SCARDHANDLE hCard, DWORD dwDisposition); > +typedef LONG (*SCardBeginTransactionPtr)(SCARDHANDLE hCard); > +typedef LONG (*SCardEndTransactionPtr)(SCARDHANDLE hCard, DWORD > dwDisposition); > +typedef LONG (*SCardCancelTransactionPtr)(SCARDHANDLE hCard); > +typedef LONG (*SCardStatusPtr)(SCARDHANDLE hCard,LPSTR mszReaderNames, > LPDWORD pcchReaderLen, > +LPDWORD pdwState,LPDWORD pdwProtocol,BYTE* pbAtr,LPDWORD pcbAtrLen); > +typedef LONG (*SCardGetStatusChangePtr)(SCARDCONTEXT hContext,DWORD > dwTimeout, > +LPSCARD_READERSTATEA rgReaderStates, DWORD cReaders); > +typedef LONG (*SCardControlPtr)(SCARDHANDLE hCard, DWORD dwControlCode, > LPCVOID pbSendBuffer, > +DWORD cbSendLength,LPVOID pbRecvBuffer, DWORD cbRecvLength, LPDWORD > lpBytesReturned); > +typedef LONG (*SCardTransmitPtr)(SCARDHANDLE hCard,LPCSCARD_IO_REQUEST > pioSendPci, > +const BYTE* pbSendBuffer, DWORD cbSendLength, > +LPSCARD_IO_REQUEST pioRecvPci, BYTE* pbRecvBuffer, LPDWORD > pcbRecvLength); > +typedef LONG (*SCardListReaderGroupsPtr)(SCARDCONTEXT hContext,LPSTR > mszGroups, LPDWORD pcchGroups); > +typedef LONG (*SCardListReadersPtr)(SCARDCONTEXT hContext,LPCSTR mszGroups, > +LPSTR mszReaders, LPDWORD pcchReaders); > +typedef LONG (*SCardCancelPtr)(SCARDCONTEXT hContext); > +typedef LONG (*SCardGetAttribPtr)(SCARDHANDLE hCard, DWORD dwAttrId,BYTE* > pbAttr, LPDWORD pcbAttrLen); > +typedef LONG (*SCardSetAttribPtr)(SCARDHANDLE hCard, DWORD dwAttrId,const > BYTE* pbAttr, DWORD cbAttrLen); I don't think the pcsc-lite library is guaranteed to be binary compatible with the Windows definitions. You'll need to include the correct headers and convert data types between Windows and Unix definitions. -- Alexandre Julliard [EMAIL PROTECTED]
re: winscard: add pcsc-lite helpers for upcoming implementation
The code is definitely cleaner with all your suggestions. I'm applying
them now.
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
> James wrote:
>> This would be a lot cleaner as:
>>
>> if (!(liteSCardEstablishContext = (SCardEstablishContextPtr)
>> wine_dlsym(g_pcscliteHandle,"SCardEstablishContext",szErr,sizeof(szErr)))
>> {
>>ERR("Failed to get SCardEstablishContext from pcsclite library. Error
>> = %s\n",szErr);
>>goto error;
>> }
>
> I think in C you can skip the cast from void *, can't you? e.g.
>
> liteSCardEstablishContext =
> wine_dlsym(g_pcscliteHandle,"SCardEstablishContext",szErr,sizeof(szErr));
Re: winscard: add pcsc-lite helpers for upcoming implementation
Thanks for your comments Juan.
Actually, the upcoming implementation checks the used function pointer at
each call and returns an error if not assigned. Also in it, winscard
always succeed to load even if pcsc-lite is not running. FYI, my first
winscard patch contains an advanced stage of the whole implementation.
Concerning the BOOL return value, it's here for "historical" reasons. I'll
remove it.
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://.idrix.fr
> +BOOL InitializePCSCLite(void)
>
> You don't use the return value:
>
> @@ -42,9 +43,11 @@ BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD
> fdwReason, LPVOID lpvReserved)
> {
> DisableThreadLibraryCalls(hinstDLL);
> WINSCARD_hModule = hinstDLL;
> +InitializePCSCLite();
> break;
> }
>
> I suspect it's safer not to fail loading winscard if PCSC-Lite isn't
> available. Instead, the functions such as SCardListCards should probably
> return empty lists. But knowing to do so relies on knowing that PCSC-Lite
> couldn't be initialized, so the return value shouldn't be thrown away.
> Or, remove the return value, and have every function check the function
> pointers it needs.
>
> --Juan
Re: winscard: add pcsc-lite helpers for upcoming implementation
+BOOL InitializePCSCLite(void)
You don't use the return value:
@@ -42,9 +43,11 @@ BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD
fdwReason, LPVOID lpvReserved)
{
DisableThreadLibraryCalls(hinstDLL);
WINSCARD_hModule = hinstDLL;
+InitializePCSCLite();
break;
}
I suspect it's safer not to fail loading winscard if PCSC-Lite isn't
available. Instead, the functions such as SCardListCards should probably
return empty lists. But knowing to do so relies on knowing that PCSC-Lite
couldn't be initialized, so the return value shouldn't be thrown away.
Or, remove the return value, and have every function check the function
pointers it needs.
--Juan
Sick
sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222
re: winscard: add pcsc-lite helpers for upcoming implementation
James wrote:
This would be a lot cleaner as:
if (!(liteSCardEstablishContext = (SCardEstablishContextPtr)
wine_dlsym(g_pcscliteHandle,"SCardEstablishContext",szErr,sizeof(szErr)))
{
ERR("Failed to get SCardEstablishContext from pcsclite library. Error =
%s\n",szErr);
goto error;
}
I think in C you can skip the cast from void *, can't you? e.g.
liteSCardEstablishContext =
wine_dlsym(g_pcscliteHandle,"SCardEstablishContext",szErr,sizeof(szErr));
if (!liteSCardEstablishContext)
{
ERR("Failed to get SCardEstablishContext from pcsclite library.
Error = %s\n",szErr);
goto error;
}
--
Wine for Windows ISVs: http://kegel.com/wine/isv
Re: winscard: add pcsc-lite helpers for upcoming implementation
On 5/23/07, Mounir IDRASSI <[EMAIL PROTECTED]> wrote:
Hi,
This patch adds helper variables and functions that exposes pcsc-lite
functionalities for the use of the upcoming implementation.
+/* loading entry points*/
+bSuccess = TRUE;
+if (bSuccess &&
+!(liteSCardEstablishContext =
(SCardEstablishContextPtr)
wine_dlsym(g_pcscliteHandle,"SCardEstablishContext",szErr,sizeof(szErr
+{
+bSuccess = FALSE;
+ERR("Failed to get SCardEstablishContext from
pcsclite library. Error = %s\n",szErr);
+}
This would be a lot cleaner as:
if (!(liteSCardEstablishContext = (SCardEstablishContextPtr)
wine_dlsym(g_pcscliteHandle,"SCardEstablishContext",szErr,sizeof(szErr)))
{
ERR("Failed to get SCardEstablishContext from pcsclite library.
Error = %s\n",szErr);
goto error;
}
return TRUE;
error:
wine_dlclose(g_pcscliteHandle,NULL,0);
g_pcscliteHandle = NULL;
return FALSE;
}
--
James Hawkins
Re: winscard: small stub implementation of winscard dll (Try 2)
Hi Alexandre, You are completely right...these variables are definitely useless!! I don't remember when I coded that but it must have been very late at night! Anyway, I'll purge them from the patch. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Alexandre Julliard wrote: > Mounir IDRASSI <[EMAIL PROTECTED]> writes: >> Thank you for your comments Alexandre. >> Concerning the SCARD_PCI_xxx , I implemented them as variables instead >> of defines because it's impossible using winelib to link against the >> exported variables g_rgSCardXXX (please see my discussion with Eric >> Pouech about that). Well, I should create variables with other names to >> achieve the same goal. >> > Linking against SCARD_PCI_xxx would be just as impossible, so I still > don't understand why you need any extra variables. Could you give an > example? >
Re: winscard: small stub implementation of winscard dll (Try 2)
Mounir IDRASSI <[EMAIL PROTECTED]> writes:
> +BOOL WINAPI DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
> +{
> +TRACE("%p,%x,%p\n", hinstDLL, fdwReason, lpvReserved);
> +
> +switch (fdwReason)
> +{
> +case DLL_PROCESS_ATTACH:
> +{
> + DisableThreadLibraryCalls(hinstDLL);
> + WINSCARD_hModule = hinstDLL;
> + /* initialize protocol requests pointers */
> +SCARD_PCI_T0 = &g_rgSCardT0Pci;
> +SCARD_PCI_T1 = &g_rgSCardT1Pci;
> + SCARD_PCI_RAW = &g_rgSCardRawPci;
AFAICT these are supposed to be macros, not variables. Also your
indentation is messed up.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: winscard stub dll
Hi Francois, Thanks for your modifications. I'll review your patch and submit it if I have no comments, ِCheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Francois Gouget wrote: > Hi, > > Here's a new version of the patch that removes the casts as suggested > by Alexandre. >
Re: winscard stub dll
Hi, Mounir IDRASSI wrote: Hi, Apart from Alexandre comment, I don't see any other possible changes. Here's a new version of the patch that removes the casts as suggested by Alexandre. -- Francois Gouget [EMAIL PROTECTED] commit 86fd1bdb35906c5601ff9b44ac2cbd6c35cdfbd9 Author: Francois Gouget <[EMAIL PROTECTED]> Date: Wed May 16 02:45:51 2007 +0200 winscard: Add a stub dll (initial implementation by Mounir IDRASSI, bugs by Francois Gouget). diff --git a/Makefile.in b/Makefile.in index 30e0581..eb5307f 100644 --- a/Makefile.in +++ b/Makefile.in @@ -417,6 +417,7 @@ ALL_MAKEFILES = \ dlls/winmm/Makefile \ dlls/winmm/tests/Makefile \ dlls/winnls32/Makefile \ + dlls/winscard/Makefile \ dlls/winspool.drv/Makefile \ dlls/winspool.drv/tests/Makefile \ dlls/wintab32/Makefile \ @@ -763,6 +764,7 @@ dlls/wininet/tests/Makefile: dlls/wininet/tests/Makefile.in dlls/Maketest.rules dlls/winmm/Makefile: dlls/winmm/Makefile.in dlls/Makedll.rules dlls/winmm/tests/Makefile: dlls/winmm/tests/Makefile.in dlls/Maketest.rules dlls/winnls32/Makefile: dlls/winnls32/Makefile.in dlls/Makedll.rules +dlls/winscard/Makefile: dlls/winscard/Makefile.in dlls/Makedll.rules dlls/winspool.drv/Makefile: dlls/winspool.drv/Makefile.in dlls/Makedll.rules dlls/winspool.drv/tests/Makefile: dlls/winspool.drv/tests/Makefile.in dlls/Maketest.rules dlls/wintab32/Makefile: dlls/wintab32/Makefile.in dlls/Makedll.rules diff --git a/configure b/configure index d322b0e..712a3be 100755 --- a/configure +++ b/configure @@ -20903,6 +20903,8 @@ ac_config_files="$ac_config_files dlls/winmm/tests/Makefile" ac_config_files="$ac_config_files dlls/winnls32/Makefile" +ac_config_files="$ac_config_files dlls/winscard/Makefile" + ac_config_files="$ac_config_files dlls/winspool.drv/Makefile" ac_config_files="$ac_config_files dlls/winspool.drv/tests/Makefile" @@ -21872,6 +21874,7 @@ do "dlls/winmm/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winmm/Makefile" ;; "dlls/winmm/tests/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winmm/tests/Makefile" ;; "dlls/winnls32/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winnls32/Makefile" ;; +"dlls/winscard/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winscard/Makefile" ;; "dlls/winspool.drv/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winspool.drv/Makefile" ;; "dlls/winspool.drv/tests/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winspool.drv/tests/Makefile" ;; "dlls/wintab32/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/wintab32/Makefile" ;; diff --git a/configure.ac b/configure.ac index 52323c7..6ad89eb 100644 --- a/configure.ac +++ b/configure.ac @@ -1747,6 +1747,7 @@ AC_CONFIG_FILES([dlls/wininet/tests/Makefile]) AC_CONFIG_FILES([dlls/winmm/Makefile]) AC_CONFIG_FILES([dlls/winmm/tests/Makefile]) AC_CONFIG_FILES([dlls/winnls32/Makefile]) +AC_CONFIG_FILES([dlls/winscard/Makefile]) AC_CONFIG_FILES([dlls/winspool.drv/Makefile]) AC_CONFIG_FILES([dlls/winspool.drv/tests/Makefile]) AC_CONFIG_FILES([dlls/wintab32/Makefile]) diff --git a/dlls/Makefile.in b/dlls/Makefile.in index f9707e7..31f3ef8 100644 --- a/dlls/Makefile.in +++ b/dlls/Makefile.in @@ -205,6 +205,7 @@ BASEDIRS = \ wininet \ winmm \ winnls32 \ + winscard \ winspool.drv \ wintab32 \ wintrust \ @@ -571,6 +572,7 @@ IMPORT_LIBS = \ wininet/libwininet.$(IMPLIBEXT) \ winmm/libwinmm.$(IMPLIBEXT) \ winnls32/libwinnls32.$(IMPLIBEXT) \ + winscard/libwinscard.$(IMPLIBEXT) \ winspool.drv/libwinspool.$(IMPLIBEXT) \ wintab32/libwintab32.$(IMPLIBEXT) \ wintrust/libwintrust.$(IMPLIBEXT) \ @@ -920,6 +922,9 @@ winmm/libwinmm.$(IMPLIBEXT): winmm/winmm.spec $(WINEBUILD) winnls32/libwinnls32.$(IMPLIBEXT): winnls32/winnls32.spec $(WINEBUILD) @cd winnls32 && $(MAKE) libwinnls32.$(IMPLIBEXT) + +winscard/libwinscard.$(IMPLIBEXT): winscard/winscard.spec $(WINEBUILD) + @cd winscard && $(MAKE) libwinscard.$(IMPLIBEXT) winspool.drv/libwinspool.$(IMPLIBEXT): winspool.drv/winspool.drv.spec $(WINEBUILD) @cd winspool.drv && $(MAKE) libwinspool.$(IMPLIBEXT) diff --git a/dlls/winscard/Makefile.in b/dlls/winscard/Makefile.in new file mode 100644 index 000..9ce7ad6 --- /dev/null +++ b/dlls/winscard/Makefile.in @@ -0,0 +1,20 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR= @srcdir@ +VPATH = @srcdir@ +MODULE= winscard.dll +IMPORTLIB = libwinscard.$(IMPLIBEXT) +IMPORTS = kernel32 + +C_SRCS = \ + scarddb.c \ + scardcomm.c \ + scardtracking.c \ + winscard.c + +RC_SRCS = \ + rsrc.rc + [EMAIL PROTECTED]@ + [EMAIL PROTECTED]@ # everything below this line is overwritten by make depend diff --git a/dlls/winscard/rsrc.rc b/dlls/winscard/rsrc.rc new file mode 100644 index 000..8226e9d --- /dev/null +++ b/dlls/winscard/rsrc.rc @@ -0,0 +1,33 @@ +/* + * Top le
Re: winscard stub dll
Hi, Apart from Alexandre comment, I don't see any other possible changes. So, if the first patch containing the API headers is OK, I can submit the winscard stub patch. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Alexandre Julliard wrote: > Francois Gouget <[EMAIL PROTECTED]> writes: > > >> * I would really have liked to get rid of the (unsigneg int) casts, but >> as the handle types are ULONG_PTRs it seems like it won't be possible. >> That's quite annoying. If anyone has suggestions... >> > > ULONG_PTRs are longs, they should be printed with %lx without casts. > >
Re: winscard stub dll
Francois Gouget <[EMAIL PROTECTED]> writes: > But then on a 64bit system an __int64 should be the same as a long so > maybe it's ok anyway. Yes, __int64 is a long on Win64. > The only issue that could happen is if we try to compile Wine's dlls > on a 64bit Windows system using Visual C++. Isn't a long 32bit in > Visual C++? Is this a case we care about? No we don't really care, but anyway I don't think Visual C++ is smart enough to warn on printf formats. -- Alexandre Julliard [EMAIL PROTECTED]
Re: winscard stub dll
Alexandre Julliard wrote: Francois Gouget <[EMAIL PROTECTED]> writes: * I would really have liked to get rid of the (unsigneg int) casts, but as the handle types are ULONG_PTRs it seems like it won't be possible. That's quite annoying. If anyone has suggestions... ULONG_PTRs are longs, they should be printed with %lx without casts. On 32bit systems yes, but not on 64bit systems. From basetsd.h: #ifdef _WIN64 typedef unsigned __int64 ULONG_PTR, *PULONG_PTR; #else /* FIXME: defined(_WIN32) */ typedef unsigned long ULONG_PTR, *PULONG_PTR; #endif But then on a 64bit system an __int64 should be the same as a long so maybe it's ok anyway. The only issue that could happen is if we try to compile Wine's dlls on a 64bit Windows system using Visual C++. Isn't a long 32bit in Visual C++? Is this a case we care about? -- Francois Gouget [EMAIL PROTECTED]
Re: winscard stub dll
Francois Gouget <[EMAIL PROTECTED]> writes: > * I would really have liked to get rid of the (unsigneg int) casts, but > as the handle types are ULONG_PTRs it seems like it won't be possible. > That's quite annoying. If anyone has suggestions... ULONG_PTRs are longs, they should be printed with %lx without casts. -- Alexandre Julliard [EMAIL PROTECTED]
winscard stub dll
As I was working on the winscard headers, I also did small tweaks on the winscard stub implementation. I admit it's mostly whitespace changes: * removed unneeded #includes. They should be added back when the implementation actually requires them. * use LPCBYTE like in the headers instead of 'const BYTE*' * standardize the stub traces * use 4-space indentation for functions * I would really have liked to get rid of the (unsigneg int) casts, but as the handle types are ULONG_PTRs it seems like it won't be possible. That's quite annoying. If anyone has suggestions... So I'm posting it here for review and so Mounir IDRASSI gets a chance to tweak it further and submit it so he gets the credit (since it's his work much more then mine). Makefile.in |2 + configure |3 + configure.ac |1 + dlls/Makefile.in |5 + dlls/winscard/Makefile.in | 20 +++ dlls/winscard/rsrc.rc | 33 dlls/winscard/scardcomm.c | 133 + dlls/winscard/scarddb.c | 325 + dlls/winscard/scardtracking.c | 104 + dlls/winscard/winscard.c | 109 ++ dlls/winscard/winscard.spec | 66 + 11 files changed, 801 insertions(+), 0 deletions(-) diff --git a/Makefile.in b/Makefile.in index 30e0581..eb5307f 100644 --- a/Makefile.in +++ b/Makefile.in @@ -417,6 +417,7 @@ ALL_MAKEFILES = \ dlls/winmm/Makefile \ dlls/winmm/tests/Makefile \ dlls/winnls32/Makefile \ + dlls/winscard/Makefile \ dlls/winspool.drv/Makefile \ dlls/winspool.drv/tests/Makefile \ dlls/wintab32/Makefile \ @@ -763,6 +764,7 @@ dlls/wininet/tests/Makefile: dlls/wininet/tests/Makefile.in dlls/Maketest.rules dlls/winmm/Makefile: dlls/winmm/Makefile.in dlls/Makedll.rules dlls/winmm/tests/Makefile: dlls/winmm/tests/Makefile.in dlls/Maketest.rules dlls/winnls32/Makefile: dlls/winnls32/Makefile.in dlls/Makedll.rules +dlls/winscard/Makefile: dlls/winscard/Makefile.in dlls/Makedll.rules dlls/winspool.drv/Makefile: dlls/winspool.drv/Makefile.in dlls/Makedll.rules dlls/winspool.drv/tests/Makefile: dlls/winspool.drv/tests/Makefile.in dlls/Maketest.rules dlls/wintab32/Makefile: dlls/wintab32/Makefile.in dlls/Makedll.rules diff --git a/configure b/configure index d322b0e..712a3be 100755 --- a/configure +++ b/configure @@ -20903,6 +20903,8 @@ ac_config_files="$ac_config_files dlls/winmm/tests/Makefile" ac_config_files="$ac_config_files dlls/winnls32/Makefile" +ac_config_files="$ac_config_files dlls/winscard/Makefile" + ac_config_files="$ac_config_files dlls/winspool.drv/Makefile" ac_config_files="$ac_config_files dlls/winspool.drv/tests/Makefile" @@ -21872,6 +21874,7 @@ do "dlls/winmm/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winmm/Makefile" ;; "dlls/winmm/tests/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winmm/tests/Makefile" ;; "dlls/winnls32/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winnls32/Makefile" ;; +"dlls/winscard/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winscard/Makefile" ;; "dlls/winspool.drv/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winspool.drv/Makefile" ;; "dlls/winspool.drv/tests/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/winspool.drv/tests/Makefile" ;; "dlls/wintab32/Makefile") CONFIG_FILES="$CONFIG_FILES dlls/wintab32/Makefile" ;; diff --git a/configure.ac b/configure.ac index 52323c7..6ad89eb 100644 --- a/configure.ac +++ b/configure.ac @@ -1747,6 +1747,7 @@ AC_CONFIG_FILES([dlls/wininet/tests/Makefile]) AC_CONFIG_FILES([dlls/winmm/Makefile]) AC_CONFIG_FILES([dlls/winmm/tests/Makefile]) AC_CONFIG_FILES([dlls/winnls32/Makefile]) +AC_CONFIG_FILES([dlls/winscard/Makefile]) AC_CONFIG_FILES([dlls/winspool.drv/Makefile]) AC_CONFIG_FILES([dlls/winspool.drv/tests/Makefile]) AC_CONFIG_FILES([dlls/wintab32/Makefile]) diff --git a/dlls/Makefile.in b/dlls/Makefile.in index f9707e7..31f3ef8 100644 --- a/dlls/Makefile.in +++ b/dlls/Makefile.in @@ -205,6 +205,7 @@ BASEDIRS = \ wininet \ winmm \ winnls32 \ + winscard \ winspool.drv \ wintab32 \ wintrust \ @@ -571,6 +572,7 @@ IMPORT_LIBS = \ wininet/libwininet.$(IMPLIBEXT) \ winmm/libwinmm.$(IMPLIBEXT) \ winnls32/libwinnls32.$(IMPLIBEXT) \ + winscard/libwinscard.$(IMPLIBEXT) \ winspool.drv/libwinspool.$(IMPLIBEXT) \ wintab32/libwintab32.$(IMPLIBEXT) \ wintrust/libwintrust.$(IMPLIBEXT) \ @@ -920,6 +922,9 @@ winmm/libwinmm.$(IMPLIBEXT): winmm/winmm.spec $(WINEBUILD) winnls32/libwinnls32.$(IMPLIBEXT): winnls32/winnls32.spec $(WINEBUILD) @cd winnls32 &am
Re: Winscard support (for smart cards)
On Mo, 2007-04-30 at 00:58 +0200, Mounir IDRASSI wrote: > +#define SCARD_S_SUCCESS0x > +#define SCARD_F_INTERNAL_ERROR 0x8011 /**< An internal > consistency check failed. */ > +#define SCARD_E_CANCELLED 0x8012 /**< The > action was cancelled by an SCardCancel request. */ > +#define SCARD_E_INVALID_HANDLE 0x8013 /**< The supplied > handle was invalid. */ > +#define SCARD_E_INVALID_PARAMETER 0x8014 /**< One or more of > the supplied parameters could not be properly interpreted. */ I have no Idea about the Code, but your idention is broken (SPACE and TAB). Wine is using 4 Space, when possible. SCARD_SCOPE/STATE/SHARE to SCARD_PROTOCOL_* as more Examples after a quick view. Thanks for helping Wine. -- By by ... Detlef
Re: Winscard support (for smart cards)
Hi all, We have noticed that our first patch for winscard containing only the headers have not been applied yet. Is this a normal delay? Is there any pending issues? Should we send the remaining list of patches to complete the winscard implementation? Any comments/remarks are welcomed. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr
Re: Adding header files for the implementation of Winscard dll (Smart Cards support)
Sorry, my mistake... I'll definitely be more careful next time. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Dmitry Timoshkov wrote: > This is a notice more for Alexandre this time, but next time please > make sure to send the files with exec bits turned off (755 -> 644). >
Re: Adding header files for the implementation of Winscard dll (Smart Cards support)
"Mounir IDRASSI" <[EMAIL PROTECTED]> wrote: diff --git a/include/scarderr.h b/include/scarderr.h new file mode 100755 index 000..c07833e --- /dev/null +++ b/include/scarderr.h ... diff --git a/include/winscard.h b/include/winscard.h new file mode 100755 index 000..f302a9f --- /dev/null +++ b/include/winscard.h ... diff --git a/include/winsmcrd.h b/include/winsmcrd.h new file mode 100755 index 000..cc03a35 --- /dev/null +++ b/include/winsmcrd.h This is a notice more for Alexandre this time, but next time please make sure to send the files with exec bits turned off (755 -> 644). -- Dmitry.
Re: Winscard support (for smart cards)
Mounir IDRASSI a écrit : Hi, Please find attached the patch for adding header files for the support of smart cards through Winscard dll. If it's OK, should I post it elsewhere? Thanks in advance. yes to [EMAIL PROTECTED] A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Re: Winscard support (for smart cards)
Hi, Please find attached the patch for adding header files for the support of smart cards through Winscard dll. If it's OK, should I post it elsewhere? Thanks in advance. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Eric Pouech wrote: > > sorry, I didn't actually compare the files, just saw the comments (my > bad) > that'll be better for the first patch not to include those C files > go ahead ;-) > A+ > From 90fb2bc92327fc839d6a0ef68c3157035cd50c65 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <[EMAIL PROTECTED]> Date: Tue, 1 May 2007 18:03:01 +0200 Subject: Header files for the support of smart cards using Winscard dll --- include/Makefile.in |3 + include/scarderr.h | 70 + include/winscard.h | 416 +++ include/winsmcrd.h | 190 +++ 4 files changed, 679 insertions(+), 0 deletions(-) diff --git a/include/Makefile.in b/include/Makefile.in index 2577872..7dc0cc3 100644 --- a/include/Makefile.in +++ b/include/Makefile.in @@ -293,6 +293,7 @@ SRCDIR_INCLUDES = \ rpcndr.h \ rpcnterr.h \ rpcproxy.h \ + scarderr.h \ schannel.h \ schemadef.h \ schnlsp.h \ @@ -351,6 +352,8 @@ SRCDIR_INCLUDES = \ winreg.h \ winres.h \ winresrc.h \ + winscard.h \ + winsmcrd.h \ winsock.h \ winsock2.h \ winspool.h \ diff --git a/include/scarderr.h b/include/scarderr.h new file mode 100755 index 000..c07833e --- /dev/null +++ b/include/scarderr.h @@ -0,0 +1,70 @@ +/* + * Copyright 2007 Mounir IDRASSI ([EMAIL PROTECTED], for IDRIX) + * + * 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 + */ + + +#ifndef _WINE_SCARDERR_H +#define _WINE_SCARDERR_H + + +#define SCARD_S_SUCCESS0x +#define SCARD_F_INTERNAL_ERROR 0x8011 /* An internal error occured while executing the operation */ +#define SCARD_E_CANCELLED 0x8012 /* SCardCancel was called to cancel the operation */ +#define SCARD_E_INVALID_HANDLE 0x8013 /* The given handle is not valid */ +#define SCARD_E_INVALID_PARAMETER 0x8014 /* An invalid parameter was given in input*/ +#define SCARD_E_INVALID_TARGET 0x8015 /* Smart card service encountered inconsistent installation information */ +#define SCARD_E_NO_MEMORY 0x8016 /* No enough memory available to complete the operation */ +#define SCARD_F_WAITED_TOO_LONG0x8017 /* A timeout occured in an internal operation */ +#define SCARD_E_INSUFFICIENT_BUFFER0x8018 /* The output buffer is too small to receive data */ +#define SCARD_E_UNKNOWN_READER 0x8019 /* The given reader name is unknwon to the system */ +#define SCARD_E_TIMEOUT0x801A /* The operation timed out */ +#define SCARD_E_SHARING_VIOLATION 0x801B /* can't access the card because of other connections*/ + +#ifndef SCARD_E_NO_SMARTCARD +#define SCARD_E_NO_SMARTCARD 0x801C /* no smart card found on the reader*/ +#endif + +#define SCARD_E_UNKNOWN_CARD 0x801D /* The given card name is unknwon to the ssytem */ +#define SCARD_E_CANT_DISPOSE 0x801E /* The system can't handle the disposition request in SCardDisconnect or SCardEndTransaction*/ +#define SCARD_E_PROTO_MISMATCH 0x801F /* The given protocol is not compatible with the currenr card context */ +#define SCARD_E_NOT_READY 0x80100010 /* The reader or the card are not ready for use */ +#define SCARD_E_INVALID_VALUE 0x80100011 /* An invalid value was detected while */ +#define SCARD_E_SYSTEM_CANCELLED 0x80100012 /* The system canceld the current operation with the reader */ +#define SCARD_F_COMM_ERROR 0x80100013 /* A communication error occured with the reader */ +#define SCARD_F_UNKNOWN_ERROR 0x80100014 /* An unknown error occured */ +#define SCARD_E_INVALID_ATR
Re: Winscard support (for smart cards)
Mounir IDRASSI a écrit : Hi Eric, I am afraid I don't see any MS comments in scarderr.h: I have written all the file from scratch and the comments are mine. Can you point them out please? sorry, I didn't actually compare the files, just saw the comments (my bad) In the final implementation, all the functions are needed even if they are stubs because they can be called by applications that ignore them if they report an error. That's why we must implement them all. But I can start with stubs in the spec file for the first patch. that'll be better for the first patch not to include those C files I'll wait for your reply before submitting the first patch. Thanks. go ahead ;-) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Re: Winscard support (for smart cards)
Hi Eric, I am afraid I don't see any MS comments in scarderr.h: I have written all the file from scratch and the comments are mine. Can you point them out please? In the final implementation, all the functions are needed even if they are stubs because they can be called by applications that ignore them if they report an error. That's why we must implement them all. But I can start with stubs in the spec file for the first patch. I'll wait for your reply before submitting the first patch. Thanks. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Eric Pouech wrote: > thanks for your work > > I still have a couple of comments: > - you don't need at first (for the skeletton) to provide an empty > implementation for a given function. If you use the stub keyword in > the .spec file, Wine will create a minimal stub for the function > (that'll make the program crash when it's called), but is sufficient > when the API is never called => this is the preferred way to go. All > your stubs are not lost, you'll reuse them when providing the first > API implementation > - basically, I'd submit a patch for the headers and a second one for > the skeletton of the DLL. Then you can go on with the various API > implementations > > From the coding itself: > - in traces, don't cast handles to int, it won't work every where... > rather use "%x", handle => that's portable > - there's still (void) functions declared as () (in the C files) > - there's still MS comments in scarderr.h > > A+ >
Re: Winscard support (for smart cards)
Mounir IDRASSI a écrit : Hi all, Followings your comments, I have rewritten the header files and split winscard.c into smaller files. You'll find attached with this email a patch containing only the headers and a skeleton for this dll. Once integrated into the source tree, I'll provide another patch (or patches) containing the rest of the implementation. I hope th thanks for your work I still have a couple of comments: - you don't need at first (for the skeletton) to provide an empty implementation for a given function. If you use the stub keyword in the .spec file, Wine will create a minimal stub for the function (that'll make the program crash when it's called), but is sufficient when the API is never called => this is the preferred way to go. All your stubs are not lost, you'll reuse them when providing the first API implementation - basically, I'd submit a patch for the headers and a second one for the skeletton of the DLL. Then you can go on with the various API implementations From the coding itself: - in traces, don't cast handles to int, it won't work every where... rather use "%x", handle => that's portable - there's still (void) functions declared as () (in the C files) - there's still MS comments in scarderr.h A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Re: Winscard support (for smart cards)
oups ...sorry...It was my fault! You are as absolutely right. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Eric Pouech wrote: > they should work across the whole buffer > are you sure you don't pass -1 as the length for the input buffer ? > A+ >
Re: Winscard support (for smart cards)
Mounir IDRASSI a écrit : Hi Eric, I have tested your hint concerning the final single call to MultiByteToWideChar in order to convert the whole area but it didn't work: even when I specify the whole length of the multi-string, it keeps stoping at the first NULL character. I guess MultiByteToWideChar and WideCharToMultiString don't understand multi-strings ( MSDN say nothing about that). they should work across the whole buffer are you sure you don't pass -1 as the length for the input buffer ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Re: Winscard support (for smart cards)
Hi Eric,
I have tested your hint concerning the final single call to
MultiByteToWideChar in order to convert the whole area but it didn't
work: even when I specify the whole length of the multi-string, it keeps
stoping at the first NULL character. I guess MultiByteToWideChar and
WideCharToMultiString don't understand multi-strings ( MSDN say nothing
about that).
Mounir IDRASSI
IDRIX - Cryptography and IT Security Experts
http://www.idrix.fr
Eric Pouech wrote:
> you have to ensure that binary compat is present for both pcsc-lite
> and MS APIs
> if not, then you'll have to convert back and forth the non "portable"
> types
> actually, we don't provide exported variables when those are used from
> a native module (those would work from a builtin module though)
> if you really need to access them from a builtin module you have to:
> - define a pointer to this (exported) variable
> - get the address of this variable:
> GetProcAddress(GetModuleHandle("modname.dll"), "varname")
> - access the variable through the pointer
>
> A+
>
Re: Winscard support (for smart cards)
Mounir IDRASSI a écrit :
Hi ,
Thank you for all your comments.
Concerning the header files, they contain portions taken from Microsoft
headers. We will rewrite them to remove any copyright issues.
For the types used, they are more close to pcsc-lite than Microsoft but
still compatible at the binary level. We will modify them to be more
close to MS SDK definitions.
you have to ensure that binary compat is present for both pcsc-lite and
MS APIs
if not, then you'll have to convert back and forth the non "portable" types
We understand the issue of having a big patch. I'll split it into small
parts as you advised. The same applies to winscard.c file.
Concerning the exported variables, we think we have followed the msvcrt
example: "@ extern name" in the spec file and the declaration in a c
file. The variables exported are visible from win32 programs and are
used without any problem.
However, there is still an issue: when when try to compile a source file
that uses them using winegcc, we get an unresolved symbol error. Did we
miss something? The only difference we see with msvcrt source is that
winscard exported variables have a structure as a type, whereas msvcrt
exported variables are pointers.
actually, we don't provide exported variables when those are used from a
native module (those would work from a builtin module though)
if you really need to access them from a builtin module you have to:
- define a pointer to this (exported) variable
- get the address of this variable:
GetProcAddress(GetModuleHandle("modname.dll"), "varname")
- access the variable through the pointer
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
Re: Winscard support (for smart cards)
Hi , Thank you for all your comments. Concerning the header files, they contain portions taken from Microsoft headers. We will rewrite them to remove any copyright issues. For the types used, they are more close to pcsc-lite than Microsoft but still compatible at the binary level. We will modify them to be more close to MS SDK definitions. We understand the issue of having a big patch. I'll split it into small parts as you advised. The same applies to winscard.c file. Concerning the exported variables, we think we have followed the msvcrt example: "@ extern name" in the spec file and the declaration in a c file. The variables exported are visible from win32 programs and are used without any problem. However, there is still an issue: when when try to compile a source file that uses them using winegcc, we get an unresolved symbol error. Did we miss something? The only difference we see with msvcrt source is that winscard exported variables have a structure as a type, whereas msvcrt exported variables are pointers. Cheers, Mounir IDRASSI IDRIX – Cryptography and IT Security Experts http://www.idrix.fr Eric Pouech wrote: > from a cursory look, it looks a very goot start !!! > > a couple of comments though: > - some functions are declared (), they should be (void) (it's C, not C++) > - wstrlen already exists: it's strlenW (even if we don't check for > NULL strings) > - don't use malloc/free but rather HeapAllocate... in windows, malloc > boils down to HeapAllocate through msvcrt, but in Wine it uses the > glibc one, which is not what you want > - ConvertListToANSI: IMO, after computing the final length, only a > single call to MultiByteToWideChar is necessary (it will convert the > whole area) > - ditto for ConvertListToWideChar > - headers: >+ the rule for including new headers in Wine is really to have them > fully retyped... looking at the comments in the file, it looks to me > you mostly copied the existing headers and their comments as well >+ some types are not the correct ones (at least on my latest SDK) > => e.g. you use long for SCARDCONTEXT whereas it's defined as a > ULONG_PTR (it will not correctly work when compiling on a 64bit > machine) (I'm not saying that your code must be 64 compliant at first, > but the headers must be) > - spec file: >+ don't define an entry point if you don't absolutely need it (most > of them should still be stubs) > - you still use C++ comments, whereas Wine only allows C comments > > from the inclusion into Wine, it's already way to big to be included > in a single operation. So, you should split up your work in smaller > pieces. For example: > - patch #1-3: new header files > - patch #4: bare DLL infrastructure (mostly .spec file (only stubs), > Makefile.in and .c file with DllMain, configure.ac) > - patch #5: a small set of functions XXX (c file, modified .spec file) > - patch #6: a small set of functions YYY (c file, modified .spec file) > > it would be also interesting to think about having several c files for > the DLL (given the number of APIs to implement) > > finally, it seems that the DLL exports some variables => they have to > be specially handled (see details on how to do it in some other DLLs, > like msvcrt) > > A+ >
Re: Winscard support (for smart cards)
Mounir IDRASSI a écrit : Hi all, We have managed to integrate our winscard source code into the wine source tree, including the configure.ac and Makefine.in files. As described in the developer's guide, I am attaching with this email the output of the command "git format-patch origin". Can someone please check if I have done it the right way? If this is ok, should I post it also to the patches mailing list. For your information, our implementation uses pcsc-lite through wine_dlopen and wine_dlsym, so pcsc-lite is not required at compile time. We have not included test files as they include the use of smart cards with proprietary applications. I will try in the near future to include a wine implementation of a graphical tool that can manipulate smart cards using the wine winscard dll. Thanks for your help. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr from a cursory look, it looks a very goot start !!! a couple of comments though: - some functions are declared (), they should be (void) (it's C, not C++) - wstrlen already exists: it's strlenW (even if we don't check for NULL strings) - don't use malloc/free but rather HeapAllocate... in windows, malloc boils down to HeapAllocate through msvcrt, but in Wine it uses the glibc one, which is not what you want - ConvertListToANSI: IMO, after computing the final length, only a single call to MultiByteToWideChar is necessary (it will convert the whole area) - ditto for ConvertListToWideChar - headers: + the rule for including new headers in Wine is really to have them fully retyped... looking at the comments in the file, it looks to me you mostly copied the existing headers and their comments as well + some types are not the correct ones (at least on my latest SDK) => e.g. you use long for SCARDCONTEXT whereas it's defined as a ULONG_PTR (it will not correctly work when compiling on a 64bit machine) (I'm not saying that your code must be 64 compliant at first, but the headers must be) - spec file: + don't define an entry point if you don't absolutely need it (most of them should still be stubs) - you still use C++ comments, whereas Wine only allows C comments from the inclusion into Wine, it's already way to big to be included in a single operation. So, you should split up your work in smaller pieces. For example: - patch #1-3: new header files - patch #4: bare DLL infrastructure (mostly .spec file (only stubs), Makefile.in and .c file with DllMain, configure.ac) - patch #5: a small set of functions XXX (c file, modified .spec file) - patch #6: a small set of functions YYY (c file, modified .spec file) it would be also interesting to think about having several c files for the DLL (given the number of APIs to implement) finally, it seems that the DLL exports some variables => they have to be specially handled (see details on how to do it in some other DLLs, like msvcrt) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Re: Winscard support (for smart cards)
On Monday 30 April 2007 00:58, Mounir IDRASSI wrote: > Hi all, > We have managed to integrate our winscard source code into the wine source > tree, including the configure.ac and Makefine.in files. As described in the > developer's guide, I am attaching with this email the output of the command > "git format-patch origin". Can someone please check if I have done it the > right way? I have to admit that somewhere around line 500 of the patch I gave up. Please split this patch into smaller, easier to read chunks. That will make getting it accepted much easier. Cheers, Kai -- Kai Blin, WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ Samba team member http://us1.samba.org/samba/team/ -- Will code for cotton. pgpycMhdJchZm.pgp Description: PGP signature
Re: Winscard support (for smart cards)
Am Mittwoch 25 April 2007 18:48 schrieb [EMAIL PROTECTED]: > Hi, > We have noticed that wine doesn't have the winscard dll responsible for the > support of smart cards under windows. For the need of one of our projects, > we are currently developing this dll for wine under Linux based on the > pcsc-lite library. Once done, we'll share it with the community. However, > we would like to known the reason behind the lack of winscard support. Is > it simply because no one needed it before or maybe there is an issue with > the pcsc-lite license? Thanks in advance for your information. I think it is because no one needed it before. As Saulius Krasuckas said, it would be better if you sent patches as you develop the library, mainly because smaller patches are easier to review. It is much easier to get a new DLL in function by function instead of the whole thing at one. Of course you can write it, then send it in in smaller pieces, but splitting it up is extra work, and you don't have the change of getting feedback while you develop it(Ok, almost no one here knows about pcsc, so don't expect much feedback anyway). pgprcokqkkkDh.pgp Description: PGP signature
Re: Winscard support (for smart cards)
Hi, If there is a sample implementation or some kinda initial source code. (Just send a initial code) We can try to help you in integrating the code into wine tree. By progressing step by step. Thanks, VJ On 4/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Saulius Krasuckas <[EMAIL PROTECTED]> wrote: > IMHO it would be best for the community if you will start doing > this immediatelly, not once done. Unfortunately, we are well advanced and we can't do it that way due to other constraints in the project. Another bad point is that, since we are not really experts in autoconf and libtool scripts, we started from a pre-configured source tree and adapted the files of the cryptdll library (the simplest one). So we will definitely need the help of the community to integrate our source seamlessly into the wine source tree. Mounir IDRASSI IDRIX - Cryptography And IT Security Experts http://www.idrix.fr
Re: Winscard support (for smart cards)
Saulius Krasuckas <[EMAIL PROTECTED]> wrote: > IMHO it would be best for the community if you will start doing > this immediatelly, not once done. Unfortunately, we are well advanced and we can't do it that way due to other constraints in the project. Another bad point is that, since we are not really experts in autoconf and libtool scripts, we started from a pre-configured source tree and adapted the files of the cryptdll library (the simplest one). So we will definitely need the help of the community to integrate our source seamlessly into the wine source tree. Mounir IDRASSI IDRIX - Cryptography And IT Security Experts http://www.idrix.fr
re: Winscard support (for smart cards)
I'm thrilled you're working on this! I must urge you to submit code early and often to Wine. The first patch you should send should just implement a stub dll. We can help you with that if you need it. Here's a good example of a new stuff DLL: http://winehq.org/pipermail/wine-patches/2007-April/038141.html By submitting a patch like this, you will pave the way for later submission of more code. - Dan
Re: Winscard support (for smart cards)
* On Wed, 25 Apr 2007 [EMAIL PROTECTED] wrote: > For the need of one of our projects, we are currently developing this > dll for wine under Linux based on the pcsc-lite library. Cool. > Once done, we'll share it with the community. Nice, but IMHO it would be best for the community if you will start doing this immediatelly, not once done. Otherwise you would probably step in a shoes of Transgaming' or Codeweavers' guys, patches from which src trees will have a somwhat hard way into Wine tree. > However, we would like to known the reason behind the lack of winscard > support. Is it simply because no one needed it before or maybe there is > an issue with the pcsc-lite license? Thanks in advance for your > information. IANAL, but if it's of BSD license, then that isn't an issue, AFAIK.
Winscard support (for smart cards)
Hi, We have noticed that wine doesn't have the winscard dll responsible for the support of smart cards under windows. For the need of one of our projects, we are currently developing this dll for wine under Linux based on the pcsc-lite library. Once done, we'll share it with the community. However, we would like to known the reason behind the lack of winscard support. Is it simply because no one needed it before or maybe there is an issue with the pcsc-lite license? Thanks in advance for your information. Cheers, Mounir IDRASSI IDRIX http://www.idrix.fr
