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.
Previously, the code prompted for the password even if a RedirectionPassword
was provided.
With this change the prompt is only shown if both settins->Password and
settings->RedirectionPassword is absent.
To be able to avoid password conversion if the password is already unicode
this change adds the sspi_SetAuthIdentityWithUnicodePassword() function
that is identical to sspi_SetAuthIdentity() except that the password is
used without further conversions in the Unicode identity.
