FreeRDP 2.0.0 will automatically free all settings strings when the
settings structure is freed. As we will also do the same for our own
settings strings, the FreeRDP settings must be kept independent. There
is no guarantee that the FreeRDP settings will be pushed before an error
causes the connection to abort, nor that the FreeRDP settings will not
need to be pushed multiple times due to an automatic reconnect.
The intent of the previous version of the SFTP directory listing code
was to break the JSON transfer at blob boundaries, waiting for an ack
before sending the next blob, however the ordering of the "blob_written"
and directory read checks could result in a directory entry being
skipped at the boundary of each blob.
The proper order would be to check the "blob_written" flag first,
however the "blob_written" flag is unnecessary. It's simpler and more
correct to just break out of the loop once the desired blob has been
flushed.
This commit effectively reverts commit 9855d875c7.
With relaxed order checks enabled, FreeRDP will indeed invoke the
OpaqueRect and PatBlt handlers (even though we do not announce support
for those orders) as long as handlers are provided.
FreeRDP version 2.0.0-rc0 and older will automatically free whatever
entry_points->pInterface is set to when the channel plugin is unloaded.
This doesn't happen in later versions, but will result in a double-free
upon disconnect for 2.0.0-rc0 in our case. As we don't need pInterface,
we can safely set this to NULL and avoid the issue entirely.
In FreeRDP 2.0.0-rc0 and earlier, Bitmap_Free(bitmap) invokes the free
handler of the given bitmap, frees bitmap->data, and then frees the
bitmap. The implementation-specific free handler needs to be aware only
of the implementation's own concerns.
After FreeRDP 2.0.0-rc0, Bitmap_Free(bitmap) only invokes the
implementation-specific free handler, and it's on the implementation to
know that bitmap->data must be manually freed with _aligned_free() and
bitmap must be freed with free(). The implementation-specific free
handler must be aware of the internals of the library.
See commit 8dda26a.
If the admin intentionally disables both copy and paste, then there is
no need to log a warning that this is the case; it was intentional. A
warning will likely set off alarm bells within production log monitoring
systems.
