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

Poser label issue [Bug 2737]

by Vikram Kumar

Hi, I've been looking into Bug 2737 http://bugs.winehq.org/show_bug.cgi?id=2737 and kind of lost on where to go next. Testing on both Poser5 English and Poser6 Japanese versions, The labels (text) on the ui don't show up. As far as the rest of the app goes, Poser 5 seems to be working okay excpet for some redraw issues, so if the lables show up correctly, the app should be quite useable. Anyway, looking at the trace, it looks like it uses DrawTextEx to draw the lables, does something with regions which I can't quite figure out, and renders the ui. The issue seems to be that the label somewhere along the line becomes a 1bit DIB which seems to be wrong. x11drv/dib gives a warning saying: warn:bitmap:X11DRV_DIB_GetImageBits_1 from unknown 1 bit bitmap (ff0000,ff00,ff) to 1 bit DIB, direct color mapping What I tried was to force a negative image on x11drv/dib.c by changing line 901 to: -BYTE neg = 0; +BYTE neg = 1; The attached image shows the result. The black rectangles are where the labels are supposed to be (This is the Poser6 Japanese's register your name & serial number etc dialog) It looks like the DIB is all white (thus the blackness when negating). If I use the non-negated image, this part becomes the same color as the background(transparent?) What the lables are supposed to look like can be found here: http://bugs.winehq.org/attachment.cgi?id=768&action=view and how wine does it is: http://bugs.winehq.org/attachment.cgi?id=767&action=view I'm kind of stuck at this point, not knowing exactly what to do next. I'd aprreciate any help, since it will be nice to have this running. Poser6 demo is available here: http://downloads.e-frontier.com/us/user/product.php?productid=12045&cat=134… Also attached is a trace of WINEDEBUG="+font,+text,+gdi,+bitmap,+seh" wine PoserJ.exe Cheers, Vik

Dec. 21, 2005

Re: PATCH/RFC: defer OLE apartment window creation

by Marcus Meissner

On Wed, Dec 21, 2005 at 02:55:14AM +0000, Robert Shearman wrote: > Marcus Meissner wrote: > > >@@ -257,6 +254,15 @@ > > return apt; > >} > > > >+void make_apartment_window(APARTMENT *apt) { > >+ if (apt->win) return; > >+ if (!(apt->model & COINIT_APARTMENTTHREADED)) > >+ return; > >+ apt->win = CreateWindowW(wszAptWinClass, NULL, 0, > >+ 0, 0, 0, 0, > >+ 0, 0, OLE32_hInstance, NULL); > >+} > >+ > > > > This isn't thread-safe. It would also be better to make this an accessor > function for the win field of struct apartment and fix up all callers to > use this. I still have to verify on Windows whether this is what it does > or whether it does something funny with message loops. I lack the time and testing abilities to do this right now (and now on xmas break). Its just a quick hack to get Google Earth running. It is now up to showing the famous GL "black screen". :( (WINEDLLOVERRIDES=*usp10=n) Ciao, Marcus

Dec. 21, 2005

Re: sound enabled but no driver checked

by Cihan Altinay

Robert Reif wrote: > Cihan Altinay wrote: > >> Quoting Robert Reif <reif(a)earthlink.net>: >> >> >> >>> Cihan Altinay wrote: >>> >>> >>> >>>> With a fresh wine prefix sound is enabled but I can't >>>> see which driver is used because none of them is checked >>>> in the new winecfg sound dialog. >>>> Did we forget to initialize the boxes on first run? >>>> >>>> Cheers, >>>> Cihan >>>> >>>> >>> >>> Use regedit to show HKCU/Software/wine/Drivers/Audio. >>> Chances are it's empty (no drivers checked) so sound is >>> disabled. It could be set to a driver that is not available >>> but winecfg checks for that and should give you an error. >>> >> >> >> Well... the key doesn't exist unless I run winecfg at least once >> and change something. In that case it's not really important because >> a user will probably do that anyway. >> The only minor issue would be that someone runs winecfg for the first >> time and is satisfied with the defaults (no driver checked -> sound off) >> so without any changes he dismisses winecfg. And in this case it seems >> one of the drivers is used by default (sound on). >> >> Cheers, >> Cihan >> >> >> >> > I have a patch to fix this. OSS is the default if there is no registry > key. Great! Will you submit it?

