Re: [Fwd: WineTools is in need of some major house cleaning!]

[Joachim von Thadden]

Dear developers and all others reading this list,

from Sven Paschukat I was informed about the discussion of removing the
WineTools link from the winehq website. I read all remarks made to that
hotly discussed topic and I am willing to tell you all a bit about the
purpose and history of WineTools as well as I will answer the questions
made by Tom Wickline. So this will be a little longish mail and I beg
your pardon for that and hope you have enough patience to read it all.

To start from the beginning, I took over the remainings of a project
winetools initially started by Frank Hendriksen <frank(a)frankscorner.org>
which was somehow orphaned. The very reason I did that was that in
autumn 2004 I had to write an article in the well known German computer
magazine c't. After fiddling with wine for a long time only to install a
stable IE6 or Office, I found that it was so absolute complicated to
describe all the steps needed only to install the IE6 (which is much
better now) and that also following these steps was very erroneous, that
I started to rewrite the winetools script for the readers of this
article.

I never meant it to become so famous and wide spread, but the download
statistics after only two month showed me that there was a massive
demand for such a tool. So this is how it started and it shows very
clearly that it was always an installer to make certain important
applications easily usable under Linux. It was never meant for testing
or developing. It was always meant for the end user being able to use
his software.

At the time of the first releases it was almost impossible to install or
work with many applications without using native DCOM and/or many of the
builtin DLLs that come with the IE6. To find a configuration for as many
apps as possible was one of the goals. Not to force users (with very low
skills) to have many different wine installations *and* many wine user
directories was a second goal. So this is the reason why, until now,
everything in WineTools is based on this native M$ software (DCOM, IE6).
And believe me, no one would be more happy to wipe this DCOM, IE6 and
MSI stuff completely from his harddisk than me!

So as so many programs rely on parts of M$ software (MFC, VB and MDAC
are other important examples) and because to install and use this
software leads to so many restrictions in the wine usage, I had to pin
wine to the emulation of Win98 and also had to massively tamper around
with DLLOverrides. The goal was to built up an environment, that can
install and use as many Windows programs as possible. This did in no way
regard to the fact that it is not very helpful for the wine developers.
It was just a practical decision.
> From time to time, Sven Paschukat and me are testing wine versions to
> figure out, whether we can skip some of the M$ stuff. We have not been
> very successful with that until now, so this is why there are so many
> remainings of the first start of the project in the concept. But again:
> This tool is for the average windows user. And believe me, I tested
> this with my brothers, who are just normal users. And they never ever
> got a piece of windows software running with wine without my heavy
> intervention. With WineTools they just need to click on some buttons
> and got their software downloaded, installed and configured.

With an amount of many thousand downloads a month, not calculating the
distribution inclusions of WineTools, I get almost the same number of
direct mails about problems with the software as are coming into the
list. And I get massive positive resonance from users who were for a
long time trying to get their stuff running with plain wine and are now
happy that it just works with WineTools.

I must admit, that there raise problems out of the fact, that the same
users are trying to install not WineTools-tested software with the setup
of WineTools and coming then to the list. And your are right that this
is an undebuggable situation. The only way around that is to smoothly
migrate WineTools to more and more builtin features as long as this does
not make the programs uninstallable or unusable.
> Betreff: WineTools is in need of some major house cleaning!
> Datum: Fri, 30 Dec 2005 03:31:43 -0500
> Von: Tom Wickline <twickline(a)gmail.com>
> An: wine-devel <wine-devel(a)winehq.org>
>
> Hello Everyone,
>
> Anyone who reads the posting on this list already knows that I stood up for
> the wineTools project and almost made a couple enemies... But me and Vitaliy
> came to a half way agreement on whether or not we should keep the link
> on our downloads page to WineTools....
>
> I feel I need to ask a couple questions here about the future of WineTools.
>
> 1) Are the concerns that Vitaliy brought up being looked into?

