September 2003 - Wine-Devel

Re: wine & ccache

by Dimitrie O. Paun

On September 30, 2003 08:16 am, Mike Hearn wrote: > Maybe oneday it would be worth porting the Wine build system to SCons > (http://www.scons.org/) From "What makes SCons better": Whenever I look at make replacements, I always find them more cluttered/verbose/uglier, but this may be because I'm so used to make. Do you have a real-life example of a scons file (non-trivial) just to see how it looks like? -- Dimi.

Sept. 30, 2003

Re: Question about WineX licences

by Dimitrie O. Paun

On September 30, 2003 09:16 am, Ove Kaaven wrote: > Now the LGPL-ness of Wine > actually makes it an advantage to hold code back from Wine in some > circumstances, whether you and I like it or not. Your argument is valid right now because there was not attempt to abstract the copy protection through some kind of interface. We've had this discussion before, and Alexandre was willing to accommodate such hooks, but the argument was put forward that this is not possible. I simply do not believe you can't abstract it, anything can be. One reason why you may not want to is that you may be afraid that if people see the interface, they will figure out how to write their own copy-protection code. But this is a business, rather then a technical or legal reason... So yeah, you may be giving something up, but you get to use a lot more Wine code. This may not be so important to you right now, but it does look like the way to go (long term, at least). It would make it way simpler for TG, it will clarify a messy situation (with so many diverging licenses), and it will bring the community closer together. I think it would be so nice to be able to say: WineX is Wine + our proprietary Direct X work + copy-protection. Even if people figure out the copy-protection, I'm sure you will not lose a single customer, you provide enough value through your Direct X work. -- Dimi.

Sept. 30, 2003

Re: uxtheme.dll

by Dimitrie O. Paun

On September 30, 2003 10:57 am, Roderick Colenbrander wrote: > Microsoft releases two sets of > comctl32 dlls. One of them is meant for backwards compatibility. Do you have any idea why would that be needed? -- Dimi.

Sept. 30, 2003

Re: uxtheme.dll

by Roderick Colenbrander

Ofcourse I want uxtheme.dll implemented since it is a very cool new dll but I think a problem will be that it needs changes in various parts of Wine. Mainly in the user and common control area. Microsoft releases two sets of comctl32 dlls. One of them is meant for backwards compatibility. Because of this I think Wine will need two dlls and it might be needed to maintain two dlls. :( Because of all this I said that it might be something for after Wine 1.0. This dll could later be reused for theming Wine and that atleast was something we planned to do behind 1.0, right? Roderick On Tuesday 30 September 2003 10:25, Shachar Shemesh wrote: > Roderick Colenbrander wrote: > >I hope you know what you will begin with. (For the ones that don't know > >uxtheme.dll is the dll that takes care of all theming on WinXP and it is > > the dll that dlls like comctl32 and all others use for theming) > > > >Some time ago I checked out uxtheme.dll a bit and it seems that it needs > >changes all over Wine. As I understand it WinXP ships with two sets of > >comctl32.dll and friends. One is the "old" version and one is a new > > uxtheme aware version. The uxtheme aware version contains lots of changes > > and uses uxtheme for theming. To use uxtheme you need to add uxtheme > > support to the dlls that need it which looks like a huge job. > > It does. > > > Perhaps this is something post Wine-1.0? > > Why? This seems liks something that can be done incrementally. Kevin is > interested in doing it. Is there any reason to wait? Kevin should be > aware of what he's getting himself into, of course, but otherwise it's > his call. That's what free software development is all about. > > >Roderick Colenbrander > > Shachar

Sept. 30, 2003

Re: Wineconf 2004, otherwise known as...

by Dmitry Timoshkov

"Mike Hearn" <mike(a)theoretic.com> wrote: > > Well, "the Russian Winter" is a common exaggeration, like > > a stray bear in every russian town, a hidden communist in > > each russian, and many others :-) > > I notice vodka isn't in that list of common exaggerations - party on! :) It's included in the list of "many others" :-) But, well, that's just a beverage which helps to survive a russian winter :-) -- Dmitry.

Sept. 30, 2003

Re: wine & ccache

by Jakob Eriksson

On Tue, Sep 30, 2003 at 01:16:17PM +0100, Mike Hearn wrote: > On Tue, 2003-09-30 at 01:40, Alexandre Julliard wrote: > > One problem is that most makefiles specify different defines, so you > > basically need to have one different rule for each C file. Then there > > are many files that have explicit rules. It could be done, but I don't > > think it's worth it, and the result would be really messy and hard to > > maintain. > > Maybe oneday it would be worth porting the Wine build system to SCons > (http://www.scons.org/) From "What makes SCons better": Woot! I was about to plug "cook" from Aegis fame, but I thought nobody likes advocacy. But if it is plugging time, "cook" is wonderful. :-) The author of "recursive make considered harmful" also authored cook. Aegis is what I use for http://vmlinux.org/jakov/Wine/ . Sure scons looks really nice too, with its support for Windows project files. -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News

Sept. 30, 2003

Re: Question about WineX licences

by Ove Kaaven

tir, 30.09.2003 kl. 09.39 skrev Jonathan Wilson: > > Everything that's LGPL should be listed on the above page. Additionally, > > code in ReWind is X11. Anything else in WineX may be assumed AFPL, but > > may also be released as X11 at TransGaming's discretion. I think most > > non-DirectX code (and even a limited subset of the DirectX code) could > > be released as X11 on request, although that's up to Gav. > To me it makes sense for TransGaming to give back everything except DirectX > since the focus of WineX is gaming and its the DirectX code and the copy > protection support that is the bits that are making transgaming the money. Perhaps. That is also what would happen if Wine was still under the X11 license, but the world isn't that simple. Now the LGPL-ness of Wine actually makes it an advantage to hold code back from Wine in some circumstances, whether you and I like it or not. For the core WineX for Linux product, this is because 1) things like the copy protection support patches have to be kept secret, therefore any code it touches can't be LGPL 2) the copy protection support affects a lot of the code - it even affects the way WineX DLLs are built - therefore it's an advantage to have as many DLLs as possible non-LGPL to allow those DLLs to be copy-protection-compatible 3) therefore, it's an advantage to use as little LGPL code as possible, and keep the number of LGPL-ed DLLs to the minimum 4) therefore, since Wine is LGPL, any Wine progress usually can't be shared by WineX, but Wine progress does make Wine a competitor, and therefore it is a disadvantage for TransGaming to help Wine progress So the fact that TransGaming still does it sometimes should be taken as good will, not as "too little", "they don't get it, that's not how OSS works", or "they're sinister and evil". TransGaming also does Mac ports on contract from game companies, and there the issues may be a little less obvious, but there are certain extra issues with the LGPL there, too. Perhaps issues CodeWeavers tried to avoid by LGPL-ing Wine, but for game companies, saying something to the effect of "no we can't add your non-free copy/hacking-protection and code encryption layer because Wine is LGPL" would probably mean no contract in 100% of the cases. This is not the exact issue, but I don't think I can discuss the specifics. > One advantage is that then TransGaming could move more of the "support > dlls" (things like ole32, oleaut32 & so on) up to the latest WINE LGPL code > (since they would no longer have any custom modifications to those dlls) > and both base WINE and WineX would get better as a consequence. That's not exactly how LGPL works. The LGPL requires not only the source and changes to it to be available, it also pretty much requires this source to be able to be compiled by the user as a drop-in replacement, basically. This is not possible if the build system is secret, as is the case with the copy protection support applied. Again, this explanation is admittedly vague, but I can't discuss the specifics. > OTOH, there may be valid reasons for TransGaming not to licence things like > OLE/COM improvements back as X11 or LPGL. The OLE/COM improvements have already all been licensed to Wine (they're also under the X11), they just haven't been merged in. Mike Hearn was on it last I heard, since I've turned out not to have the time to adapt it for Wine.

