antoniong wrote: > austin987 wrote: > >> On Fri, Feb 6, 2009 at 11:56 AM, antoniong <wineforum-user@xxxxxxxxxx> 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. >> >> -- >> -Austin >> > > > 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 Leopard (10.5). > 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. James McKenzie