Sven Paschukat suggested to implement a mode for WineTools to install
without native components and without that tampering in the registry.
This allows automatic installations *and* insight for developers if
something goes wrong. We can also add a debugging mode to enable the
logging of wines debug channels, to make a mailable report of bugs.
Also the other suggested corrections will be looked over and changed if
applicable.
> 2) On sourceforge there are still downloads of version 1.30 from
> December 3, 2003 why is this? and do you plan to cancel this project
> or at least update it?
> sourceforge site: 
> http://sourceforge.net/project/showfiles.php?group_id=61341
>
> 3 )Freshmeat list WineTools latest version at 2.1.0 and last updated 1
> year, 4 months ago
> do you plan to update this site and list new versions as there released?
> http://freshmeat.net/projects/winetools/?branch_id=51159&release_id=164227

I personally had never anything to do with these versions. The one on
Sourceforge is Frank Hendriksen's. He was already contacted by Sven
Paschukat to remove the project, but Sourceforge does not allow to
remove projects. So instead he already pointed a link to the official
WineTools site. I don't see what we can do more here.

The one on Freshmeat was taken over and is maintained by Sven Paschukat.
Also Freshmeat does not allow the removal of projects. But Sven will
update the versions there and we will try to keep it uptodate. We might
also move the whole download section to Freshmeat to unburden my
download server.
> 4) Could the maintainers of WineTools help new users in #winehq on
> irc? or start a new channel #wine-tools (or something to that effect)
> and help WineTools users? Can you list either the #winehq channel or a
> new channel on your site and ask experienced users to help new users?

I am very astonished about this request. If you look through the mailing
list you will find, that Sven and me are already giving support on the
wine-users mailing list. That we will not and can not maintain a channel
should be clear as we are not earning our money by looking at channels.
Also the demand by Vitaly to provide rapid fixes to requests on such a
channel or the list is something that can be only meant as a joke!!! If
Vitaly is a man of independent means it is nice for him but we are a
free time project and can only work for WineTools, as the name suggests,
in our *free* time. And we have also a family, friends, mistresses and
other hobbies...
> I am not trying to be critical..... I hope winehq keeps the link to
> your project but you guys may need help more on winehq, and also keep
> information sites more up to date for this to take place. and also
> look in to  Vitaliy's concerns.

Well, we also do not like winehq to remove the project's link. As for
the support I already wrote a line above about that. Note that there is
a massive amount of users using Wine via WineTools. Almost all users
coming from Windows are using this software if they like to use their
programs. This might lead to more and more end user questions on the
list. As a possible solution for that, if you think this gets the upper
hand, I would suggest to have a new mailing list wine-winetools and to
redirect all users to that one. We will propagate then this list in the
readmes and on the WineTools sites. And for sure we will sit on this
list like spiders lurking for our prey...

At least I want to thank all wine developers for their absolute
fantastic work! In my opinion this is one of the most interesting and
most ambitious projects in the community of open source software. And it
really works astonishingly good.

Regards
	Joachim von Thadden
-- 
"Never touch a running system! Never run a touching system?
          Never run a touchy system!!!"

[Fwd: WineTools is in need of some major house cleaning!]

[Vitaliy Margolen]

Tuesday, January 24, 2006, 2:06:06 AM, Joachim von Thadden wrote:
> Dear developers and all others reading this list,

[skip]
> I never meant it to become so famous and wide spread, but the download
> statistics after only two month showed me that there was a massive
> demand for such a tool. So this is how it started and it shows very
> clearly that it was always an installer to make certain important
> applications easily usable under Linux. It was never meant for testing
> or developing. It was always meant for the end user being able to use
> his software.

The problem with this as I see, is that we as Wine developers creating
an environment of one kind. And these "tools" almost totally override
that environment.
> At the time of the first releases it was almost impossible to install or
> work with many applications without using native DCOM and/or many of the
> builtin DLLs that come with the IE6. To find a configuration for as many
> apps as possible was one of the goals. Not to force users (with very low
> skills) to have many different wine installations *and* many wine user
> directories was a second goal. So this is the reason why, until now,
> everything in WineTools is based on this native M$ software (DCOM, IE6).
> And believe me, no one would be more happy to wipe this DCOM, IE6 and
> MSI stuff completely from his harddisk than me!

