On 10/7/11 2:35 AM, Peter Åstrand wrote: >> For the record, I did try this 2 years ago, with the patch you and >> Pierre submitted upstream to MinGW. It compiled but did not link. > > So why didn't you report this? I cannot found anything about this, > neither in the tracker nor on the mailinglist. The patch apparently > worked fine for Adam and it worked fine for us.
I mentioned it several times on the list, in the context of our discussions regarding moving to CMake for Windows, regarding the autotools performance problem on Windows, etc. Don't know how the patch could have possibly worked fine, since it did not apparently add anything to the link libraries-- or, if it did, that portion was apparently not accepted by MinGW. >> Well, curiously, apparently that patch made it into MinGW64, and I just >> tried again with that compiler-- same result. Compiles but does not >> link, because the stub is not in libuuid. > > Never heard of such a problem. Can you please give us the technical > details? Which missing symbol, which error message... Why don't you try building it on a recent version of MinGW64 (it's probably reproducible using MinGW64 for Linux) and see for yourself? >> That was why we, as a team, decided it was necessary to continue >> supporting Visual Studio. > > This is not what I remember. I thought we just waited for MinGW to > accept the patch. When we had this discussion before, we discussed the fact that they had rejected the patch, but apparently they did eventually accept the header portion of it. >> Interestingly, your new patch to libos does work with MinGW32, but now >> it interferes with the broken patch in MinGW64. > > How does it interfere? Please give us the technical details. Doesn't compile. The headers interfere. Again, try it for yourself. I'm not in a mood to be helpful to you right now. >> For every piece of Win32 functionality I need that isn't supported in >> MinGW, now I'm faced with > > MinGW contains most of the Win32 functionality one needs. Especially if > you want to keep supporting older versions of Windows, which I suppose > we want. We don't want a WinVNC or vncviewer which only works on Windows > 7+. I thought you had the same goals, since you have been working on > supporting platforms such as RHEL4? Peter, you have a real talent for twisting words around. Supporting Windows 7 does not mean that the code only works on that platform. It means that, perhaps, it may be necessary to conditionally use APIs on that platform to make WinVNC work properly. Then again, maybe that platform can be supported via simple bug fixes. Until WinVNC is working fully on W7, I am unwilling to paint myself into a corner and make it difficult to use any advanced functionality that might need to be used. Further, do you not realize that, after you have stated your case, there is no purpose to continuing to re-state and re-spin it? I have already come to a professional decision on this based on the relevant facts and my years of experience as a Windows developer. Unless you are going to provide any new information, then there is nothing to be gained by continuing this discussion. There is certainly nothing to be gained by engaging in ad hominem attacks, other than making me angry, which you have succeeded in doing. >> (a) reverse-engineering a stub for it > > Writing a short text file using the MSDN documentation is hardly > reverse-engineering. Just as a for-instance, DEFINE_GUID(CLSID_ActiveDesktop,0x75048700L,0xEF1F,0x11D0,0x98,0x88,0x00,0x60,0x97,0xDE,0xAC,0xF9); DEFINE_GUID(IID_IActiveDesktop,0xF490EB00L,0x1240,0x11D1,0x98,0x88,0x00,0x60,0x97,0xDE,0xAC,0xF9); is not anywhere in the MSDN documentation and, in fact, appears to have been pretty much blindly copied from the Microsoft header files. I am certain that the MinGW Project has discussions regarding potential dangers of IP infringement whenever new interfaces are added, and I know they discussed such things in the context of the ActiveDesktop patch. I would be uncomfortable putting new, non-obvious Win32 interface code into TigerVNC without a similar vetting process, and our project is really not in the position to do that vetting. >> (b) writing a CMake compile and link test to verify that it isn't in >> MinGW > > What's the problem? Writing CMake (or Autotool) tests is the standard > approach when using functionality that is not guaranteed to work on all > platforms. This is the approach we are using for UNIX as well, remember. You're confusing the issue, Peter. When we write "platform" checks, "platform" typically means a particular O/S configuration. Few people would be on board with, for instance, depending on a particular piece of functionality in GCC that was broken in some releases. >> and, if so, that the MinGW version isn't broken, > > This is seldom. The MS compilers also has bugs. ?! That argument doesn't even make sense. We're talking about Windows functionality that is not supported or partially supported in MinGW. We're not talking about the general stability of the compiler in general, but honestly, I've never had any problems with recent Visual Studio releases. >> That isn't exactly an efficient development model. > > Having to try every simple change with two different toolchains is worse. It's actually quite simple to do if you have a real Windows machine. However, since you don't, that is why I proposed a compromise. >> You need to understand that my lack of comfort with MinGW is dictated >> by the somewhat hackish approach necessary to get stuff like the above >> to work. > > I think you consider it as being hackish just because you have little > experience with it. This is bordering on professional slander, Peter, and it is completely unacceptable. I've been hacking Windows (in the programming sense of the word), both at the user and kernel level, since NT 3.1 was out. I have been using MinGW for quite a long time as well, both on Windows and Linux. MinGW is a great compiler, and I'm happy it exists. It doesn't solve every problem, however. There are certain things it does better than VStudio, and there are certain things VStudio does better. In applications that have close ties to the operating system and drivers, such as WinVNC, VStudio is a better choice, unless you simply want to freeze the application and never grow its functionality in the future. If we really want our version of WinVNC to be relevant, then it needs to not be an afterthought. >> Enterprise-quality software is not built by hacking. > > "Enterprise" means different things to different people. Very often it > is not a positive thing. Take a look at > http://thedailywtf.com/Articles/The-Enterprise-Dependency.aspx (or > search for other Enterprise articles) and you'll see what I mean. http://www.cendio.com/products/thinlinc/ "Cendio is an enterprise software company offering a Terminal Server solution to enable Server Based Computing." I'm pretty sure Red Hat would also disagree with you. >> I also understand your lack of comfort with Visual Studio. You >> haven't used it continuously for 15 years like I have. I'm not saying >> that you're wrong-headed for being uncomfortable with Visual Studio, >> but neither should you say I'm wrong-headed for being uncomfortable >> with MinGW. > > For me, it doesn't have *anything* to do with "feeling uncomfortable". > It's about selecting one toolchain that does the work; supports all of > our platforms. If Visual Studio could run under Linux and generate > binaries for Linux, Solaris, OS X etc, then we could discuss getting rid > of MinGW. But that won't happen. Peter, it *doesn't* do the work, not without lots of *hacking*. The fact that you would even recommend building *Mac* software on a *Linux* platform proves my point. Who does that? Certainly no one building Mac software professionally. Apple certainly does not support it, nor are there many resources online to tell you what to do if such a configuration doesn't work. That is the definition of "esoteric" and "hackish." I want to develop code. I don't want to futz with unsupported compiler configurations. So basically, what you're saying is that everyone who wants to work on our code needs to have a Linux machine? Does that not seem a little unreasonable to you? Most people who develop Windows code use a Windows machine, and most people who develop Mac code use a Mac machine. We need to support those people. This is not just Cendio's baby. >> Comfort level is very important when developing something. I don't >> want to feel like I have to patch libos every time I use something >> that MinGW doesn't have, and I don't want to have to maintain build >> tests for any advanced functionality to determine whether or not it's >> present or broken in MinGW. >> >> I feel like I've been more than reasonable and willing to compromise >> about this. As the one who's going to be developing WinVNC, I need to >> feel like I'm free to do what I need to do to make it work for my >> customer, and I am not comfortable using MinGW for WinVNC at this time. > > Ok. You don't want to change your habits, but you want to force us to > test build with Visual Studio before every commit? How is this a > compromise? All the extra work would be on us not currently using Visual > Studio. ?! My habits are hardly relevant, Peter. I'm trying to do what's technically in the best interests for the WinVNC portion of the project, so I can move it forward. We've been supporting Visual Studio for 2 years now. Obviously that hasn't created a burden on you yet, because you haven't been testing it, and that's why we're having this discussion to begin with. My assumption is that Cendio isn't going to ever do the right thing and set up a Windows machine for dev testing, so the compromise is that you guys keep doing what you've always done, but since you're not going to test VStudio, I want to minimize the damage potential by minimizing the code that is built with VStudio. Thus, I move WinVNC into a sub-build, and that way, most of the stuff you work on regularly, such as FLTK, doesn't need to be supported on VStudio any longer. If you don't see that to be a compromise, well then, I can't help you. >> Once things are working properly on W7 and Vista, then we can >> re-evaluate. > > We can start with making sure WinVNC works with MinGW. If you have no > objections, I'd like to commit the patch. I have strong objections, since the patch breaks MinGW64. Why are you so focused on this, Peter? I didn't think Cendio cared about WinVNC. Frankly, now your attitude is making me re-consider whether using TigerVNC is the appropriate path forward for my customer. I certainly do not want to have to spend hours debating with you each time I want to do what I feel is best, and what my experience dictates is best. This whole discussion has become utterly ridiculous. ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
