May be a bad idea to have Winetools in the next SUSE release

[Jan Zerebecki]

Hi.

For Andreas Jaeger: I CCed you, because you said on
http://en.opensuse.org/Wishlist_Packages_that_are_already_there
that Winetools got included for the next SUSE release. I hope you
are the correct person to talk to or at least can forward this to
someone who is. The following might be usefull information for
you:

I think a quote from http://www.winehq.org/site/download somewhat
sums up the cencus on this list regarding Winetools: "WineTools
[is] only recommended if installation or operability of Windows
software failed on pure Wine. Since WineTools radically alters
your Wine configuration please do not report bugs in programs
with WineTools installed. Instead contact the author of WineTools
Joachim von Thadden."

Some other facts:

Winetools is only sporadically updated for new versions of Wine
(as http://www.von-thadden.de/Joachim/WineTools/ indicates; this
site also contains some warnings regarding the support status).

Winetools radically alters some vital Wine settings and thus
makes many other apps fail.

This leads to many users asking for help in #winehq on freenode.
But nobody there wants to support winetools and thus can only
suggest them to remove their .wine and redo it without winetools
(which usually makes it work).

Currently no Winetools developer works closely with the Wine
developers to correct problems of interaction between Winetools
and Wine.

IMHO it would be best to either not include Winetools in a
distribution or find a more active developer for it who is
willing to support Winetools and cooperate with Wine developers.
Or at least put up a big warning where it is read by a user that
installs Winetools through the distributions package management.

Jan

[Joachim von Thadden]

Am Thu, Mar 09, 2006 at 01:41:06PM +0100 schrieb Jan Zerebecki:
> I think a quote from http://www.winehq.org/site/download somewhat
> sums up the cencus on this list regarding Winetools: "WineTools
> [is] only recommended if installation or operability of Windows
> software failed on pure Wine. Since WineTools radically alters
> your Wine configuration please do not report bugs in programs
> with WineTools installed. Instead contact the author of WineTools
> Joachim von Thadden."

As there are arguments floating around about WineTools that are
definitely not correct I think I have to make some things here clear.
> Some other facts:
>
> Winetools is only sporadically updated for new versions of Wine
> (as http://www.von-thadden.de/Joachim/WineTools/ indicates; this
> site also contains some warnings regarding the support status).

WineTools is not "sporadically" updated as it makes no sense to update
it  with every new Wine release. The purpose is not to keep track Wine,
the purpose is to have a stable basis. As such WineTools often stays
with a specific Wine version for a time. This is the same what
Crossover-Office does. So you would also not include that if you were
allowed to?
> Winetools radically alters some vital Wine settings and thus
> makes many other apps fail.

This first part is true, the second definitely not. WineTools is at the
moment the only way to have all major commercial windows programs run
simultaneously with Wine under Linux if you do not want to pay for
Crossover-Office.

If what you say is true then name the apps that fail with WineTools and
run with *plain* Wine. I am waiting for your list. And I will include
them in the next release (if I can download them legaly).
> This leads to many users asking for help in #winehq on freenode.
> But nobody there wants to support winetools and thus can only
> suggest them to remove their .wine and redo it without winetools
> (which usually makes it work).

Yes, this is true. As we are a freetime project we have not the time to
sit on an IRC channel. But there is always

a) this mailinglist where we sit and listen
b) the possibility to mail us directly

Again: I am nosy to know which apps work after removing a WineTools
.wine.
> Currently no Winetools developer works closely with the Wine
> developers to correct problems of interaction between Winetools
> and Wine.

What does that mean? We are making a tool to make Windows programs run
with Wine. We do not develop Wine and our main goal is not to achieve as
much debugging informations as possible. The goal is to make the usage
of Wine as easy as possible for users coming from Windows and who are
customized to point and click interfaces. Again: The goal is not to
develop Wine. The goal is to use it easy.

Regards
    Joachim von Thadden

[Marcus Meissner]