This is not the case anymore. But not thanks to winetools. We never get
enough testing of these parts from users. Because they've been told to
install m$ components to make anything to work.
> So as so many programs rely on parts of M$ software (MFC, VB and MDAC
> are other important examples) and because to install and use this
> software leads to so many restrictions in the wine usage, I had to pin
> wine to the emulation of Win98 and also had to massively tamper around
> with DLLOverrides. The goal was to built up an environment, that can
> install and use as many Windows programs as possible. This did in no way
> regard to the fact that it is not very helpful for the wine developers.
> It was just a practical decision.

I'm not aware of any limitations that mfc, vb-runtime and mdac places on
the system. In fact most of these components are identical in all windows
versions. Also don't forget that now Wine is more win2k like then win9x.
> From time to time, Sven Paschukat and me are testing wine versions to
> figure out, whether we can skip some of the M$ stuff. We have not been
> very successful with that until now, so this is why there are so many
> remainings of the first start of the project in the concept. But again:
> This tool is for the average windows user. And believe me, I tested
> this with my brothers, who are just normal users. And they never ever
> got a piece of windows software running with wine without my heavy
> intervention. With WineTools they just need to click on some buttons
> and got their software downloaded, installed and configured.

How often do you guys check if a piece of software can be installed on
Wine as-is? Without any additional configuration or native components?
The point and click user have to know what they are clicking on, or not
be presented with the bad choices. With the way it is _ALL_ new times
visiting http://www.winehq.org/site/download have an impressions that
winetools are the absolute requirement and download and install them.

I can't tell how many times I had to tell the user to vipe their ~/.wine
dir and start from scratch _not_ using winetools because what they want
to run does not require anything that winetools install.

Also I don't see any post from you or Sven about these problems in the
bugzilla. How do we know that there are any problems?
> With an amount of many thousand downloads a month, not calculating the
> distribution inclusions of WineTools, I get almost the same number of
> direct mails about problems with the software as are coming into the
> list. And I get massive positive resonance from users who were for a
> long time trying to get their stuff running with plain wine and are now
> happy that it just works with WineTools.

Well yeah, you just riding on the back of Wine. As I mentioned before,
every single person visiting download page thinks that winetools are
something mandatory.
Can we see some of those responses? I really like too see what programs
run and don't run with and without winetools. Also please redirect all
those users to appDB. We need information there available for everyone to
see, not in your e-mail box (no offence).
> I must admit, that there raise problems out of the fact, that the same
> users are trying to install not WineTools-tested software with the setup
> of WineTools and coming then to the list. And your are right that this
> is an undebuggable situation. The only way around that is to smoothly
> migrate WineTools to more and more builtin features as long as this does
> not make the programs uninstallable or unusable.

There should be _no such software_. The winetools have to setup
environment in a such a way that it is unified! If you saying that all
you did is tinkered with lots of stuff to get few applications to work,
this in not good. Wine is not cedega designed to run games and games
only. That just proves my point that environment you have setup with
winetools is less flexible and more restrictive then Wine itself.
> > Betreff: WineTools is in need of some major house cleaning!
> > Datum: Fri, 30 Dec 2005 03:31:43 -0500
> > Von: Tom Wickline <twickline(a)gmail.com>
> > An: wine-devel <wine-devel(a)winehq.org>

