The PCSC SCard implementation in winpr tried to rename reader and group
names received from PCSC to something similar to what the windows smart
card service would return.
Because of the following reasons this mapping was removed:
* reader names are not standardized
* no mapping of reader name should be required at all
* the mapping added extra complexity
* the mapping didn't produce the same names as if the reader was
directly connected on windows (or redirected from a windows host)
In case there are situations where this is nevertheless required this
feature can simple be (re-)implemented a part of the smart card channel.
Also the formatting was fixed.
SCardAddReaderName isn't part of the SCard API.
Note: removing this also removes the possibility to redirect single
smartcard readers with /smartcard:READERNAME. However this features
wasn't implemented in a general way and will be re-added as part of
the smart card channel directly.
The state tracking/modifications (presumably thought as optimization?!) in
PCSC_SCardGetStatusChange_Internal cause a lot of applications to behave
incorrectly and/or hang. Ideally no modifications of the states should
be necessary as PCSC implements the same API as passed over the channel.
In case SCardGetStatusChange returned an error the call didn't return
any data but STATUS_NO_MEMORY as the calloc failed. This caused problems
with multiple applications server side (hangs and incorrect behavior).
Now the case when no readers are returned is handed correctly and the
data is also filled and send if the call fails.
The smart card channel tried to mimic mstsc's behavior on if an IRP was
processed synchronously or asynchronously. As the channel uses one thread per
context it could happen, especially with PCSC, that the main
channel thread was blocked waiting for an smart card operation to
complete. To prevent that behavior only call known safe functions in the
main thread (like CreateContext) and call the rest asynchronously.
For example the channel would block if a ListReaders is invoked on
the same context where a GetStatusChange (infinite timeout)
was already pending. Only when a status change happened the channel
would continue.
Note: Due to the one context per thread design it's important that
cancel isn't queued an alway run synchronously. Otherwise a specific
context might lock.
Device control calls always returned SCARD_S_SUCCESS even if an error
occurred. This caused server side software (including the card manager)
to behave incorrectly.
According to MS-RDPESC the smart card channel must set the IoStatus to
an NTSTATUS in case a encoding or decoding error happens. The smart card
channel did this correctly but the output stream was modified
incorrectly causing the smart card remote manager to stop in error
cases.
