After reading through the FAQ here
I've noticed this particular statement: "The C++ compilers from Microsoft, Intel and Borland are not supported by the tools in the GPL version." The most common and most widely used C++ for Windows is none other than Visual C++. However, at this point OSS development using Qt/Windows GPL is for GCC developers only.

The cross-platform part of QT is the API not the tools. If I am a Windows developer I expect to be able to use my IDE, of my choice, and still be able to use QT as an API in my application. By only allowing gcc for Windows development TrollTech is, in one fell swoop, alienating most Windows developers. Why would they do this?

"The cross-platform part of QT is the API not the tools. If I am a Windows developer I expect to be able to use my IDE, of my choice, and still be able to use QT as an API in my application. By only allowing gcc for Windows development TrollTech is, in one fell swoop, alienating most Windows developers. Why would they do this?"

Actually, if you pay the proprietary license to Trolltech (part of the "dual license"), you can use QT with Visual C++.

The reason the GPL version of QT is not available for Visual C++ is that Visual C++ is proprietary and it's license is incompatible with the GPL. Thus, the GPL version of QT must be used with gcc (or any other GPL compiler, and gcc is the best, so why would you use anything else?).

This should not be a big deal, since you can still use QT Designer, and add logic code in separate cpp files, then compile in the command line. It's still very easy, especially considering that QT Designer is completely awesome and goes beyond what Visual C++ does (point and click GUI development).

This is not alienating Windows developers. In fact, it is giving Windows developers more options - previously, a GPL version of QT was not available for Windows at all.

The compiler not being GPL has nothing to do with being allowed to compile GPL'd software with it. There's a clause in the GPL which explicitly allows this sort of things. Also, the fact that VC is not supported doesn't mean it won't work or won't be made to do so.

Exactly, there's nothing precluding a fork of Qt which adds support for these other compilers. Support just won't be available in Trolltech's released version. The question is whether any in the open source community will care enough to try to maintain a fork with support for MS/Intel compilers.

Last time I checked Visual Studio didn't come cheap. I.E if you are not one of those pirates chances are that if you use VS you are a commercial company developing comercial software - for which you need the appropriately licensed QT, which will support VS...

Last time I checked, VC++ non Professional versions (i.e. academic & co) are about 30 $, and the Professional version is about 600 $.
Not to mention that VC++ 8.0 Express Beta is free, VC 7.1 compiler is free (and so is the Plateform SDK). Basically, the only thing you have to pay for is the IDE. So as far as the price is concerned, MS compiler is as free as GCC.

Qt license fee ranges from 1500 $ to 7000 $ per developer.

I think some people here have to rethink their logic behind the concept of "afford".
The company I work for certainly cannot afford Qt licenses, even if they have a license for each Windows XP running in our offices.

I think the reason they're only supporting GCC and not Visual Studio is because people have already ported Qt to Cygwin, which circumvents their "business model" of only releasing Qt for Unix platforms. If people can already use Qt with Cygwin, there's no point in keeping the official Windows version closed. And does any commercial compiler support Cygwin?

Can you actually deploy or distribute programs developed on the cheap personal or "standard" versions of VC++ or Borland C++? I seem to remember seeing restrictions on the Borland personal version.

I think keeping the F/OSS version of Qt for F/OSS development tools and the Closed Source License version for Commercial closed source tools is a good idea. I also DON'T think OpenWatcom should be supported UNLESS SciTech buys TrollTech to get Qt for their proposed OpenWatcom Linux version of course. ;c) While Open Watcom is Now F/OSS it is still being built with proprietary closed software developers that used Watcom when it was a commercial proprietary product in mind.

Most Open Source developers for Windows use the Visual C++ 6 compiler to compile their apps. And just so most of you know, their is a portion in their that is incorrect:

" I.e. Microsoft used to have a
clauses in their VC++ EULA that explicitly forbid developing of GPL
software. "

Microsoft, in no way shape or form have or had any clause that forbade the development of GPL software, not ever. This is a misconception that has been around the web for a long time. They have clauses in their EULA which keeps users from deploying VS and any component from running the suite on WINE but not from developing free software.

