[Interest] Apologies on the "bloat" thread (a.k.a yes Windows is still important)
thiago.macieira at intel.com
Thu Apr 11 02:50:53 CEST 2013
On quarta-feira, 10 de abril de 2013 19.28.10, Justin Ferguson wrote:
> > that make sense on Windows must be implemented on Windows before they are
> > accepted. Any changes made >anywhere must not break the build >on Windows
> please accept this criticism as earnest, heartfelt and with the best
> intentions: whomever(s) QAs the wibdows build process needs a kick in the
> rear. when I built 5.0 it became quite obcious many of the configuration
> options hadnt been tested or tested in some time.
The default config was tested. But yeah, when you start fiddling with the
options, the dust bunnies start to appear.
Unfortunately, it's a problem whose solution doesn't scale. Developer and QA
time is at a premium. We simply cannot test all combinations of all options.
We could remove them, but that would be a greater disservice. So the Qt
Project decided to focus on the default config and only a handful of really
> >and we've worked with the MinGW >community to come up with a decent
> > distribution of theirs that can >produce good-performance code.
> thats awesome to hear, I would greatly encourage the mingw team to review
> the differences in terms of security that msvc provides, theres just no
> comparison. (id est does anyone have even a first gen safeseh for c++
> exception handling? nm sehop and so on).
Exception handling is exactly the problem. The MinGW that we shipped in Qt
5.0.1 and 5.0.2 uses setjmp/longjmp (SJLJ) for exceptions, which is a huge
performance bottleneck. For Qt 5.1, we'll instead ship one with DWARF2.
MinGW64 is readying itself to release SEH support.
For Qt's purposes, DW2 or SEH is identical. It might not be to you if you need
your exceptions to unwind Windows DLL stacks.
> its a volunteer project, IMHFO thats the best kind, but we do ourselves a
> disservice if we ever believe that can rwally compete with the millions of
> dollars and hours that microsoft research has put into their products, is
> there even an oss/fs set of static analysis tools that compete with prefix
> et al?
Uh... let me introduce you to Linux :-)
It started as a volunteer effort and look at where it is now.
> for Windows, for me, anythjng other than MSVC feels like im taking
> liberties with my users machines.
I definitely keep my MSVC2012 updated.
> > also recognise that Microsoft Visual Studio is an awesome tool, as long
> as you
> > don't have to go beyond its boundaries.
> what boubdaries? if we wanted to break it down the debugging apis in
> windows is generally waaay better, windbg is awesome for both userland and
> ring0 and doesnt blow up on threads and I end up losing so much time
> remembering the nuances of the scripting language in question that I can
> generally pump out c++ way faster, especially with the new standard and/or
> boost. I sometimes refer to it as being what I imagined shell scripting in
> tcsh to have been like before I tried it.
The exact subject of the flame war: requiring extra tools and extra libraries,
putting it all together. Windows dev philosophy is that everything is self-
contained, and that translates to how MSVC is used. Requiring users to have
Perl, Python, zlib and SQLite is not acceptable on Windows. And don't ask them
to open a command prompt, if possible.
> without argument, just when in Rome its painful to speak Greek.
Indeed. When in Rome, do as the Romans.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the Interest