It's a reoccurring issue that users try to build individual components
by pointing cmake at a specific subdirectory, e.g. 'cmake vncviewer'.
CMake, unfortunately, has insufficient protection against this so we'll
need to add a manual check.
This commit only adds it to the most likely places for misuse so we
don't have to pollute every CMakeLists.txt.
These are not valid outside of UTF-16 so seeing them in a UTF-8 sequence
means that something is wrong with that sequence. Best to filter them
out rather than letting them propagate and have unknown effects.
We should handle this in the low-level protocol code as much as possible
to avoid mistakes. This way the rest of the code can assume that strings
are always UTF-8 with \n line endings.
We mostly use classical C strings, but the memory management around them
can get confusing and error prone. Let's use std::string for the cases
where we need to return a newly allocated string.
The generally recommended way is to include it from source files, not
headers. We had a mix of both. Let's try to be consistent and follow the
recommended way.
Support the VMware Cursor Position extension on vncviewer
This change makes it possible for re-synchronizing the remote cursor on
the vncviewer when in fullscreen mode. This is done by locally moving
the cursor position to what the server thinks it should be.
Now SDL games should work!
This would mess up most conversions from UTF-8 as the caller wouldn't
know how far to step to get to the next valid character, resulting in
markers for invalid data to be injected here and there.
Also add some unit tests to avoid this reoccurring.
If you have the setting "Emulate middle mouse button" turned on, a click
and drag can fail if it is done very quickly. The position of the
initial click will be incorrect in such a case because the timeout will
delay events.
Major restructuring of how streams work. Neither input nor output
streams are now blocking. This avoids stalling the rest of the client or
server when a peer is slow or unresponsive.
Note that this puts an extra burden on users of streams to make sure
they are allowed to do their work once the underlying transports are
ready (e.g. monitoring fds).
Our fast paths assume that each channel fits in to a separate byte.
That means the shift needs to be a multiple of 8. Start actually
checking this so that a client cannot trip us up and possibly cause
incorrect code exection.
Issue found by Pavel Cheremushkin from Kaspersky Lab.
Provides safety against them accidentally becoming negative because
of bugs in the calculations.
Also does the same to CharArray and friends as they were strongly
connection to the stream objects.
Otherwise we might be tricked in to reading and writing things at
incorrect offsets for pixels which ultimately could result in an
attacker writing things to the stack or heap and executing things
they shouldn't.
This only affects the server as the client never uses the pixel
format suggested by th server.
Issue found by Pavel Cheremushkin from Kaspersky Lab.
We now filter incoming data, which means we can start assuming the
clipboard data is always null terminated. This allows us to clean
up a lot of the internal handling.
Let CMsgHandler::serverInit() handle initial set up
Avoid using the callbacks used for runtime changes for the initial
setup. They weren't really useful anyway as you could not allocate
a framebuffer without also knowing the pixel format. So make things
more clear by letting serverInit() get the initial settings.
Avoid direct access to the screen dimensions and layout so that we
can make sure it stays sane. This also makes sure the layout is
properly updated when we only get the screen dimensions from the
server.