I first would like to ask you if this is the standard response time? If
Wine changes something big that brakes Wine, how long will that take for
you or Sven to fix winetools?
> > Hello Everyone,
> >
> > Anyone who reads the posting on this list already knows that I stood up for
> > the wineTools project and almost made a couple enemies... But me and Vitaliy
> > came to a half way agreement on whether or not we should keep the link
> > on our downloads page to WineTools....
> >
> > I feel I need to ask a couple questions here about the future of WineTools.
> >
> > 1) Are the concerns that Vitaliy brought up being looked into?
> Sven Paschukat suggested to implement a mode for WineTools to install
> without native components and without that tampering in the registry.
> This allows automatic installations *and* insight for developers if
> something goes wrong. We can also add a debugging mode to enable the
> logging of wines debug channels, to make a mailable report of bugs.
> Also the other suggested corrections will be looked over and changed if
> applicable.

Installing without any kinds of alterations to the Wine have to be
_mandatory_ and should be the default option. As far as bug reports -
the information collected have to cover each field in bugzilla and
provide enough information for developers. But wait, it's useless if any
of the native components were used. Because that would be the first
replay on the bug report - remove any native components and try again.

[skip]
> > 4) Could the maintainers of WineTools help new users in #winehq on
> > irc? or start a new channel #wine-tools (or something to that effect)
> > and help WineTools users? Can you list either the #winehq channel or a
> > new channel on your site and ask experienced users to help new users?
> I am very astonished about this request. If you look through the mailing
> list you will find, that Sven and me are already giving support on the
> wine-users mailing list. That we will not and can not maintain a channel
> should be clear as we are not earning our money by looking at channels.
> Also the demand by Vitaly to provide rapid fixes to requests on such a
> channel or the list is something that can be only meant as a joke!!! If
> Vitaly is a man of independent means it is nice for him but we are a
> free time project and can only work for WineTools, as the name suggests,
> in our *free* time. And we have also a family, friends, mistresses and
> other hobbies...

