Cool. I wonder how this will play into KDE on Windows..

It will give some good boost to KDE on Windows. Viva Trolls!11

“The Visual Studio Express environment is just so much superior and easier to use for existing Windows developers compared to what MinGW provides.”

Huh?? Who cares about Visual Studio Express? Eclipse rocks!

http://wascana.sourceforge.net/

Anders, that’s nice for you.

I’m currently using Eclipse, but it’s heavy on memory (more so than MSVC2005 Express) and there’s a bunch of features that’s not supported with it. No other C/C++ dev environment on the Windows Platform can beat the integrated debugger from MSVC2005, for example. Project management is one such other topic which is more convenient to use with MSVC2005.

I hate to say, but MSVC2005 (Express) rocks. Period.

Thank you Trolltech, I love you guys!

And how did you overcome the VSEE licensing issues? I thought (and if I recall correctly that was confirmed on mailing list by TT people) VSEE’s EULA was stopping you from supporting OpenSource Qt for VSEE?

“The Visual Studio Express environment is just so much superior and easier to use for existing Windows developers compared to what MinGW provides. We foresee many of the Open Source projects switching to VS EE for development after this change.”

I hope not! It’s bad to make Free Software rely on proprietary toolchains. And good luck to cross-compile with the M$ tools. With MinGW, I can develop on GNU/Linux, cross-compile with i386-mingw32-g++ and ship the result without ever touching a Window$ machine. I can even test in WINE, though I have to fake the Window$ version to Me because WINE doesn’t properly implement the Window$ 2000 font functions.

Here’s the environment variable hacks and tweaked qmake mkspecs I’m using to use i386-mingw32-g++ with qmake:
http://tigcc-linux.cvs.sourceforge.net/tigcc-linux/ktigcc/mingw/

TT could have supported VSE a long time ago. At the time, I still used VSE for editing, but since there was no integration, eventually the dancing around with moc and crappy MinGW was too much hassle. VSE kicks Eclipse in the nuts by the way for things like code completion. CDT had no code completion at all last time I tried it.

It’s far too little far too late. Everyone has already moved on…..

Kevin: It’s not like it “relies” on a proprietary toolchain, it just makes it an extra available option. For those who like using MinGW, nothing will change.

Well.. I use MinGW for Win platform and develop my app in GNU/Linux. But still I don’t use wine to test it. I prefer VirtualBox.

I am curious, how about the redistribution of the VSEE compiled Qt app? As I tried in the past, it was quite painfull (Qt with unofficial patches), I was forced to use that stupid redist installer until I switched to MinGW.

O. And choice is a good thing ;).

Have a nice day :).

Thx @Trolltech

Kevin: Did you ever tried to debug an gcc-compiled program on windows with gdb? I don’t no anything worse than this… and sometimes you need to debug win32 specific things. KDevelop/win32 will not be an option as it also uses gdb.

I did, using a Cygwin version of Insight (there was no native MinGW Insight back then, there’s one now). It worked relatively well, but with occasional bugs (like “step” sometimes doing a “continue” instead for some reason, and some crashes). I haven’t tried the current MinGW Insight builds, so I don’t know if they are better or worse.

If it makes you feel better, there’s a worse nightmare than the MinGW GDB: trying to debug anything running in WINE. I wasn’t able to get any debugger attached to my process at all, or at least not in a way where debuginfo would actually be loaded. winegdb didn’t work. IIRC, I also tried firing up a MinGW gdb.exe in WINE, that didn’t work either. Luckily, Valgrind (memcheck) running on the GNU/Linux binary found the bug I was looking for on that occasion, it was a memory access bug which for some reason was only fatal on Win32.

Great news!

I think the only thing still keeping me on VS(E) is the debugger - fast, simple and just works. From my experience, gdb is very slow when loading large c++ executables with many symbols, often “loses” the current thread when you’re single stepping, doesn’t seem to support c++ exceptions in a real way, etc. Although post-mortem core file inspection is pretty cool (this is probably only for linux & similar). Otherwise, I think open source IDEs have got it covered pretty well. Amusingly, KDevelop 3.4 code completion actually works better on our multi-100k code base than VS 2005 pro intellisense

Great news. MinGW lacks support for GDI+ and some other APIs, has glacial compile speeds for some code, and is excruciating to debug with gdb. I tend to switch to working on Linux when debugging whenever possible. Being able to use the VS EE debugger on Windows will be a big step, as will GDI+ support. Thanks!

I help maintain a C++ library (PoDoFo) and some associated Qt-based GUI tools. It’s been a real hassle that most people use PoDoFo with VC++ but if they want to use the GUI tools they’ve had to build another copy of PoDoFo for use with MinGW for that. Getting rid of that requirement is a bonus.

I’m curious about the status of VS commercial versions though. If a commercially licensed VS user is developing or building Open Source software, can they use this new Qt/Win release to do that, or must they download the Express Edition as well? I don’t see the latter as a significant issue, but it’d be nice if they could use their existing tools so long as the sw they were developing was OSS licensed. I suspect business concerns won’t permit that, but it’d be nice to have a definite answer (I lack a VS commercial version to test with) so the build documentation can be accurate. If VS commercial users still have to maintain a separate build of the PoDoFo library with VS EE to use the GUI tools shipped with PoDoFo it’s not a big deal, but it’d be nice if they didn’t.

Great news, again!

So the Qt 4.3.2 is coming ?

excellent news indeed. There are always people wining about how they can’t use the MS compiler out of the box with the open source version I was always thinking, stop wining, you are lucky to get Qt already for free! But if you people can afford this.., that’s great!

now I can make some really lean n mean exe’s on win

No more 3rd party patches to support MSVC Express

Hmm well I managed to make it work by adding the following lines to C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat

@set PATH=C:\Program Files\Microsoft Platform SDK\Bin;%PATH%
@set INCLUDE=C:\Program Files\Microsoft Platform SDK\Include;%INCLUDE%
@set LIB=C:\Program Files\Microsoft Platform SDK\Lib;%LIB%

I think I was supposed to install the platform SDK to C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK

Oh well.

And it seems my previous post was EATEN by your malicious blog! I was just moaning about how it isn’t at all obvious how you’re supposed to get it all to work. I’ll post a how-to once I have.

Girish, in 2005 year Troll sad, that this step in unavailable, because EULA incompatible with the GPL.
http://www.qtforum.org/thread.php?postid=36558#post36558
What happens now?

Sergey,
It’s not our job to ensure end users don’t break an EULA they agree to.