December 2005 - Wine-Devel - list.winehq.org

Re: has the LGPL licence fell through ?

by Brian Vincent

> Wine is LGPL as I understand it. Codeweavers takes advantage of that, as do > other companies I imagine (Transgaming?). What's one more company basing a > product on Wine code, provided they follow the license they agreed to when they > received the code? > > Give them a chance is all I am saying... Well, there is such a thing as contributing to the community as opposed to ripping it off. They are perfectly within their rights to work in a bubble or not share any of their ideas with anyone. They can also make simple bugfixes in Wine and not even bother to submit a patch to wine-patches. Heck, they don't even need to send a thank you note. That's not the right thing to do and we all know it. Wine has a track record of being ripped off by companies. Perhaps it's not as bad as other projects, such as Samba, but it's definitely happened. So far SpecOpsLabs have a pathetic track record that only seems to be getting worse. Let's run this down from the beginning: 1. They showed off a product without any explanation that Wine was involved. In fact, at first they completely denied Wine was part of their product: http://www.winehq.com/?issue=220#Project%20David%20? 2. Then Ge van Geldorp discovered that Wine really was part of it: http://www.winehq.com/?issue=222#Project%20David%20Uses%20CodeWeavers%20Cro… 3. That was followed shortly thereafter by Mike McCormack discovering a CrossOver only hack was visible in a screenshot. So they basically ripped off CodeWeavers. SpecOpsLabs never had an explanation for why a CrossOver specific bug some how made it into their tree. In fact, they specifically denied using CXO: http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=14… (Given the choice between believing Mike, who probably knows all of the gory details about that bug, or SpecOpsLabs.. well, I think I'd trust Mike any day of the week. And twice on Sundays.) 4. Then SpecOpsLabs sent one email to wine-devel asking for info on how to contact Alexandre. Honestly, how difficult is it to find Alexandre's email address? How many "Alexandre Julliard's" do you think turn up when you type the name into Google? Several members of the Wine community graciously replied to the email with no response from them. http://www.winehq.com/?issue=241#SpecOps%20Labs%20Steps%20Up Everyone asked for more info so if they planned on contributing that there wouldn't a duplication of effort. All in all, we've graciously asked them to contribute and not gotten a response in return. You know what pisses me off though? They can't even spend five minutes sending a thank you note to wine-devel. By the way, I only wrote this response since I plan on including it in this week's WWN and I figured I'd write it here first rather than editorializing it. Does anyone think it's unduly harsh? Merry Christmas, SpecOps. I hope you enjoy your gift of 1.7 million lines of code. -Brian

Dec. 21, 2005

Re: [lostwages] Remove winetools from download page

by Michael Jung

On Tuesday 20 December 2005 23:23, Vitaliy Margolen wrote: > Thus removing it from the official download page is a wise choice. I'm we > will still get number of users on wine-users and #winehq with winetools > related problems. But at least we will stop spread of "bad habits". I did'nt use winetools for quite a while now, but it was a great tool to get a newbie up and running with wine back then. If it hurts us more than it helps today, then we should take some action. But could we perhaps get in contact with Joachim von Thadden before we remove the link? He has put a lot of effort in winetools and he's a great wine advocate (He wrote a multi page technical article on wine for c't magazine a few months ago, which is one of the big computer publications here in germany. This article was based on winetools, but also did a lot of advertising for CodeWeavers and Wine in general). In my opinion he deserves some respect from our part. We should give him a chance to fix the problems with winetools before we silently remove the link. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Dec. 21, 2005

LockWindowUpdate status?

by Dan Kegel

The last two ISVs I've talked with both had unpleasant flashing while updating rich text boxes. Both call LockWindowUpdate, and one ISV mentioned that he had to do that on Windows to prevent flashing. Poking around a bit, it seems Mike Hearn wrote at patch for this: http://www.winehq.org/hypermail/wine-patches/2004/04/0304.html but it's not yet been applied: http://www.winehq.com/hypermail/wine-devel/2004/07/0483.html What's its current status? Perhaps the time has come. Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 21, 2005

