Re: New version of setup.exe broken when running with WINE

[Christopher Faylor <cygwin at cygwin dot com>]

On Mon, Mar 25, 2002 at 06:50:35PM +0100, Sylvain Petreolle wrote:
>>Sorry, but it is not.  When an emulation environment does not properly
>>emulate Windows and causes a problem with a program, then it is not the
>>program's fault.
>
>I agree with you, but in that case, setup.exe wouldn't have function by
>the past ...

Sorry, but I can't parse this sentence.

If you are saying that a previous version setup used to work in Wine, then
the answer to that is "So?"   We're not going to confine ourselves to only
using things which work on Wine.

>>I really don't understand this line of thinking.  If you had a problem
>>running Powerpoint under Wine would you report it to Microsoft?
>
>Has been made many times by us...  and then more web sites are talking
>about compatibility of their programs with Wine.  Let's take HeadLight
>Software example.  After a few bug reports, they put a page about Wine
>and GetRight ...  it's running properly under Wine today.

That's just great for them.  As I said, this isn't a goal for cygwin.
Or, rather, if there are ways to configure wine such that it works
better with cygwin, then, sure, we can make that information available.
We're not going to modify cygwin to accomodate Wine.

>>Yeah, these are people reporting problems in *Wine*.
>>
>Not only.  Cygwin Bash is doing (maybe ?) unwanted access to COM1 port
>when run under Wine for example

Again, the answer is "So?" If bash is working correctly in its native
environment (Windows 9x/Me/NT/2000/XP), then it is working as designed.
If it is not working well on Wine, then it is very likely to be A WINE
PROBLEM.

If there is a real problem lurking somewhere that only manifests on Wine
for some reason, then you're welcome to debug it and submit a patch.
Since it doesn't seem to be affecting any of the audience for which
Cygwin was targetted, it is a non-issue for me, right now.

This is partially a practical matter.  Debugging a system like Wine
complicates things enormously.  Even if cygwin was doing something
strange with com ports, it could potentially take a lot of time
convincing oneself that this wasn't actually a Wine problem.  That
would mean debugging Wine to see what was going on.  Personally, I
have no interest and no time for such an undertaking.

>>I'd certainly reject any patch that I saw whose sole purpose was to add
>>Wine support to cygwin.  To answer your question: Cygwin is the power
>>company.  Wine is the hair dryer.  Fix the hair dryer.
>>
>Please give me a try : Cygwin & Wine are 2 power companies...  It would
>be great to make a dialog to fix problems of the BOTH parts, not only
>one...  You 'll only have benefit

As far as analogies go, the concept of two power companies doesn't work
anyway.

Anyway, to reiterate for the final time, if you want problems fixed that
manifest in Wine, you're probably on your own.  That's not a big deal
however.  The source code is available.  If you find an actual bug there
is no reason why you can't fix it.

By and large, this is how free software development works.  If you see
a need, it is much much more likely to get filled if you volunteer the
time to do it yourself.  That is what the miniscule number of people
working on this project are doing.

And, please don't come back with the "Not a programmer, don't have time,
it's to your benefit" argument.  None of those are relevant.  If you are
unable to do the work yourself then continuing to assert that it is of
some nebulous benefit to cygwin is fruitless.  Your best (and sometimes
only) leverage in a free software project is your own contribution.
Contributing arguments is often just a polarizing activity.  It doesn't
get any work done and just ends up pulling people away from things that
they could be doing.

It's possible that Wine *is* of some importance to someone who is
working on setup.exe or cygwin.  If it is, more power to them.  If this
mythical person starts submitting patches, however, I'm certainly going
to be inspecting them closely to make sure that we aren't adding
workarounds just for Wine.

If the patch entailed a way of doing things that worked around a problem
in Wine without impacting the code in any way either performance-wise or
clarity-wise, I'd probably accept it.

That's it.  I think I've made myself very clear on this issue.  I won't
be responding further.

cgf
--
Please do not send me personal email with cygwin questions.
Use the resources at http://cygwin.com/ .

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/