Am Mittwoch 03 Februar 2010 16:37:31 schrieb Martin Paljak: > > so the only variable I see is the placement of opensccm.c > > (and the name for it - "cardmod.c" is ok for you?). > > Yes. > > > in my opinion a single source file could be placed in a seperate > > directory. and we can either create a seperate dll that contains > > this extra code and links opensc-2.dll (or includes it static). > > Yes, see the picture @ http://www.opensc-project.org/opensc/wiki/MiniDriver
ok. hmm, but if we create an extra dll for the card module, the original name "opensccm" might be better. move the file to "cardmod/opensccm.c" and create "opensccm.dll"? is that ok for you. > dll-s are OK if they have a purpose, stuffing many interfaces in a single > dll could be useable but not necessarily the best idea. A single interface > from a single DLL is the easiest concept to grasp for anyone. yes. but it requires that not only windows can load the dll mentioned in the registry, but that this dll can load the other dll it depends on as well. so I guess they all have to be in the path and/or system32 directory (not sure if you can set the path for the logon process, thus I guess system32 or system64 is the place it needs to be. hmm, is the logon process on 64bit windows a 64bit application? then we would need a 64bit card module and depending libraries I guess). > > you know that code much better than I do. but didn't the cardmod reader > > also share a lot of code with pcsc reader driver? IIRC that was the > > argument for keeping it in that file, and not creating a new > > reader-cardmod.c file. > > It is in fact a corner case of the PC/SC driver, not a separate driver. > > > what do you suggest should be done? and is it ok to commit the patch now > > and work on it, or does it have to be changed before it gets into svn? > > Things required to implement support for existing card handles provided to > minidriver should be done as a) conditional code and/or the module built > in a separate pass it is! unless you have defined HAVE_CARDMOD_H nothing is changed (except for that small little extra field in one structure). > b) smaller code changes in the current code path. > > Current amount of copypaste should be reduced and should not be commited. sorry, I can't help with that, as I now next to nothing about reader-pcsc.c. can you work with François on that? my preference would be to commit the current code (with other directories / filenames etc.): the changes to existing code are minimal and cut&paste issues can be reduced later without affecting other code. > Last time I worked with a minidriver you *had* to have the ATR-s your card > is willing to handle in the registry. Installer and registry writer would > be necessary. both? ah, ok. let my rephrase my question this way: can you install both a vendors cardmodule and opensc cardmodule at the same time, or would they conflict? we will need to tell people not only how to register opensc as card module, but also how to get rid of those registry keys, if they cause problems for some vendors card module. and maybe also make sure we don't blindly overwrite registry keys, but notice if they already exist and handle that somehow. > For some reason my build instance did not pick up the cardmod.h file the > first two times I tried. hmm. configure error? can you check config.log for the reasons? > The header can not be included in the package for > licensing reasons? yes, microsoft doesn't license it for distribution. that is stupid, but well... it should be part of the plattform SDK too, so every normal windows developer with visual C has it already on his disk somewhere. Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
