[sword-devel] Windows users as "poor cousins"?

[Greg Hellings]

On Sat, Oct 3, 2009 at 4:03 AM, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
>
> Jonathan Morgan wrote (after quoting my entire lengthy message):
>
> > In my opinon, the expected compiler to be used for Windows binaries is
> > VC++, whether it is proprietary or not (for example, ask Mozilla, or
> > OpenOffice, or Python).
>
> Expected by whom?  Microsoft does not provide a compiler and linker with
> its OS.  There is no default C or C++ compilation environment on
> Windows.  Expected by commercial C/C++ developers who have never worked
> on any other platform?  Maybe.  Is that a good thing?  If so, why?

I would venture to guess that it's expected both by the commercial
developers you mention and by the majority of people working on
Windows who are programming on Windows as a hobby.  Personally I've
heard calls on this list for making our work more visible to Windows
users and hopefully we'll be able to garner some more programmers due
to the vast acceptance of Windows in the market.  Many of my
classmates when I was in school "expected" to be able to do their work
in Windows with Visual C++, despite the fact that BSD, Linux and
Solaris were all provided by the school, as was VC++, Borland and
MinGW.

Do we want more programmers from the Windows world to join in our
efforts?  If so, the all-free all-the-time goal that I hear shining
through your statements in this email probably isn't a good way to
encourage them.  I'd love to see statistics, if anyone can find them,
related to the number of developers who prefer to work with VS over
the number who prefer to work with other build chains.  I'd hang my
hat on VS coming out significantly ahead of any others for desktop
development.

>
> > I believe it is generally considered to produce better and more
> > efficient code than MinGW (whether correctly or not, I cannot judge).
>
> Maybe -- as you said, you cannot judge, so that info shouldn't carry too
> much weight, until it actually affects real world use of SWORD or one of
> the SWORD-using applications.  I submit that on current multi-GigaHertz
> multi-core CPUs and multiple GigaBytes of RAM, differences of a few
> percent in code optimization efficiency (whether space or speed) are
> probably not critical to most desktop or laptop-wielding SWORD users.
> If you have SWORD use cases on modern desktop of laptop machines where
> such efficiency gains are indeed vital to successful SWORD deployment,
> please share them, that would be interesting to know about.  For
> cellphones and similar smallish embedded platforms (some cellphones have
> 64GB of storage these days... hardly small!), that kind of difference
> might well be critical... but VC++ does not seem to target common
> devices running Symbian, Android, whatever they call the Palm Pre OS,
> etc. etc. at all.  Wonderfully optimized compiled code that won't
> execute on a given hardware platform or OS is not much help to users of
> that platform.

http://www.willus.com/ccomp_benchmark.shtml has some interesting
benchmarks.  Granted, it was last updated in 2007, he was using gcc
2.95 and VC 6.  His conclusions are in line with other, more recent
comparisons that I've seen.  On his first benchmark note that:
compile times in msvc are 3 TIMES as fast
execution time averages across all the systems are 23% faster in msvc
OK, so compile times aren't an enormous deal, but I'd say a 23% speed
execution increase is.  Also interesting, Borland was the only system
to score slower than MinGW.  On his fourth benchmark (skipping 2 and
3, since they are Fortran) again, MSVC comes in with approximately 3x
the compilation speed but now the performance difference is negligible
with MSVC very slightly ahead.  All of those benchmarks were floating
point, scientific computing based.  In the Integer realm, again we see
the same compile-time performance boost in MSVC but this time MinGW
came in very slightly ahead in actual performance.

http://keyj.s2000.ws/?p=86 contains more recent information with
Visual Studio 2005, 2008, MinGW 4.3 and Intel's compiler 11.0.  In all
of his benchmarks it appears that VS and MinGW are closely tied in
performance, with Intel's compilers kicking the pants off of both of
them.  It seems to boil down to his last paragraph, which seems to
hold the biggest gem on his page: "The Intel compiler is nice, but
it’s hard to use (Visual Studio integration doesn’t work with the
Express Editions) and tends to generate bloated code, 50% larger than
MSVC’s. The differences between MSVC and GCC are noticeable, but still
not worth the hassle of using GCC on Win32 or being sad because of the
unavailability of MSVC on Linux."

