I just red the article on the website about winetools. This is controversy is a non starter in my oppinion. I believe that something like winetools should be included in the wine distribution to begin with. It should be something under the control of the developers themselves and bug reports should be added to fix any problems. Why did it take someone outside of the wine development team to do this. For the average user we don't want to have to make a gazillion changes in winecfg. You guys are always adding new features or making changes. I want to just get something going not get stopped at the door by a huge barrier to entry. If the development team had such a tool it could make test releases and production releases. The production release would have the right combination of native libraries and windows DLLs installed to get things going. While the test release would be used for people who want to test. I think this would be an excellent compromise here. This way the development of winetools and wine will go in the right direction to a final working system. Furthermore.... IE is a necessary part of windows now. Functionality for it needs to be in wine. Its not something that can be disgarded or ignored. Allot of applications use IEs DLL's and functionality these days. So its intrinsically part of the windows API. You won't get 100% compatibility without the functionality it offers.
I can agree with this; I have only one windows program that I can't replace with a linux variant, and this program relies on parts of IE to display results of a template. I have a workaroud by going to Konqueror, a couple of mouseclicks more; but when asked the community for help all I get is "use winetools", "use sidenet", "go to Francks' corner", or the nasty ones "why the hell would you use IE?" I don't, I'm an Opera user since 10 years or so, first in Windows, now in Linux. In the mean time all suggestions ended in errors or freesing programs to get IE. So I live without IE and with spectacles. Op Fri, 03 Mar 2006 23:34:29 +0100 schreef Philip V. Neves <pneves@telus.net>:> I just red the article on the website about winetools. This is > controversy is a non starter in my oppinion. I believe that something > like winetools should be included in the wine distribution to begin > with. It should be something under the control of the developers > themselves and bug reports should be added to fix any problems. Why did > it take someone outside of the wine development team to do this. For the > average user we don't want to have to make a gazillion changes in > winecfg. You guys are always adding new features or making changes. I > want to just get something going not get stopped at the door by a huge > barrier to entry. > > If the development team had such a tool it could make test releases and > production releases. The production release would have the right > combination of native libraries and windows DLLs installed to get things > going. While the test release would be used for people who want to > test. I think this would be an excellent compromise here. This way the > development of winetools and wine will go in the right direction to a > final working system. Furthermore.... IE is a necessary part of windows > now. Functionality for it needs to be in wine. Its not something that > can be disgarded or ignored. Allot of applications use IEs DLL's and > functionality these days. So its intrinsically part of the windows API. > You won't get 100% compatibility without the functionality it offers. > > _______________________________________________ > wine-users mailing list > wine-users@winehq.org > http://www.winehq.org/mailman/listinfo/wine-users >-- Met vriendelijke groeten Wim ------------------------------------------------------- Een veilige toekomst voor digitale documenten: Open Document Formaat (ODF) http://nl.openoffice.org/
On 3/3/06, Philip V. Neves <pneves@telus.net> wrote:> I just red the article on the website about winetools. This is > controversy is a non starter in my oppinion. I believe that something > like winetools should be included in the wine distribution to begin > with. It should be something under the control of the developers > themselves and bug reports should be added to fix any problems. Why did > it take someone outside of the wine development team to do this. For the > average user we don't want to have to make a gazillion changes in > winecfg. You guys are always adding new features or making changes. I > want to just get something going not get stopped at the door by a huge > barrier to entry. >If you had read both sides of the debate properly, you wouldn't be asking this question. While we the developers always want to give the user a more enjoyable experience, things like winetools and sidenet are not the right way to go about it. winetools and sidenet install applications by using native dll overrides, thus preventing wine's builtin dlls from being used. If our builtin dlls aren't being used, then we don't get the proper feedback and bug reports that help us make our implementation better. An app like winetools will never be incorporated into wine, and that is agreed upon by the developer's of both wine and winetools.> If the development team had such a tool it could make test releases and > production releases. The production release would have the right > combination of native libraries and windows DLLs installed to get things > going. While the test release would be used for people who want to > test. I think this would be an excellent compromise here. This way the > development of winetools and wine will go in the right direction to a > final working system. >This system might be beneficial to winetools, but it would only hurt the development of wine.> Furthermore.... IE is a necessary part of windows now. Functionality for > it needs to be in wine. Its not something that can be disgarded or > ignored. Allot of applications use IEs DLL's and functionality these > days. So its intrinsically part of the windows API. You won't get 100% > compatibility without the functionality it offers. >You don't have to install native IE to get this funcionality. Jacek Caban is doing a great job implementing the underlying libraries of IE, the libraries that are required by many apps. While it's not yet complete, we are working towards 100% compatibility. -- James Hawkins
Am Fri, Mar 03, 2006 at 02:34:29PM -0800 schrieb Philip V. Neves:> I just red the article on the website about winetools. This is > controversy is a non starter in my oppinion. I believe that something > like winetools should be included in the wine distribution to begin > with. It should be something under the control of the developers > themselves and bug reports should be added to fix any problems. Why did > it take someone outside of the wine development team to do this. For the > average user we don't want to have to make a gazillion changes in > winecfg. You guys are always adding new features or making changes. I > want to just get something going not get stopped at the door by a huge > barrier to entry.Hello, there has already been a comment by the developers but I want to make one too, as I am the maintainer of WineTools. As you have read, the purpose of WineTools is to make installing as many apps as possible as easy as possible. This is very hard to achieve as Sven Paschukat and me have not the time to maintain dlloverrides for every single application supported by WineTools. So we use a single big configuration for almost all applications. And we use many builtin DLLs from the installation of IE6. This leads to the problem that a failure with WineTools is not debuggable by the Wine developers. Sven and me are trying to help as good as possible if someone has problems with WineTools. And we are trying to change the WineTools configuration to use only builtin dlls for as many apps as possible. So if you are happy with the apps WineTools supports and have a valid license of >=Win98 then just go with that. If you are trying to install a not supported app and have success, mail me and I will include the app in the next WineTools release. If you have problems with an app and we can not help you, then you can try it with plain Wine and in case of failure get support from the Wine developers. I think WineTools will never be included into Wine itself because of the heavy changes it makes to the Wine standard configuration to achieve its goal, unless such changes are not needed any more. And also then it is questionable whether it makes sense, because WineTools is then only a simple downloader/installer and not more. If Wine gets to run most apps out of the box you might take any share-/freeware installer and just do the same.> Furthermore.... IE is a necessary part of windows now. Functionality for > it needs to be in wine. Its not something that can be disgarded or > ignored. Allot of applications use IEs DLL's and functionality these > days. So its intrinsically part of the windows API. You won't get 100% > compatibility without the functionality it offers.The Wine-Developers are programming very hard to make embedded IE6 calls usable by Open Source replacements like mozilla control. If this is done there will be no need to install IE6 under Wine. Note that this is a *very* important goal, because otherwise you always have to have a valid Windows license. And Wine is trying hard to get around that! Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"
>> Furthermore.... IE is a necessary part of windows now. >> Functionality for it needs to be in wine. Its not >> something that can be disgarded or ignored. Al >> lot of applications use IEs DLL's and functionality >> these days. So its intrinsically part of the windows >> API. You won't get 100% compatibility without the >> functionality it offers. > > The Wine-Developers are programming very hard to make > embedded IE6 calls usable by Open Source replacements > like mozilla control. If this is done there will be > no need to install IE6 under Wine.I'd like to test this functionality more in Wine (I've been building from CVS code lately, so currently I'm post-0.9.9). The problem is, some apps will explicitly *check* for the MSIE level installed, and will refuse to install unless they like what they see. So we still need a way to "register" a fake MSIE version. As an example, I was just trying to install H&R Block's _DeductionPro_ that came with TaxCut 2005 (which, BTW, installs & runs fine under Wine, just needing a couple of tweaks. A report on that later). DPro wanted at minimum MSIE 4.0, and didn't see anything that gave it a valid MSIE version. Any suggestions on what many of these apps are looking for in the way of IEversion calls?