In this article we are going to develop a Smart Card Library that will ease the development of Smart Card Applications using the Win32 SDK and/or MFC. This assumes that youíre familiar with Win32 and MFC. The library builds upon the available support for Smart Cards in Windows by providing an Object Oriented wrapper over the WinSCard API. One advantage of using this library is the layered approach, which isolates the core APIís available to non-Win32 conformant languages like java to access this library through JNI (Java Native Interfaces). If youíve already developed some applications using the APIs exposed by WinSCard.dll then youíll be well aware of the complexities involved and here is an attempt to ease them.
Writing a Smart Card Library - The Approach (Page 2 of 5 )
Let's first talk about how one writes an application with just the WinSCard.dll raw APIs and then we'll move to writing the OO Wrapper. As mentioned above the core of the Win32 Smart Card subsystem is the WinSCard.dll, which exposes a number of APIs for Smart Card access and Reader Configuration.
The typical steps to access a Smart Card with the raw API's would be as under:
Use the SCardEstablishContext API to get a Context Handle associated with a reader. You need this because the other APIs need you to pass a context handle as parameter.
Later using the SCardConnect API you obtain hCard that is handle to a card. Just like above you need this handle to communicate with the Card.
You may then use SCardStatus with the above hCard value to get the status of the card before you actually start with some transaction.
You then use SCardTransmit API to send APDU to the associated card and retrieve the response at the same time. You'll need the hCard value here too.
After you're done using the Card you use the SCardDisconnect API to disconnect from the Card using the hCard value associated with the card. Then this hCard value is no longer valid and you should do a SCardConnect call again to retrieve a new handle in case you want to reconnect again
Finally when you don't need the connection with the reader device you just call the SCardReleaseContext API to release the Context handle associated with the reader.
It's fine as long as you're writing a small application but as your business logic grows so would be the calls and references to the WinSCard APIs and it's really not advisable even for a medium project going over 3000LOC. Moreover it's solely up to the programmer to put the data in a format that is dictated by the WinSCard APIs. It was a lot of hit and trial the first time I wrote an application in this way. Sooner or later you find that you're not writing good code if you follow this approach.
Compare this approach to the object oriented approach where in you've a number of class like in the diagram below that encapsulate one or more Smart Card objects. The CPSCSCReader class encapsulates a Reader object, which is responsible for managing reader connections, keeping the status updated internally and sending/receiving data to/from the card. There are a few helper classes too like CPCSCCommand, which encapsulates an APDU (Application Protocol Data Unit) object and CRegListDlg, which enables you to select a reader from those connected to your machine. You can skim through the code for these classes or run the demo application to see them in action.