The additional compat_mkdir function was not necessary at all.

`windows.h` is referring to `winsock.h` (unless the `WIN32_LEAN_AND_MEAN` is defined).
The structs used in this header are defined in `winsock2.h` or in `winsock.h`, but we are using Winsock2 of course!
So we have to include winsock2.h and refrain from including windows.h here

Basically taken from https://github.com/danielgindi/FileDir with some adjustments

Passing NULL to sprintf() would most likely crash the program.

`strings.h` and `resolv.h` are not available on MSVC, and some POSIX functions are renamed or deprecated

For all of those missing/deprecated POSIX functions, we just add a macro mapping to the _underscored version of MSVC.

The new x11vnc repo is at https://github.com/LibVNC/x11vnc.

This bug was introduced in the MSVC patches.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

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>

[JES: provided commit message, split out unrelated changes]
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>

That's because there are duplicate #defines, and when Winsock2 is defined
before windows.h then windows.h detects that and prevent redefinition.

See
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/4a90b143-1fb8-43e9-a54c-956127e0c579/windowsh-and-winsock2h?forum=windowssdk

[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>

Fixing two more security issues (remote server crash)

Do not accept a scaling factor of zero on PalmVNCSetScaleFactor and SetScale client->server messages. This would cause a division by zero and crash the server.

Check malloc() return value on client->server ClientCutText message. Client can send up to 2**32-1 bytes of text, and such a large allocation is likely to fail in case of high memory pressure. This would in a server crash (write at address 0).

Merge patches from KDE/krfb

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Fix integer overflow in MallocFrameBuffer()

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.

Promote integers to uint64_t to avoid integer overflow issue during
frame buffer allocation for very large screen sizes

This allows for reinitializations of e. g. sockets in a SHUTDOWN state.
The only state that doesn't make sense to reinitialize are READY states.