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: 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)
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)
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 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, 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_ATR0x80100015 /* The ATR value is invalid */ +#define SCARD_E_NOT_TRANSACTED
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)
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, kai Dot blin At gmail Dot com 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)
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)
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 , 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 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 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)
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+
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
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.
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)
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)
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)
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
