Win32 Port Efforts (eKA$H fork)

Christian Stimming stimming at
Mon Dec 11 11:12:21 EST 2006

Hash: SHA1

Dear Jon,

Thanks for this information and the link to the download page (although
the download rate seems to be rather slow, 56 KB/sec?). I'm sorry to
hear about your effort only with this 4-weeks-moderation delay. Surely
the gnucash-devel list is the better place to discuss this contribution.

jarney1 at schrieb:
> Several months ago, I began an effort with eKos Financial group to port
> gnucash to the win32 platform. This work was largely based on the
> gnucash-2.0.0 release (not the SVN head). This has resulted in a largely
> stable gnucash under many versions of Win32. This does, however, differ
> significantly from the SVN version. While gnucash is only a portion of
> the entire collection of packages in the eKOSystem, it was the package
> to which the most change was required to get a clean build. The guidance
> from the gnucash wiki was integral to the success of this port.

Thanks for the feedback about the wiki page. As you can guess yourself,
it's a bit of a pity that you have been working on the 2.0.0 code for
your fork "eKA$H", whereas we have been using SVN-trunk for the other
porting effort. This means many potential upstream patches probably
duplicate changes that we already have.

> Many win32 port efforts consist of loosely coupled sets of packages,
> each having to be installed manually and conflicts abound. The approach
> that eKOS financial has taken is to model the win32 port effort more
> closely after GNU/Linux distributions and what results is a GNU/Win32
> distribution which we are terming the eKOSystem.

Actually, such an approach would be very useful for the "native" GnuCash
win32 distribution as well. Do you think it could also be used by the
original gnucash developer group, i.e. without the kind of rebranding
that you added in your forked source code?

Nevertheless it is good to have a look at your source code - thanks for
explaining how to find your modified source. Some remarks about your
source package:
* Your modified tip-of-the-day list ("Debt is bad.") is fun :-) .
* Thanks for keeping the four separate source code tarballs. This makes
it much easier for us/me to isolate your different sets of changes.
* All in all I can see approx. 250 files that have been modified by you;
I'll attach the unified diff between gnucash-2.0.0 and your modified
version for the other developers to see, in the three sequential batches
that you implemented (step 1-3).

Some discussion, starting from your latest changes (gnc-win32-step3):

* In src/app-utils/gnc-ui-utils.c you did two changes, adding
gnc_lconv_set_utf8(&lc.positive_sign, ""); and
- -  while (fraction != 1)
+  while (fraction > 1)
Any reasons for these two?


* Obviously you worked around the fact that win32 doesn't have "%lld"
for scanf by implementing your own code for this format. However, I
discovered win32 has "%I64d" (SVN r14806). Is there any problem with
that format?

* You did some changes in the QIF import, but those don't seem to change
the real code, do they? Did you observe any problems with QIF importing
on windows?


* You replaced the type names GUID by GNC_GUID and CURRENCY by
GNC_CURRENCY, IGNORE by GNC_IGNORE and others. Any reasons for this,
especially the latter two? I vaguely recall GUID being defined in some
winapi header file, but in SVN-trunk apparently there's no longer a
problem with this. Unfortunately this makes the diff quite hard to read.
You don't happen to have a source tree with only these two namechanges,
do you? :-)

* In lib/libqof/qof/qofbackend.c you added some extra code that is
calling some libtool functions. Should this avoid double-initialization?
When would this be a problem?

* You added an extra data field to the Account data type, "asset class",
along with appropriate reading/writing code in the xml backend and an
extra asset-class.scm scheme report. What do you intend to use this data
field for? Also, this additional data field probably makes the data
files GnuCash and your fork "eKA$H" mutually incompatible (because the
gnucash parser will choke on the unknown XML element)?

* Did you find a solution for lauching a gzip child process for writing
or reading compressed files? In your latest source it doesn't seem so,
as the code will still write/read uncompressed files only.

> I plan to continue distributing the gnucash port as a part of our system

Feel free to continue to do so - that's the wonders of open source.
However, the potential data file incompatibility due to the "asset
class" data field would really bug us. Do you think you can implement
this with sufficient forward- and backward compatibility?

> In testing the gnucash port, I have found that gnucash itself is largely
> stable with the exception of the already observed issues surrounding
> ORBit. What we have observed is that ORBit works well on all of the
> Windows XP 2002 SP 2 in our office, but some Windows XP 2002 SP 2
> machines have issues. We are thusfar unable to isolate the differences
> that cause the problem but are certainly keenly watching for them.

Good to hear. We also don't know more about this except for what is
already written on the wiki page. Thank you for your feedback and good
luck with your own business model and software package.

Christian Stimming
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnc-win32-step1.diff.gz
Type: application/x-gzip
Size: 69972 bytes
Desc: not available
Url : 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnc-win32-step2.diff.gz
Type: application/x-gzip
Size: 5108 bytes
Desc: not available
Url : 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnc-win32-step3.diff.gz
Type: application/x-gzip
Size: 1101 bytes
Desc: not available
Url : 

More information about the gnucash-devel mailing list