* top level GDI functions return 0 on error and != 0 otherwise but the
low level functions (16bpp.c, 8bpp.c 32bpp.c) which are called did it
exactly the other way around. Those were adapted.
* change gdi_InvalidateRegion to BOOL and check calls where appropriate
* integrate comments from pull request
Change the return type of Stream_Ensure*Capacity from void to BOOL to be
able to detect realloc problems easily. Otherwise the only way to detect
this was to check if the capacity after the call was >= the required
size.
In case Stream_Ensure*Capacity fails the old memory is still available
and need to freed outside.
This commit also adds checks to most calls of Stream_Ensure*Capacity to
check if the call was successful.
Commit 0357a38e31 modified the function
fastpath_send_update_pdu() to check if the desired update is possible
by checking the payload size against the computed maxLength and the
clients's advertised max request size.
If the check failed that commit added a workaround which simply
copied the payload to a slow path updade.
This workaround is totally flawed and causes protocol errors:
- the fast path update code is not checked and required data format
conversions are missing
- depending on the fast path update code rdp_send_data_pdu() would
have to be called with differend data pdu type values but the
workaround always uses DATA_PDU_TYPE_UPDATE
- the workaround does not check if the total size would exceed
the maximum possible size for a slow path update
The check if a fast path output is actually possible with the
passed parameters is basically a good idea.
However, if that check fails it would only indicate an error in
the server implementation who must not generate updates that
exceed the client's max request size.
Even though a slow-path conversion would be possible there is
much more involved than simply copying the payload stream.
In addition it is highly doubtful if there is a benefit at all.
Even the oldest rdesktop and windows ce clients do support fast
path and although some lack the multi-fragment update capability
we cannot really send larger updates using slow-path outputs.
For the reasons elucidated above, I have removed the workaround
but kept a modified version of the check if a fast-path output
is possible at all.
* make sure fast-path packages are not fragmented if no
multifragment support was announced
* handle special server side case where the multifragment size
received from the client is smaller than one maximum fast-path
PDU size
This patch introduce misc checks when receiving pointer updates. We check
that the cursor are in the bounds defined by the spec. We also check that
the announced mask sizes are what they should be.
- fixed invalid stream position if extEncryptionMethods is not used
- enabled 56bit rdp security method
- fixed entropy reduction of the keys for 40 bit and 56 bit
- added rdp security incl. FIPS for fastpath output
- added FIPS encryption to fast path input
- fixed FIPS key generation in server mode
- fixed stream length correction in FIPS mode
- added rdp encryption for licensing packets (apparently some clients,
specifically cetsc, require the license packets received from the
server to be encrypted under certain RDP encryption levels)
- replace errnous virtual extended mouse event in focus in event
