Please note that CMake, when used with Visual C++ and NMake, will always
set the default build type to Debug, so it always has to be overridden
on the command line (see BUILDING.txt.) Setting the default
CMAKE_BUILD_TYPE to Release, per below, is only useful with MinGW or
other types of builds.
On 3/3/11 9:08 AM, Antoine Martin wrote:
Does 7.5 work now? Shall I be using that instead? (I wasn't because
there were some strange build errors previously - maybe fixed now)
7.5 doesn't work on RHEL 4 or 5, but it may work on more recent systems
with newer autotools.
or is in the current
binaries that DRC built. I am running the same binaries and I am still
specifying in the old manner. I have not tested the short form using
them. I was not sure if that work was completed yet.
Again this is my understanding from following that thread. If anything
in my 2
Is there a good reason why only VncAuth and TLSVnc are enabled on the
server by default? Would it be reasonable to enable the other secure
types as well?
DRC
--
Free Software Download: Index, Search Analyze Logs
On 3/1/11 3:10 PM, Martin Koegler wrote:
I had the same problem long ago, I modifed the vncserver script this way:
system(($vncStartup ; $0 -kill :$displayNumber ) .
quotedString($desktopLog) . 21 ) if ($vncStartup);
The change is minimal and it does not change the function/parameters
On 3/2/11 3:00 AM, Sebastiaan Breedveld wrote:
Working on understanding too: if VeNCrypt would be the default, the
authentication is always done using PAM. However, a 'vnc' pam file is
not present by default. It is also not trivial to make one since each
distribution has its own way of
OK, that makes sense. Thanks.
On 3/2/11 4:41 PM, Martin Koegler wrote:
On Tue, Mar 01, 2011 at 08:53:27PM -0600, DRC wrote:
Is there a good reason why only VncAuth and TLSVnc are enabled on the
server by default? Would it be reasonable to enable the other secure
types as well?
X509
On 3/1/11 7:03 AM, Sebastiaan Breedveld wrote:
As far as checking for the VNC password, we're no longer requiring
VeNCrypt to be specified in the -SecurityTypes parameter, so checking
for that won't work. The correct approach is to check whether
-SecurityTypes is not specified -- or --
On 2/25/11 2:13 AM, Martin Koegler wrote:
The problem is, that some pam modules react differently, if they are
invoked by root or a normal user.
The debian pam_unix eg. let normal users only verify their own
password and fails on any other user name. Other modules like pam_krb5,
(also
why it would only be happening with TLS, though. It may not
even be the same issue as what I was seeing.
On 2/25/11 2:29 PM, Robert Goley wrote:
I have been doing more testing with the binaries DRC provided. Thanks
for those btw. For the most part, these are working great. I have
noticed
On 2/23/11 5:55 AM, Martin Koegler wrote:
Why does the trace/error infrastructure of libjpeg puts all parameters
for formating the message into a structure and then calls via a
pointer a functions (emit_message), which determines, if the message
should be printed?
Not sure. That is inherited
On 2/22/11 5:57 AM, Pierre Ossman wrote:
(2) The ability to drive different clients at different frame rates (a
per-client image queue with frame spoiling accomplishes this.)
RFB Continuous Updates solves (1) but not (2). (2) would require a
fundamental re-architecture of Xvnc.
To my
This doesn't work right. If the server security type order is being
honored, then it should be the case that if I set the server order to
VncAuth,TLSVnc, the client should use VncAuth by default as long as
VncAuth is in the client's list of security types. That is not what is
happening. TLSVnc
Confirmed. Let me spin a new build and double check it, and I think
we're go for beta after that.
On 2/21/11 7:43 AM, Adam Tkac wrote:
On Mon, Feb 21, 2011 at 07:19:31AM -0600, DRC wrote:
This doesn't work right. If the server security type order is being
honored, then it should be the case
On 2/21/11 10:30 AM, Adam Tkac wrote:
May I have some questions about Windows installer?
1. Why there is no winvnc with TLS?
Because the only way I knew how to build TLS support was using MinGW,
and WinVNC can't be built with MinGW. When I build TLS support on
Windows, I am using the
On 2/20/11 11:27 AM, Martin Koegler wrote:
Adding SSH Tunnling to the comparison would be interesting (the CPU
time of ssh must be added to the server/client time, as the SSH
process does the crypto operations on behalf of TigerVNC).
To be clear, the CPU time in my measurements was the
On 2/18/11 4:55 AM, Adam Tkac wrote:
The attached patch improves frame rates to 9-11 fps.
Good catch, I improved your patch a little and commited it as r4295.
With the patch GNUTLS debug routines are registered only when we
need their output.
Definite improvement. Here's what I now see
On 2/18/11 3:11 AM, Adam Tkac wrote:
Building X.Org 7.5 on older systems, like RHEL 4/5 will probably fail
because upstream doesn't care about backward compatibility much.
In my opinion we can build Xvnc only on fairly new systems, like
RHEL-6 (not sure about RHEL-5). Resulting static Xvnc
Since Martin has confirmed that the GnuTLS slow-down is not
system-specific, I propose to move forward with changing the default
server security types such that VncAuth is first and VeNCrypt is implicit.
On 2/11/11 12:09 PM, DRC wrote:
On 2/11/11 2:24 AM, Martin Koegler wrote:
It should
On 2/17/11 3:38 PM, Martin Koegler wrote:
This decision has been commited by Adam in rev 4093 and 4094.
He has ripped out the support switching between Client and Server
security type order and set the default to client.
I propose the following solution to enable software rendering in the
portable version of TigerVNC:
(1) When Xvnc is built with build-xorg, add
--with-dri-driver-path=../lib/dri to the Xorg configure options
(2) Modify vncserver as follows:
Index: unix/vncserver
On 2/16/11 2:25 AM, Martin Koegler wrote:
Both approches use different security models:
* sshing as user on the server and then executing the rest (session
listing, ...) as user too fits in the unix permission schema: The
client only does automatically, what the user could have done
On 2/14/11 3:59 PM, Martin Koegler wrote:
OK, let me see if I can get you a 2D benchmark to use.
Thanks.
I've been doing more digging. I have verified that indeed the software
OpenGL renderer is creating way too much overhead to be useful for the
purposes of this testing, even when just
On 2/16/11 10:03 AM, Adam Tkac wrote:
(1) When Xvnc is built with build-xorg, add
--with-dri-driver-path=../lib/dri to the Xorg configure options
That makes sence but you need to use ../lib64/dri on 64bit Linux.
Another solution, as I wrote on
On 2/15/11 9:22 AM, Mike Fisk wrote:
1. Complete session management functionality including flexible
authentication, strong encryption, spawning new sessions, reconnecting
to existing sessions, etc. I lump a lot of things together that do
not have to be part of the RFB protocol and X server
On 2/14/11 4:52 AM, Adam Tkac wrote:
I successfully use CMake Visual Studio 2008 Express to build all
Windows stuff with all features. And I'm also using MS VStudio for
debugging testing on Windows. I will extend BUILDING.txt with
information how to build GNUTLS support on Windows.
On 2/14/11 5:42 AM, Adam Tkac wrote:
I see a couple problems with this solution:
1. This method still closes the socket after identifying a port,
which would allow the port to be allocated again before
/usr/bin/ssh finally gets around to opening the forwarding channel
and
On 2/14/11 2:25 AM, Martin Koegler wrote:
The performance problems are triggered by running running high
performance applications like virtualgl, which is not part of any
major distribution]. So any user of default installation of a major
linux distribution has either an Xvnc without 3D
On 2/14/11 4:02 PM, Eric Stadtherr wrote:
Do you know of a way to check for the successful bind? One of the
behaviors that drove me down the libssh path was that /usr/bin/ssh
happily continues running despite failing to bind to the local port.
Therefore there is no exit status to interrogate
/xorg.build directory from
DRC and extract it to the same path. I would like to find a more
permanent way to fix this problem but it should only be an issue on
distributions that have a version of xorg too old to build the Xvnc
program against
I'm not following you. We already established that the auth extensions
can be used without building the code with GnuTLS support, so why is
this still an issue?
On 2/13/11 3:47 PM, Martin Koegler wrote:
On Fri, Feb 11, 2011 at 10:53:48AM -0600, DRC wrote:
I would still be interested
is correct.
Also, I was using TLSVnc, not TLSNone, but that shouldn't make a
difference, right?
DRC
On 2/13/11 1:11 PM, Martin Koegler wrote:
On Sat, Feb 12, 2011 at 03:19:48PM -0600, DRC wrote:
You have to run glxspheres with vglrun. Otherwise, it will use the
software OpenGL renderer
On 2/12/11 12:55 AM, Pierre Ossman wrote:
We want less bundled stuff, not more. Better we do a nice writeup
(possibly with helper scripts) on how to build GnuTLS on Windows.
Building it with MinGW is a no-brainer (although it takes a while, due
to the slowness of MSYS autotools.) I built
On 2/11/11 9:30 PM, Eric Stadtherr wrote:
I see GnuTLS and libssh as providing fundamentally different
capabilities. GnuTLS provides transport-level encryption of application
data, which in TigerVNC's case provides encrypted RFB protocol over a
direct socket connection. libssh provides an
On 2/11/11 9:16 PM, Eric Stadtherr wrote:
I see a couple problems with this solution:
1. This method still closes the socket after identifying a port,
which would allow the port to be allocated again before
/usr/bin/ssh finally gets around to opening the forwarding channel
the exact scenario under which I am
running the benchmarks, set your TigerVNC geometry to 1240x900 and use a
1280x1024 resolution on the client display.
DRC
On 2/12/11 1:13 PM, Martin Koegler wrote:
On Fri, Feb 11, 2011 at 10:53:48AM -0600, DRC wrote:
On 2/11/11 2:17 AM, Martin Koegler wrote:
What do
On 2/11/11 3:20 AM, Pierre Ossman wrote:
As Cendio is
proposing to move to a unified cross-platform viewer code, I even wonder
whether we shouldn't split viewer and server into separate builds. How
much of the code will really be shared by both once the viewer is using
FLTK?
common/,
On 2/11/11 2:17 AM, Martin Koegler wrote:
What do you mean still get 20 Mbit? You mean Megapixels/second? Or
do you mean Megabits/second of throughput? Because without VeNCrypt, my
I mean the value showen in the viewer info dialog. What tools are you using?
A thorough description of my
On 2/11/11 2:24 AM, Martin Koegler wrote:
It should be possible (HAVE_GNUTLS not defined). In that case,
VeNCrypt + Plain are still available.
Right you are. I built without GnuTLS, and Plain definitely does still
work. That makes me feel better about the feature, in general.
I guess the
On 2/11/11 12:06 PM, Eric Stadtherr wrote:
The port conflict arises when you start two vncviewers with the -via
flag back-to-back pointed to two different servers. In lockstep, both
viewers will:
1. look for a free TCP port on the local host within a pre-determined
sequence (by
On 2/11/11 1:05 PM, Martin Koegler wrote:
They are useful for cross-compiling (mingw as cross-compiler) - in
fact, they were the only way for me to get an working windows viewer
with GNU TLS support.
You can cross compile using MinGW and CMake. See BUILDING.txt. I
really want to fix whatever
On 2/11/11 1:05 PM, Martin Koegler wrote:
For the VeNCrypt project, I have been building GNU TLS with MS VC 6.0
(as part of the project like zlib).
I thought, that the project would prefer out of tree GNU TLS, but:
If somebody with commit access, would commit (a not too broken)
solution for
On 2/11/11 4:10 PM, Robert Goley wrote:
This is true, it was added because VNC did not support session
encryption. I would much prefer a high performance TLS with no need for
SSH. The benefit of bouncing off firewalls and other machines is useful
occasionally but is not a required function.
-0600
DRC dcomman...@users.sourceforge.net wrote:
I could write a book on the difficulties I've had with GnuTLS. I am
ultimately finding that I have to pretty much build it from source on
all of the platforms. Honestly, I don't really care about the
encryption aspects of it at all
On 2/10/11 2:24 AM, Martin Koegler wrote:
I really wonder how useful of a feature built-in session encryption is
if it's this slow. Without encryption, I can get approximately 20
Megapixels/second. Tunneling through SSh, about the same. With TLSVnc,
I get about 7.5 Megapixels/second. For
On 2/10/11 3:35 PM, Martin Koegler wrote:
We could always port over an authentication method that supports
username/password without the full encryption framework. I don't have
any objections to that.
It's already present in the SVN version, but not enabled in the
default security type
On 2/10/11 4:00 PM, Martin Koegler wrote:
Please don't mix up Encryption with VeNCrypt. VeNCrypt consists of two
parts:
1) An extended chooser, which has enough available security type
numbers even for every hobby developer.
2) New security types (TLS encryption with/without certificates,
We should probably add something like Copyright (C)2010-2011 TigerVNC
Team to po/tigervnc.pot.
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they
at it...
Robert
On 02/10/2011 05:11 PM, DRC wrote:
On 2/10/11 3:39 PM, Robert Goley wrote:
What are the SecurityType options that must be passed to enable it?
This would be useful in benchmarking differences between TLS and non TLS
connections...
On the server:
-SecurityTypes=VeNCrypt,Plain
with
GnuTLS, as far as I can tell.
Since all of this labor was unpaid, if anyone would like to donate to
one of my other projects to help me offset the cost, it would be very
much appreciated. The links for donations are under
http://VirtualGL.org and http://libjpeg-turbo.VirtualGL.org.
DRC
This is good work, but I'll be 100% honest-- after digging myself into a
deep pit of GnuTLS Hell this week, the thought of introducing yet
another dependency on yet another security library makes me cringe. Is
libssh really necessary? I've never observed the port conflicts you're
talking about.
Uh, no. Precisely not. I'm still hacking. I will let you know.
On 2/9/11 2:28 AM, Pierre Ossman wrote:
On Mon, 07 Feb 2011 11:41:14 -0600
DRC dcomman...@users.sourceforge.net wrote:
I would love to be able to build with GNU TLS before this happens. Can
you please look at the problem I
.
An unrelated issue is that whenever I try to use the vncviewer GUI to
set the Zlib level to something other than the default, the server
crashes (the log says ZlibOutStream: deflate failed.)
DRC
--
The ultimate all-in-one
/tigervnc.pot), and the new versions differ from the
versions that are checked into SVN.
DRC
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find
I would love to be able to build with GNU TLS before this happens. Can
you please look at the problem I reported regarding the use of the older
GNU TLS version?
On 2/7/11 3:48 AM, Adam Tkac wrote:
Hello all,
all features which have been proposed approved for TigerVNC 1.1 are
commited in
(1) Can we please get rid of the Visual C++ project files that are still
hanging around?
(2) What is the purpose of the common/javabin directory? Can it be deleted?
(3)
unix/xorg-7.5-patches/0001-Add-dridir-parameter-to-specify-DRI-drivers-director.patch
and
/home/drc/worksrc/tigervnc/common/rfb/UserPasswdGetter.h:21: warning:
'class rfb::UserPasswdGetter' has virtual functions but non-virtual
destructor
/home/drc/worksrc/tigervnc/common/rfb/ColourMap.h:29: warning: 'class
rfb::ColourMap' has virtual functions but non-virtual destructor
/home/drc
not consider this an good option, and I
suspect DRC has similar wishes when it comes to deployment.
wxWidgets is disqualified as a consequence of this as it uses GTK on
Unix platforms.
What's left is FLTK. This is not the most fancy toolkit out there, but
it gets the job done and is very
Whenever I get a chance, I'll try upgrading my version of autoconf and
see if that allows me to build successfully with 7.5.
On 11/15/10 9:41 AM, Alan Coopersmith wrote:
DRC wrote:
'build-xorg -version 7.5' should be considered an experimental feature
at the moment. I have never been able
'build-xorg -version 7.5' should be considered an experimental feature
at the moment. I have never been able to successfully build TigerVNC
against Xorg 7.5 on RedHat Enterprise 4 or 5. Currently, I get an error
when build-xorg tries to autoconf the Xorg source:
configure.ac:468: error:
Honestly, I didn't develop those extensions, so I'm trying to process
the information second-hand. :) If the same functionality can be
implemented without using the Tight security type, then I guess I have
no problem with removing it. UCAR ultimately wants to look at
implementing the TurboVNC
TurboVNC 1.0 uses the Tight security type to implement its auth
extensions, and it relies upon the ability to advertise capabilities to
the client using that mechanism. Whether or not the Tight security type
actually does anything in our implementation, I think it is important to
be able to
On 11/2/10 10:58 AM, Antoine Martin wrote:
--disable-config-hal and --disable-config-udev configure options should
fix
those issues.
Would you recommend that hal and udev be turned off for a default
generic build? Or is it a harmless error?
I don't really see much point in having them for a
I'll look into it this week.
On 10/29/10 6:12 PM, Robert Goley wrote:
I spoke too soon but it was related to your change. Apparently, on my
last test I did not use the -static flag. This time I did which tripped
the errors. The errors did not appear when I did a simple ./configure
because
On 10/29/10 8:01 AM, Adam Tkac wrote:
Windows code currently doesn't use i18n so in my opinion you don't
have to hurry up with this.
Just noticed this, and I am breathing a sigh of relief. I guess all I
need to figure out is GnuTLS, then.
Please post log. I think I was the one who made that change.
On Oct 29, 2010, at 1:52 PM, Robert Goley rago...@rdasys.com wrote:
The changes made to configure.ac after revision 4128 have broken the checks
for gnutls on Debian 5.0 (Lenny). Using the version from 4128 works
perfectly.
What should work:
-- 32-bit and 64-bit builds using NMake (with Visual C++ 2005-2010),
Visual Studio 2005-2010 IDE, or MinGW/MinGW-w64 (either native or
cross-compiled on Linux.)
-- WinVNC, if built with Visual C++. The default is currently to
disable the WinVNC build when using MinGW, but you
to generate internationalization files, then
it defeats the purpose of using a cross-platform build tool.
DRC
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps games for the Nokia N8
in our autotools system all at once makes my head spin.
DRC
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development
Cendio is going to finance the project, so I will be beginning work on
the new CMake build system within the next week. I need to do some
investigation first to get a feel for how to do cross-compilation, host
detection, feature checking, and other things that will eventually be
necessary
later and package it the same. I will try to build under 7.5 on linux
later and get you the specific errors I was getting too.
Robert
On 10/01/2010 05:09 AM, DRC wrote:
The specific errors I see when trying to build with the Xorg 7.5 code on
RHEL 4 and 5 are as follows:
configure.ac:468
wants it for testing. I will build the 32 bit version for Snow Leopard
later and package it the same. I will try to build under 7.5 on linux
later and get you the specific errors I was getting too.
Robert
On 10/01/2010 05:09 AM, DRC wrote:
The specific errors I see when trying to build
I see that as a feature, not a bug. We don't want it to be a
free-for-all. We want access controls similar to the subversion repository.
On 10/1/10 4:44 PM, Martin Koegler wrote:
On Fri, Oct 01, 2010 at 02:38:53PM -0500, DRC wrote:
I agree. SourceForge has mediawiki pre-installed, so
or the git repo. I haven't tried 7.4 since before the TLS stuff was
officially added. I will try 7.4 again and post my results. Noticed
the typo in the last email. I meant TigerVNC of course
Robert
On 09/30/2010 12:40 PM, DRC wrote:
Me too! That is why I'm willing to work
/16/10 4:15 AM, Adam Tkac wrote:
On Thu, Sep 16, 2010 at 03:14:02AM -0500, DRC wrote:
Once I can successfully get a static build going on RHEL 4 (still having
problems with the lack of gnutls_transport_set_global_errno), I'll look
into these issues. libgcrypt and libgnutls are definitely
On 9/20/10 3:42 AM, Adam Tkac wrote:
Which version of autoconf are you using?
The version that ships with RHEL 4 (2.59).
The attached patch seems to make things work properly. Question for
Martin: Is the while(0) really necessary? I don't understand why the
macro can't just be:
#define
know Windows is your focus.
Robert
On 09/29/2010 05:40 PM, DRC wrote:
I've looked at SCons cursorily. The original reason why I started
looking at CMake was that I'm a visualization guy, and CMake has a lot
of traction in that community (that's where it came from originally.)
More
On 9/18/10 4:48 AM, Martin Koegler wrote:
Autoconf allows adding a argument list to a Macro defined by AC_DEFINE:
| -- Macro: AC_DEFINE (VARIABLE, VALUE, [DESCRIPTION])
| -- Macro: AC_DEFINE (VARIABLE)
| Define VARIABLE to VALUE (verbatim), by defining a C preprocessor
| macro
On 9/9/10 2:11 AM, Martin Koegler wrote:
I can not imaging, how such errors can happen.
This test only adds the following to config.h:
| /* Is gnutls_set_global_errno present */
| #define gnutls_transport_set_global_errno(A) do { errno = (A); } while(0)
|
So any code not refering to
On 9/16/10 4:15 AM, Adam Tkac wrote:
My MinGW patch isn't accepted, yet. And I'm not sure if it will be
accepted:
https://sourceforge.net/mailarchive/message.php?msg_name=AANLkTikg0hAGpArLTqFSWn6IdSI5aNOwJk-3ZDl4rqrq%40mail.gmail.com
I'm going to merge my vcstudio_buildsys branch to trunk so
I have confirmed that RHEL 4 doesn't have the
gnutls_transport_set_global_errno function:
g++ -DHAVE_CONFIG_H -I. -I/home/drc/worksrc/tigervnc/common/rdr -I../..
-I/home/drc/worksrc/tigervnc/common
-I/home/drc/worksrc/tigervnc/common/zlib -O3 -static-libgcc -fPIC -Wall
-MT librdr_la
On 9/7/10 4:53 AM, Adam Tkac wrote:
Imagine this situation:
server:
- admin starts it with following parameter:
-SecurityTypes VeNCrypt,Plain,TLSNone,None
client:
- started with following parameter
-SecurityTypes VeNCrypt,TLSNone,Plain
In this situation client will select
On 9/3/10 12:00 AM, Martin Koegler wrote:
The client side honors the Security Type order of the server - code
for using the client side order was removed with Remove unused
CConnection::setClientSecTypeOrder function on Jul 20 2010.
So does that mean if Plain is enabled on the server and put
On 9/2/10 11:53 PM, Martin Koegler wrote:
After checking, when gnutls_transport_set_global_errno was introduced,
please decide yourself, if support for older versions is really
necessary.
I need to try building this stuff on RHEL 4 to make sure it all works on
that platform. I'll try to get
Can you refresh my memory as to the fallback order of both the
encryption and auth options on the server end, as well as how a user
could configure the server to use only certain encrypt/auth options?
One other question-- does the user/password authentication use the Unix
Login Authentication
No, the patch was checked into the subversion trunk, which is being used
to stage 1.1. It didn't make it into 1.0.1. I just checked in the same
patch to the 1.0 branch, so in case we do a 1.0.2 release, it'll be in
there. In the meantime, you'll probably have to build from source to
get it. I
On 7/23/10 3:40 AM, Martin Koegler wrote:
On Thu, Jul 22, 2010 at 04:02:52PM -0500, DRC wrote:
This makes the use of extended authentication types somewhat useless
from the point of view of a SysAdmin, though. If there is not a way for
them to enforce, or at least strongly encourage, the use
On 7/22/10 12:27 AM, Martin Koegler wrote:
-- A set of allowed security types can be configured for the VNC
server. It should be possible for a SysAdmin to specify this in a
central config file, which will take precedence over command line
options or per-user config files (thus, if a SysAdmin
On 7/21/10 3:16 AM, Adam Tkac wrote:
This is a valid argument but I would like to see feedback from other
TigerVNC developers to decide which types should be enabled by
default. I will open a separate thread for this.
I am joining into this discussion late, so I don't think I fully
understand
On 7/8/10 6:56 AM, Adam Tkac wrote:
Sorry for late response, I was away.
Ah, so you are not connecting to winvnc4 but to Windows RDP server?
Then, from my point of view, we might consider this as intended
feature because I can hardly imagine how winvnc4 and RDP server can
run simulateously
EViE was removed in Xorg 7.5. I tried running
./build-xorg init -version 7.5
on my tree and then grepping for evie under xorg/, and I see no
references except in the change logs and such.
That being said, I don't think anyone has successfully built TigerVNC
with Xorg 7.5. I was contracted to
In the Build Xorg section of build-xorg-7.4, can you try adding the
following code?
if [ ${module} = pixman ]; then
extraoptions=${extraoptions} --disable-gtk
fi
On 7/1/10 2:49 PM, Antoine Martin wrote:
Hi,
I have seen this one before on another platform (was OSX IIRC), but I
still have
As far as code compatibility, let's start with the fact that MinGW is
constantly behind the curve on the Windows API and always will be.
Yes, but it's quite easy to add missing libraries and headers, when
necessary.
Quite easy? No, far from it. Witness how long it has taken to resolve
the
On 6/1/10 6:52 AM, Thomas Sondergaard wrote:
Why does it have to be horribly ugly and inefficient? Do you also
consider the port-forwarding mechanism in ssh to be a horrible ugly
hack? Other than the large framebuffer update messages causing latency
problems for other traffic, I don't see
On 5/28/10 4:51 AM, Thomas Sondergaard wrote:
DRC wrote:
Why reinvent the wheel? I don't see why it's our job to reproduce the
functionality of SSH. Just use SSH.
Convenience is a good answer. Another answer is that VNC is used for
many things, and not all users that are allowed
Why reinvent the wheel? I don't see why it's our job to reproduce the
functionality of SSH. Just use SSH.
Now, if you instead mean internal encryption of the RFB protocol stream,
then didn't we get that as a result of the GNU TLS functionality that
Adam added?
On 5/25/10 4:19 AM, Thomas
to IID_IActiveDesktop
I have attempted adding -luuid and -lshell32 to the link line. Those
libraries are where CLSID_ActiveDesktop and IID_IActiveDesktop are
defined in Visual C++.
On 5/14/10 2:35 AM, DRC wrote:
I suspect that I'm the first person to have ever attempted to build the
TigerVNC Windows components
On 5/18/10 5:35 AM, Adam Tkac wrote:
I just tested the MS Visual C++ Express 2010 and I have to agree with
you the code compatibility is a valid point. Visual C++ prints bunch
of stupid warnings, like hey, this function is not thread safe.
Seems that non-threaded Windows program is simply a
On 5/17/10 9:52 AM, Peter Åstrand wrote:
Wouldn't it make more sense to fix the problems with MinGW instead? If
the official downloads are bad, we can provide our own
MinGW-for-windows. Shouldn't be very difficult. Sounds more fruitful
than trying to maintain multiple build systems.
Windows
I personally find IDE's more of a struggle than command line tools.
Plus, switching to a new IDE would be a lot more trouble than simply
converting and fixing the existing DSP files. Additionally, we'd still
have to use Visual C as the underlying compiler. It's not that building
TigerVNC from
201 - 300 of 359 matches
Mail list logo
