* Use new ConvertUtf8ToWChar, ConvertUtf8NToWChar,
ConvertUtf8ToWCharAlloc and ConvertUtf8NToWCharAlloc
* Use new ConvertWCharToUtf8, ConvertWCharNToUtf8,
ConvertWCharToUtf8Alloc and ConvertWCharNToUtf8Alloc
* Use new Stream UTF16 to/from UTF8 read/write functions
* Use new settings UTF16 to/from UTF8 read/write functions
* Fixed format strings to match arguments
Reviewed and replaced all %d specifiers to match proper type
* Added proxy dynamic channel command type to log messages.
Microsoft Windows imposes strict filename restrictions on its platform.
As RDP is developed by Microsoft and the RDS in MS Windows is typically
used as remote desktop server for the RDP protocol, these filename
restrictions are also enforced in WinPR, when copy-pasting files over
the clipboard.
However, in some connections no peer on MS Windows is involved and in
these situations, these filename restrictions are just an annoyance.
With a recent API addition in WinPR, it is now possible to override the
callback, where the filename is checked, whether it is valid.
So, use this new API to relieve the filename restriction, when the
connected remote desktop server is not on MS Windows.
* Fixed remdesk settings pointer
* Fixed sign warnings in display_write_monitor_layout_pdu
* Use freerdp_abort_connect_context and freerdp_shall_disconnect_context
* Added and updates settings
* info assert/dynamic timezone
* mcs assert/log/flags
* Fixed and added assertions for wStream
* Unified stream length checks
* Added new function to check for lenght and log
* Replace all usages with this new function
* Cleaned up PER, added parser logging
* Cleaned up BER, added parser logging
* log messages
* Modified Stream_CheckAndLogRequiredLengthEx
* Allow custom format and options
* Add Stream_CheckAndLogRequiredLengthExVa for prepared va_list
* Improved Stream_CheckAndLogRequiredLength
* Now have log level adjustable
* Added function equivalents for existing logger
* Added a backtrace in case of a failure is detected
* Fixed public API input checks
When a FormatDataRequest by xfreerdp is answered with the
CB_RESPONSE_FAIL flag, then the request was answered, but xfreerdp does
not mark it as answered, by leaving the request as pending.
This results in non-functional copy-paste actions, when copying
something from the server side, after the failed request.
A similar situation can happen, when a new FormatList is received,
while there is a pending FormatDataRequest.
Fix these situations by clearing the pending request, when a form of an
answer, either via CB_RESPONSE_FAIL flag or via new FormatList, is
received.
Fixes: https://github.com/FreeRDP/FreeRDP/issues/7757
I personally find it more convenient to have pasted data written to
the X11 PRIMARY selection, so that I can paste it with a fast middle-
button click, than to write to CLIPBOARD which typically needs a key
sequence or menu action.
This commit adds a command-line option to let me express that
preference: now I can say "/clipboard:use-selection:PRIMARY" on the
command line, which not only enables clipboard transfer but also says
which X selection I want it to talk to. The previous options
"+clipboard" and "-clipboard" are also still supported.
A selection owner is supposed to respond to a request for the
selection target TIMESTAMP by providing the X server time at which the
selection was written. There was a /* TODO */ comment in xf_cliprdr
where the code to do that should have been.
The absence of this can cause a problem when pasting into some X
clients. xtightvncviewer, in particular, will give up the attempt to
read from the clipboard at all if it doesn't get a satisfactory
response to the initial TIMESTAMP request - and the non-answer zero
value "CurrentTime" counts as unsatisfactory. It won't be happy with
anything short of a real X server time value.
(Checking the VNC source code, that's because it reads both PRIMARY
and CLIPBOARD and picks the one with the later timestamp. So it does
depend on the timestamps existing.)
When you're writing to the selection in response to a normal X event
like a mouse click or keyboard action, you get the selection timestamp
by copying the time field out of that X event. Here, we're doing it on
our own initiative, so we have to _request_ the X server time. There
isn't a GetServerTime request in the X protocol, so I work around it
by setting a property on our own window, and waiting for a
PropertyNotify event to come back telling me it's been done - which
will have a timestamp we can use.