Sept. 30, 2003

Re: winealsa: improve sound quality for IDsDriverImpl

by Mike Hearn

On Tue, 2003-09-30 at 07:43, Jerry Jenkins wrote: > But the test is really a time-cost task. I won't merge it into WINEALSA if I > can't improve it. > > Does anyone have any suggestions? Well I for one am a bit confused. The reason it needs to be a runtime check is so we can compile Wine on one machine then run it on a totally different one, and Wine figures out what it can and cannot do on the fly. If we are altering its behaviour according to the capabilities of the compiling machine then this is very bad indeed.

Sept. 30, 2003

Re: Question about WineX licences

by Mike Hearn

On Tue, 2003-09-30 at 08:39, Jonathan Wilson wrote: > OTOH, there may be valid reasons for TransGaming not to licence things like > OLE/COM improvements back as X11 or LPGL. In fact the OLE/DCOM work Ove did has been licensed back to ReWind under the X11 license, and I have a partial merge sitting on my hard disk. It worked well enough for the app I ported while at QinetiQ which did some rather advanced things with COM, but is not of merge quality yet. Doing a proper merge though is really not that easy, in particular Ove and Marcus have duplicated quite a bit of work, and figuring out the correct "seams" to merge along is tricky. At some point I need to make it build again, and send in a big patch like Ove did for me, so that if somebody else feels like doing a better job they can do.

Sept. 30, 2003

Re: uxtheme.dll

by Mike Hearn

On Tue, 2003-09-30 at 04:43, Sylvain Petreolle wrote: > This isnt a windows system dll. Isnt that another attempt like > cards.dll ? Sure it is. Apps attempt to LoadLibrary it if they detect it to enhance their drawing capabilities. It's conceivable that one day apps will not have this backwards compat code and simply require Windows XP or above, so it needs to get done. It's also the Right Way to make Wine not look like ass on our pretty desktops, because the win32 apps will be theme aware.

Sept. 30, 2003