I don't imply that any one have to be in #winehq all the time. The
problem here, is that all users of winetools don't share information in
any way. Because they are not directed to do so. And most don't know what
they are doing on Linux anyway. I've seen big numbers of first time Linux
users that immediately grabbed winetools and installed IE because they
wanted to have something "familiar" on Linux (btw about 75% of those were
running as root).
But then when they wanted to install something more usefull (a game, or
some office program, they couldn't). No one on #winehq channel uses
winetools or advertises them. But that channel is the firs place most
people go for help _now_.

And just the volume of the users with different problems but all related
to winetools tells me that something is not right...

Also all the how-tos and any other instructions on the www.winehq.org or
any other place on the Internet written for vanilla Wine and not
winetools. So if something doesn't work your users are stranded (same as
they are on windows - no one will help them, because that's the
environment you've setup).
> > I am not trying to be critical..... I hope winehq keeps the link to
> > your project but you guys may need help more on winehq, and also keep
> > information sites more up to date for this to take place. and also
> > look in to  Vitaliy's concerns.
> Well, we also do not like winehq to remove the project's link. As for
> the support I already wrote a line above about that. Note that there is
> a massive amount of users using Wine via WineTools. Almost all users
> coming from Windows are using this software if they like to use their
> programs. This might lead to more and more end user questions on the
> list. As a possible solution for that, if you think this gets the upper
> hand, I would suggest to have a new mailing list wine-winetools and to
> redirect all users to that one. We will propagate then this list in the
> readmes and on the WineTools sites. And for sure we will sit on this
> list like spiders lurking for our prey...

I'm still really want to see this particular link removed from the
download page and possibly moved to wiki page. This link in such a
prominent place that every single person things that it's a mandatory for
running Wine. Especially the way description is worded.

I think it's really silly for Wine trying to be the pure replacement of
windows and yet advertise such a utility that clearly undermines
development in number of critical areas.


Vitaliy.

[Fwd: WineTools is in need of some major house cleaning!]

[Joachim von Thadden]

Am Tue, Jan 24, 2006 at 09:20:56AM -0700 schrieb Vitaliy Margolen:
> How often do you guys check if a piece of software can be installed on
> Wine as-is? Without any additional configuration or native components?

With every major release.
> The point and click user have to know what they are clicking on, or not
> be presented with the bad choices. With the way it is _ALL_ new times
> visiting http://www.winehq.org/site/download have an impressions that
> winetools are the absolute requirement and download and install them.

I do not know whether this is true. Me myself never looked into the
third party section. I also do not see why anyone will think out of the
title "3rd Party Tools" that WineTools is an "absolute requirement".
> I can't tell how many times I had to tell the user to vipe their ~/.wine
> dir and start from scratch _not_ using winetools because what they want
> to run does not require anything that winetools install.
>
> Also I don't see any post from you or Sven about these problems in the
> bugzilla. How do we know that there are any problems?
> > With an amount of many thousand downloads a month, not calculating the
> > distribution inclusions of WineTools, I get almost the same number of
> > direct mails about problems with the software as are coming into the
> > list. And I get massive positive resonance from users who were for a
> > long time trying to get their stuff running with plain wine and are now
> > happy that it just works with WineTools.
>
> Well yeah, you just riding on the back of Wine. As I mentioned before,

Thank you! Your are such a polite person. And you are reading so well.
I never stated that I get positive resonance for Wine. And I never
aimed to get the cheers for Wine. Think what you are posting!
> every single person visiting download page thinks that winetools are
> something mandatory.

And I don't see that as I mentioned.
> Can we see some of those responses? I really like too see what programs
> run and don't run with and without winetools. Also please redirect all
> those users to appDB. We need information there available for everyone to
> see, not in your e-mail box (no offence).

The questions I get are almost all about WineTools, not about crashing
programs. Most users of WineTools install only what they can with
WineTools as of a lack of skill on the command line. The ones that
really want to get a program running with what ever setup come to the
list.
> > I must admit, that there raise problems out of the fact, that the same
> > users are trying to install not WineTools-tested software with the setup
> > of WineTools and coming then to the list. And your are right that this
> > is an undebuggable situation. The only way around that is to smoothly
> > migrate WineTools to more and more builtin features as long as this does
> > not make the programs uninstallable or unusable.
>
> There should be _no such software_. The winetools have to setup

Well, you will allow that there other opinions in the world, will you?
> environment in a such a way that it is unified! If you saying that all
> you did is tinkered with lots of stuff to get few applications to work,
> this in not good. Wine is not cedega designed to run games and games

You will not be able to force people to use wine for what *you* think
is right. It is good for what it is working for.
> only. That just proves my point that environment you have setup with
> winetools is less flexible and more restrictive then Wine itself.

I am sure it is. So it might only work for the few apps it is meant
for. And that is the only purpose.
> > > Betreff: WineTools is in need of some major house cleaning!
> > > Datum: Fri, 30 Dec 2005 03:31:43 -0500
> > > Von: Tom Wickline <twickline(a)gmail.com>
> > > An: wine-devel <wine-devel(a)winehq.org>
>
> I first would like to ask you if this is the standard response time? If
> Wine changes something big that brakes Wine, how long will that take for
> you or Sven to fix winetools?

I had holidays and many things to do after returning home. And as we
are not commercial we do not have a "standard response time". We also
do not test every new version of Wine, because the stock of programs
supported by WineTools need some time to test. So as Cedega or
CrossOver do we stick on a version with our setup for a while.
> > > Hello Everyone,
> > >
> > > Anyone who reads the posting on this list already knows that I stood up for
> > > the wineTools project and almost made a couple enemies... But me and Vitaliy
> > > came to a half way agreement on whether or not we should keep the link
> > > on our downloads page to WineTools....
> > >
> > > I feel I need to ask a couple questions here about the future of WineTools.
> > >
> > > 1) Are the concerns that Vitaliy brought up being looked into?
> > Sven Paschukat suggested to implement a mode for WineTools to install
> > without native components and without that tampering in the registry.
> > This allows automatic installations *and* insight for developers if
> > something goes wrong. We can also add a debugging mode to enable the
> > logging of wines debug channels, to make a mailable report of bugs.
> > Also the other suggested corrections will be looked over and changed if
> > applicable.
>
> Installing without any kinds of alterations to the Wine have to be
> _mandatory_ and should be the default option. As far as bug reports -

