2014-11-13 18:21 GMT+01:00 David Woodhouse <[email protected]>: > On Wed, 2014-11-12 at 19:53 +0100, Ludovic Rousseau wrote: >> 2014-11-12 18:55 GMT+01:00 David Woodhouse <[email protected]>: >> > On Wed, 2014-11-12 at 18:18 +0100, Ludovic Rousseau wrote: >> >> 2014-11-12 17:39 GMT+01:00 David Woodhouse <[email protected]>: >> >> > Should I be worrying about SCardReconnect(), and doing something like >> >> > the example in http://pcsclite.alioth.debian.org/pcsc-lite/node13.html? >> >> > Or does the use of transactions save me from that concern? >> >> >> >> Why do you think you would need SCardReconnect()? >> > >> > Because I see warnings about having to do so if SCardTransmit() and >> > other functions return SCARD_W_RESET_CARD... but I have no real clue >> > when/if they might actually *do* that in practice. >> > >> >> It may be the case if another application has reset the card. But >> >> maybe the use case would be to remove and insert the key again. >> > >> > OK, thanks. >> > >> > I have it building and running on Windows too now, but I always just get >> > SCARD_W_CARD_REMOVED from the call to SCardConnect(). Is that my fault, >> > or just Windows being its normal difficult self? >> >> Sorry. I can't really help on Windows. >> >> You may want to start with a very simple program [1] on Windows. > > This turned out to be a problem with the device. It has optional support > for pressing the button to virtually 'eject' and 'reinsert' the card. > > I *enabled* this 'virtual eject' mode, and now I can press the button to > make the card appear and disappear, and it works in Windows too. > > I disabled that mode again to check that I'm not going mad — and it's > really true that although the card is unconditionally present under > Linux and OS X, it appears as unconditionally *removed* to the Windows > VM.
I am not sure I follow you here. Adding a VM in the equation is always adding complications. But if it works for you then that is fine. > My last question for now, I think: in what character set are the reader > name strings returned from SCardListReaders() and given to > SCardConnect()? > > Obviously in Windows we can use the UTF16 SCardListReadersW() and > SCardConnectW() abominations, and modern systems using pcsclite *ought* > to be UTF-8 everywhere. But are there any circumstances under which > pcsclite will give me legacy 8-bit character sets? Legacy 8-bit character set is something like ISO 8859-1 (also known as Latin-1)? > For CCID it looks like the names currently all come from Info.plist, and > never from USB descriptors? Is that right? Exact. So if your Info.plist contains "garbage" then will also do the PC/SC name. > I thought there was a USB > class so we didn't *need* a comprehensive list of vendor/device IDs? Exact. But pcsc-lite has no (yet) support for a class driver. > Putting non-ASCII into Info.plist appears to make the file fail to parse > — although that file starts with <?xml version="1.0" encoding="UTF-8"?> > it *isn't* actually parsed as XML. On GNU/Linux it is parsed (by pcsc-lite and libccid) using a hand made parser: tokenparser.l [1]. Valid characters are: ([A-Z]|[a-z]|[0-9]|[ \t]|[!@#$%^&*()\-+/_\:?.,=~'";\[\]])+ Do you need real UTF-8 reader names? > But what about other IFD drivers ? No idea. Bye [1] http://anonscm.debian.org/viewvc/pcsclite/trunk/PCSC/src/tokenparser.l?view=markup -- Dr. Ludovic Rousseau _______________________________________________ Pcsclite-muscle mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
