[wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Alan W. Irwin]

On 2013-07-01 19:58+0100 Hin-Tak Leung wrote:

> --- On Mon, 1/7/13, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
> ... I hope your negative
>> attitude
>> toward the Cygwin toolchain is not typical of such
>> developers.  After
>> all, even though the Windows GNU toolchain code bases have
>> diverged
>> between the two groups of developers, there is still a
>> common interest
>> between MinGW and Cygwin developers regarding getting the
>> GNU
>> toolchain to work properly on Windows.
> ...
>

> Look. You have been advised a few times, that it is possible and
even easy to bypass installation-related problems and been given brief
instructions on how to do so.

The problem discussed on this thread is not with the generic part of
the installation you have referred to but instead the problem is with
running one of the post install scripts that is invoked by setup.exe.

> you have also been told, *many times*,
and *by the cygwin developers*, that you are just encounter one
problems out of many, and there are more problems to come, in the
thread you posted to the cygwin mailing list.

Many times by you and once by a Cygwin developer.  I have answered both,
but I am going to try again now since you brought it up again.

Even if that assertion were true (something we don't know until some
Wine developer with an interest in Cygwin systematically looks at it
for the latest Wine to see how many Cygwin bugs are left for that much
improved version of Wine) it only strengthens my argument. The fact
remains, Cygwin is open-source software so in theory (i.e., the Wine
developer pursuing this opportunity will need some knowledge of
Cygwin) you know exactly what is going on with the calls to Windows
software, and you can also directly compare results for those calls
between the Wine version and Microsoft version of Windows. Therefore I
think it is obvious that Cygwin represents a good opportunity to get
rid of Wine bugs.  If there are a lot of such bugs like you and the
Cygwin developer assert, then it represents even a bigger opportunity
to debug those Wine issues with exact source code in hand that
demonstrates the issue.  I think we don't really know what
bugs are still left in recent Wine until a systematic evaluation is
done of Cygwin on Wine, but my argument stands whether
there are a lot of such bugs or only a few.

> Going personal and accusing others of being biased is not a way of
getting help.  If you have bothered to look it up as you claim to do,
while I have a formal association with mingw, I have made absolutely
no contribution to mingw at all, ever.

Sourceforge lists you as a MinGW developer, but I believe you when you
state that is only a formal association.  I knew of that possibility
of just a formal association so that is why I was careful to put in
phrasing like "apparently", and "if this is true". I am sorry you
missed that phrasing and took that as a personal attack.

Regardless of your association or not with MinGW, I am still concerned
the opinions you have expressed here on the Cygwin tool chain are
biased. That is because I have my own bias. In short, I have a
prejudice against anyone stating anecdotal evidence concerning issues
with _any_ open-source software if they don't back up that anecdotal
evidence with a solid bug report.  For example, you stated some
anecdotal evidence about a bug in Cygwin "cat", but when I requested a
reference for your associated bug report to Cygwin you were silent.
That told me a lot.

> The cygwin people would have told you the exact same thing: running
mingw on wine is fair easier and more straight-forward.

That is obvious and strengthens the argument for using Cygwin
as a debugging tool for Wine.

> [...]and that cygwin is
not mingw, and there are important difference where wine is concerned.
You seem to assume the difference between cygwin and mingw is small -
they are not, and really a world apart, as far as wine is concerned.

You are completely wrong about what I assume. Try reading what I have
said earlier today.  The two projects are obviously quite different
which is why I have stated earlier today that Cygwin represents a
different opportunity (and a more extensive opportunity because it is
a lot bigger) than MinGW/MSYS to debug Wine.  Of course, that
opportunity is there only if Cygwin _on Microsoft Windows_ mostly
works and is not riddled with bugs.  I think that is a fair assumption
since Cygwin does have a significant userbase that actually uses it on
Microsoft Windows.

Something about this opportunity to use a comparison of Cygwin's
behaviour on Microsoft Windows versus the Wine version to debug Wine
obviously bothers you, and because of that you have clearly stated you
would prefer the Wine developers here ignore this opportunity and work
on something else.  However, I completely disagree with your opinion
about that opportunity.  Any fixes to Wine that make it more like
Microsoft Windows will help _all_ Windows software being run on Wine.
That said, the actual Wine developers here will probably ignore both
our opinions and only investigate Cygwin on Wine if that general
debugging opportunity interests them. But, of course, that is the way
it should be!

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________