Dec. 21, 2005

Re: [lostwages] Remove winetools from download page

by Tom Wickline

On 12/21/05, Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote: > > 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. I am in agreement with the above paragraph.. Cheers, Tom > > Bye, > -- > Michael Jung > mjung(a)iss.tu-darmstadt.de > >

Dec. 21, 2005

Re: has the LGPL licence fell through ?

by Andreas Mohr

Hi, On Wed, Dec 21, 2005 at 07:48:09AM +0000, Aric Cyr wrote: > Seeing that SpecOps Labs history of ignoring Wine developers extends for more > than a year, then yes I can agree with that. Yup, there has been more silence than anything else. > According to their Partners' page, IBM and Turbolinux and a few others seem to > be footing the bill. I'm sure a well written email to either of those places > would get a real response, and probably apply due pressure on SpecOps Labs. Oh, now that's "interesting". Especially given that IBM's usual stance about Wine is often said to be... umm... let's say "mildly sceptical". But since the "Partners" text already mentions that it is an IBM Philippines cooperation, this seems to imply that the corporation's left hand doesn't know what the right hand is doing (yet! this might change in the future... Hello SpecOpsLabs!). Oh well... Andreas Mohr

Dec. 21, 2005

Re: has the LGPL licence fell through ? (forw)

by Aric Cyr

Joerg Mayer <jmayer <at> loplof.de> writes: > On Wed, Dec 21, 2005 at 07:48:09AM +0000, Aric Cyr wrote: > > Maybe I'll fire off an email to Turbolinux to see what they have to say, > > although technically unless I purchase or receive their product I am not > > directly entitled to the GPL/LGPL code from them. Anyone have a copy of > > Can you please let me know why you think that? > > ---------------------------- > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > ... > ------------------------------- You are reading this from the wrong point of view I believe. The "You" in this case would be SpecOps Labs. They implicitly agree to this LGPL license by modifying hte copyrighted code. > > So I guess if they are using some code of yours that you provided to them under > LGPL, you are entiteld to request the source. In case this goes to court you'll > need a copy, but for now it is sufficient to be sure that they are distributing > a product based on your code which is covered by the LGPL. Anyone who buys their product, or anyone they give their product to is entitled to the source code. >From LGPL section 4 (remember, "You" = SpecOps Labs): 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. > Again: It is *you* who granted them the right to use your code, and by putting > it under LGPL you made sure that you are entitled to any changes they make to > *the* code once they start distributing your code (or derivatives) to thrid > parties. That way you can reqeust the changes even when the new product costs $10M. No,that's not the way GPL or LGPL works I'm afraid. These licenses exist so that the users of the applications, etc will always have free access to the source code, and the free rights to redistribute it as necessary. Their purpose is free speech not free beer. As Brian said, they are perfectly in their right upto now (as long as there are no products with Wine code floating around), it's just that they are really sticking it to the the community and not playing nice. It is (current) philisophical, not legal. When someone gets a copy of David, and SpecOps Labs refuses to disseminate the code, then it will become legal. - Aric

Dec. 21, 2005

New trying to debug missing menubar

by Joseph Garvin

