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+