I cannot imagine releasing a Windows product and asking Windows developers to use that complete crap pile GCC. That is just insane. Having to build a Windows app using GCC is like having to lift a 10 megaton boulder just to get out the front door. It's stillborn. It's dead. It's dumb. Forget it.

Now if they end up canceling the Windows product in the next year or two it will all make sense, won't it? Because I bet that will be what happens with the C++ version of Qt. It's the walking dead.

I almost exclusively use MinGW anyway and for that matter its free, and, for those that need an IDE for MinGW there's always Rhide for DOS and Dev-C++ for Windows.

I would be using MinGW in Windows exclusively except that I needed the Borland compiler to use the non-commercial edition of Qt 3.2.1 I got with the book C++ GUI Programming with Qt3. I also use Allegro and it works very nicely with MinGW.

People that can afford MS VC++ can probably save up for a copy of Qt, although the commercial version of Qt is expensive. People using VC++ also have the option of using MFC and the form designer in VC++, although having used both my prefference is for Qt.

"I cannot imagine releasing a Windows product and asking Windows developers to use that complete crap pile GCC. That is just insane. Having to build a Windows app using GCC is like having to lift a 10 megaton boulder just to get out the front door. It's stillborn. It's dead. It's dumb. Forget it. "

Pure and utter FUD, you didn't even mention anything wrong with GCC you just started insulting it, please act your age and not your shoe size.

GCC is the compiler that is used for the Linux kernel, and in most distributions all the GNU software too; GCC is also widely used in BSD, Solaris, BeOS, Mac OS X and especially in Windows amongst hobby developers and even freelance commercial developers.

All these people use GCC and like it, sure MS VC++ is nice too, I know since I've checked it out myself; however, GCC is guaranteed to be standards compliant, its open source so you know whats in it, and there are good IDE's for it on almost every platform, MS has a spotty track record when it comes to standards compliance and so far I've only seen MS VC++ for Windows, leaving out everyone who runs another OS.

If I'm not mistaken Apple's XCode uses GCC, KDevelop uses GCC and Dev-C++ uses GCC, these are three very popular IDEs and there's good reason for that. GCC along with a good IDE like those I just mentioned is just as easy to use as MS VC++, and if you use Qt you don't need to worry about having a form designer since thats what Qt designer is for. Qt4 will be designed so it can be integrated into IDEs and hopefully the Dev-C++ folks will make good use of that feature, I already know that KDevelop will since I've already seen it done in SUSE Linux 9.2 and I think Trolltech will take care of XCode integration themselves. When that is done what advantage with MS VC++ have left? KDevelop and Qt Designer have better syntax highlighting, so the only IDE it will still have the upper hand on will be Dev-C++.

"It's in the works. The new Qt will be C# and support .NET and Mono. There is no cross-platform future for C++ because C++ is dead on the Windows platform."

Oh please do shut up, you have already made it obvious that you don't know anything about GCC and now you claim that Trolltech is making a C# only version of Qt!

Trolltech is not working on a C# only version of Qt, OSS developers are writing C# bindings just like they've written Qt bindings for Python and Ruby. There is absolutely no intent to replace the C++ version of Qt.

Btw. Please stop calling yourself "Qt License Holder" its obvious you don't know enough about Qt to actually use it in which case you would have never purchased a USD ~$1500 license for it either.