Re: has the LGPL licence fell through ?

by Tim Schmidt

> Trusting perhaps, but not an over-reationist for sure. Has anyone approached > SpecObs Labs and asked for the code? Have they said "no"? This is all just > speculation and hardly worthy of a thread until such comes to pass. For a > company to (fairly) prominantely state on their product web page that they will > release their modified Wine code to the open source community is reassuring. > Innocent until proven guilty is always a nice standard to live by I believe. An > trust me, a small company like SpecOps Lab certainly doesn't want to bring down > the wrath of the open source community down upon it... besides the legal > ramifications, the bad press would be enough to cause the severe problems, if > not force them to shut down (due to lack of customers). > > Wine is LGPL as I understand it. Codeweavers takes advantage of that, as do > other companies I imagine (Transgaming?). What's one more company basing a > product on Wine code, provided they follow the license they agreed to when they > received the code? > > Give them a chance is all I am saying... > ... and no I don't want your stink'in swamp :) The SpecOps folks have been contacted before, search the archives. As for Transgaming, they use a pre-LGPL fork of the Wine code, parts of which they've released under the Aladin Public License, parts under a BSD-like license, parts have never been released. I believe it's quite safe to say that out of the three companies, Codeweavers is the only one to have mutually agreeable relations with the wine project. Skepticism and distrust is not an unfounded reaction under such conditions. --tim

Dec. 21, 2005

Re: has the LGPL licence fell through ?

by Aric Cyr

Tom Wickline <twickline <at> gmail.com> writes: > > On 12/20/05, Aric Cyr <Aric.Cyr <at> gmail.com> wrote: > > > > It sounds like there is hardly an issue here (provided they do as they > > say)... > > move along, nothing to see here. :) > > Your a trusting fellow I see. > > You should look at this swamp land I have for sale, its guaranteed to perc. :D > > Tom Trusting perhaps, but not an over-reationist for sure. Has anyone approached SpecObs Labs and asked for the code? Have they said "no"? This is all just speculation and hardly worthy of a thread until such comes to pass. For a company to (fairly) prominantely state on their product web page that they will release their modified Wine code to the open source community is reassuring. Innocent until proven guilty is always a nice standard to live by I believe. An trust me, a small company like SpecOps Lab certainly doesn't want to bring down the wrath of the open source community down upon it... besides the legal ramifications, the bad press would be enough to cause the severe problems, if not force them to shut down (due to lack of customers). Wine is LGPL as I understand it. Codeweavers takes advantage of that, as do other companies I imagine (Transgaming?). What's one more company basing a product on Wine code, provided they follow the license they agreed to when they received the code? Give them a chance is all I am saying... ... and no I don't want your stink'in swamp :) Regards, Aric

Dec. 21, 2005

Re: has the LGPL licence fell through ?

by Tom Wickline

On 12/20/05, Aric Cyr <Aric.Cyr(a)gmail.com> wrote: > > It sounds like there is hardly an issue here (provided they do as they say)... > move along, nothing to see here. :) Your a trusting fellow I see. You should look at this swamp land I have for sale, its guaranteed to perc. :D Tom > > - Aric > > > >

Dec. 21, 2005

Bug 3885

by Tom Spear

Hi, I was working on bug 3885 tonight, and am stuck now.. Could someone take a look and test a couple of things? I'm running 2.6 series kernel, and it keeps dieing into the debugger before the main window opens. I think that it will sart with builtin msvcrt with 2.4 series kernel, but not 2.6, but since I'm in the middle of another project, I cant reboot to find out. It will at least start under both series for sure with native msvcrt. Louis Lenders removed a trace line from wine and recompiled and it started, even with builtin, which is kinda weird, since he didnt run it with any traces. So it may be a combination of a bug in that trace, and a bug in the 2.6 kernel.. Once running the app, with either builtin or native msvcrt, it goes thru the first benchmark and then spits out an error dialog box when it goes to start the next one, regardless of which benchmarks the app is told to test.. IOW, you can tell it to run #1 and #2, and it will spit out the error before starting #2, and take you back to the main app window. Or you can tell it to run #1 and #3, and same happens, or you can tell it to run #2 and #3, and same happens, so its not something to do with the way wine is handling the benchmark itself. Louis also hard coded D3D_OK into wine in the right spot and managed to get the program to go thru all benchmarks from 1-16, so wine is mis-reporting something there. If someone could take a look and propose a fix, it would be appreciated, seems to me that the 2 fixes should be fairly trivial to come up with since those 1 line hacks worked to get around the aforementioned problems. If we can get it to start on 2.4 and 2.6 with builtin and get it to go all the way to mark 16 before it spits out an error, then that will be another bug closed, and I will file a separate one for mark 16.. Tom

