First of all, let me say that I am not a developer. But I have been interested in Wine since early 2003. The thing that has always made me scratch my head is that the Windows software that motivates me to install Wine on my linux system (i.e. MS OFfice, etc.) has never worked with wine in a reliable manner. Meanwhile, Codeweaver has always had MS Office working on Wine.
Now shouldn't getting the most common windows software working on Wine in an idiot-proof (meaning I can get it to work) manner be the highest priority for Wine developers? Instead, this is left to CodeWeavers and others.
I know that if you fiddle around with the stock release long enough you can get MS Office working on Wine as I have on a number of occasions, but shouldn't making this work for everyone be the highest priority for getting Wine to be adopted more widely?! Or is Wine more targeted to gamers which is mostly what I read about on WineHQ?
I just can't understand why the more common application are left to a commercial company. My conspiratorial side makes me want to think this is a conspiracy but I am sure there is valid technical and logistical reasons for it so I am asking you guys.
Thanks.
Sasan
Sasan Iman wrote:
I know that if you fiddle around with the stock release long enough you can get MS Office working on Wine as I have on a number of occasions, but shouldn't making this work for everyone be the highest priority for getting Wine to be adopted more widely?! Or is Wine more targeted to gamers which is mostly what I read about on WineHQ?
My guess: Wine is not a product so it's not targeted to anyone. It's a community project developed by volunteers - and the primary priority of those volunteers is to get Wine to run the applications they want to use. Since there are many nice free & libre cross-platform alternatives to the MS office suite there is just not much incentive to get it to run or keep it running. Games OTOH...
Felix
Well a lot of gamers use wine, wine is meant to be a general "run this windows app" program where as Codeweavers, and Cedega work case by case with teams to get specific apps working. If you have a bug, submit it, otherwise add data to bugs in the DB, and eventually it will all work out.
On 3/28/07, Sasan Iman iman@simantis.com wrote:
First of all, let me say that I am not a developer. But I have been interested in Wine since early 2003. The thing that has always made me scratch my head is that the Windows software that motivates me to install Wine on my linux system (i.e. MS OFfice, etc.) has never worked with wine in a reliable manner. Meanwhile, Codeweaver has always had MS Office working on Wine.
Now shouldn't getting the most common windows software working on Wine in an idiot-proof (meaning I can get it to work) manner be the highest priority for Wine developers? Instead, this is left to CodeWeavers and others.
I know that if you fiddle around with the stock release long enough you can get MS Office working on Wine as I have on a number of occasions, but shouldn't making this work for everyone be the highest priority for getting Wine to be adopted more widely?! Or is Wine more targeted to gamers which is mostly what I read about on WineHQ?
I just can't understand why the more common application are left to a commercial company. My conspiratorial side makes me want to think this is a conspiracy but I am sure there is valid technical and logistical reasons for it so I am asking you guys.
Thanks.
Sasan
Hi,
Getting common applications working is NOT the goal of wine. The goal of wine is to write an open source reimplementation of the Win32 api. Those two goals are related, but not exactly the same. The difference is how to deal with hacks that are known to be incorrect but happen to fix an application. Those are not accepted into wine, no matter which application they fix.
CrossOver uses Wine under its hood, and CrossOver's wine tree contains some hacks to make Microsoft Office and other popular applications happy. However, CodeWeavers contributes patches back and employs many major developers to work on various parts of wine, including Alexandre Julliard, Robert Shearman, Jakec Caban, me, and many others.
Neither Wine nor CrossOver are specifically targeted at games or office applications. CrossOver supports some games(like Half-Life 1 and 2, World of Warcraft, Prey), and my job is to work on Wine's Direct3D support.
I won't be able to convice you that the whole thing is not a conspicary because I am a codeweavers employee, but maybe searching the wine changelog for @codeweavers.com can convice you? (Though many codeweavers employees use their own private mail address to send patches).
Regarding the hacks to get Microsoft Office running, the modified Wine source in CrossOver is publically available at http://www.codeweavers.com/products/source . You are welcome to locate the hacks that fix Microsoft Office(I think their authors will kindly assist you with that), clean them up and send them to wine-patches for inclusion. (on a sidenode, a few weeks ago I noticed that some mirror had a broken copy of the archive which did not unpack completely. I think it should be fixed by now. So if the archive doesn't unzip its not conspiracy, it is a fault of the provider of our mirrors)
Hope my explanations answer your questions, Stefan
Sorry to jump into the discussion at this late date, but while I run Wine occasionally for some software I get in my email - no, not viruses, thank goodness! - and some other software that I get with family photo CDs, etc, I haven't done anything with it lately, apart from installing an old Win32 compiler I was given. I still don't know whether it works properly - I know most of lcc-win32 and OpenWatcom work happily :-)
I was wondering, there is Wine, there is CrossOver, and there is Cedega. CrossOver I know contribute their source back, I don't know about Cedega, and I (apparently) can't run both Wine and CrossOver at one and the same time, I can't even install both (apparently - I could be wrong on this ;).
Is there any project to solve the Wine/CrossOver dual installation problem/question? Any for a putative Wine/Cedega dual installation? Any suggestions?
Thanks
Wesley Parish
On Friday 30 March 2007 07:21, Stefan Dösinger wrote:
Hi,
Getting common applications working is NOT the goal of wine. The goal of wine is to write an open source reimplementation of the Win32 api. Those two goals are related, but not exactly the same. The difference is how to deal with hacks that are known to be incorrect but happen to fix an application. Those are not accepted into wine, no matter which application they fix.
CrossOver uses Wine under its hood, and CrossOver's wine tree contains some hacks to make Microsoft Office and other popular applications happy. However, CodeWeavers contributes patches back and employs many major developers to work on various parts of wine, including Alexandre Julliard, Robert Shearman, Jakec Caban, me, and many others.
Neither Wine nor CrossOver are specifically targeted at games or office applications. CrossOver supports some games(like Half-Life 1 and 2, World of Warcraft, Prey), and my job is to work on Wine's Direct3D support.
I won't be able to convice you that the whole thing is not a conspicary because I am a codeweavers employee, but maybe searching the wine changelog for @codeweavers.com can convice you? (Though many codeweavers employees use their own private mail address to send patches).
Regarding the hacks to get Microsoft Office running, the modified Wine source in CrossOver is publically available at http://www.codeweavers.com/products/source . You are welcome to locate the hacks that fix Microsoft Office(I think their authors will kindly assist you with that), clean them up and send them to wine-patches for inclusion. (on a sidenode, a few weeks ago I noticed that some mirror had a broken copy of the archive which did not unpack completely. I think it should be fixed by now. So if the archive doesn't unzip its not conspiracy, it is a fault of the provider of our mirrors)
Hope my explanations answer your questions, Stefan
On Mon, Apr 09, 2007 at 10:06:19PM +1200, Wesley Parish wrote:
I was wondering, there is Wine, there is CrossOver, and there is Cedega. CrossOver I know contribute their source back, I don't know about Cedega
Since wine 0.9 someone with "transgaming" in the author field got 3 patches into wine. They don't publish some of their source and/or part of their published source is not under LGPL or another free software licence (both is legally allowed in that case).
, and I (apparently) can't run both Wine and CrossOver at one and the same time, I can't even install both (apparently - I could be wrong on this ;).
You can install multiple Wine installations, a crossover install and a cedega install on the same machine without problems (though it's some time ago that I verified it for the later two).
Jan
You can install multiple Wine installations, a crossover install and a cedega install on the same machine without problems (though it's some time ago that I verified it for the later two).
Yes, this is supposed to work(CrossOver and Wine at least). But note, that running "wine" on the command line does never run crossover. The main way to run something with Crossover is to install it using the installation wizard, then use the menu entries created to run it. You can also run something manually using ~/cxoffice/bin/wine or /opt/cxoffice/bin/wine, whereever crossover is installed.
I don't know how this works with cedega, but I'd be really surprised if you can't install cedega additionally.
Thanks. I'll try it out first with CrossOver and Wine and some older Windows-based stuff I've got.
Wesley Parish
On Monday 09 April 2007 22:46, Stefan Dösinger wrote:
You can install multiple Wine installations, a crossover install and a cedega install on the same machine without problems (though it's some time ago that I verified it for the later two).
Yes, this is supposed to work(CrossOver and Wine at least). But note, that running "wine" on the command line does never run crossover. The main way to run something with Crossover is to install it using the installation wizard, then use the menu entries created to run it. You can also run something manually using ~/cxoffice/bin/wine or /opt/cxoffice/bin/wine, whereever crossover is installed.
I don't know how this works with cedega, but I'd be really surprised if you can't install cedega additionally.
On 3/28/07, Sasan Iman iman@simantis.com wrote:
I know that if you fiddle around with the stock release long enough you can get MS Office working on Wine as I have on a number of occasions, but shouldn't making this work for everyone be the highest priority for getting Wine to be adopted more widely?! Or is Wine more targeted to gamers which is mostly what I read about on WineHQ?
CodeWeavers isn't Evil. I think everyone involved in Wine would agree with that. There is absolutely no question that without their involvement several core pieces of Wine probably wouldn't exist. For example, MSI, COM, MSHTML, etc. We'd probably still have a good Direct3D implementation though because Stefan is sick like that.
As far as getting Office to work, you and everyone else are more than welcome to work on that. We even have a free graphical regression testing system (cxtest) that CodeWeavers developed that could help you maintain that. Personally, I'd be ecstatic if you'd be willing to work on that.
Finally, I wouldn't exactly say Wine is targeted at gamers any more than anything else.
-Brian
Thank you all for your replies.
First of all, my conspiracy accusation was meant more as a joke than a real belief. Being a hardcore engineer myself, albeit not in your domain, I appreciate the hard work and dedication that goes into these types of projects.
Second, the explanation about running Office requiring special hacks makes a lot of sense so from a technical point of view, I understand the reason for having a side release (through Codeweaver) for running Office.
But third, I must say that even though I agree with your general comments that Wine is not targeted to an application but is meant to be a core implementation, but I think having the top most used windows software working on Wine out of the box will do wonders for its popularity (I have no proof for this other than the fact that I personally don't run wine because I can't run Office and I have tried 6-7 times in the last 3 years every time hoping the new release will do the trick). I don't know how much effort it would take to get Office working on Wine but if getting it to work out-of-the-box means putting it on many more systems (leading to more people getting interested, more mileage leading to more bug reports, more people finding reason to get involved to fix bugs, etc.) then the extra effort may well be worth it. And let me say that Office alternatives on linux are not really a solution at this point. For example, even though OpenOffice is good for writing documents from scratch, documents' look and feel is different in OpenOffice than Word and that just forces me to find a Windows machine every time I need to open a Word document.
I don't really know how many people like me are out there. If I am the only one, then I am wasting your times. But if there are many others like me, then I don't think any of you will argue against the benefits and the priority of having Office work in the stock release. Maybe a good way to approach this is to put up a survey or a poll on WineHQ and ask people if they'd use Wine if software X and Y and Z was running out-of-the-box? That way you'd also find out how many non-technical people are following Wine to solve their computing needs.
Thanks again for your hard works. I've been cheering you guys on for a few years and will continue to do so.
Sasan
Brian Vincent wrote:
On 3/28/07, Sasan Iman iman@simantis.com wrote:
I know that if you fiddle around with the stock release long enough you can get MS Office working on Wine as I have on a number of occasions, but shouldn't making this work for everyone be the highest priority for getting Wine to be adopted more widely?! Or is Wine more targeted to gamers which is mostly what I read about on WineHQ?
CodeWeavers isn't Evil. I think everyone involved in Wine would agree with that. There is absolutely no question that without their involvement several core pieces of Wine probably wouldn't exist. For example, MSI, COM, MSHTML, etc. We'd probably still have a good Direct3D implementation though because Stefan is sick like that.
As far as getting Office to work, you and everyone else are more than welcome to work on that. We even have a free graphical regression testing system (cxtest) that CodeWeavers developed that could help you maintain that. Personally, I'd be ecstatic if you'd be willing to work on that.
Finally, I wouldn't exactly say Wine is targeted at gamers any more than anything else.
-Brian
I agree that wine should be able to run office out of the box, but I also agree with most of the developers' goals, which is to rewrite the windows api (that is my interpretation, and slimmed down at that). It is unfortunate that office doesn't work, but in order to make sure the api is clean and we replicate windows, bugs and all, we can't have hacks in the main source tree. Having more people get involved is always worth it, and ideas such as yours are not a waste of the developers' time. Unfortunately linux adoption has not become widespread enough for most people simply because the driver support for all the little gismos and gadgets is not there, and it doesnt just work, which is what most people want, and so without the LUB incerasing, the WUB will not increase.
Tom
On 3/29/07, Sasan Iman iman@simantis.com wrote:
Thank you all for your replies.
First of all, my conspiracy accusation was meant more as a joke than a real belief. Being a hardcore engineer myself, albeit not in your domain, I appreciate the hard work and dedication that goes into these types of projects.
Second, the explanation about running Office requiring special hacks makes a lot of sense so from a technical point of view, I understand the reason for having a side release (through Codeweaver) for running Office.
But third, I must say that even though I agree with your general comments that Wine is not targeted to an application but is meant to be a core implementation, but I think having the top most used windows software working on Wine out of the box will do wonders for its popularity (I have no proof for this other than the fact that I personally don't run wine because I can't run Office and I have tried 6-7 times in the last 3 years every time hoping the new release will do the trick). I don't know how much effort it would take to get Office working on Wine but if getting it to work out-of-the-box means putting it on many more systems (leading to more people getting interested, more mileage leading to more bug reports, more people finding reason to get involved to fix bugs, etc.) then the extra effort may well be worth it. And let me say that Office alternatives on linux are not really a solution at this point. For example, even though OpenOffice is good for writing documents from scratch, documents' look and feel is different in OpenOffice than Word and that just forces me to find a Windows machine every time I need to open a Word document.
I don't really know how many people like me are out there. If I am the only one, then I am wasting your times. But if there are many others like me, then I don't think any of you will argue against the benefits and the priority of having Office work in the stock release. Maybe a good way to approach this is to put up a survey or a poll on WineHQ and ask people if they'd use Wine if software X and Y and Z was running out-of-the-box? That way you'd also find out how many non-technical people are following Wine to solve their computing needs.
Thanks again for your hard works. I've been cheering you guys on for a few years and will continue to do so.
Sasan
Brian Vincent wrote:
On 3/28/07, Sasan Iman iman@simantis.com wrote:
I know that if you fiddle around with the stock release long enough you can get MS Office working on Wine as I have on a number of occasions, but shouldn't making this work for everyone be the highest priority for getting Wine to be adopted more widely?! Or is Wine more targeted to gamers which is mostly what I read about on WineHQ?
CodeWeavers isn't Evil. I think everyone involved in Wine would agree with that. There is absolutely no question that without their involvement several core pieces of Wine probably wouldn't exist. For example, MSI, COM, MSHTML, etc. We'd probably still have a good Direct3D implementation though because Stefan is sick like that.
As far as getting Office to work, you and everyone else are more than welcome to work on that. We even have a free graphical regression testing system (cxtest) that CodeWeavers developed that could help you maintain that. Personally, I'd be ecstatic if you'd be willing to work on that.
Finally, I wouldn't exactly say Wine is targeted at gamers any more than anything else.
-Brian
On Thu, Mar 29, 2007 at 03:17:35PM -0700, Sasan Iman wrote:
I don't know how much effort it would take to get Office working on Wine but if getting it to work out-of-the-box means putting it on many more systems (leading to more people getting interested, more mileage leading to more bug reports, more people finding reason to get involved to fix bugs, etc.) then the extra effort may well be worth it.
I think the applications that would give Wine the most popularity are the current long term top games. I don't have any need for MS Office at all. It differs from person to person what they think is most needed in wine. And that is fine, because fixing wine properly for one application doesn't prevent fixing it properly for another one and one fix often helps many applications.
If someone has the money to pay for MS Office, they certainly have the (comparably) peanuts to pay for CrossOver. Paying CX means paying someone to make wine better. Why wouldn't they want to do this?
If many people are interested in getting MS Office to run on wine (in a turn key way or even only in a follow a how-to way) surely one of them is willing to work on it, right? With an application that already runs on CrossOver it's even something that doesn't need too much work as all the hard things were already done by CX. If anyone needs help on how to work on wine, I'll be happy to help anyone help wine (best done on IRC).
How good an application is supported by the wine community obviously depends on how much work people put into it. You can see that there is a difference by e.g. comparing the appdb entries of World of Warcraft and MS Office. WoW has since some time details on the appdb on how to make it run in wine. There are none for MS Office and there aren't even detailed bug reports (on those versions I looked at). Working to get an application in wine running usually also has the benefit that sometimes people help achieving that, who don't have any specific interest in that application.
So I expect you to follow up on what you said and scratch your personal wine itch. Free software is about sharing work. In the sense that when we put our effort together we get something that is more than what we would have when we didn't share. This can also mean paying someone to do the work for you.
Jan
Sasan
...but I think having the top most used windows software working on Wine out of the box will do wonders for its popularity
Is popularity a desirable goal?
Will increasing the number of users result in a benefit for the Wine project?
nick
************************************************************ Opinions contained in this e-mail do not necessarily reflect the opinions of the Queensland Department of Main Roads, Queensland Transport or Maritime Safety Queensland, or endorsed organisations utilising the same infrastructure. If you have received this electronic mail message in error, please immediately notify the sender and delete the message from your computer. ************************************************************
On Mon, 2007-04-02 at 09:59 +1000, nicholas.g.lawrence@mainroads.qld.gov.au wrote:
Sasan
...but I think having the top most used windows software working on Wine out of the box will do wonders for its popularity
Is popularity a desirable goal?
Will increasing the number of users result in a benefit for the Wine project?
nick
Yes. Wine's development speed has roughly correlated with its user base; popularity brings more bug reports, volunteers, and funding for paid work.
Thanks, Scott Ritchie
Scott Ritchie wrote:
On Mon, 2007-04-02 at 09:59 +1000, nicholas.g.lawrence@mainroads.qld.gov.au wrote:
Sasan ...but I think having the top most used windows software working on Wine out of the box will do wonders for its popularity
Is popularity a desirable goal?
Will increasing the number of users result in a benefit for the Wine project?
nick
Yes. Wine's development speed has roughly correlated with its user base; popularity brings more bug reports, volunteers, and funding for paid work.
Thanks, Scott Ritchie
I whole heartedly agree. If it were not for "dirty little hacks" Crossover Linux would not run some of the very programs that make it so popular. Popularity with users is the driving force for developers. Developers go where the users are and I know there are enough bug reports in bugzilla to keep all the developers we can handle busy. I am not saying that we should put in just any old hack but there are cases where we really miss the boat because we want to get things "right".
Take for example bug 6413: http://bugs.winehq.org/show_bug.cgi?id=6413 This is just one case of a generic problem where a program provides it own version of a DLL but wine does not use it. There have been quite a number of bugs with this same problem. In most of these bug reports (all?) it has been that our implementation needed to be fixed to match what native provides. I am not sure that this is the case here but I think that is beside the point.
From past experimentation I have seen that windows will not use its own version
of a DLL if it finds one int the same directory as the program so why do we not do the same?
Yes, we would not get that particular bug report but we may have lost many more users because of the same problem. If we want to have the best of both worlds we could have a message box pop up saying that wine found a program supplied DLL and if you use it, you could be covering up a bug in our implementation of that DLL and let the user decide. Some users will try out our built in and make a bug report and that bug report will be easier to deal with that trying to track down which DLL overrides might work.
--
Tony Lambregts
On Saturday 07 April 2007 23:52, Tony Lambregts wrote:
Scott Ritchie wrote:
Yes. Wine's development speed has roughly correlated with its user base; popularity brings more bug reports, volunteers, and funding for paid work.
[...]
I whole heartedly agree. If it were not for "dirty little hacks" Crossover Linux would not run some of the very programs that make it so popular. Popularity with users is the driving force for developers. Developers go where the users are and I know there are enough bug reports in bugzilla to keep all the developers we can handle busy. I am not saying that we should put in just any old hack but there are cases where we really miss the boat because we want to get things "right".
What boat? I'm not selling a product. I don't need to meet any deadline. Unless Google pays me, I do my Wine development in my spare time. I've spent my last two years working on a feature that about a handful apps out there will use. There is one bug report in bugzilla for my stuff, and that's actually invalid. If I spent my time waiting for users to get interested in this area, Wine still wouldn't do NTLM.
[Some talk about a msvcrt bug]
Yes, we would not get that particular bug report but we may have lost many more users because of the same problem. If we want to have the best of both worlds we could have a message box pop up saying that wine found a program supplied DLL and if you use it, you could be covering up a bug in our implementation of that DLL and let the user decide. Some users will try out our built in and make a bug report and that bug report will be easier to deal with that trying to track down which DLL overrides might work.
Most users will figure out that clicking "use the override" will make less problems than the other button. I'm not sure that'll lead to easier bug reports.
Cheers, Kai
Kai Blin wrote:
On Saturday 07 April 2007 23:52, Tony Lambregts wrote:
Scott Ritchie wrote:
Yes. Wine's development speed has roughly correlated with its user base; popularity brings more bug reports, volunteers, and funding for paid work.
[...]
I whole heartedly agree. If it were not for "dirty little hacks" Crossover Linux would not run some of the very programs that make it so popular. Popularity with users is the driving force for developers. Developers go where the users are and I know there are enough bug reports in bugzilla to keep all the developers we can handle busy. I am not saying that we should put in just any old hack but there are cases where we really miss the boat because we want to get things "right".
What boat? I'm not selling a product. I don't need to meet any deadline. Unless Google pays me,
We (The Wine project) produce a product and we have a deadline even if you do not acknowledge it. It occurs every time we cannot run a program when a potential user really needs it.
I do my Wine development in my spare time.
So do I, In fact so do a lot of people. Welcome to the club.
I've spent my last two years working on a feature that about a handful apps out there will use. There is one bug report in bugzilla for my stuff, and that's actually invalid. If I spent my time waiting for users to get interested in this area, Wine still wouldn't do NTLM.
Your right about NTLM not being used much and that is part of the reason for not having many bug report against it, Another part of it is that if a program uses NTLM but it does not install or crashes before requiring any authentication you will not see a bug report until the previous bug is fixed (or worked around).
I'm really curious as to what DOES motivate you to work on NTLM if you don't care about users using it.
Regardless of the previous statements there are plenty of other bug reports out there that you could work on if that do not involve NTLM. Please don't misunderstand me I'm not saying you that you should. What you do with your free time is up to you. The point I was making is that there are lots of unresolved bug reports to keep developers busy on if they are looking for something to do.
[Some talk about a msvcrt bug]
Yes, we would not get that particular bug report but we may have lost many more users because of the same problem. If we want to have the best of both worlds we could have a message box pop up saying that wine found a program supplied DLL and if you use it, you could be covering up a bug in our implementation of that DLL and let the user decide. Some users will try out our built in and make a bug report and that bug report will be easier to deal with that trying to track down which DLL overrides might work.
Most users will figure out that clicking "use the override" will make less problems than the other button. I'm not sure that'll lead to easier bug reports.
It will be easier because the user can identify what dll he had to put to native because we tell him. That assumes that he wants to help the wine project, as opposed to just getting the program to run.
The way it is right now the program may fail, and if the user is like most users, that would be the end of it. No debugging, just Wine failed to run the program and a bad user experience.
Now it is possible that this user really wants to get this program to run and he goes onto the wine users list and asks for some help. So hopefully someone tells him to try dll overrides and it works and that's great but it does not guarantee he will make a bug report.
In fact this can lead to the situation where the user gets into the habit of always copying in as many native DLLs as he can and always overriding to native which is why we hate WineTools.
The way I see it we really nothing to loose on this.
--
Tony Lambregts
On Sunday 08 April 2007 08:51, Tony Lambregts wrote:
What boat? I'm not selling a product. I don't need to meet any deadline. Unless Google pays me,
We (The Wine project) produce a product and we have a deadline even if you do not acknowledge it. It occurs every time we cannot run a program when a potential user really needs it.
Ok, it's not what I'd call a deadline. It's more like a dead vague area. But with your definition, I can agree that we have something like that.
I do my Wine development in my spare time.
So do I, In fact so do a lot of people. Welcome to the club.
Yes, I just wanted to point out that I have two modes when working on Wine. One is in my spare time, and one is when I'm paid to work on it.
I've spent my last two years working on a feature that about a handful apps out there will use. There is one bug report in bugzilla for my stuff, and that's actually invalid. If I spent my time waiting for users to get interested in this area, Wine still wouldn't do NTLM.
Your right about NTLM not being used much and that is part of the reason for not having many bug report against it, Another part of it is that if a program uses NTLM but it does not install or crashes before requiring any authentication you will not see a bug report until the previous bug is fixed (or worked around).
It's a rather obscure area. I know five programs using secur32.dll. One of them is free, the others don't even have a free demo.
I'm really curious as to what DOES motivate you to work on NTLM if you don't care about users using it.
Well, I admit I wouldn't have started in that area if it wasn't the most interesting project I found for GSoC 2005. I had never even heard of that API before doing the research for that project. Now that I have started it, I of course want to see it working.
Regardless of the previous statements there are plenty of other bug reports out there that you could work on if that do not involve NTLM. Please don't misunderstand me I'm not saying you that you should. What you do with your free time is up to you. The point I was making is that there are lots of unresolved bug reports to keep developers busy on if they are looking for something to do.
Granted. I've been doing that when I had some spare time. Working on winsock bugs, I can tell that about one in ten bug reports is detailed enough (after requesting more information) to actually nail down a bug. For the nine other bug reports, you can spend a lot of time searching the bug, so yes, enough to keep you busy.
Most users will figure out that clicking "use the override" will make less problems than the other button. I'm not sure that'll lead to easier bug reports.
[...]
In fact this can lead to the situation where the user gets into the habit of always copying in as many native DLLs as he can and always overriding to native which is why we hate WineTools.
And how exactly is automatically using native dlls if found in the application's directory going to help? Won't people get into the habit of putting as many native dlls as possible into the application's working directory as well?
I agree we probably won't loose much, but I'm not sure what we're going to win, apart from easier dll overrides.
Cheers, Kai
Kai Blin wrote:
Granted. I've been doing that when I had some spare time. Working on winsock bugs, I can tell that about one in ten bug reports is detailed enough (after requesting more information) to actually nail down a bug. For the nine other bug reports, you can spend a lot of time searching the bug, so yes, enough to keep you busy.
We agree that Lousy bug reports are abundant
Most users will figure out that clicking "use the override" will make less problems than the other button. I'm not sure that'll lead to easier bug reports.
[...]
In fact this can lead to the situation where the user gets into the habit of always copying in as many native DLLs as he can and always overriding to native which is why we hate WineTools.
And how exactly is automatically using native dlls if found in the application's directory going to help? Won't people get into the habit of putting as many native dlls as possible into the application's working directory as well?
I doubt that, if they were to do that they are still more likely to go the route of putting them in the system directory and doing a global override because its easier.
I agree we probably won't loose much, but I'm not sure what we're going to win, apart from easier dll overrides.
1. Fewer lousy bug reports because when the bug is reported it will be more concise.
2. More applications working out of the box.
--
Tony Lambregts
I doubt that, if they were to do that they are still more likely to go the route of putting them in the system directory and doing a global override because its easier.
I agree we probably won't loose much, but I'm not sure what we're going to win, apart from easier dll overrides.
- Fewer lousy bug reports because when the bug is reported it will be
more concise.
Reports of problems with a whole load of binary blobs loaded. Native DLLs CAN help, but do not have to. Like native DCOM. It sometimes helps, but it can also do undocumented and unimplemented operations.
Often native dlls instead of builtin ones cause problems.
Stefan Dösinger wrote:
I doubt that, if they were to do that they are still more likely to go the route of putting them in the system directory and doing a global override because its easier.
I agree we probably won't loose much, but I'm not sure what we're going to win, apart from easier dll overrides.
- Fewer lousy bug reports because when the bug is reported it will be
more concise.
Reports of problems with a whole load of binary blobs loaded. Native DLLs CAN help, but do not have to. Like native DCOM. It sometimes helps, but it can also do undocumented and unimplemented operations.
Often native dlls instead of builtin ones cause problems.
How can knowing off the bat which dlls are overridden be a problem. I would rather see a bug report that says this "program works when I override commctrl.dll but not with built in" than "This program does not work please help". Of course we can have problems with mixing native versions with built in but we can get that now anyway. The most often situation is that these programs have a single dll that would be used instead of built in.
--
Tony Lambregts
-
Brian Vincent -
Bryan Haskins -
Felix Nawothnig -
Jan Zerebecki -
Kai Blin -
nicholas.g.lawrence＠mainroads.qld.gov.au -
Sasan Iman -
Scott Ritchie -
Stefan Dösinger -
Tom Spear -
Tony Lambregts -
Wesley Parish