Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
On 2013-07-01 06:13+0100 Hin-Tak Leung wrote: [...]In terms of relative importance, consider that mingw (both native and cross) GNU toolchain works well, the toolchain part of cygwin is hardly a priority. Once again you are implying the MinGW GNU toolchain is better than the Cygwin GNU toolchain without mention of any bug reports from you to Cygwin to back up that assertion. Your constant repetition of this theme made me curious so I looked you up on the web, and it appears you are a MinGW developer. If you really are a MinGW developer, 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. You certainly have the right to express your opinion about the Cygwin toolchain here, and you _might_ even be correct, but I am concerned you are biased since you appear to be broadcasting anecdotal evidence without sending in bug reports to Cygwin concerning what you have found. And now to get back on topic again, thanks, André, for that reference to http://wiki.winehq.org/CygwinSupport. The two points there are worth repeating: For Wine, the upside would be: * a very good test suite * a much more solid implementation of the fundamental Win32 APIs These same points can be made about MinGW/MSYS and my work on building software (whose build is configured by my build_projects project) on Wine with that toolchain. And that work has already contributed to 3 Wine fixes (two of which were regressions introduced in the 1.5.x series). However, it should be emphasized that Cygwin is a very much bigger free software project than MinGW/MSYS. So it provides a much more comprehensive and rigourous test of Wine than MinGW/MSYS, and this will be the case for the forseeable future. The number of software projects whose builds are configured by build_projects is growing, but that number it is still very much smaller than the list of software builds that are included in the Cygwin distribution. 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 __
Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
--- On Mon, 1/7/13, Alan W. Irwin ir...@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; 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. 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; whereas I have made some patches available, etc to cygwin's GNU findutils (merged into coreutils eventually), LaTeX, emacs/xemacs, over a decade ago. My history with cygwin is about twice as old as my association with mingw. That's a matter of public record. If you bother to look further, the main reason is really that cygwin is a commercial entity - part of Redhat now, but was a privately-own company until 13 years ago when Redhat acquired part of it. Formal membership to cygwin has always been different from how formal membership to mingw operates, for that very reason; and that I live locally to where that company was, (and the part of cygwin that Redhat choose not to buy, still is), and probably know or have met some of the cygwin developers in person. I don't have the fortune to meet/know many, but they have my respects. The cygwin people would have told you the exact same thing: running mingw on wine is fair easier and more straight-forward, and there are very simple technical reasons why that is the case; 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. Going via exaggeration/sensationalist (showstoppers) or personal attack is not going to win you any help. FWIW, on the latter point, few are interested in reading a 20-line introduction about your life (or lack of it) every time at the bottom of your posts. That's another thing that put people off from helping you.
Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
On 2013-07-01 19:58+0100 Hin-Tak Leung wrote: --- On Mon, 1/7/13, Alan W. Irwin ir...@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
Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
On Mon, Jul 1, 2013 at 7:11 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2013-07-01 19:58+0100 Hin-Tak Leung wrote: --- On Mon, 1/7/13, Alan W. Irwin ir...@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. While it's likely that debugging this (and other) Cygwin problems with Wine would find and eliminate bugs from Wine, it also takes a lot of effort and know how to do so. That time is often better spent on issues that require less effort to debug, and help more user visible applications. In other words, while fixing Cygwin issues is a valuable effort, it takes a lot of time and effort that is better spent elsewhere. If you want to spend that time and effort, feel free to do so. But asking others to spend their time to debug issues that fix Cygwin isn't likely to find many volunteers. -- -Austin
