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

[Jonathan Marsden]

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 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.

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.

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.

> 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.

> 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!

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? :)

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".

Jonathan