Winscard support (for smart cards)

[Mounir IDRASSI]

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