> > Currently no Winetools developer works closely with the Wine
> > developers to correct problems of interaction between Winetools
> > and Wine.
>
> What does that mean? We are making a tool to make Windows programs run
> with Wine. We do not develop Wine and our main goal is not to achieve as
> much debugging informations as possible. The goal is to make the usage
> of Wine as easy as possible for users coming from Windows and who are
> customized to point and click interfaces. Again: The goal is not to
> develop Wine. The goal is to use it easy.

Hmm, I have some kind of recommendation here.

What about winetools using ".winetools" as WINEPREFIX setting?

This would make it possible to keep a ".wine" for the purists, and
".winetools" for the "just get things done" people.

Up to now winetools does not seem to honor a WINEPREFIX setting
(also a bug I think).

Ciao, Marcus

[Hiji]

> Hmm, I have some kind of recommendation here.
>
> What about winetools using ".winetools" as
> WINEPREFIX setting?
>
> This would make it possible to keep a ".wine" for
> the purists, and
> ".winetools" for the "just get things done" people.
>
> Up to now winetools does not seem to honor a
> WINEPREFIX setting
> (also a bug I think).

Seperating .wine and .winetools would be cool.  In
fact, the only reason I don't use winetools is because
it "dilutes" my pure wine install.  Just tossing in my
2 cents!

Hiji

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Marcus Meissner schrieb:
> Hmm, I have some kind of recommendation here.
>
> What about winetools using ".winetools" as WINEPREFIX setting?
>
> This would make it possible to keep a ".wine" for the purists, and
> ".winetools" for the "just get things done" people.
>
> Up to now winetools does not seem to honor a WINEPREFIX setting
> (also a bug I think).
>
> Ciao, Marcus

Hey, you steal Joachim's ideas ;-)

That's one point we have discussed in similar form. One directory for 
the present winetools mode and another for a new builtin mode where 
winetools just acts as a menu driven loader and installer.

Sven

[Joachim von Thadden]

Am Fri, Mar 10, 2006 at 12:55:20AM +0100 schrieb Sven Paschukat:
> Marcus Meissner schrieb:
> > Hmm, I have some kind of recommendation here.
> >
> > What about winetools using ".winetools" as WINEPREFIX setting?
> >
> > This would make it possible to keep a ".wine" for the purists, and
> > ".winetools" for the "just get things done" people.
> >
> > Up to now winetools does not seem to honor a WINEPREFIX setting
> > (also a bug I think).
> >
> > Ciao, Marcus
>
> Hey, you steal Joachim's ideas ;-)
>
> That's one point we have discussed in similar form. One directory for 
> the present winetools mode and another for a new builtin mode where 
> winetools just acts as a menu driven loader and installer.

Sorry for the delay: I have been on CeBIT computer fair.

To come to an end with that:

Sven and I are doing the following for WineTools at the moment:

- change WineTools to use WINEPREFIX
- using a standard WINEPREFIX="$HOME/.winetools" if not set otherwise
- change * to builtin,native
- change version to WinXP
- run as many apps as possible without tweaking

The last one is the annoying one as it needs many testing *and* I know
of no way to say "do not use the default" in winecfg or the registry.
If there is a way, please mail me.

I think using the AppDB for getting install and execution infos for
programs is very hard to accomplish. We were already thinking about a
way to send data of successful installations or executions
automatically into a DB but dropped that. It would be very nice to have
but it has to be

- repeated for every version of wine
- checked for correctness
- if there are competing entries they have to be manually resolved
- probably many other problems

Regards
    Joachim von Thadden

[Rich Gilson]

On Thursday 09 March 2006 08:27, Joachim von Thadden wrote:
> Am Thu, Mar 09, 2006 at 01:41:06PM +0100 schrieb Jan Zerebecki:
> > I think a quote from http://www.winehq.org/site/download somewhat
> > sums up the cencus on this list regarding Winetools: "WineTools
> > [is] only recommended if installation or operability of Windows
> > software failed on pure Wine. Since WineTools radically alters
> > your Wine configuration please do not report bugs in programs
> > with WineTools installed. Instead contact the author of WineTools
> > Joachim von Thadden."
>
> As there are arguments floating around about WineTools that are
> definitely not correct I think I have to make some things here clear.
> > Some other facts:
> >
> > Winetools is only sporadically updated for new versions of Wine
> > (as http://www.von-thadden.de/Joachim/WineTools/ indicates; this
> > site also contains some warnings regarding the support status).
>
> WineTools is not "sporadically" updated as it makes no sense to update
> it  with every new Wine release. The purpose is not to keep track Wine,
> the purpose is to have a stable basis. As such WineTools often stays
> with a specific Wine version for a time. This is the same what
> Crossover-Office does. So you would also not include that if you were
> allowed to?