Dec. 21, 2005

Re: has the LGPL licence fell through ?

by Aric Cyr

Troy Rollo <wine <at> troy.rollo.name> writes: > > On Wed, 21 Dec 2005 09:24, Tom Wickline wrote: > > Yes I have read the licence just re read it for that matter... > > So why no patches from SpecOps? > > It is not a requirement that patches be submitted - only that source code be > made available. Patches are normally submitted because it is more convenient > for the developer if the change is in the canonical version. If the developer > does not see the value of having their patch in the canonical tree, they will > not (and are not required to) submit it. > > > should Wine move to GPL to keep from > > being robbed of its code? > > What difference do you expect that to make? > > > If your wondering why I'm ranting : > > http://news.inq7.net/infotech/index.php?index=1&story_id=60585 > > What version of Wine is their stuff based on? The TurboLinux Japanese page simply says they are licensing David from SpecOps Labs and that it is partially based on Wine. Following the link to SpecOpS Labs, I read the fine print at the bottom of this page: http://www.specopslabs.com/projdav-framework.htm It sounds like there is hardly an issue here (provided they do as they say)... move along, nothing to see here. :) - Aric

Dec. 21, 2005

Re: [wined3d] Code questions

by Aric Cyr

Oliver Stieber <oliver_stieber <at> yahoo.co.uk> writes: > Your right the mipmap level should only ever need to be set once, just after > the texture is > created. The problem is that this doesn't seem to work, at least with ATIs > drivers this demo > (http://www.codesampler.com/dx9src/dx9src_3.htm#dx9_texture_filtering) fails, > along with many > games and demos without some weird code. This is one of the two regression > problems that are > preventing d3d8-wined3d wrapper and evict managed resources from being checked > in. > I'd say check it in anyways... if you are worried about breakage on ATI machines, you could always check the gl_vendor and skip the code that causes problems on ATI machines. > Again, I'm fairly sure that there are some things that don't work without > reapplying the states > all the time. The last time I looked at this was just after the last big patch > I put out so I > can't quite remember which demos/games didn't work. I'll test these on my ATI machines and check to see if these work-arounds are still valid/needed. If there are any bugs or issues with ATI's driver, please let me know the details and I'll communicate them to ATI. > I'm just about to start tidying up directx.c, or at least the supported > formats bit of directx.c > and then I was going to tidyup drawprim a bit. What is the expected coding > style, I just coppied > that one that was being used. That would be great. If there is anything you'd like to delegate to me just let me know... maybe I'll start with a clean up of device.c. The only thing that really bothers me, style-wise, is the line length of some of the code. But wine doesn't seem to really have any style guidelines so I guess I'll have to live with this for now. Regards, Aric

Dec. 21, 2005

Re: PATCH: wctime / wasctime

by Robert Shearman

Marcus Meissner wrote: >@@ -88,6 +88,8 @@ > MSVCRT_unexpected_function unexpected_handler; > MSVCRT__se_translator_function se_translator; > EXCEPTION_RECORD *exc_record; >+ MSVCRT_wchar_t *wctime_buffer; /* buffer for ctime */ >+ MSVCRT_wchar_t *wasctime_buffer; /* buffer for asctime */ > }; > You need to free these buffers on thread destruction. -- Rob Shearman

Dec. 21, 2005