Personally I use the commercial versions of Visual Studio, and I hear
that Intel's compiler integrates marvelously well with it.  Don't know
I'd be willing to drop $600 on it, though.  So really, it seems to
boil down to: what are personal preferences.  I, for one, like to use
the "best tool for the job" without too much regard for whether or not
it's proprietary or open source.  Since Visual Studio has a very nice
code editor and project editor, and because it is fairly ubiquitous
whenever *I've* encountered people trying to build Windows programs,
I'll personally stick with it.

>
> Further, VC++ has some obvious downsides, too.  I can't fix VC++ if I
> need to, and I can't apply whatever I do learn about it on other
> platforms, either.  Nor can you.

I can't remember ever finding a hole in a compiler, let alone trying
to fix it.  This sounds like "high horse" mentality, and not a
practical consideration for me.  For you, perhaps it is, but
definitely not for me and not for programmers who are used to working
with a commercial compiler.

>
> For you, VC++ may be great.  If you can form a little packaging team
> that uses VC++ and then creates nice pretty easy Windows-style .MSI
> installers for SWORD, and so take that specific load off the SWORD devs,
> that would be great.  Especially if you can do that so automated regular
> builds and uploads of those to crosswire.org can happen.  Then (after
> more work!) repeat this for BibleTime and Xiphos, add more comprehensive
> automated test suites for all of this, and we'll really have something
> valuable, I suspect.
>
> Especially in the absence of such a team and such installers, I feel
> that using skills and experience I already have, and using a toolchain
> which is portable to or can target every general purpose OS I know of,
> is *much* more worthwhile and of more interest, for me, doing this as an
> unpaid volunteer, than spending my time learning details of a
> proprietary toolchain for one proprietary OS.  Incidentally, I suspect
> that my "irrelevant" (ancient? archaic? obsolete?) knowledge of GCC and
> autotools is quite likely to still be useful when VC++ is just a distant
> memory :)
>
> Questions about "Windows doesn't seem to encourage compiling things, how
> do I get started?" would suggest that there may in fact be room for
> providing and documenting a reasonably straightforward way to do that
> very thing, on Windows, using existing portable cross-platform open
> source tools.  Automating it, so others do not even have to do any SWORD
> compiling for Windows themselves, seems an obvious and logical next
> step.  If you think there is also room for doing that kind of thing with
> VC++, you may very well be 100% correct.  If that is something which is
> of interest to you, cool -- do it!  If your results are clearly better
> than anything I can come up with, then I'll almost certainly drop this
> little side project at that point.

With the exception of automating the system, since I have little
interest in that, I've already built and documented building SWORD
with VC++.  Chris Little has also built it with VC++.  I don't know if
he's documented it or not, but this task has already been done.

>
> > BPBible uses VC++ to build Sword binaries to make it work with the
> > standard Python distribution on Windows.
>
> IMO it's really sad that anyone would choose an open source
> cross-platform language such as Python, on top of an open source
> cross-platform library such as SWORD, and then deliberately restrict the
> resulting application to just one OS.  But it is your project, and so
> entirely your choice.

It's sad to me that you would want to foist the MinGW/MSYS system onto
Windows and encourage potential developers in Windows to take one look
at that, compare it in their minds against VC++, and say, "Nah, if I
have to learn autotools and bash to get this done, never mind."
Personally, if I wasn't already comfortable with Bash, I would
certainly think that!  I still do think it, because of the need to
deal with autotools (I'd rather see a different system used which
would allow a single, centralized set of build scripts instead of
having to maintain the auto* and VC++ and BCB separately, but I'm in
no position to complain about that, since I haven't volunteered to
step up and create such a system).