There's an old Windows 3.1 app I'm trying to use under wine, but it's menubar is missing. It was used for in house development for a really old game, but the programmer has asked me not to redistribute it so I can't provide a link/download. The application otherwise looks and acts exactly as it should -- but the File/About/etc. menubar is missing and thus the ability to use any of those options (I don't think the app has any accelerators). Seeing as this is such a "simple" bug (watch me eat my words) I thought it'd be a good chance to try some wine hacking. So I read the wine developer guide and tried my best. But my unfamiliarity with the Windows API / Wine has me stuck :P I've included the results of me running with WINEDEBUG=+menu below. The only thing that sticks out to me is this: warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 Which occurs multiple times. Looking at dlls/user/menu.c (function starts on line 101), it looks like USER_HEAP_LIN_ADDR is returning a 0 pointer which causes the warning. Someone in #winehq said USER_HEAP_LIN_ADDR is for 16<->32 bit conversion because 16bit apps use segment:offset to address memory (I'm still not totally sure how a segment differs from a memory address) while 32bit apps use flat addresses. USER_HEAP_LIN_ADDR itself looks like a very magical macro where to look based on it. strings informs me it's a Borland C++ 1991 app, if that's important. When I did a +relay all that showed up between the warn:menu's was calls to ENABLEMENUITEM. Hints for a newb? :) trace:menu:CreateMenu return 0x50 trace:menu:MENU_GetSysMenu hWnd 0x10022 (hMenu 0x50) trace:menu:LoadMenuIndirectW 0x7f9cea54, ver 0 trace:menu:CreateMenu return 0x94 trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f120, str L"&Restore" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9cea5c trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf120, Text=L"&Restore" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f010, str L"&Move" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9cea72 trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf010, Text=L"&Move" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f000, str L"&Size" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9cea82 trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf000, Text=L"&Size" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f020, str L"Mi&nimize" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9cea92 trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf020, Text=L"Mi&nimize" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f030, str L"Ma&ximize" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9ceaaa trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf030, Text=L"Ma&ximize" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id 0000, str (nil) (not a string) trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=(nil) trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x0, Type=sep } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f060, str L"&Close\tAlt-F4" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9ceac8 trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf060, Text=L"&Close\tAlt-F4" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id 0000, str (nil) (not a string) trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=(nil) trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x0, Type=sep } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f130, str L"&Switch to ...\tCtrl-Esc" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9ceaee trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf130, Text=L"&Switch to ...\tCtrl-Esc" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id 0000, str (nil) (not a string) trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=(nil) trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x0, Type=sep } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f141, str L"&About WINE ..." trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9ceb28 trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf141, Text=L"&About WINE ..." } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id 0000, str (nil) (not a string) trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=(nil) trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x0, Type=sep } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000480, id f142, str L"&Put 'Debug mark' in debug log" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=480 str=0x7f9ceb52 trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf142, Text=L"&Put 'Debug mark' in debug log" } trace:menu:SetMenuDefaultItem (0x94,61536,0) trace:menu:MENU_CopySysPopup returning 0x94. trace:menu:InsertMenuW hMenu 0x50, pos -1, flags 00002410, id 0094, str (nil) (not a string) trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=2410 str=(nil) trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x94, Sub=0x94, Type=sep,pop,rorder } trace:menu:MENU_GetSysMenu hMenu=0x50 (hPopup 0x94) trace:menu:GetMenu for 0x10022 returning (nil) trace:menu:GetMenu for 0x10022 returning (nil) trace:menu:GetMenu for 0x10022 returning (nil) trace:menu:EnableMenuItem ((nil), 00ca, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cb, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00c9, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cf, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00d1, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cc, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cd, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00ce, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00d0, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 012e, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 012d, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:GetMenu for 0x10026 returning (nil) trace:menu:GetMenu for 0x10026 returning (nil) trace:menu:GetMenu for 0x10022 returning (nil) trace:menu:GetMenu for 0x10022 returning (nil) trace:menu:GetMenu for 0x10022 returning (nil) trace:menu:EnableMenuItem ((nil), 00ca, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cb, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00c9, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cf, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00d1, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cc, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cd, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00ce, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00d0, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:GetMenuState (menu=0x94, id=f060, flags=0000); trace:menu:do_debug_print_menuitem item: { ID=0xf060, State=default, Text=L"&Close\tAlt-F4" } trace:menu:GetMenuState (menu=0x94, id=f060, flags=0000); trace:menu:do_debug_print_menuitem item: { ID=0xf060, State=default, Text=L"&Close\tAlt-F4" } trace:menu:DestroyMenu (0x50) trace:menu:DestroyMenu (0x94)

