Features Download

From: Kai Tietz <Kai.Tietz-n97bsLhj/YiaMJb+Lgu22Q <at> public.gmane.org>
Subject: Re: Harmonizing mingwrt / w32api with mingw-w64
Newsgroups: gmane.comp.gnu.mingw.devel
Date: Monday 20th July 2009 10:52:29 UTC (over 9 years ago)
Keith Marshall
 wrote on

> On Sunday 19 July 2009 15:24:42 Vincent R. wrote:
> > I totally disagree because Kai is contributing a lot to make
> > progress gcc on win platform.
> You are, of course, entitled to your own opinion.
> > There a few people like that I can name like Dave Korn, Danny
> > Smith , Aaron Laframboise
> And, at the time when Kai embarked on his unnecessary fork, two of 
> those were committed contributors to mingw32, not to mingw-w64.
> > Another remark is the fact that everytime I had an issue
> > with binutils/gcc on win(ce) platform I asked Kai and HE ALWAYS
> > tried to understand what was wrong and to fix things.
> Yet, he completely failed to appreciate the utter insanity of 
> discarding all of those experienced developers he had previously 
> been working alongside, and diluting his developer pool.
> Don't get me wrong.  Kai has been productive in pursuing his goals 
> for mingw-w64, but imagine how much *more* productive his efforts 
> might have been, to the benefit of *both* mingw32 *and* mingw64, if 
> he had continued to work in a spirit of co-operation with those 
> experienced developers he left behind.


I would liked to reply to the ongoing discussion on mingw-dvlr by myself 
earlier, but I had to wait for this until today, as the subscribed e-mail 
is that from my office and I wanted to speak with other team-members 

First we appreciate that Chris raised this discussion. And I attended it 
SF mailing list viewer interested.

But some points there said are simply not true.
A long time ago (already 2005) the company we were working for wanted to 
port our software to 64bit windows. As of the fact that a large part of 
the software is using ObjectiveC there is only one compiler on windows to 
compile it. GCC. So we began to search for a 64bit gcc/binutils port. But 
nothing was there. Not on mingw not anywhere else. Just some postings in 
newsgroups saying "yes we would love to have it, but no time/knowledge to 
do it." GCC4 was not even really windows 32bit ready at that time.
We talked to mingw people but got similar responses. We also offered to 
help and to do it on our own, together with the mingw project. 

The port was done by the company I am still working for. Me (Kai) was one 
of the team, which did the white-room port beginning 2006. After the port 
was mostly complete we tried to provide this port to mingw.org. As at this 
time I was still under NDA (which was released now 6 months ago, so that I 
am allowed to write about this more openly), so I couldn't anwser all 
questions raised. But there weren't much question, mostly offending and 
even rumors were spreaded. Nothing of the reaction of mingw.org's 
leaderships has shown to us a perspective or a target in co-operation for 
this. So we decided to put this code into a project on SF, because it 
should become open source and we were in need to have an public repository 
(this we did in October 2007).  In 2008 the company OneVision offical 
donated the sources and headers to me in person (and for mingw-w64) under 
the condition, that it has to remain open source.  At this point, we began 
as mingw-w64 project to increase our support also for x86 support. The 
major politic of mingw-w64 is to work for further development strict with 
upstream (open available) version without private patches to external 
projects. Also we never made difference in user support, if somebody is 
using a compiler from packager x, or y, as this doesn't help the user 
querying questions. Also we have regular builds for developers of upstream 
source, so we can verify and check very quickly, that upstream source 
keeps working.

The major point that we reduced co-operation - as mingw-w64 and before 
project start - is, that we were offended and defamed by persons (which 
are maintainers of mingw.org) more then once. Why should we accept this 
silently and play nice to a bad game. I never offended somebody from 
mingw.org team by open mailing-list flame, I tried to avoid putting oil 
into the fire. But I had to see pretty often on your ML the statement for 
users, which were searching for gcc windows 64-bit support, the statement 
"We don't support this fork.". Well does this shows the wish of 
co-operation? Honestly we are no children and no baboons, and those kind 
of talks and habits common to mingw.org are childish and callow. And those 
kind of discussion lead nowhere. As long as there is such a management of 
mingw.org, which prefers to talk over, but not with somebody, we as 
mingw-w64 have problems to accept and take them serious.

Secondly, to defame my work on gcc as selfish and just good for mingw-w64 
is ignorance and just shows the real issue here. Most patches I did where 
directly related to 32-bit as well as for
64-bit code of binutils and gcc. A lot them are one reason why 4.4.x and 
binutils works better for 32-bit than for a long time. Mingw.org was and 
will benefiting by them greatly. We provide some of our patches for shared 
runtime parts (because we don't want to do battle on users-head) to 
mingw.org, as we have the strong opinion that this is a win/win situation 
for both projects. We prefer to make things real, instead of just talking 
about it, and trying not to accuse.

Kai Tietz and Roland Schwingel

OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Strasse 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementaerin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Strasse 9 ? 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschaeftsfuehrer: 
Manuela Kluger

Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
CD: 4ms