Hello, >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.
Ok, to be more clear I suggest "opensc-cardmod.dll"... >> 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). Yes dlls must be in Path, the Path can be update at install process. >> 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? Ok for me if a convenient solution can be find. >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. It's my point of view too. >> 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. I don't understand exactly but Installer (.inf file) write registry so in windows 7 You need only installer (a .inf file) and for Vista you need registry writer only... >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? The link betwin a card and a module dll is made by ATR in registry, You provide ATR, ATRMask and CSP to use. I'm not sure but first matching module take the hand on others... >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. Oh yes I don't think about that. >Regards, Andreas So I plan to: - Move libopensc/opensccm.c to cardmod/cardmod.c -> build opensc-cardmod.dll - Update code to transmit SCARDHANDLE and SCARDCONTEXT by "env" to reader-pcsc.c In first step I keep actual hack code of reader-pcsc.c and if possible change it to reduce duplicate code. Are you agree with this? Martin can you say if it's acceptable for you ? Andreas ? Best Regards, François
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
