On 7/28/2010 2:38 PM, Andreas Jellinghaus wrote:
Am Mittwoch 28 Juli 2010, um 08:22:24 schrieb Ludovic Rousseau:Mac OS X uses uint32_t and normal C types like in: PCSC_API int32_t SCardConnect(SCARDCONTEXT hContext, const char *szReader, uint32_t dwShareMode, uint32_t dwPreferredProtocols, LPSCARDHANDLE phCard, uint32_t *pdwActiveProtocol); The PC/SC (and pcsc-lite) API uses DWORD and such Windows types everywhere. I do not plan to change that but that would be also a very good idea. Windows types are so unreadable (for me). PCSC_API LONG SCardConnect(SCARDCONTEXT hContext, LPCSTR szReader, DWORD dwShareMode, DWORD dwPreferredProtocols, LPSCARDHANDLE phCard, LPDWORD pdwActiveProtocol);so I'm still not sure if you want to break abi or api. but if you do, the mac os X style above looks quite nice to me, so switching to those instead of the windows data types would be best (if you want to break abi). Regards, Andreas
I like the Apple versions, as: http://www.pcscworkgroup.com/specifications/specdownloadV1.php pcsc5_v2.01.01.pdf says: 3.1.1 Data Types The following data types are used in defining the Resource Manager interface: • BYTE == unsigned char, an 8-bit value • USHORT == unsigned short, a 16-bit value • BOOL == short, signed 16-bit value • DWORD == unsigned long, a 32-bit value • STR == char array (string) • GUID == unsigned char[16], a 128-bit unique identifier • RESPONSECODE == long , signed 32-bit value • HANDLE == a 32-bit value • VOID == unspecified data type whose interpretation is context dependent The statement that DWORD is unsigned 32 bit is the key. But pcsc3_v2.02.00_sup2.pdf says: 3.3.2 Implementation note for Windows and Linux Under Windows and Linux1 the following function shall be used: LONG SCardControl ( SCARDHANDLE hCard, DWORD dwControlCode, LPCVOID lpInBuffer, DWORD nInBufferSize, LPVOID lpOutBuffer, DWORD nOutBufferSize, LPDWORD lpBytesReturned Note: Linux PCSC-Lite use the same function call as Windows Wile looking at the sizes, endian also needs to be addressed. I did not see any references to endian for multi byte parameters, so I would assume that it is host order? But I did see in pcsc10_v2.02.08-pdf section 2.5.1 to "byte ordering is descibed by machine architecture" in section 2.5.1 for reader features which should then include the PIN_VERIFY USHORT wPINMaxExtraDigit. But the CCID specifications appear to want little endian, which get complicated as it is not clear where something like the wPINMaxExtraDigit USHORT should get converted from one to the other The Omnikey 3821 reader I have wants the bytes in the order max then min, i.e. little endian. The HOST_TO_CCID16 and HOST_TO_CCID32 macros used in pcsc_lite, and OpenSC try to address this but are different on big endian machines today! (I only got the reader this week, and have it working on a Sun Sparc big endian machine, with a few mods to OpenSC which exposes many of these issues.)
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
-- Douglas E. Engert <[email protected]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