You are forgetting the arrangement that TrollTech made concerning QT Free Edition WHICH IS THE C++ VERSION. They essentially said that if that particular version is ever dropped or the company goes bankrupt THE LATEST VERSION OF IT GOES UNDER A BSD-MIT STYLE LICENSING instead of the QPL-GPL-Pay system it has now (This would be QT/Free 3x as of now.). This would mean it will become LEGAL to develop PROPRIETARY SOFTWARE under KDE without ponying up the $1700 (they recently raised the minimum price) licensing fee. (I Believe that KDE would probably stick with C++ and QT version 3 under these circumstances. A COMPLETELY FREE toolkit is just too good a thing to pas up. It would get business developers interested in KDE the way they are in GNOME now.

I actually do think a good case in court could be made that this arrangement was built around the C++ version and NOT a new C# version and therefore I don't really think that TrollTech would be dumping the C++ version any time soon unless thet REALLY WANT competition from their old C++ toolkit as a COMPLETELY FREE SOFTWARE to the C# version.

The future of C++ on Windows is... .NET and managed code.
It is not what Qt 3.X/4.X is doing (which is low level Windows C API's).

Qt/C++ for Windows has been EOL'd at 5.0. There will be patches after this so it is not "dropped", but there will be no further development and support will be gradually phased out.

Qt will likely move to .NET as either Managed C++ or C#. The last I heard it was C# so it would be compatible with Mono and easier cross-platform compatibility vs. Managed C++.

And yes, on Windows, GCC is a crap pile. It is not suitable for Windows development. So Trolltech's release of a "bogeyman" version of Qt on Windows is just a troll. Which actually fits them quite well.

So Qt's build system is qmake, and the GPL version won't support generating MSVC project files - but does anything prevent using GNU make (from Cygwin) with MSVC's compiler? IIRC, Mozilla does this on Windows and works fine. Or did TrollTech actually delibrately break MSVC compatibility at a source level? (My guess is no, but I havn't checked.)

As for why supporting the VC compiler, even if not the IDE, is important - ABI compatibility (for C++ libraries). Gcc mangles C++ names differently from MSVC/ICC, so C++ code compiled with GCC won't work with stuff from MSVC without special attention from both sides. This is appearently why some plugins (e.g., Sun JRE) won't work with Mozilla compiled with GCC on Win32...

Trolltech is not working on a C# only version of Qt, OSS developers are writing C# bindings just like they've written Qt bindings for Python and Ruby. There is absolutely no intent to replace the C++ version of Qt.

Yes, and there are QtJava bindings to - regenerated for Qt 3.3.4 as part of the KDE 3.4 release.

As a Qt bindings developer (java and ruby), I'm pretty excited by the possibility of cross-platform Free Software with Qt 4. I don't know enough about Windows development environments, to have an opinion of the quality of the gcc Windows port. But I've been using gcc since 1993 and there's certainly nothing wrong with it on OpenStep, Cocoa or Linux for writing enterprise quality, mission critical applications. As long as a ruby development environment has been built with gcc, and it works, I don't think anyone will be able to tell whether their ruby bindings runtime was written in gcc or VC++. More a matter of having a decent 'one click' install than a major technical problem.

I don't know if it will be possible to compile the QtJava bindings with gcc, and use gcj or gij to run them. It would certainly be great to have a complete GPL'd toolchain, to create java, ruby and python RAD environments, especially if KDevelop could be ported too sometime.

qmake ist not an Makefile handler, it generates them.
Usually you will use nmake when processing Makefiles for the MSVC commandline compiler.

As the input for qmake is a qmake project file and some compiler specific option files, it will very likely be possible to generate nmake compatible Makefiles with qmake from Qt4/Win/GPL, unless qmake for Qt4 has changed fundamentally.

I guess the only difference between qmake from GPL licenced Qt and qmake from commercial licenced Qt will be the capability fo generate Visual Studio project files, but I guess VS can create projects by itself, can't it?

It's really funny, but I was wondering what people could bring up against us now, after we announced that we - again - release a huge amount of tested, deployed professional high quality code under the GNU GPL. And the reaction is as expected: "Thanks for the finger, a******e, why didn't you give me the whole hand?". Guess what, you do get the whole hand. You get the entire Qt source code under the GNU GPL, well-tested, portable C++ code.

Now, let's consider the issue wrt what compilers we do support for the Qt Open Source Edition on Windows. We've decided that we support gcc, just like we do on the Mac and on Unix/Linux X11, and on embedded Linux. "Support" means that we will make it really easy to use it. We _want_ people to use the Open Source edition of Qt, after all, the more the better. Those people who commented that gcc on Windows was "a joke" are not quite up to date with their knowledge. I had agreed a few years ago, but not today. It's very useful these days, and it's getting better. And we do hope to motive people to make it even better. Now why would we want that? What's the advantage of using gcc on Windows? Number one: your code is portable. Code written on Linux with gcc, on the Mac with gcc, or on Windows with gcc is significantly more portable than code written with different compilers. And we want people to write cross-platform applications with the Open Source edition of Qt, not pure Windows stuff. Vice versa, you will have a hard time trying to compile KDE code with e.g. MSVC 6 (which is still one of the most used windows compilers for commercial projects). What do you think would happen if MSVC was the only compiler on Windows, and people started to port Linux software to Windows? I tell you what would happen: Linux developers would have to uglify their code, avoid using advanced templates stuff, use lots of conditional compiles, and obey many extra rules that they currently don't have to care about. We do that at Trolltech, because we get paid for it. Would we do it for fun? Hardly. With gcc, you don't have that problem. Your code becomes truly portable.

Now, does Qt Open Source edition for MS-Windows work with other compilers? Most certainly it does, because the code is _identical_ to the commercial Qt edition. Do we ship an integration into Microsoft's IDEs or build systems (their are several now)? Yes we do, to our commercial customers.

Is it hard to build Qt with other compilers, or to create Makefiles that build Qt applications with other compilers? No, this is not harder than to compile _any_ _other_ _piece_ of _code_. Integrating moc, uic, and rcc build steps isn't harder than integrating lex and yacc. Use whatever build system you like (autoconf, jam) and do it. KDE - and most Qt-based Open Source software on Linux - doesn't even use qmake!

Having said that: is this a decision for all eternity, even if it turns out to be totally impractically for Open Source developers on Windows and it hinders the OSS community to grow on windows? I don't think I have to answer that one. Second question: Will it take long until someone comes up with a version of qmake on sourceforge that supports commercial compilers and other build systems? I don't have to answer that one either, as I said, the code is very compiler independent, so it's not hard at all. But - as someone pointed out - there is a big difference between "supported" and "works". It's all GPL after all. GPL doesn't mean, that we work for you for free, it means that you have the freedom to do stuff.

I thought I was used to getting crap after 8 years of Open Source experience, and being able to ignore it, well, I'm not. Even if we donated $1 to every programmer per line of code commited to source forge under the terms of the GPL, we would get crap: "Why only $1? Why only code? Why only GPL? What about inflation adjustment? Why not for internal non-published code?" :-)

There are a few things to notice already before starting the 32MB download:

- the core tools do obviously not contain a make tool. This would usually be "nmake" if you decide to purchase VC++. Without a make tool, using a C++ compiler is virtually impossible.

- the Q&A section already answers the question "Are there any restrictions on how I use the Visual C++ Toolkit?" like this:

"In general, no."

This already raises an eyebrow of the average OSS developer planning to develop GPL'ed software.

"You may use the Toolkit to build C++ -based applications, even commercial applications, and you may redistribute those applications in accordance with the terms of the End User License Agreement (EULA)."

This raises the second eyebrow, and confirms that the use of the VC++ Toolkit requires to you release your application under the Microsoft EULA. Note that this answer mentiones only "applications", so it is unclear at this point whether you are entitled to develop other software with the VC++ toolkit, e.g. libraries.

Getting curious, you read the EULA itself. Here you read in section 1.1.

"Microsoft grants to you as an individual, a personal, nonexclusive license to make and use copies of the Software (i) for your internal use; (ii) for designing, developing, testing and demonstrating your software product(s); and (iii) for evaluation of the Software."

Ah, so I might in fact not even be entitled to redistribute the software I develop? And if I am, the software I want to release must not be redistributed by the receiver? How does this work with the GPL... Continuing to 3.2:

"[...] You also agree not to permit further distribution of the Redistributables by your end users except you may permit further redistribution of the Redistributables by your distributors to your end-user customers if your distributors only distribute the Redistributables in conjunction with, and as part of, the Licensee Software and you and your distributors comply with all other terms of this EULA." and

"An "Excluded License" is any license which requires as a condition of use, modification and/or distribution of software subject to the Excluded License, that such software or other software combined and/or distributed with such software (x) be disclosed or distributed in source code form; (y) be licensed for the purpose of making derivative works; or (z) be redistributable at no charge."

Somehow all this does not sound like Open Source at all, does it now?

So I'm not a lawyer, just a simple support engineer. But from what I know about the GPL it is pretty clear to me that I cannot comply with both the license of the VC++ Toolkit and the GPL when releaseing my software. So either I cannot use Qt under the GPL, or I cannot use the VC++ Toolkit.

I'm surprised at the apparent level of knowledge that "Qt License Holder" claims to possess. Apparently he or she is not too fond of us.

That's of course OK, but I'd like to clear out a pretty clear misunderstanding: Qt based on C++ is alive and well on all platforms, and will keep bringing value to both our customers and the Open Source community in the foreseeable future. There are no plans to EOL Qt at all.

Ok, I agree that some people here are giving you crap for no good reason, but you also have to try to understand why this is so:

The announcement of Qt/Windows 4.0 getting available under the GPL got many people, including me, very excited. This was finally going to allow OSS developers to reach a Windows audience without kludges and without using ugly stuff like MFC.

However, having to install Cygwin/Mingw is just a big dissapointment... I think that should have been cleared up in the original annoucement. That way people would just thank you for the GPLing instead of finding out later and venting their frustrations the hard way.

You don't put technically details in a press release, unless you seriously don't want the press to write about it. What you do instead is to provide a FAQ for those of us who are developers, and you put a prominent link into the initial announcement and ask people to go there for details. This we did. Read the questions and answers on http://www.trolltech.com/developer/faqs/duallicense.html. The answer to "What does Qt Commercial Editions have that the Qt Open Source Edition does not?" talks about the initial scope of supported compilers.

About the big disappointment: people for whom installing mingw is significant hurdle are not the target audience for the Qt Open Source edition, I'm happy to admit that. Personally I have trouble imagining someone who can program Qt, but can't install a compiler (how would that person install visual studio?) In fact I have never met a single open source developer for whom that had been a problem. Everybody I meet installs some amount of GNU software, including gmake, emacs, and bash, anyway before they start working on a Windows computer.

"Ah, so I might in fact not even be entitled to redistribute the software I develop? And if I am, the software I want to release must not be redistributed by the receiver? How does this work with the GPL... Continuing to 3.2"

I believe that the portion of the EULA you quote refers to the vctoolkit itself and not the software you develop.

"Somehow all this does not sound like Open Source at all, does it now?"
It's obvious you can't link gpled code to microsofts dll's (aka Redistributables) as you would either have to "infect" those libraries with a gpl licence and microsoft obviously wont let you do that, or licence your code under a more liberal licence (lgpl, mit etc).

Trolltech: thank you for all the Free software you developed. Your business model is just great.

Others: Don't you see that not supporting the make tools for proprietary compilers is just an attempt to raise a bit the bar and avoid proprietary use of Qt GPL? I am sure that someone will create these tools, and you will be able to download them and use Qt with VC++. Only Trolltech won't support it, otherwise, why someone would pay to use Qt commercial for internal development? They *should* offer something extra for windows only in house developers, stay profitable, improve Qt GPL and stay competitive against proprietary solutions. Remember: if you kill a cow, you can' t milk it. Their offer is *extremely* generous. We should be thankfull. I am.

Someone stated that there is nmake isn't bundled with the Microsoft's 7.1 C++ free compiler. I think that is right. However, I do believe that if you also download their .Net SDK (which is free), they have a version of nmake with it.

So what is the big deal here? Sounds like its not even worth making a press release over. The facts are if your serious about making Windows software. You use Visual Studio or Borland's development tools.

"So what is the big deal here? Sounds like its not even worth making a press release over. The facts are if your serious about making Windows software. You use Visual Studio or Borland's development tools."

Unless of course you're serious about developing _cross platform_ software. That's the whole point. Sorry that this was lost on you.

The Win32 subsystem will never be removed from windows. Microsoft may include a .NET subsystem to replace the runtime, but there is no way they would completely dump Win32. How many of their applications are or will be written in .NET?? Office, SQLServer, Exchange, Visual Studio, etc. How would other ISVs feel about rewritting their entire application against a new API? This would include not only text editors, but things like DBMS, mail servers, web-servers, photo/image editing tools, etc. Do you really think forcing ISVs to rewrite their entire code base is a good business decision on Microsoft's part? Win32 is the Windows system call interface [the native API is largely undocumented and unsupported]. This isn't going to change anytime soon nor should it. BTW, what do you think the CLR is written in?

ms wants as many people using dotnet as possible. win32 will probably be around for a very long time, but apps that use it will probably look out of place before too long. when you have a win32 app sitting next to a avalon-ized .net app, companies will port their stuff to .net. how many vb5 apps are still being written?

Granted, but moving from Win16 to Win32 provided immediate benefits: flat 32 bit address space [no more NEAR/FAR pointer crude], process isolation and memory protection, pre-emptive multi-tasking, kernal threads, Async I/O. Converting your app to Win32 allowed you to use all of the functionality provided by the OS. That's not the case with moving from Win32 to .NET. Are you saying that some functionality in future versions of Windows will only be available via .NET and not through the Win32 subsystem? I think this would be a huge mistake for Microsoft.

In terms of a Win32 app looking out of place, this only matters for desktop software. This certainly wouldn't be the case for server apps (DBMS, mail servers, etc.)

Section 1.1 applies to the compiler itself, not products created with the compiler.

That first excerpt from Section 3.2 states that, if you include the VC++ run-time libraries (the "Redistributables") with your product, anybody who receives your product can not re-redistribute those RTLs without including your product.

The second excerpt dictates how your license of choice applies to the RTLs. (x) Your license can't force MS to reveal their source for the RTLs. (y) Your license can't allow others to create derivatives of the RTLs themselves. (z) Your license can't force a product written with the RTLs to be free-as-in-beer.

Lawyers are good at intentional obfuscation like that.

The good news is that the GPL already has this covered. I quote Section 3:

"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

So the GPL explicitly excludes Microsoft's compiler RTLs, thus reducing these sections of the VC++ Toolkit EULA to a long-winded CYA clause.

You trolls (should) know very well it is getting very hard to write a good Windows app using Qt. Even Qt 4.0 (basically an architectural re-factor) does little to address this issue. Maybe as company managers you are all clueless and the Trollship will run itself aground on a sunny beach and all the trolls will frolic in the light of day for the rest of their lives. Ooops. I forgot. Sunlight kills trolls.

While I don't want to get anyone at Trolltech in trouble for being honest, the sun is beginning to fade on Qt/C++ as a cross-platform solution. There is no great C++ support for Windows development other than Managed C++. And C++ is not the main Mac development language either. The only foundation that spans platforms now is .NET/Mono. This is why the Qt/C++ product will be phased out after 5.0 and replaced with a new Qt based on a new foundation (not raw Windows API's).

