* 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
(some client side channels and all server side channels still need to be
ported to new api)
server: build fix, do not disable threads for rfx encoder
cliprdr client channel: implemented support for DisableThreads option
looks like thread does not make sense at all for this channel
do not initialize disabled image codecs (respect settings)
channels: client: rail: added support for DisableThreads setting
changed "BOOL DisableThreads" to "UINT32 ThreadingFlags"
dropped unnecessary apu changes
draft implementation of threading settings aware message handling api
for addins/channels
rail: use new messaging api
fixed memory leak
msgs handlers external api changes (as requested)
msgs_handlers: init fix
fixed memory leak
logic fix
resolved problems appeared after rebase to master, dropped unnecessary
changes
git clang-format origin/master
fixed TestFreeRDPCodecRemoteFX.c
"formatting, run `clang-format` please"
properly use new "rfx_context_new(BOOL, UINT32)" everywhere
passed Threading Flags to "rfx_context_new" where available
in older C standarts veriables declaration must be done before any code
requested changes
clang-format as requested
use broken signatures of standert C functions for m$ s**tos
clang-format
requested changes
requested changes
moved ThreadingFlags to stable api zone
define type for channel msg handler
typo fix
clang-format
build fix
us ThreadingFlags from server settings
git clang-format origin/master
clang-format
When channels are cleaned up OpenHandle is most of the time
already 0. Ignore the argument checks for
CHANNEL_EVENT_WRITE_CANCELLED and CHANNEL_EVENT_WRITE_COMPLETE
only check where actually required (CHANNEL_EVENT_DATA_RECEIVED)
This one is for proxy use. The proxy must know what format is requested by the other side
of the connection, for determining if the message should be passed
or ignore (for example, if we want to allow only text, the proxy must
verify that the requested format received in Format Data Request PDU is
a text format.
If the server sends us garbage (or the client provides it) then it is
possible for the multiplication to overflow (as it is performed on
unsigned 32-bit values) which will result in a false positive failure of
the sanity check. Avoid it by rearranging arithmetics a little.
Keep the multiplication in the error message because we are interested
in the number of bytes in the stream and how it compares to the number
we have expected based on the presumed file count.
The file contents PDUs support 64-bit file sizes and offsets, but
MS-RDPECLIP explicitly says in 2.2.5.3 File Contents Request PDU that
file larger that 4 gigabytes are not supported by the server. It turns
out that the supported size is even lower than that. The server cannot
correctly handle files larger than 2 gigabytes (inclusive). When faced
with such files it correctly retireves the lower part, but fails to
accept any data past that boundary. After receiving a file range reply
the server repeats the file range request with the same offset, and
again, and again, and again, making no progress and blocking the file
transfer indefinitely. This is not the behavior we would like to have.
Microsoft support site acknowledges and documents the issue [1],
suggesting the users to use disk drive redirection instead to transfer
large files. (File transfers via cliprdr are considerably slower than
disk drive redirection so the suggestion makes very much sense.)
However, we would like to avoid the lockdown of the remote session if
the user does attempt to transfer such files so we add a size check.
Putting it into the conversion from FILEDESCRIPTOR to CLIPRDR_FILELIST
is not an ideal place (the clients may not use the common utilities),
but that's good enough currently.
[1]: https://support.microsoft.com/en-us/help/2258090
Do not try to 'helpfully' fixup the length of the data provided by the
client when FILECONTENTS_SIZE is present. This can lead to a crash if
the client wants to report an error in msgFlags, sets cbRequested to
zero, and does not provide any data in requestedData. For example,
XFreeRDP does this in xf_cliprdr_send_file_contents_failure() and
xf_cliprdr_clipboard_file_size_failure().
