Hi
Jon's request for opinions has finally stung me out of lurking on this list -
thanks. I am a developer of card based applications and we try to support as
many readers and interfaces as possible, including PC/SC and OpenCard.
Here are some assorted opinions and replies;
PC/SC
=====
PC/SC does give each installed driver a chance to see if the reader is there on
startup. The behavior then is very much down to the quality of the driver. The
worst I have seen scanned all the com ports, and even if it did not find the
reader carried on scanning - locking out 90% of access to all your ports. The
finest drivers, either handled the live connection / disconnection through plug
and play, or provide a control panel applet to 'enable' or 'disable' the driver
from looking at a particular port. I have not come across a reader that need a
card to be inserted before the reader is detected. I have tested the GCR410, but
unfortuately not the 410p - however the GemPlus's generic GemCore drivers are
among the best.
Life gets even more interesting if you have more than one reader installed, a lot
of the developers / protocols are based on very similar code and so the first
'search' may leave the protocol with the reader in an unknown state by the time
the proper reader comes to poll for it. Better still there are cases where the
not-quite invalid responses from a reader lock the protocol in a retry loop.
Drivers do things like toggling lines to get a response from readers, which has
some very interesting effects on other readers and devices.
My advice is to have one reader enabled at a time ( look closely at the installed
files, many PC/SC drivers, particularly early Betas don't uninstall ).
Finally, if you are an applications developer, remember to leave a lot of time to
develop your install script. Installing your application is no doubt very easy,
but are you going to include the base components, how about a couple of drivers.
Will your clients be disappointed when it all installs and then says 'no pc/sc
installed' ?
It can be done, but from the applications developer side you are in for some
grief, and your support people will have to know PC/SC inside-out since it is all
viewed as 'your software' by the client.
I haven't tried the PCMCIA implementation yet, and by Jon's comments it sound like
I am not going to enjoy it. The only non-serial reader I have tried is the
Smarty, which is ideal if you don't have any serial ports going. Since it can't
poll ( it uses the floppy drive) it comes with a polling start-bar applet, but
there is an extension you can make to your code to poll programmatically if you
wish.
( excuse the quick piece of product placement but the light version of our
PhoneFile application is available for free download. It includes support for just
two readers; native Smarty support and, more interestingly for this discussion,
PC/SC. It is for the management of GSM SIM cards, so any of you who have GSM
phones can use it as a test tool for your PC/SC installations.
http://www.pipistrel.com/phonefile/light/ )
OCF <-> PC/SC bridge
=================
This does work. I have downloadable applications that use OCF/ PC/SC to locate and
access cards.
I have been using GSM SIM cards ( similar to iso t=0 but not exactly the same)
cards, and at the moment I am using a dreadful fudge of using the
PassThruCardService. But, so long as the ocfpcsc1.dll is found ok it all seems to
spring into life.
Again the problems that I faced seemed mostly to be with installation and PC/SC
drivers, but so far every supplier I have taken problems to has been very eager to
help. My advice is thoroughly to check the PC/SC drivers & card operation before
adding the OCF layer.
I agree with Jon that this is an important part of the OCF implementation, but if
you have the choice 'go native', the fewer layers of code between you and the
smart-card the better. If your preferred card-reader supplier does not publish an
OCF interface, then ask them! If we all do it, and test their beta drivers to
destruction, then we will end up with a useable and well supported standard.
Good luck,
Howard Tytherleigh
Pipistrel Software Ltd.
Barber Jon wrote:
> Well, I've had some interesting experiences with PCSC and the OCF bridge.
>
> Firstly, PCSC by itself. From my experience, for serial smart card readers,
> <snip>
>
> What's even worse is PCSC for PCMCIA. <snip>
>
> However, I haven't been able to use the PCSC
> OCF bridge successfully (this is with OCF 1.1). Trying with a variety of
> readers has had varied results, non working 100%. <snip>
>
> It seems to me that the OCF PCSC bridge is crucial to the future of OCF, as
> MS is to ship PCSC as standard with Windows2000. If anyone has had success
> using the PCSC <-> OCF bridge please let the mailing list know.
>
> All opinions strictly my own, of course, and not my employers.
>
> Jon.
>
Visit the OpenCard Framework's WWW site at http://www.opencard.org/ for
access to documentation, code, presentations, and OCF announcements.
-----------------------------------------------------------------------------
To unsubscribe from the OCF Mailing list, send a mail to
"[EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of the
message.
