As a Win developer, I want to make a suggestion (sorry if it was already discussed - or if similar mechanism already exists): What if some simple way will be provided for Win developers to say which options they prefer for WINE to use for their application? While it may seem to somewhat contradict to the 'big bright future' of the WINE (with all the apps running flawlessly under WINE), it would hopefully allow for immediate increase of out-of-the-box supported applications.
For example, it could be a resource string of special format (for example, "__WINE_CONFIG_HINT: "Managed" = "N""), and multiple hints should be allowed. This hint should override system-wide settings but in turn should be overridden by per-app settings in wine config file/registry.
_________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
John Smith wrote:
As a Win developer, I want to make a suggestion (sorry if it was already discussed - or if similar mechanism already exists): What if some simple way will be provided for Win developers to say which options they prefer for WINE to use for their application? While it may seem to somewhat contradict to the 'big bright future' of the WINE (with all the apps running flawlessly under WINE), it would hopefully allow for immediate increase of out-of-the-box supported applications.
For example, it could be a resource string of special format (for example, "__WINE_CONFIG_HINT: "Managed" = "N""), and multiple hints should be allowed. This hint should override system-wide settings but in turn should be overridden by per-app settings in wine config file/registry.
This will just allow developers to hide bugs in wine and slow development even further, I thing it's a bad idea.
Ivan.
This will just allow developers to hide bugs in wine and slow development even further, I thing it's a bad idea.
Ahem. To say it politely - I didn't get an impression that WINE developers are desperately looking for unknown bugs to fix.
Situation is pretty simple. We have an application, which works Ok under WINE, provided that Managed=N specified (with CrossOver it works Ok out-of-the-box). We won't change our code to go around WINE shortcomings (we checked relevant portions of our code though for potential bugs and found nothing), but we would add some kind of hint to make life of our customers a little bit easier. On the other hand, if WINE team doesn't care about current WINE end-users (and there are lots of them, despite the fact that WINE is still Alpha; they just download binary RPM provided and expect their favorite applications to work out-of-the-box) and thinks that they should wait until bug-free WINE released - we don't care much either.
From: Ivan Leo Puoti ivanleo@gmail.com Reply-To: ivanleo@gmail.com To: wine-devel@winehq.com Subject: Re: Throwing in an idea (probably it was discussed before though) Date: Mon, 22 Aug 2005 00:31:07 +0100
John Smith wrote:
As a Win developer, I want to make a suggestion (sorry if it was already discussed - or if similar mechanism already exists): What if some simple way will be provided for Win developers to say which options they prefer for WINE to use for their application? While it may seem to somewhat contradict to the 'big bright future' of the WINE (with all the apps running flawlessly under WINE), it would hopefully allow for immediate increase of out-of-the-box supported applications.
For example, it could be a resource string of special format (for example, "__WINE_CONFIG_HINT: "Managed" = "N""), and multiple hints should be allowed. This hint should override system-wide settings but in turn should be overridden by per-app settings in wine config file/registry.
This will just allow developers to hide bugs in wine and slow development even further, I thing it's a bad idea.
Ivan.
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
John Smith wrote:
Situation is pretty simple. We have an application, which works Ok under WINE, provided that Managed=N specified
Then just tell your users to set that in winecfg, AFAIK winecfg allows app specific settings. I'm sure your great guys but any such mechanism could be easily abuse by lazy programmers, also once it wasn't needed some sort of backwards compatibility may even be needed, I don't think it's a great idea. One simple solution would be to provide default settings for apps that have known problems, Alexandre hasn't ruled that out if it helps some apps to work out of the box.
Ivan.
Then just tell your users to set that in winecfg, AFAIK winecfg allows app specific settings.
1. It is still not 'out-of-the-box' - and from this point of view it doesn't matter much whether it is hacking config file or using GUI; 80% of end-users will try it and throw it away if it doesn't work without hacking settings; 20% of others will ask questions, and will hack config or run winecfg, but those 80% will be lost. 2. (not really relevant to this discussion, but relevant to the whole issue of supporting end-users): binary RPMs for RedHat/Fedora on winehq.org are still 20050524, and winecfg is pretty much useless there. If WINE team does care about end-users, it would be nice to have binary RPMs for the most popular distribution not that much out-of-date.
I'm sure your great guys but any such mechanism could be easily abuse by lazy programmers,
Don't see much ways to abuse in general - eventually WINE is supposed to run _any_ Win application, right? Also I've suggested that config/winecfg per-application settings should override those 'hints', so user is still in control of it.
also once it wasn't needed some sort of backwards compatibility may even be needed,
If all it is about is overriding currently existing settings, no backward compatibility is required.
One simple solution would be to provide default settings for apps that have known problems, Alexandre hasn't ruled that out if it helps some apps to work out of the box.
Ok, this probably is even better; what about integrating such a thing with AppDB and automatically include some special field from AppDB data into winehq distribuitions?
_________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
John Smith wrote:
- It is still not 'out-of-the-box' - and from this point of view it
doesn't matter much whether it is hacking config file or using GUI; 80% of end-users will try it and throw it away if it doesn't work without hacking settings; 20% of others will ask questions, and will hack config or run winecfg, but those 80% will be lost.
As some have suggested you can write the settings to the registry yourself
Ivan.
Le lun 22/08/2005 à 07:58, John Smith a écrit : [snip]
- (not really relevant to this discussion, but relevant to the whole issue
of supporting end-users): binary RPMs for RedHat/Fedora on winehq.org are still 20050524, and winecfg is pretty much useless there. If WINE team does care about end-users, it would be nice to have binary RPMs for the most popular distribution not that much out-of-date.
Yes, that's my fault. After moving in June, I haven't found the time yet to reinstall all my computer stuff (I'm typing this sitting on the floor with my keybord on my knees), so I don't know when I'll get back to it. I already missed two releases, and haven't produced any rpm for FC4 (for which I get a couple emails per week).
If somebody wants to step up to the task (at least temporarily), I'd be glad to share my experience with them.
Vincent
Ivan Leo Puoti wrote:
John Smith wrote:
Situation is pretty simple. We have an application, which works Ok under WINE, provided that Managed=N specified
Then just tell your users to set that in winecfg, AFAIK winecfg allows app specific settings.
You can also set it yourselves in in your app. As configuration is in registry, every app can modify it.
Jacek
Then just tell your users to set that in winecfg, AFAIK winecfg allows app specific settings. I'm sure your great guys but any such mechanism could be easily abuse by lazy programmers, also once it wasn't needed some sort of backwards compatibility may even be needed, I don't think it's a great idea. One simple solution would be to provide default settings for apps that have known problems, Alexandre hasn't ruled that out if it helps some apps to work out of the box.
Isn't it possible that the App just writes some registry entries to HKCU/Software/Wine/AppDefaults/Filename.exe/ ???
Stefan
John Smith wrote:
This will just allow developers to hide bugs in wine and slow development even further, I thing it's a bad idea.
Ahem. To say it politely - I didn't get an impression that WINE developers are desperately looking for unknown bugs to fix.
Because it's a tedious and boring task to narrow down those unknown bugs in closed-source apps. And that's exactly why we ask you (since you got access to the sources) to tell us what the application is trying to do which doesn't work in Wine...
Actually fixing bugs is usually easy, tracking them down OTOH...
(we checked relevant portions of our code though for potential bugs and found nothing)
Even if your application relies on undocumented behaviour ("potential bugs" heh) it should work - if it doesn't that's a bug in Wine which should be fixed.
And by the way:
Managed=N breaks focusing for everything on my box (bug #2149)... :-)
Felix
Because it's a tedious and boring task to narrow down those unknown bugs in closed-source apps. And that's exactly why we ask you (since you got access to the sources) to tell us what the application is trying to do which doesn't work in Wine...
Ahem. And how long it usually takes to fix the bug for not-top-10 application? And please, don't suggest to fix it ourselves - it is not going to happen in corporate environment.
As for 'tell us what the application is trying to do' - you've got all APIs in your hands, so what's the problem to track down system calls? The issue our app is experiencing is quite a subtle one - it works Ok with Managed=N or with Desktop=YYYxZZZ (or from CrossOver BTW), but with default WineHQ distribution when it tries to minimize one of it's top-level windows with an explicit call to ShowWindow, the window is not only minimized, but also reduced to 1x1 pixel; when restoring it, sometimes it is restored normally, sometimes not. This behaviour was reported for Gnome/KDE/Xfce and can be fixed with 'Managed' or 'Desktop' settings I've mentioned above.
(we checked relevant portions of our code though for potential bugs and found nothing)
Even if your application relies on undocumented behaviour ("potential bugs" heh) it should work - if it doesn't that's a bug in Wine which should be fixed.
Well, in fact WINE compatibility wasn't our goal in such a check (WINE installation base is still negligible, and probably will remain negligible until some attention will be paid to out-of-the-box compatibility - at least like in CrossOver); it was just a good reason to check for potential incompatibilities under 'native' Win platforms. Also note that having WINE work perfectly is not our goal (personally I would like it, but the company coudln't care less).
Managed=N breaks focusing for everything on my box (bug #2149)...
As it would fix the problem for 99% of our users, and won't affect those who doesn't run our app, IMO it is still good enough.
Also I remember you've just told that fixing bugs is easy - why does it still exist then?
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
John Smith wrote:
Ahem. And how long it usually takes to fix the bug for not-top-10 application? And please, don't suggest to fix it ourselves - it is not going to happen in corporate environment.
Not that long if you provide a small testcase with source that triggers the bug
As it would fix the problem for 99% of our users, and won't affect those who doesn't run our app, IMO it is still good enough.
Then write the setting to the reg yourself, and hope the wine config key never moves.
Ivan.
John Smith wrote:
Because it's a tedious and boring task to narrow down those unknown bugs in closed-source apps. And that's exactly why we ask you (since you got access to the sources) to tell us what the application is trying to do which doesn't work in Wine...
Ahem. And how long it usually takes to fix the bug for not-top-10 application? And please, don't suggest to fix it ourselves - it is not going to happen in corporate environment.
If you give a scenario that is easilly reproduceable, it is rare that problems go more than a couple of days unfixed. Sometimes you hit something that requires a rewirte of half the relevant subsystem, but usually it's just a small ommision, and is easilly fixed.
The thing that takes so much time is tracking the exact behavior that goes wrong.
Also I remember you've just told that fixing bugs is easy - why does it still exist then?
Fixing bugs is easy. Finding them is not. It's exactly the same with proprietary software too, btw. If a user reports "this doesn't work", my experience is that you spend two weeks in QA trying to reproduce the problem, half a day fixing it, and a couple more weeks testing the solution. It's fairly rare that the relations are much different, but do let us in on your experience.
All we are saying is "pin-point the problem for us".
Shachar
On Mon, 22 Aug 2005 22:46, John Smith wrote:
Ahem. And how long it usually takes to fix the bug for not-top-10 application? And please, don't suggest to fix it ourselves - it is not going to happen in corporate environment.
Sure it is. There are several corporates around here where fixing bugs in Wine is corporate policy.
-
Felix Nawothnig -
Ivan Leo Puoti -
Jacek Caban -
John Smith -
Shachar Shemesh -
Stefan Dösinger -
Troy Rollo -
Vincent Béron