The reality that I have come up with is this:
Even following the instructions provided in the appdb to install IE6 (which is 
necessary for almost anything else to work properly) I can't seem to get it 
to install properly.  When I run an install through Winetools, it works 
flawlessly.  When I try to install TurboTax under "pure" Wine, it fails 
miserably without having to do dll overrides and such.  When I install it 
under Winetools, I have no problems getting it to run without having to tweak 
the hell out of it.
> > Winetools radically alters some vital Wine settings and thus
> > makes many other apps fail.
>
> This first part is true, the second definitely not. WineTools is at the
> moment the only way to have all major commercial windows programs run
> simultaneously with Wine under Linux if you do not want to pay for
> Crossover-Office.
>
> If what you say is true then name the apps that fail with WineTools and
> run with *plain* Wine. I am waiting for your list. And I will include
> them in the next release (if I can download them legaly).
> > This leads to many users asking for help in #winehq on freenode.
> > But nobody there wants to support winetools and thus can only
> > suggest them to remove their .wine and redo it without winetools
> > (which usually makes it work).
>
> Yes, this is true. As we are a freetime project we have not the time to
> sit on an IRC channel. But there is always
>
> a) this mailinglist where we sit and listen
> b) the possibility to mail us directly
>
> Again: I am nosy to know which apps work after removing a WineTools
> .wine.
> > Currently no Winetools developer works closely with the Wine
> > developers to correct problems of interaction between Winetools
> > and Wine.
>
> What does that mean? We are making a tool to make Windows programs run
> with Wine. We do not develop Wine and our main goal is not to achieve as
> much debugging informations as possible. The goal is to make the usage
> of Wine as easy as possible for users coming from Windows and who are
> customized to point and click interfaces. Again: The goal is not to
> develop Wine. The goal is to use it easy.
>
> Regards
>    Joachim von Thadden

Please don't misunderstand me, I have a great deal of respect for what what 
the Wine developers have accomplished so far; however, I feel that those that 
have put the effort into Winetools have done so because they saw a need and 
filled it.  In the realm of ease of use and user-friendliness, Wine is 
horribly lacking.  Yes, it is getting better, but I think that Winetools is 
the closest thing I've seen that would make it so that an average user could 
us it.

IMHO, the Wine developers should spend less time b*tching about Winetools and 
more time figuring out how they can 1) build a front-end that is better than 
Winetools, or 2) help improve Winetools so that it works more to their liking 
but still offers an easy, user-friendly interface.

Personally, I would like to see an application (be it Winetools or something 
else, it doesn't really matter to me) that would interface with the appdb.  
You could launch this front-end and it would pull up a list of all the 
applications in the appdb that have special "config" files.  These files 
would tell this front-end EXACTLY what dll overrides are necessary, what 
files to run, what needs to be installed beforehand, etc.  Then, if there is 
ever a change (due to Wine improving support for a particular dll so that an 
override is no longer needed, for example) all that would have to be done is 
to update the "config" file attached to the program in the appdb and *bingo*, 
you've just "update" your front-end!

I say I would like to see it because I do not personally have the requisite 
programming skill to accomplish such a task, but I'm convinced it could be 
done and that there are programmers out there in the Wine community that 
would easily be able to accomplish such a task.

This whole Wine/Winetools argument has been a thorn in my side for a while 
because I see both sides of the argument and can understand both stances.  
However, I'm also watching and not seeing any compromise being made.  It's 
like both sides have formed ranks and dug in.

It's not my intention to just whine and cry about things, but I'm not in a 
position to directly help.  What I can do is offer my ideas and opinions.  I 
have I haven't pissed too many people off because that was not my intention.

I do look forward to every new release of Wine that comes out, hoping that 
it's that much closer to allowing me to leave Windows behind for good.

[Mike McCormack]

Rich Gilson wrote:
> On Thursday 09 March 2006 08:27, Joachim von Thadden wrote:
> > customized to point and click interfaces. Again: The goal is not to
> > develop Wine. The goal is to use it easy.

I think you'd have alot more friends around here if your goal was to 
help develop Wine.  As it stands, WineTools somewhat impedes testing and 
bug reporting of Wine versions of dlls (eg. ole32, oleaut32, rpcrt4) 
since you encourage your users to use Windows versions of those dlls, 
even though the Wine ones work for many applications.
> IMHO, the Wine developers should spend less time b*tching about Winetools and 
> more time figuring out how they can 1) build a front-end that is better than 
> Winetools, or 2) help improve Winetools so that it works more to their liking 
> but still offers an easy, user-friendly interface.

