[sword-devel] Windows Development

Greg Hellings greg.hellings at gmail.com
Tue Oct 5 17:47:10 EDT 2021


Hi Jeff,

On Mon, Oct 4, 2021 at 5:25 PM Jeff Becker <jbecker at fiveviews.com> wrote:

> Hello, everyone.
>
>
>
> Sorry for disappearing a few months ago without resolving the questions
> that I had. I have been taking care of issues in my personal life which I
> won’t go into here.
>
>
>
> I’ve had time to consider what I would do with the project that I have
> been working on and inquiring about here.  Seems I have a few options:
>
> 1)      Make the existing Win32 code work for what I’m doing;
>
The existing Win32 is good and complete. It can do everything you need from
a traditional Windows standpoint. It was recently improved with better
Unicode path support. I'm happy to help you work on building it, if you
have trouble. I do have a desktop, whence I'm writing you this message now,
that is running Windows 10. I know at least one of the BibleTime developers
also runs Windows to generate release builds on that platform.

> 2)      Convert what I have to the Linux platform and use what’s actually
> available and current in the SWORD Project;
>
This will be the path of least resistance from the SWORD side. I have no
knowledge into what else you're doing to know how it will affect that.

> 3)      Work to bring the work you all have done into the current Windows
> / .Net Framework environment;
>
This would be a good route. I don't believe anyone has done it, though we
do have active bindings for a large variety of other platforms already:
Python, Perl, JNI, <That thing Troy uses for Web>, Objective-C. We do know
how to get bindings done, so you're welcome to take this path.

> 4)      Give up and go another route;
>
Happy hunting if this is your route!

>
>
> I’m leaning toward the third, but I don’t want to step on any toes. It
> will involve:
>
> ·         *Work out design issues* (such as .Net only or .Net as a
> wrapper, Azure compatibility)
>
I would suggest a wrapper. Rewrites of SWORD tend to never reach feature
completeness because there is OODLES of acknowledgement of corner cases in
Sword that it already handles.

> ·         *Create MS VC++ Project(s)* / Solution
>
This can be done, but you can also build off the CMake tooling that's
already in place if you would like to. There's already bits in there to
handle Python and Perl bindings being build from CMake, so it can probably
handle adding some .Net wrapping.

> ·         *Import code pages* (mostly .cpp and .h pages presumably)
>
> ·         *Work out build issues* for both *32 and 64 bit* platforms
>
The library currently handles both of these very smoothly across a large
number of architectures.

> ·         *Test* the results (beginning with my own existing projects)
>
> ·         *Share* the code, preferably using a method you all are used to
> using
>
The official SVN is where all the magic happens. Most of us are happy to
work in a git mirror while something matures and then eventually shine it
up to get it submitted to Troy for inclusion in the SVN.

> ·         *Maintain* the code (including changes to the main code base),
> possibly as a new branch of the existing code
>
Hopefully we can find a way to avoid a permanent branch. Other bindings
live in a bindings directory in the source tree and that is how they stay
up to date.

>
>
> I’m willing to take this on if it’s something that will be used by others
> and, hopefully, supported by others as well.
>
>
>
> I have to admit that my VC++ skills need improvement since I spend most of
> my time in C#.  But it’s a welcome chance to build my skill set. But, of
> course, any help would be greatly appreciated, especially in understanding
> both the current state and plans for the existing code base.
>
>
>
> Regarding the other options listed above:
>
> 1)      I have successfully accessed the sword.dll file from C#.  It
> required creating two separate wrapper classes and obtaining the mangled
> name using a utility provided with Visual Studio.  There are shortcomings
> to this approach including extensive coding and performance hits.  We can
> discuss those if a decision is made to move forward;
>
> 2)      I think I individually, we as contributors and potential
> contributors, as well as others who will come on later will all lose out
> without a viable, up-to-date interface for Windows VS development;
>
Prophecies of our doom have been often repeated, being aimed at everything
from our website (JSP-based) to our hosting (self-hosted SVN) to our
language (C and C++). I look forward to this not panning out, either.

> 3)      Bringing the code into current Windows, Visual Studio and .Net
> Framework development;
>
> 4)      I like what’s been accomplished in the SWORD Project and I want
> to both use it and contribute to it.
>

--Greg

>
>
> I look forward to hearing from you all, especially those who currently
> work in Windows development with this code.
>
>
>
> Jeff Becker
>
>
>
>
>
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20211005/918ead2d/attachment.html>


More information about the sword-devel mailing list