Dec. 21, 2005

Re: has the LGPL licence fell through ? (forw)

by Joerg Mayer

as a simple reply isn't sent to the list.... ----- Forwarded message from Joerg Mayer <jmayer(a)loplof.de> ----- Date: Wed, 21 Dec 2005 09:22:11 +0100 From: Joerg Mayer <jmayer(a)loplof.de> To: Aric Cyr <Aric.Cyr(a)gmail.com> Subject: Re: has the LGPL licence fell through ? In-Reply-To: <loom.20051221T082013-24(a)post.gmane.org> On Wed, Dec 21, 2005 at 07:48:09AM +0000, Aric Cyr wrote: > Maybe I'll fire off an email to Turbolinux to see what they have to say, > although technically unless I purchase or receive their product I am not > directly entitled to the GPL/LGPL code from them. Anyone have a copy of Can you please let me know why you think that? ---------------------------- 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. ... ------------------------------- So I guess if they are using some code of yours that you provided to them under LGPL, you are entiteld to request the source. In case this goes to court you'll need a copy, but for now it is sufficient to be sure that they are distributing a product based on your code which is covered by the LGPL. Again: It is *you* who granted them the right to use your code, and by putting it under LGPL you made sure that you are entitled to any changes they make to *the* code once they start distributing your code (or derivatives) to thrid parties. That way you can reqeust the changes even when the new product costs $10M. Ciao Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ----- End forwarded message ----- -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

Dec. 21, 2005

Re: Bug 3885

by Aric Cyr

Tom Spear <speeddymon <at> gmail.com> writes: > 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. > I took a look at the D3D_OK hack, and I believe the problem to be CheckDeviceFormat in wined3d/directx.c. This function should return an error if D3DFMT_D32 is checked for on cards which don't support 32bit depth. Currently it just returns OK for most formats though. This code is really just a stub as it stands, and needs to be converted to check if there are any visuals that meet the requested format's requirements, and if there is, return D3D_OK, otherwise D3D_NOTAVAILBLE. To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case (you'll need to add it) in wined3d/directx.c in IWineD3DImpl_CheckDeviceFormat() and see if that fixes that issue or not. This would be just another hack though, so a real patch would still be necessary as I decribed above. - Aric

Dec. 21, 2005

Re: has the LGPL licence fell through ?

by Aric Cyr

Tim Schmidt <timschmidt <at> gmail.com> writes: > 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. Ya, I suspected that of Transgaming actually, hence the (?). I just did a search, a read through the thread from Sept. Thanks for the heads up. Didn't know that this is old news. > 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. Seeing that SpecOps Labs history of ignoring Wine developers extends for more than a year, then yes I can agree with that. According to their Partners' page, IBM and Turbolinux and a few others seem to be footing the bill. I'm sure a well written email to either of those places would get a real response, and probably apply due pressure on SpecOps Labs. Maybe I'll fire off an email to Turbolinux to see what they have to say, although technically unless I purchase or receive their product I am not directly entitled to the GPL/LGPL code from them. Anyone have a copy of Turbolinux 11 with this David stuff in it? If there are no users to disseminate the product (which they are allowed to do, given the inherent LGPL license), then there is effectively no way to get our hands on the source code. You can do whatever you want to GPL/LGPL code, but if you don't give the result to anyone (binary or otherwise) you do not have an obligation to release those changes back to the original author (as was mentioned earlier in this thread). Regards, Aric

Dec. 21, 2005