[Wine] "viewed as not acceptable by the community"
jjmckenzie51 at earthlink.net
Fri Feb 6 23:06:37 CST 2009
> austin987 wrote:
>> On Fri, Feb 6, 2009 at 11:56 AM, antoniong <wineforum-user at winehq.org> wrote:
>>> Fine if that is you're opinion but you have given perfect arguments against the philosophy of Open souces.
>> How so?
>>> Last but not least: I came here with a perfectly normal and simple question (how to detect whether Wine is running) and all I met were people telling me to find the error (without even thinking that such might be near to impossible) and not even a single bit of help!
>> I gave you a few different ways to do it, which you apparently
>> ignored. As I said, it's a really bad idea to do, but if you want to,
>> the best way would be to detect the broken behavior (since many
>> windows machines may do the same thing). Another good way is to do as
>> Utorrent does, and make the hack optional in the settings, so that if
>> Wine is fixed, the hack can be disabled.
>> On a side note, you go between implying that you wrote this code and
>> want to fix it for Wine and acting as if normal users can detect that
>> Wine is running. How will a user allowing a program to detect Wine
>> help, unless the program already had some hacks? Like I said, it's
>> programmers that are concerned about this, not end users.
> I nowhere wrote or even suggested that I was the one writing the code! I am the one testing a Windows app that is supposed to run under Linux using Wine.
This was not clear in your initial messages.
The question now is what did or did not work with the application.
Remember, the goal of the Wine project is to reconstruct, as closely as
possible, the Win32 environment for different versions of Windows(TM).
> I have no access (and do not want to) to the winsource code neither do I want any access to the Wine sourcecode.
And for program testing, this is not necessary.
> To me Wine is a utility that makes it possible to run Win apps under Linux! Nothing more, nothing less.
As Austin stated, add several other *NIX flavors. My favorite is MacOSX
> However, there seems to be a problem and with my over 40 years of programming experience I seek a solution by which the developer of the app can easily adapt his programm to the yes/no Wine.
Impressive as it is, I have almost 30 years of program testing. I've
found items in Wine that don't work. I took the time to file a bug
report. That is how things work. We don't want you to go back to the
programmer and state that XYZ is the way to detect that you are running
under Wine and here is the fix to get your program working. Why?
Because XYZ may not work with tomorrow's updated Wine builds. This is
still a very fluid project. If you were to look at the functions
provided by Wine 1.0 and then look at what we propose to provide with
Wine 1.2, this would become immediately apparent. As I stated in my
very blunt message, there are real technical reasons why the source
should not be looking for Wine but rather be built as clean as possible
(this means no usage of 'secret' Microsoft functions) to avoid problems
with either Operating System.
> Possible consequences in the futute are his not yours and are his to decide only.
That is very true. However, programmers should know that building to
secrets only known to the program producers create unstable builds that
work with one build of an OS and not any other. I've been there and
tested that. Not to hammer the nail anymore, but building to
functionality that exists today is poor programming practice. Building
to known interfaces with known inputs and outputs is a real good best
practice. Testing is much easier on both the unit and full program
level. Please advise your programmer friend that we want to make Wine
function at the same level as Windows(TM). This includes broken
functionality and all.
More information about the wine-users