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.

These will always be byte streams at heart, so let's try to keep them
with a proper type. Should make it clearer how they will be used.

It is much more natural than custom methods for this very common
operation.

Avoids a bit of complexity by delegating that handling to a string
object.

Let's use a more common type instead of something homegrown. Should be
more familiar to new developers.

It's more standard and familiar than our custom CharArray type, and it
still gives us automatic freeing of the buffer.

We could probably have used std::unique_ptr instead, but we are
currently targeting older compilers where C++11 isn't standard yet.

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.

Avoid having our own custom stuff and instead use the modern, standard
types, for familiarity.

This allows us to separate accidentally unused, from explicitly unused
parameters, which allows us to turn on such checks in the compiler.

The flags should always be empty anyway.

We don't want any stray exceptions as we are cleaning up, so handle any
still pending decoder errors by just logging them. We are already
shutting down so there is no need to abort the connection here.

Otherwise we can get crashes on NULL dereference. This should only
happen on reverse connections where we don't have a server address.

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.

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!

The peer expects a response, so we should also be able to respond that
there is no clipboard data currently available.

The extended clipboard protocol has the ability for the peer to request
things to be sent automatically, without a request message. Make sure we
honor such settings.

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).

These are not universal in the protocol so having functions for them
only obfuscates things.

Some systems (like TLS) need to send some final data before closing
a connection. Make sure this is properly handled by cleaning up the
security object before closing the underlying network socket.

Implements support in both client and server for the extended
clipboard format first seen in UltraVNC. Currently only implements
text handling, but that is still an improvement as it extends the
clipboard from ISO 8859-1 to full Unicode.

In prepartion for better clipboard extensions that can send Unicode
data between the client and server.

Change the internal clipboard API to use a request based model in
order to be prepared for more advanced clipboard transfers.

There is some bug in gcc's new -Werror=format-overflow that makes it
think majorVersion could end up being very large. Increase the target
buffer for now to keep gcc happy.

ServerParams should contain the server state and not information about
client settings or capabilities. Move those things up a level to the
CConnection object.

No need to have one setting for each extension. All the client code
needs to indicate is if it supports resize. The common code can then
map this to relevant extensions.

These were either completely unused, or always true.

Tight is the default preferred encoding, so we don't really need
special handling for it to be first in the list.

This is a lot safer and cleaner. The old code had a fixed size that
we didn't properly keep track of.

Make sure all methods only write what is given as arguments, and
avoid side effects by getting data from parameter objects. This keeps
things readable in the calling code.

It's a generic client thing, so abstract it in to the common library.
Makes it easier to integrate with other common code.

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.

Add an explicit callback for subclasses to do their startup in. This
makes it easier to do proper ordering, and avoids mistakes.

We need to track different things in the server and client, so
separate things to two independent structures to keep things more
clear.

That object is just a container for the current state. Move the I/O
to the classes already doing such stuff.

There is already an implicit connection between them, so let's make
it explicit. This allows easy lookup outside of the processMsg() function.

These are just confusing and obfuscating. Do a normal delete of
these objects instead.

Include the type of exception in the string generated by each
subclass. Also simplify the constructs to what is needed.

They are created in SConnection's and CConnection's constructors but never destroyed.

There is no reason for the indirection, so lets make them direct members.

This implements the basic infrastructure for multi-threaded
decoding of rects. However there is just one thread reading data
and one thread decoding it. More logic is needed to safely decode
multiple rects at the same time.

We need more callbacks for correct operation of multi-threaded
rect decoding.

Done in preparation for multi-core decoding. Keeps the complexity
out of the other classes. This also moves ownership of the
framebuffer in to CConnection. It's the CConnection object that is
aware of the threads and how to synchronise with them. Therefore
the ownership of the framebuffer must also be there to make sure
it isn't deleted whilst threads are working.