The [MS-RDPESC] clearly states in section 2.2.2.18 that Status_Call's
cbAtrLen must not be used when generating Status_Return response. This
is also how FreeRDP 1.1 behaves.
* fix StatusW_Call to rely and use SCardStatusW
* fix trace call in StatusW_Call - needs to be called after the sizes
are set
* unify SCardStatus functions for pcsc - let the internal function handle unicode directly
This fixes an issue with size calculations of SCardStatusW.
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.
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.
