Peter Åstrand wrote: > The MSVC compiler might be free today, but what about tomorrow? The > history also indicates that MS moves quite rapidly when it comes to > development environments: The 2008 version might soon be replaced with > something new and incompatible. This has happened numerous times > before. In fact, when I started working with TightVNC, one problem I > had was that the build system required MSVC 6.0, but that version > wasn't available any longer... > > MSVC also has some other serious limitations, such that it only > supports compiling code that's are located on local drives. Samba > shares, for example, does not work. (At least this was the case last > time i checked.) > > If you use MSYS, Cygwin is not necessary. So I think it's safe to say > installing MSYS, MinGW and even NASM on Windows should be as easy or > even more easy than installing MSVC 2008. Well, except that MSYS doesn't have the AutoTools. So if you insist on using AutoTools, then that requires Cygwin, which is a somewhat bloated install. And if you think MSVC technology changes quickly, Cygwin pushes out incompatible package changes on practically a daily basis.
MinGW simply does not support the full Win32 spec, and the parts of the spec it does support often do not behave correctly. Don't think I haven't tried to use MinGW with VirtualGL and TurboVNC on many occasions. In the case of TurboVNC, it was a non-starter, because the TightVNC server code relied on some libraries that simply weren't provided by MinGW. I haven't yet looked at TigerVNC/Windows to see if that's still the case. In the case of VirtualGL, I ran into all sorts of problems with C++ exceptions that caused me to abandon MinGW. In general, it's been my experience that if you want the Windows API to work as specified, use Microsoft's compilers. I have 15 years of Win32 development experience and know a few things about that. Also, this goes back to the argument of maintainability. The goal isn't just to be able to compile our code once on a given platform. It has to be easy to add features and fixes to it. Maybe someone wants to use DirectX or some other technology that doesn't work with MinGW. I agree, in general, that OSS compilers are better. But I'm in the business of solving problems, not creating them, and if MSVC is the best tool to solve the problem, then that's the one I use. If it isn't free tomorrow, then I'll worry about that tomorrow. There are similar concerns with OSS compilers, such as what if someone suddenly decides to stop maintaining it. That is particularly a concern with Cygwin. I have seen many cases, such as in the Cygwin/X11 project, where the port went without a maintainer for years. Whether or not we're depending on a healthy OSS project or a healthy company, we're depending on something either way, and in either case, the rug could be pulled out from underneath us. Microsoft could just as easily change the O/S and make it suddenly incompatible with MinGW, but seeing as how MSVC is their application, it's guaranteed that it will always work with their O/S. I again go back to looking to the OSS community for a best practices model, and if you look at the most popular Win32 OSS projects, the lion's share of them build with MSVC. That's because any serious professional Win32 developer has MSVC. It's just a fact of life. ------------------------------------------------------------------------------ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