>
> > Whether or not MinGW/autotools works is irrelevant, since it is not
> > the expected development environment.
>
> You have now made repeated statements about "the expected" development
> environment or software tool.  However, you have provided no evidence
> that the majority of volunteer C++ programmers in the SWORD-using world
> prefer one development environment over the other.  That a couple of
> *very* large projects which started out commercial and later switcher to
> open source use the Microsoft toolchain is not really relevant to SWORD,
> which has been cross platform for many years now -- longer than either
> Mozilla or OpenOffice I suspect!

I don't think he's making the point that most SWORD programmers would
"expect" it.  I think he's pointing to most Windows developers would
"expect" it.  Yes, an equally unsubstantiated claim as your statements
to the tune of GCC will be here when VC is a long-distant memory and
your implicit claim that Windows programmers don't expect it.  I'd
like to see a study pointing one way or the other.  I already said
where my money is.

>
> More interestingly, if you take a "the Microsoft way is *the* expected
> way" approach to toolchain choice on Windows, why would you choose
> Python rather than a Microsoft-specific proprietary scripting language?
>  Surely on Windows, Python is not "the expected scripting language".
> Perhaps VBscript or maybe Visual Basic or maybe C# is, on that basis.  A
> VBscript interpreter comes with every copy of a desktop or server
> Microsoft OS since 2000, I think, so that surely is "the expected
> scripting language" on that platform? :)

Give me VBScript hooks to SWORD and maybe this point would be
relevant.  OK, so not myself, because I have no knowledge of
programming in VBScript or knowledge of whether such an interface is
possible.

>
> This has wandered a long way from the "poor cousins" starting point.
> Let's return to those hypothetical cousins for a moment.  Their poverty
> relates to lack of SWORD binaries on their chosen OS.  There seem to be
> some in the Windows world who don't really care what development
> environment is used, just so long as they can (if necessary compile and)
> use the very latest SWORD code.  I'm starting to work on something that
> may eventually address that niche, and I'm documenting and publishing
> what I have done so far, as I do it.  If you have an alternative that
> uses VC++ which you believe is superior, then please do publish it, and
> please do set up regular automated SWORD builds (and corresponding
> automated .MSI installer creation) for Windows with it -- perhaps *that*
> could make what I am doing "irrelevant".

As I said above -- already done.  Anyone who wanted to could grab my
description from the BibleTime development wiki and try to follow it
to build the SWORD library.  It's a little stale, but I last updated
it after 1.6.0, so it's not that stale.  VisualStudio comes with a
built-in tool to make a VERY minimal .MSI installer.  It also comes
with an extremely extensive set of scripting tools and macros if you
want to automate it.  If SWORD's build utilities had a built-in
packaging mechanism, that would already be taken care of (BibleTime's
build system uses CMake which comes with CPack which will allow
packaging to be automated on different systems.  Currently it has code
which works well on Mac OS X to build a drag-and-drop installer and
works on Windows to build an NSIS based installer all within our one
build system.  autotools has no similar system that I'm aware of, and
it is not used it for VC++ based builds of SWORD on Windows anyway.).

OK, now that I've talked longer than I probably should have -- in
short, the work has already been done to build SWORD with MSVC.  It
has already been built with MinGW/MSYS also by Matthew.  Both produce
code with comparable execution performance on Windows according to
benchmarks I've seen.  I'd venture to guess that we would have more
people interested in building on Windows if they knew off-hand that
the system builds out of the box with VS AND with MinGW, since we
wouldn't have to push one on people who prefer the other.

And yes, all of this seems to have grown out of a simple notice that
BibleCS for 1.6.0 has not yet been released.  Troy said he's hoping to
fix that this weekend - I sincerely hope that he has the time.  In the
interim, people are more than welcome to check out Xiphos, BPBible or
help me figure out why Qt4 seems to have great distaste for SVG files
on Windows.

--Greg