As Joachim states, his "goal is not to develop Wine".  That's kind of 
incompatible with the goals of "Wine developers", isn't it?

Mike

[Tony Lambregts]

Rich Gilson wrote:
> On Thursday 09 March 2006 08:27, Joachim von Thadden wrote:
> > What does that mean? We are making a tool to make Windows programs run
> > with Wine. We do not develop Wine and our main goal is not to achieve as
> > much debugging informations as possible. The goal is to make the usage
> > of Wine as easy as possible for users coming from Windows and who are
> > customized to point and click interfaces. Again: The goal is not to
> > develop Wine. The goal is to use it easy.
> >
> > Regards
> >    Joachim von Thadden
>
> Please don't misunderstand me, I have a great deal of respect for what what 
> the Wine developers have accomplished so far; however, I feel that those that 
> have put the effort into Winetools have done so because they saw a need and 
> filled it.  In the realm of ease of use and user-friendliness, Wine is 
> horribly lacking.  Yes, it is getting better, but I think that Winetools is 
> the closest thing I've seen that would make it so that an average user could 
> us it.
>
> IMHO, the Wine developers should spend less time b*tching about Winetools and 
> more time figuring out how they can 1) build a front-end that is better than 
> Winetools, or 2) help improve Winetools so that it works more to their liking 
> but still offers an easy, user-friendly interface.
>
> Personally, I would like to see an application (be it Winetools or something 
> else, it doesn't really matter to me) that would interface with the appdb.  
> You could launch this front-end and it would pull up a list of all the 
> applications in the appdb that have special "config" files.  These files 
> would tell this front-end EXACTLY what dll overrides are necessary, what 
> files to run, what needs to be installed beforehand, etc.  Then, if there is 
> ever a change (due to Wine improving support for a particular dll so that an 
> override is no longer needed, for example) all that would have to be done is 
> to update the "config" file attached to the program in the appdb and *bingo*, 
> you've just "update" your front-end!

I think this is a "Good Idea" (tm)

There are always going to be programs that need tweaks to get them to run.

I know of a few that will work fine just by changing the windows version but 
fail miserably with a "clean wine" [1]. These programs usually fail in XP as 
well but it would be nice for the users to have an easy way to get them to run 
"out of the box" in wine

There are others that look for a certain file and if it does not exist the 
program fails[2]. Just creating an empty file with the appropriate name is often 
enough to get the program working. This is a class of bug that is sure to be 
around for a while.

The last class of bugs are the ones that require native (windows) DLL's [3]. It 
would be nice to be able to keep track of these somewhere so that developers 
know which files need to be worked on

Most people are not programmers and even fewer are capable of being developers 
but if we can find a way to make everyones life easier both developers and users 
then we should do it.

In simple terms we get WineTools to query the AppDB with an application name (ie 
somename.exe) and we return a list of applications for the user to choose from 
and the after the user selects the program WineTools gets the appropriate 
overrides from the AppDB and sets them for the user.

I think that that this is do-able if we work together.

--

Tony Lambregts

[1]
http://appdb.winehq.org/appview.php?versionId=4349

[2]
http://bugs.winehq.org/show_bug.cgi?id=4796
http://bugs.winehq.org/show_bug.cgi?id=3661

[3]
http://bugs.winehq.org/show_bug.cgi?id=4631

[Jason Green]

On 3/11/06, Tony Lambregts  wrote:
> In simple terms we get WineTools to query the AppDB with an application name (ie
> somename.exe) and we return a list of applications for the user to choose from
> and the after the user selects the program WineTools gets the appropriate
> overrides from the AppDB and sets them for the user.
>
> I think that that this is do-able if we work together.

First, great idea.

Second, here's a [very incomplete] list of what would need to be done
to pull this off:
- AppDB would have to be extended to be able to get and report this
data, and it would make sense for each App's maintainer to be able to
manage that information.
  - Biggest issue here is that this information could have a tendency
to change very rapidly, so it might overload the app maintainers if
they had to track this for each version of wine.  What I think would
make sense is to have regular snapshots (every 3 months?) and release
a new version of "Winetools Plus" or whatever you want to call this
thing a month later to give the maintainers time to update each of
their apps based on the frozen version.
- Data needed: AppID, AppVersionID, WineVersionID, Window Version, DLL
Overrides, Window settings (fullscreen/windowed - sometimes and
issue), Sound options, Video acceleration required, General notes or
HOWTO's, etc.  You would need separate overrides/settings for
Installing vs. Running the app.
- AppDB could dump this information to an xml format which "Winetools
Plus" could be distributed with.  Maybe have an option to download the
latest xml file directly from winehq.org.
- The 'Winetools Plus' front-end would just be a menu which would
query all of the apps in the xml dump.  The user picks they app they
want to install, and it reads the necessary information, verifies the
source installation media, and goes at it.
- Applying patches to apps might get tricky (e.g., where wine only
successfully runs version 1.5 of the app, but 1.0 is on the CD), but
I'm sure it could be worked out.

Anyway, there's a start.  That would encourage users to get involved
in the AppDB reporting process as well as better organize how to just
"get things done" using wine.

My 2 cents.

Jason

[Tony Lambregts]

Jason Green wrote:
> On 3/11/06, Tony Lambregts  wrote:
> > In simple terms we get WineTools to query the AppDB with an application name (ie
> > somename.exe) and we return a list of applications for the user to choose from
> > and the after the user selects the program WineTools gets the appropriate
> > overrides from the AppDB and sets them for the user.
> >
> > I think that that this is do-able if we work together.
>
> First, great idea.
>
> Second, here's a [very incomplete] list of what would need to be done
> to pull this off:
> - AppDB would have to be extended to be able to get and report this
>
> data, and it would make sense for each App's maintainer to be able to
> manage that information.
> - Biggest issue here is that this information could have a tendency
>
> to change very rapidly, so it might overload the app maintainers if
> they had to track this for each version of wine.  What I think would
> make sense is to have regular snapshots (every 3 months?) and release
> a new version of "Winetools Plus" or whatever you want to call this
> thing a month later to give the maintainers time to update each of
> their apps based on the frozen version.

Well how often this should be updated depends on the development of the various 
dll. If all a program requires wine to emulate Windows 3.1 then it might not 
need updating ever.
> - Data needed: AppID, AppVersionID, WineVersionID, Window Version, DLL
>
> Overrides, Window settings (fullscreen/windowed - sometimes and
> issue), Sound options, Video acceleration required, General notes or
> HOWTO's, etc.  You would need separate overrides/settings for
> Installing vs. Running the app.

You are right that we will probably need entries for both the installer and the 
program itself.
> - AppDB could dump this information to an xml format which "Winetools
>
> Plus" could be distributed with.  Maybe have an option to download the
> latest xml file directly from winehq.org.

I see this as a dynamic thing as the list could get quite large. and downloading 
the whole thing for just one program seems excessive.
> - The 'Winetools Plus' front-end would just be a menu which would
>
> query all of the apps in the xml dump.  The user picks they app they
> want to install, and it reads the necessary information, verifies the
> source installation media, and goes at it.

I think that it would be better if the user entered into WineTools the name of 
the exe they were trying to run but you may be right about this option
> - Applying patches to apps might get tricky (e.g., where wine only
>
> successfully runs version 1.5 of the app, but 1.0 is on the CD), but
> I'm sure it could be worked out.

We cannot solve all the problems at once.
> Anyway, there's a start.  That would encourage users to get involved
> in the AppDB reporting process as well as better organize how to just
> "get things done" using wine.

I would like to here from Joachim as to what WineTools would need. The main 
thing I would like to get away from in WineTools is the blanket changes that it 
now does of making wine emulate windows 95 and use native Dlls by default.

Thanks for your input

--

Tony Lambregts

Tony Lambregts

[Tom Wickline]

On 3/9/06, Joachim von Thadden  wrote:
> > This leads to many users asking for help in #winehq on freenode.
> > But nobody there wants to support winetools and thus can only
> > suggest them to remove their .wine and redo it without winetools
> > (which usually makes it work).
>
> Yes, this is true. As we are a freetime project we have not the time to
> sit on an IRC channel. But there is always
>
> a) this mailinglist where we sit and listen
> b) the possibility to mail us directly

