This topic branch provides compatibility for Windows, without the
MINGW32 dependency.
It is based on https://github.com/LibVNC/libvncserver/pull/22.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With Microsoft Visual C++, we cannot use pthreads (MinGW sports an
emulation library which is the reason we did not need Windows-specific
hacks earlier). Happily, it is very easy to provide Windows-specific
emulations for the pthread calls we use.
[JES: fixed commit message]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Microsoft Visual C++ does not allow pointer arithmetic on void pointers.
[JES: fixed commit message]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To support Microsoft Visual C++, we must not guard Windows-specific code
in MinGW-specific #ifdef guards.
Happily, even 64-bit MSVC defines the WIN32 constant, therefore we can use
that instead.
[JES: fixed commit message, reordered commit, split out unrelated changes]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The stdint.h file was copied from:
https://runexe.googlecode.com/svn-history/r9/trunk/src/runlib/msstdint.h
(we can incorporate it because it is licensed under the 3-clause BSD
license.)
[JES: fixed commit message, fixed stripped copyright header]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In Microsoft's Visual C runtime, the snprintf() function is actually
called _snprintf. Let's just #define the former to call the latter.
[JES: fixed commit message]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We link to ws2_32.lib which corresponds to the winsock2.h header, not the
winsock.h header.
[JES: fixed commit message]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This change is technically not required to support MSVC, but it was
detected by Microsoft's compiler.
[JES: fixed commit message]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
If MallocFrameBuffer() returns FALSE, frame buffer pointer is left to
NULL. Subsequent writes into that buffer could lead to memory
corruption, or even arbitrary code execution.
check_xrandr_event() assumes X_LOCK is taken before it is called, and
currently calls X_UNLOCK on behalf of the caller. But in practice, all
callers assume that the lock is still held after check_xrandr_event()
returns. In particular, this leads to a double-unlock and crash in
check_xevents() on any xrandr event.
check_xrandr_event() assumes X_LOCK is taken before it is called, and
currently calls X_UNLOCK on behalf of the caller. But in practice, all
callers assume that the lock is still held after check_xrandr_event()
returns. In particular, this leads to a double-unlock and crash in
check_xevents() on any xrandr event.
This makes the library friendly to use as a git submodule within another
project, and should change nothing when compiled alone.
For example when having a directory structure like "my_project/external/libvnc",
where in libvnc resides a checkout of libvncserver, one can just reference that
directory from the CMakeLists.txt in my_project with
> add_directory ( external/libvnc )
and add vncclient / vncserver in my_project's taret_link_libraries, one can just
hack away without having to manually make / install LibVNCServer whenever
something is changed there.
Since we connected to the client through the repeater, chances are
that we want this server shut down once the client disconnected.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
UltraVNC offers an add-on to connect clients and servers via IDs with
a so-called repeater (e.g. to bridge firewalled clients and servers):
http://www.uvnc.com/products/uvnc-repeater.html
This example demonstrates how to use that feature with a
LibVNCServer-based server.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
While at it, also ignore the documentation of the RFB protocol best
downloaded manually from
http://www.realvnc.com/docs/rfbproto.pdf
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
rfbClientSetClientData() allocates a new rfbClientData, but never gets
cleaned up, which causes memory leaks.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Christian Beier
Johannes Schindelin
Daniel Cohen Gindi
Nicolas Ruff
Luca Falavigna
Luca Falavigna
newsoft
Amandeep Singh
Will Thompson
Matthias Treydte
dextero
Robbert Klarenbeek