Currently since the hash/keyCompare/keyClone members on the
context->cache were never being set, we were using the
HashTable_Pointer* variants, meaning that lookup always
failed (since we never ask for the same *pointer* twice).
This also revealed that the logic for autoallocate on these ops
was a bit backwards, and some error codes and support for the
"freshness" counter were missing.
In Win10 (at least with some card minidrivers) the freshness
counter is load-bearing and smartcard login won't work without
implementing a very basic version of it.
Terminating null character was inserted in the middle of readerNames instead of
last position in the unicode version of SCardStatus function.
This commit fix it.
* 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.
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.
Conflicts:
channels/smartcard/client/smartcard_operations.c
channels/smartcard/client/smartcard_pack.c
channels/smartcard/client/smartcard_pack.h
smartcard_operations: move handling of call argument into functions
The call argument was only use by static functions and was always equal
to operation->call. Remove the argument and use operation-call directly.
Also put the memory allocation and check into the same place.
Conflicts:
channels/smartcard/client/smartcard_operations.c
Updated formatting and API
1)
Added missing checks for CreateEvent which also required the
following related changes:
- changed freerdp_context_new API to BOOL
- changed freerdp_peer_context_new API to BOOL
- changed pRdpClientNew callback to BOOL
- changed pContextNew callback to BOOL
- changed psPeerAccepted callback to BOOL
- changed psPeerContextNew callback to BOOL
2)
Fixed lots of missing alloc and error checks in the
changed code's neighbourhood.
3)
Check freerdp_client_codecs_prepare result to avoid segfaults
caused by using non-initialized codecs.
4)
Fixed deadlocks in x11 caused by missing xf_unlock_x11() calls
in some error handlers
5)
Some fixes in thread pool:
- DEFAULT_POOL assignment did not match TP_POOL definition
- don't free the pool pointer if it points to the static DEFAULT_POOL
- added error handling and cleanup in InitializeThreadpool
* Check for NULL parameters in PCSC_ConvertReaderNameToWinSCard (Issue #2184)
* Remove masking of dwEventState as it is not needed under Linux and MacOSX and it helps in ThinLinc environment
* Workaround for Mac OS X Yosemite (10.10) SCardStatus Bug (Issue #2184)
* Since Mac OS Tiger (10.5.6), Apple introduced new function for SCardControl calls named SCardControl132(), the old SCardControl doesn't work (cf. https://opensource.apple.com/source/SmartCardServices/SmartCardServices-55111/src/PCSC/winscard_clnt.c)
