Winscard support (for smart cards)

Eric Pouech eric.pouech at
Mon Apr 30 01:55:39 CDT 2007

Mounir IDRASSI a écrit :
> Hi all,
> We have managed to integrate our winscard source code into the wine source tree, including the and 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
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 
- 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), and .c file with DllMain,
- 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 


Eric Pouech
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

More information about the wine-devel mailing list