Hello,

I don't believe you would have to spend all of your free time sitting
on a # winetools IRC channel. The channel could maintained by current
users.. You know, users helping users kinda thing. And if you guys
have some extra time to spend on the channel fine if you don't that
would be fine as well.
  The way it is now WineTools users don't have a mailing list, a IRC
channel or forum to ask questions or any real way to seek help other
than sending you a direct mail. And experienced users don't have any
of these venues to help people.

Just my $.02

Tom

[Jan Z.]

Thank you, Andreas Jaeger for the clarification regarding the
inclusion of Winetools in SUSE.

On Thu, Mar 09, 2006 at 02:27:23PM +0100, Joachim von Thadden wrote:
> Am Thu, Mar 09, 2006 at 01:41:06PM +0100 schrieb Jan Zerebecki:
> > Winetools is only sporadically updated for new versions of Wine
> > (as http://www.von-thadden.de/Joachim/WineTools/ indicates; this
> > site also contains some warnings regarding the support status).
>
> WineTools is not "sporadically" updated as it makes no sense to update
> it  with every new Wine release. The purpose is not to keep track Wine,
> the purpose is to have a stable basis. As such WineTools often stays
> with a specific Wine version for a time. This is the same what
> Crossover-Office does. So you would also not include that if you were
> allowed to?