GCC is not the foundation of an efficient development environment on Windows. It is just plain foolish unless you are a hobbyist that is just too stupid to download Microsoft's compiler(s). Or pay a few more dollars for their low-end IDE. So why even support GCC? Essentially zero development on Windows is done using GCC. Why even try and make people go through the living hell of trying to utilize UNIX tools to develop on Windows? It is a guaranteed way to make sure people DO NOT use your framework.

There is a rapidly fading value proposition and no amount of Trollish -- i.e. childish -- antics will stop this. Only a reworking of what Trolltech has to offer. I do hope that there is something better than Qt4 in the works (as I've been told). Quite frankly, it would be great FOR ALL if Qt moved to C# instead of C++. I can only imagine how cool Trolltech could make Qt with .NET runtime type management capabilities. And how it would be great to have all of KDE running on top of Mono. Very cool.

Good luck, trolls. It was fun to see the "Trolls of Denial" and "Trolls of Childish Anger" show up. It really did make the party. Now please get back to working hard on Qt#.

"not very. So those of you complaining about having to use GCC are either extremely lazy, just want to argue and complain, or incompetent."

Or you want to use libraries built by others with VC.

Or you just prefer VS's IDE.

There are plenty of reasons beyond your childish "incompetent" and "lazy" lines.

I'll say this again: commercial compiler support in the free edition is available for UNIX platforms. This very much appears that Trolltech is playing politics. If they don't want to support VC++ with the free edition, fine. It's their product. To claim that this is somehow due to the commercial nature of VC++ is silly, however.

Ok, so if you are going to use other people's libraries that is fine. You will have the liraries' source code, and unless they are something crazy and exotic, chances are they will work with GCC.

Or you just prefer VS's IDE.

You can still use it. Make your GUI's in Qt Designer. Write your code in Visual Studio. Compile with GCC.

As stated GPL'ed Qt is intended to be used to make crossplatform programs, not Windows-only programs. So supporting GCC is a perfectly logical decision.

This very much appears that Trolltech is playing politics.

I really doubt it. If anything it could be more business related than politics.
But even if they are, so what? They certainly have the right to do whatever they want. God, look at all M$ has been doing forever...

Dude, you ate too much Microsoft FUD and marketspeak, the world isn't going the C# way as fast as MS wants you to believe. Client side business stuff is moving fast to .NET, VB 6 based houses are too (well, that's desktop business stuff...), but C++ (the native one) isn't dying. When Longhorn finally gets released, we'll see what happens.