We will definitely not follow dictations made by you! And the default
installation option will alway the one that leads to the best results.
That's the purpose of this tool.
> I don't imply that any one have to be in #winehq all the time. The
> problem here, is that all users of winetools don't share information in
> any way. Because they are not directed to do so. And most don't know what
> they are doing on Linux anyway. I've seen big numbers of first time Linux
> users that immediately grabbed winetools and installed IE because they
> wanted to have something "familiar" on Linux (btw about 75% of those were
> running as root).
> But then when they wanted to install something more usefull (a game, or
> some office program, they couldn't). No one on #winehq channel uses
> winetools or advertises them. But that channel is the firs place most
> people go for help _now_.

I already admitted that this is a problem and suggested a second mailing
list for WineTools. We have not enough spare time to read channels.
> And just the volume of the users with different problems but all related
> to winetools tells me that something is not right...

I am not reading the channel so I can not prove that but on the list I
don't see that there are massive problems with WineTools. There are for
sure users trying to install unsupported software with WineTools. This
is not covered by WineTools. And they can not, as we all already stated,
be helped by wine-developers. So this is why I suggest an additional
mailing list.
> Also all the how-tos and any other instructions on the www.winehq.org or
> any other place on the Internet written for vanilla Wine and not
> winetools. So if something doesn't work your users are stranded (same as
> they are on windows - no one will help them, because that's the
> environment you've setup).

Many of the tweaks of within WineTools come from the appdb and other
net sources. But again: WineTools allows the installation of supported
software only. We can give a *big* warning on startup that this means
that wine-developers will not be able to help on failure.
> I'm still really want to see this particular link removed from the
> download page and possibly moved to wiki page. This link in such a
> prominent place that every single person things that it's a mandatory for
> running Wine. Especially the way description is worded.

I wonder if there is anyone else on the list who reads the download
page and thinks, WineTools are mandatory. I can definitely not see that.
> I think it's really silly for Wine trying to be the pure replacement of
> windows and yet advertise such a utility that clearly undermines
> development in number of critical areas.

The purpose of WineTools is not to "undermine" and also it is, was and
will never meant to be a "pure replacement of windows". And this is
nowhere stated.

To come to an end with this discussion I would suggest the following:

- adding a list wine-winetools for WineTools users
- adding a warning in the software and on the WineTools site that the
  usage of the software leads to undebuggable situations for
  developers, so no help from there can be expected
- changing the text in the download section according (there is already
  a note stating to use pure wine first)
- smoothly migrating the WineTools to pure Wine with as less as
  possible tweaking

Regards
	Joachim von Thadden
-- 
"Never touch a running system! Never run a touching system?
          Never run a touchy system!!!"

[Fwd: WineTools is in need of some major house cleaning!]

[Tony Lambregts]

Joachim von Thadden wrote:

I understand the goal of WineTools and I can see both sides of this issue but 
for for some of us it really is frustrating because it makes our jobs harder.
> The purpose of WineTools is not to "undermine" and also it is, was and
> will never meant to be a "pure replacement of windows". And this is
> nowhere stated.
>
> To come to an end with this discussion I would suggest the following:
>
> - adding a list wine-winetools for WineTools users

This would be nice but who is supposed to host the mailing list. It could be 
just a news group though.
> - adding a warning in the software and on the WineTools site that the
>   usage of the software leads to undebuggable situations for
>   developers, so no help from there can be expected

This would be good
> - changing the text in the download section according (there is already
>   a note stating to use pure wine first)

This new note is confusing still (I will submit a better patch)
> - smoothly migrating the WineTools to pure Wine with as less as
>   possible tweaking

There should be a way to do this. Making this list more prominant and updating 
it when wine tools is not required would help.


http://www.von-thadden.de/Joachim/WineTools/wt0.9jo.html

--

Thanks

Tony Lambregts