Sorry, I wasn't aware of that.

Perhaps then the best for Winetools users and Wine developers is
to enable Winetools to be distributed with it's own version of
Wine (as cx-office and cedega do it) and (as someone else already
suggested) to save it's data and fake Windows under .winetools .
That would also prevent problems when a distribution contains a
version of Wine that is not supposed to be used with the
contained version of Winetools. For example afaik the SUSE
factory tree contains Wine 0.9.5 and Winetools 0.9jo but your
website suggests Wine 0.9.{1,2,3} for that Winetools version.

What do you think about this?
> > Winetools radically alters some vital Wine settings and thus
> > makes many other apps fail.
>
> This first part is true, the second definitely not. WineTools is at the
> moment the only way to have all major commercial windows programs run
> simultaneously with Wine under Linux if you do not want to pay for
> Crossover-Office.

I think you forgot that one can manually configure wine to
support that, even if it is a bit of work.
> If what you say is true then name the apps that fail with WineTools and
> run with *plain* Wine. I am waiting for your list. And I will include
> them in the next release (if I can download them legaly).
> From various users i got the impression the most problems where

with Steam and apps that don't work with Windows version set to
win98. But all this may be the fault of those users and i never
tried winetools my self... So better ask your users if you want
to make winetools better.

Jan

[Andreas Jaeger]

Jan Zerebecki  writes:
> Hi.
>
> For Andreas Jaeger: I CCed you, because you said on
> http://en.opensuse.org/Wishlist_Packages_that_are_already_there
> that Winetools got included for the next SUSE release. I hope you
> are the correct person to talk to or at least can forward this to
> someone who is. The following might be usefull information for
> you:

Winetools is not part of our default installation and will not be
provided with the CD set, it's just an extra optional package that
people that know about it can easily use,

Andreas