Wow, Peter. So condescending. If I was in any mood to compromise before, I'm certainly not now.
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. 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. That was why we, as a team, decided it was necessary to continue supporting Visual Studio. Interestingly, your new patch to libos does work with MinGW32, but now it interferes with the broken patch in MinGW64. Do you see where this is going? For every piece of Win32 functionality I need that isn't supported in MinGW, now I'm faced with (a) reverse-engineering a stub for it, (b) writing a CMake compile and link test to verify that it isn't in MinGW and, if so, that the MinGW version isn't broken, and (c) conditionally using either the MinGW version of the header (if it exists) or our header and conditionally linking the MinGW version (if it exists) or our version. That isn't exactly an efficient development model. 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. Enterprise-quality software is not built by hacking. 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. 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. Once things are working properly on W7 and Vista, then we can re-evaluate. In the meantime, your choices are to accept my compromise or to keep things the way they are. Personally, I think that splitting WinVNC into its own sub-build has other advantages as well, irrespective of the choice of compiler, and I like the idea of having separate installers for server and viewer. On 10/6/11 9:31 AM, Peter Åstrand wrote: > On Thu, 6 Oct 2011, DRC wrote: > >>> IMHO, this is not unsolvable. If MinGW still refuses to add support for >>> this, we should be able to include the missing definitions in the >>> TigerVNC code base. >> >> It's not just missing definitions. The patch you guys tried to commit >> upstream didn't work, because it did not include support for >> IActiveDesktop in the actual link libraries. AFAIK, including such >> support would require back-engineering the Windows libs, which is why >> MinGW rejected the idea. > > It seems that you have misunderstood how build time linking of Windows > binaries works. You don't actually need the full library; only a stub. > This stub can be generated with "dlltool", typically from a .def file. > In the case of the ActiveDesktop constants though, you also need to have > a small .c file containing 2 rows of DEFINE_GUID. > > MinGW hasn't yet accepted the patch because one single constant > (IID_IActiveDesktop ) cannot be found in the registry or the MS > documentation on MSDN. Instead, a binary was used to retrieve the value. > They haven't used that approach before. (The constant can now also be > found on http://social.msdn.microsoft.com.) > > >>> Here's an offer: If we fix so that WinVNC can be built with a standard >>> MinGW distribution, can we then remove support for Visual Studio? >> >> Assuming you could fix WinVNC in its current incarnation, my main >> concern would still be that you would be painting me into a corner, >> whereby I couldn't use any other advanced functionality if I needed it >> in the future. Plus, I think it's probably a moot point, because I'm >> doubtful that anyone can make WinVNC work with MinGW, even in its >> current incarnation. > > Could you please stop saying that things are close to impossible without > even trying? > > Attached is a patch that adds the missing definitions to the internal > libos, if necessary. With this patch, building WinVNC with MinGW seems > to work fine. > > If you would need any "advanced functionality" in the future, you can > just add the missing constants and/or stubs, just as I did. This is > typically very straight forward. We have been using MinGW for almost 10 > years, and with the exception of this ActiveDesktop COM stuff, we > haven't had much problems. > > Rgds, --- > Peter Åstrand ThinLinc Chief Developer > Cendio AB http://www.cendio.com > Wallenbergs gata 4 > 583 30 Linköping Phone: +46-13-21 46 00 ------------------------------------------------------------------------------ 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
