On 10/6/11 2:50 AM, Peter Åstrand wrote: > Remind me, which functionality is missing if you build without Visual > Studio?
WinVNC. It's always been WinVNC. > It seems to me that instead of wasting time on maintaining multiple tool > chain, you could invest that time in streamlining the GCC based one. > > I think we should stop using Visual Studio. From the start my position > has been that multiple tool chains will mean trouble. I accepted that > approach however since I understood that you wanted it that way, but > since you are now telling us that you are unhappy with the current > situation, perhaps it's time to through Visual Studio out. > > Forcing everybody to use Visual Studio is not an option. I wanted it that way?! Peter, you have a somewhat strange memory. Did I not just say in my previous message that I would be happy to abandon Visual Studio if we could get away with it? The reason we can't is because of WinVNC. We can't build WinVNC on MinGW because MinGW lacks the necessary API's, and the necessary API's were rejected upstream. This is about to become even more of a problem, because I'm being contracted by another company to improve WinVNC so that it can be used on Vista and W7, and that may yet require the use of more APIs that aren't supported in MinGW. It has nothing to do with streamlining. It has to do with the fact that MinGW will always be playing "catch up" with Microsoft, and some of the Microsoft API's can't be included because of IP concerns. Thus, there will always be certain functionality that can't be leveraged through the MinGW toolchain. It just so happens that some of that functionality is necessary to make WinVNC work. The basic facts of this case are the same as they were 2 years ago: we cannot abandon Visual Studio without abandoning WinVNC, and we cannot abandon WinVNC without effectively forking TigerVNC, since WinVNC depends on a lot of the same infrastructure as Xvnc, not to mention integrates the same Java viewer, etc. Yet, if you'll recall, I was the one who proposed exactly such a fork about 3 months ago, and Cendio decried the idea, and ultimately I agreed with your reasoning. There is interest in the community for a more high-performance WinVNC, and the most expedient path forward to that is to leverage my previous work in optimizing the TigerVNC encoder. Otherwise, I would have to do a similar overhaul to TightVNC 2.0.x or some other WinVNC code base, which I don't relish-- both because it would require a similar 100-hour effort to re-invent TigerVNC's wheel and also because it would create yet another fork. Besides, let's back up a minute-- the modification that broke the Visual Studio build was in FLTK. The FLTK Project supports Visual Studio as one of their build chains, so someone was going to have to fix the build eventually in order for it to be accepted upstream. I assume that upstream acceptance is the ultimate goal for these FLTK patches. Thus, I believe that it is quite reasonable to expect that whoever is developing the FLTK patches test them on the compilers that the FLTK Project supports. Every minute you guys spend arguing with me is a minute less that I have to spend on optimizing the VNC Viewer or doing other things that are supposed to be a priority, so I'll let you decide whether it's worth it to continue this discussion. Personally, I don't think it is. We have a requirement to support Visual Studio as long as we have a requirement to support WinVNC. I don't think my request was in any way unreasonable. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
