|
Hello, I'm curious about the differences in the implementation of PC/SC
Lite SCardStatus vs. Windows PC/SC. Hopefully the answer
isn't too obvious due to documentation I missed or a previous discussion on this list. We've noticed a discrepancy between the SCARD_* constants to define SCardStatus() values returned from WinSCard.lib (a library provided for SmartCard development with MicroSoft SDK) and the values from pcsclite.h: pcsclite: #define SCARD_PRESENT 0x0004 #define SCARD_ABSENT 0x0002 #define SCARD_SPECIFIC 0x0040 Windows SDK,(include/WinSmcrd.h) #define SCARD_PRESENT 0x0002 #define SCARD_ABSENT 0x0001 #define SCARD_SPECIFIC 0x0006 pcsclite constants have the values expressed as bit masks. The SDK defines them as bit offsets. (ie. they have a simple algebraic relationship to one another). The Windows documentation indicates that SCardStatus() will return <i>one</i> among several values: http://msdn2.microsoft.com/en-gb/library/aa379803.aspx which implies a hierarchy wherein one state implies other states. A windows app. linked against WinSCard.lib from the SDK bears out the Windows documentation. For example, SCardStatus() returns 0x0006 when a card is inserted in the reader, corresponding to SCARD_SPECIFIC. The PC/SC lite documentation is different: http://pcsclite.alioth.debian.org/pcsc-lite/node19.html It indicates the card state values are logically ORed, and I confirmed wthat by running testpcsc on Solaris, using the same SmartCard inserted in the reader as in the test above, where the value 0x34 was returned, which as a combination of the following states: SCARD_PRESENT SCARD_NEGOTIABLE SCARD_POWERED Why did PC/SC lite decide to go this route? It does seem in some ways more useful or intuitive, but doesn't it work against application portability? Should the difference be documented? I wonder how many developers have had confusion or problems with this? Can anyone offer some insights or background on this? I'm not familiar enough with the differences between PCSClite and PC/SC to know how compatible and portable they were intended to be. Thanks, Paul |
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