If you really think that Qt is no good, or will be in a short time frame, because it isn't C#, sorry, but you are a moron.

"You can still use it. Make your GUI's in Qt Designer. Write your code in Visual Studio. Compile with GCC"

Which misses much of the point of using VC++. It's more than just a text editor.

"I really doubt it. If anything it could be more business related than politics."

So, why do they support UNIX commercial compilers if the reason give by Ettrich is to be believed? Obviously, they recognize that OSS writers use commercial comppilers on various UNIX flavors (which are all FAR more expensive than VC++).

"But even if they are, so what? They certainly have the right to do whatever they want. God, look at all M$ has been doing forever..."

"How is that so? The commercial edition provides full MSVC support. Do try to keep up."

The GPL edition does not (which is the point of this whole thread), while providing qmake specs for *commercial* *UNIX* compilers. UNIX flavors and Windows are not being treated equally (and haven't been from the start). The provided reason, that only commercial developers will use commercial compilers holds no water for this reason, since commercial toolchain support is/was in the X11 GPL version. Do try and pay attention.

Oh of course, because you cannot possibly make a mistake and misunderstand my post can you? This is what is known as a Narcissus complex. How incredibly self-righteous!

"The GPL edition does not (which is the point of this whole thread), while providing qmake specs for *commercial* *UNIX* compilers. UNIX flavors and Windows are not being treated equally (and haven't been from the start). The provided reason, that only commercial developers will use commercial compilers holds no water for this reason, since commercial toolchain support is/was in the X11 GPL version."

I don't have any problem with this statement. Who exactly are you trying to convince?

"Do try and pay attention."

Pay attention to who? You? I wasn't even conversing with you. You were the one who chipped in, mate. FYI, I am fully aware of the original point of this thread. As happens regularly on these boards, other issues develop from the initial thread, other ideas, varying opinions. I was addressing one of those opinions - nothing else. That's how message boards work.

You know what? I am wondering... is there a simmilar discussion on Microsoft-directed boards with a topic "Why isn't MSVC released under GPL?". Because all you people screaming and crying about why doesn't Qt-GPL support MSVC should also put a pressure on M$ to release their compiler under GPL compatible license. As for now I haven't seen an opensourced MS compiler, have you? Trolls already made their first step, why shouldn't Microsoft do the next one? If they cared for their users, they surely should.