- wine-devel - winehq.org

linux from scratch
by Shane Shields 27 Feb '02

27 Feb '02

Never underestimate the power of stupidity and naievity, especially as projects like 'Linux from scratch' are getting popular. FYO i built my system using linux from scratch and it runs better than the redhat 6.2,7.1,7.2 distributions (insert preferred dist) no core dumps AT ALL. my directorys are posixs standard and i know more about linux than someone who just puts in a cd and answers some questions and ends up with some flakey bloatware. a stupid or naieve person CANNOT install linux from scratch but they can from a redhat cd. everybody can drive a car but not everyone can fix or build one. Shane Shields -- To drink the WINE of success you must first seek the sayings of source _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Re: regapi compatibility with regedit
by Andriy Palamarchuk 27 Feb '02

27 Feb '02

Alexandre, I submitted this patch on Feb 25, but it is not applied yet. Anything wrong with the patch? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com

1 0

Implementing SHAppBarMessage
by Drew Ogle 27 Feb '02

27 Feb '02

Hi, we were talking on #winehq about implementing SHAppBarMessage while not horridly important , implementing it properly could take a good bit of work. The problem is thus; when an application registers a hWnd and gets the system to allocate it a certain space, when other windows mazimize, they don't maximize over the appbar ( point in case -- ICQ ) this would then take some work in wineserver. For corectness' sake we would want to make these changes, but they could also introduce bugs. Sidenote: someone told me that Eric is working on SHAppBarMessage, is this correct? --Dante

2 1

Regression testing
by Rick Romero 27 Feb '02

27 Feb '02

Hi all, I've been trying to track down the source of my Visual Foxpro "Left click in a window, and 'freeze'" error, and with the help of Lawson Whitney, I *think* I've managed to narrow it down to the patch that causes it. If I checkout wine from cvs, then do a cvs update -D "2001-06-19" I get a 'working' wine. If I update to 06-20, wine doesn't work. There are a few patches that were committed on the 19th, but one appears to mostly likely have been the culprit: Log message: Moved hardware message queue handling to the server. Patch: http://cvs.winehq.com/patch.py?id=992978202334525382146239 First, I suppose I should apply each patch for that day, just to be sure, but I'm guessing/hoping someone else knows if that large 'move' caused some problems or not (so I can avoid spending that time). Second, is there anything I can do to help narrow this down further? I see there are a couple WM_LBUTTONDOWN things that I could trace, but I'm not sure that's the best place to start.. In short, what should I do now? :) Thanks, Rick

1 0

Traditional Chinese (CP950) not displaying in WINE
by Anthony Fok 27 Feb '02

27 Feb '02

Hello all, We are experimenting some problems with displaying and inputting Chinese characters in WINE (January 2002 or newer). For example, most Chinese characters show up as squares, and it seems that WINE doesn't accept Chinese input via XCIN (an input method server using the XIM protocol). Did we misconfigured something? Or is this a known problem in WINE? Any pointers would be appreciated. Thanks! Cheers, Anthony -- Anthony Fok Tung-Ling ThizLinux Laboratory <anthony(a)thizlinux.com> http://www.thizlinux.com/ Debian Chinese Project <foka(a)debian.org> http://www.debian.org/intl/zh/ Come visit Our Lady of Victory Camp! http://www.olvc.ab.ca/

3 5

new Bug in OLE
by mehmet yasar 27 Feb '02

27 Feb '02

Microsoft Visual Studio 6 is crashing when opening an existing projet, with current CVS version of Wine (Wine20020122 was OK). Comparing both, I have found the change that triggers the crash. It is function StgOpenStorage in OLE32/storage32.c, line 5595 : hr = StorageImpl_Construct( newStorage, hFile, pwcsName, NULL, grfMode, TRUE, - FALSE); + !(Fad.nFileSizeHigh || Fad.nFileSizeLow) /* FALSE */ ); TRACE shows that Fad.nFileSizeHigh = Fad.nFileSizeLow = 0; As you can see in TRACE the crash occurs in StorageImpl_WriteBigBloc. I suppose Wine is trying to write to a readonly opened file ? (because file is opened with GENERIC_READ) I hope this will help finding a fix. Mehmet YASAR -------------------- BackTRACE Unhandled exception: page fault on write access to 0x419d0000 in 32-bit code (0x402a6db4). In 32-bit mode. 0x402a6db4 (NTDLL.DLL.memcpy+0x34 in libc.so.6): movl %eax,0x0(%edi) Backtrace: =>0 0x402a6db4 (NTDLL.DLL.memcpy+0x34 in libc.so.6) (ebp=405d5e34) 1 0x40899438 (StorageImpl_SaveFileHeader+0x188(This=0x403f3440) [storage32.c:3084] in libole32.so) (ebp=405d6058) 2 0x408986d0 (StorageImpl_Construct+0x170(This=0x403f3440, hFile=0xd4, pwcsName=0x405d6414, pLkbyt=0x0, openFlags=0x10, fileBased=0x1, fileCreate=0x1) [storage32.c:2265] in libole32.so) (ebp=405d6180) 3 0x4089bc7e (StgOpenStorage+0x21e(pwcsName=0x405d6414, pstgPriority=0x0, grfMode=0x10, snbExclude=0x0, reserved=0x0, ppstgOpen=0x405d6488) [storage32.c:5595] in libole32.so) (ebp=405d63f4) 4 0x5009c4b2 (DEVSHL.DLL.4593+0x111 in D:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVSHL.DLL) (ebp=405d6464) -------------------- debugmsg +ole,+storage,+file trace:file:CreateFileA D:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin\mfcclwz.dll GENERIC_READ F ILE_SHARE_READ OPEN_EXISTING trace:file:ReadFile 212 0x405d61ec 511 0x405d5ed4 (nil) trace:file:ReadFile 212 0x405d61ec 511 0x405d5ed4 (nil) trace:storage:StgOpenStorage (L"Y:\\wine\\testDC\\testdc.opt", (nil), 10, (nil), 0, 0x405d6488) trace:file:CreateFileA Y:\wine\testDC\testdc.opt GENERIC_READ OPEN_EXISTING trace:storage:BIGBLOCKFILE_FileInit file len 49664 trace:storage:BIGBLOCKFILE_MapPage mapped page 0 to 0x419d0000 trace:storage:StorageImpl_WriteBigBlock memcpy (0x419d0000 0x405d5e4c 512 ) wine: Unhandled exception, starting debugger... --------------------

1 0

Re: ImageList fixes
by daveh-wine＠cadlink.com 27 Feb '02

27 Feb '02

From: mstefani(a)redhat.de >> The hotspot handling in imagelist is broken. This fix partially >repairs it. >... and breaks it too. With your patch the hotspot handling in It was a crude attempt to differentiate between the subtle difference in meaning of the hotspot passed in to BeginDrag and that passed in to SetDragCursorImage. The BeginDrag hotspot sets the position of the image wrt the current mouse position and also sets the hotspot there. Subsequently calling SetDragCursorImage does not physically move the image, but changes the mouse messages to reflect the offset. We probably need to do more substantial logic and track both hotspots independantly to achieve better Windows emulation. The bHSPending can be removed as it was only there to prevent the image moving as a result of a call to SetDragCursorImage after BeginDrag with different hotspots. If this breaks my application too much I'll do a more thorough fix and test more widely. Dave Hawkes

1 0

Re: ImageList fixes
by Michael Stefaniuc 26 Feb '02

26 Feb '02

Hello, sorry to replay so late but I didn't had the time to test your patch before. On Fri, Feb 22, 2002 at 08:39:39PM -0500, Dave Hawkes wrote: > The hotspot handling in imagelist is broken. This fix partially repairs it. ... and breaks it too. With your patch the hotspot handling in FreeSolitaire is broken. The attached patch reverts a small portion of your patch and fixes the recursion. For what do you need bHSPending? With the recursion removed it's pretty useless. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: Native DDE problems
by List vmn 26 Feb '02

26 Feb '02

Erich!!!! Very Cool! Thanks for your prompt answer. Please send me the patch. I will surely test it! Just one question on your answer, my two apps are called DISP.EXE and PDV.EXE Is one of them 16 and the other 32 bit ? If I recompile both of them to 32 bit or 16 bit, should DDE work? I can also try that. Frankly, I didn´t even know that one was 16 and the other 32 bit. Miguel Feitosa At 21:11 26/2/2002 +0100, you wrote: > > The http://www.winehq.com/News/status.html states that the implementation > > of the serial/parallel port > > is 90% complete but that DDE is still being implemented by Eric Pouech and > > not functional. >the status page is now a bit outdated >DDE (and DDEML) now kinda work >however, some 16 bit support is still missing in DDE (and DDEML), hence >your >problems as the trace shows >as of today : >- two 32 bit apps should be able to communicate through DDE >- two 16 bit apps should be able to communicate through DDE >- however, a 16 bit and a 32 bit app will not be able to communicate > >I have a yet unfinished patch here that should (partly) take care of >that >if you have the wine source and are ready to do some testing, I can >provide >you the patch to see if it helps in your situation > >as DDEML is a pure 16 bit DLL (the 32 bit DDEML implementation is part >of >USER32), it's very unlikely that native DDEML will work in wine >so, sticking to builtin USER/USER32/DDEML is the only viable solution >(even >if it's not completly done yet) > >A+

2 1

Artilcle - loading Windows DLL's under Linux
by Nick Temple 26 Feb '02

26 Feb '02

Hello All -- I am working on an article about how to load Windows DLL's under Linux. This system is for stand-alone Linux applications that only need to use some of the logic in a single Windows DLL, not a full WINE implementation. The code has been "borrowed" and tweaked from the avifile distribution (which is GPL'd), originally borrowed from WINE (BSD license), and will be re-released under the GPL or LGPL once the article is published. I have found the following names in the headers of the various files I'm using: Eric Youndale & Erik Bos Martin von Löwis Marcus Meissner Thomas Sandford Robert J. Amstadt Alexandre Julliard I plan to give credit either at the end of the article or in a sidebar. I would also like to put in a "blurb" about the WINE and avifile projects in the article (or sidebar) as well. Is there a standard blurb I can use? Also, I want to make sure that the appropriate people / organizations get credit. I am willing to accept comments on the completed version before publication to make sure I'm not stepping on any toes, please contact me directly if you are interested. Thanks in advance for the feedback, Nick

7 6

wineserver request size
by Eric Pouech 26 Feb '02

26 Feb '02

how to handle large wineserver request structure ? I've been working on adding the dwFillAttribute handling to CreateProcess (and passing between parent and child) while I was at it, I also added all the other fields (window geometry, console title/size...) at the end the two requests used in the process (new_process and init_process) are larger than the fixed request_max_size structure (80 bytes would be needed) so, what's the preferred way of handling this: 1) bump the request_max_size to the needed size (but all requests will be penalized about it) 2) remove the request_max_size (therefore aligning the size of the request on the one of the biggest available) 3) try to compress the structure fields (most of the data are 32 bits, whereas they would fit in 16 bit fields) 4) store the data above the 64 bytes into the variable part of the message (but that would break the current structure scheme) A+

3 2

Native DDE problems
by List vmn 26 Feb '02

26 Feb '02

Hi! I started using wine (wine-20020122 compiled from source tarball) a couple of weeks ago to run a store-point-of-sale application. The idea is to port this windows application to linux. Before porting, we decided to check if the app could be emulated on linux with wine or recompiled with winelib. This is also necessary to run proprietary windows DLLs from third parties such as credit card companies that bind the application to specific hardware. The software uses a lot of external hardware such as printers, barcode scanners, special keyboards etc. These hws usually communicate through the serial port. Another important feature of the software is the use of DDE - Dynamic Data Exchange from the windows API. The application is broken into at least two executables that communicate through DDE. The http://www.winehq.com/News/status.html states that the implementation of the serial/parallel port is 90% complete but that DDE is still being implemented by Eric Pouech and not functional. After reviewing the manuals and spending a few days on trial runs, I decided to try and bring in the native DDEML.DLL and see if the exe´s would communicate. QUESTION: Should this native windows library work under wine, has anybody tried this? When I tried running the software with the native DDE engine (from Win98), I get DDE errors and a warning saying that DDE is not functional yet. This is expected as reported by the status.html page. When I tried running the software with a setup that only the DDEML.DLL was native, the program crashed with an exception. I tried running the program with several debug channels but couldn´t detect the problem. The only thing learned was that the program seemed to be crashing inside USER.DLL builtin code. I then tried several different native/builtin setups using mainly the following DLLs: Native DLLs DDEML.DLL OLE32.DLL COMCTL*.DLL COMDLG*.DLL SHELL.DLL SHELL32.DLL I even tried bringing in USER and USER32. Some of these setups were documented not to work and didn´t. Everytime I got a setup that seemed to work, the software would crash with basically an exception or page fault. I then decided to use winedbg. I was able to get a stack trace of the software at the time of the exception. It is at the end of this email. I also put a complete run of winedbg --debugmsg +msg 'c:\sw\store.exe' in http://admin.vmn.com.br/wine/out.txt From the trace it seemed that USER builtin in code was not yet finished and handling correctly DDE messages or had a messaging bug related to DDE or not. I read the functions in c code from the trace and couldn´t see any obvious problems. They seemed complete and finished. QUESTION: Is the builtin USER.DLL complete? QUESTION: Should it interact correctly with DDEML.DLL? If DDEML.DLL and USER.DLL were communicating through COM then they should interact correctly but since DDE is a protocol dating back to win3.1, probably older than OLE and COM, maybe they don´t. I have thought of reworking the original software to use SOCKETS but this is quite a lot of work. I am new to wine so I may be missing something obvious. Thanks in advance for any help. Miguel Feitosa TRACE First chance exception: page fault on read access to 0xc032090d in 32-bit code (0x400a47d6). In 32-bit mode. Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0277 GS:0000 EIP:400a47d6 ESP:40ca69ac EBP:40ca69b0 EFLAGS:00010202( R- 00 I - - 1 ) EAX:c032090f EBX:40100ef8 ECX:000003e7 EDX:c032090d ESI:c032090f EDI:40ca6a10 Stack dump: 0x40ca69ac (_end+0x237d58): 406c1c84 40ca69c8 406266c6 c032090f 0x40ca69bc (_end+0x237d68): 406c1c84 080745a8 40ca6b70 40ca6a84 0x40ca69cc (_end+0x237d78): 4062f205 000003e7 c032090f 40ca6a10 0x40ca69dc (_end+0x237d88): 40ca6a14 406c1c84 080745a8 40ca6b70 0x40ca69ec (_end+0x237d98): 00000000 00000000 00000000 406911ae 0x40ca69fc (_end+0x237da8): 406c1c84 00010021 00000000 00000000 0x40ca6a0c (_end+0x237db8): 004e: sel=0277 base=40cb7000 limit=00000fff 32-bit rw- Backtrace: =>0 0x400a47d6 (GlobalLock+0x1a(hmem=0xc032090f) [global.c:1090] in libntdll.so) (ebp=40ca69b0) 1 0x406266c6 (UnpackDDElParam+0x46(msg=0x3e7, lParam=0xc032090f, uiLo=0x40ca6a10, uiHi=0x40ca6a14) [misc.c:130] in libuser32.so) (ebp=40ca69c8) 2 0x4062f205 (post_dde_message+0x35(dest_tid=0x80745a8, data=0x40ca6b2c, info=0x40ca6b70, data=0x40ca6b2c, data=0x40ca6b2c, data=0x40ca6b2c) [message.c:1142] in libuser32.so) (ebp=40ca6a84) 3 0x4062ff94 (put_message_in_queue+0xc8(dest_tid=0x80745a8, info=0x40ca6b70, reply_size=0x0) [message.c:1587] in libuser32.so) (ebp=40ca6b50) 4 0x40630b0e (PostMessageW+0xba(hwnd=0x10029, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [message.c:1995] in libuser32.so) (ebp=40ca6b94) 5 0x4063173a (PostMessage16+0x66(hwnd16=0x29, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [msg16.c:89] in libuser32.so) (ebp=40ca6bc4) 6 0x4061f4e9 (USER_CallFrom16_p_word_wwwl+0x29(proc=0x406316d4, args=0x403b613e) [user.spec.c:1052] in libuser32.so) (ebp=40ca6be0) 7 0x4008f14a (__wine_call_from_16_word+0x8e [relay16.s] in libntdll.so) (ebp=40ca6c10) 8 0x03af:0x5a71 (bp=a5ae) 9 0x03af:0x38e8 (bp=a5cc) 10 0x03af:0x3617 (bp=a5f0) 11 0x03af:0x150a (bp=a618) 12 0x033f:0x1dec (bp=a640, far call assumed) 13 0x033f:0x1f1f (bp=a668) 14 0x028f:0x0c86 (bp=a904) 15 0x0287:0x00e0 (bp=0000) 0x400a47d6 (GlobalLock+0x1a [global.c:1090] in libntdll.so): cmpw $0x5342,0xfffffffe(%eax) 1090 if(pintern->Magic==MAGIC_GLOBAL_USED) Wine-dbg>First chance exception: page fault on read access to 0xc032090d in 32-bit code (0x400a47d6). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0277 GS:0000 EIP:400a47d6 ESP:40ca69ac EBP:40ca69b0 EFLAGS:00010202( R- 00 I - - 1 ) EAX:c032090f EBX:40100ef8 ECX:000003e7 EDX:c032090d ESI:c032090f EDI:40ca6a10 Stack dump: 0x40ca69ac (_end+0x237d58): 406c1c84 40ca69c8 406266c6 c032090f 0x40ca69bc (_end+0x237d68): 406c1c84 080745a8 40ca6b70 40ca6a84 0x40ca69cc (_end+0x237d78): 4062f205 000003e7 c032090f 40ca6a10 0x40ca69dc (_end+0x237d88): 40ca6a14 406c1c84 080745a8 40ca6b70 0x40ca69ec (_end+0x237d98): 00000000 00000000 00000000 406911ae 0x40ca69fc (_end+0x237da8): 406c1c84 00010021 00000000 00000000 0x40ca6a0c (_end+0x237db8): 004e: sel=0277 base=40cb7000 limit=00000fff 32-bit rw- Backtrace: =>0 0x400a47d6 (GlobalLock+0x1a(hmem=0xc032090f) [global.c:1090] in libntdll.so) (ebp=40ca69b0) 1 0x406266c6 (UnpackDDElParam+0x46(msg=0x3e7, lParam=0xc032090f, uiLo=0x40ca6a10, uiHi=0x40ca6a14) [misc.c:130] in libuser32.so) (ebp=40ca69c8) 2 0x4062f205 (post_dde_message+0x35(dest_tid=0x80745a8, data=0x40ca6b2c, info=0x40ca6b70, data=0x40ca6b2c, data=0x40ca6b2c, data=0x40ca6b2c) [message.c:1142] in libuser32.so) (ebp=40ca6a84) 3 0x4062ff94 (put_message_in_queue+0xc8(dest_tid=0x80745a8, info=0x40ca6b70, reply_size=0x0) [message.c:1587] in libuser32.so) (ebp=40ca6b50) 4 0x40630b0e (PostMessageW+0xba(hwnd=0x10029, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [message.c:1995] in libuser32.so) (ebp=40ca6b94) 5 0x4063173a (PostMessage16+0x66(hwnd16=0x29, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [msg16.c:89] in libuser32.so) (ebp=40ca6bc4) 6 0x4061f4e9 (USER_CallFrom16_p_word_wwwl+0x29(proc=0x406316d4, args=0x403b613e) [user.spec.c:1052] in libuser32.so) (ebp=40ca6be0) 7 0x4008f14a (__wine_call_from_16_word+0x8e [relay16.s] in libntdll.so) (ebp=40ca6c10) 8 0x03af:0x5a71 (bp=a5ae) 9 0x03af:0x38e8 (bp=a5cc) 10 0x03af:0x3617 (bp=a5f0) 11 0x03af:0x150a (bp=a618) 12 0x033f:0x1dec (bp=a640, far call assumed) 13 0x033f:0x1f1f (bp=a668) 14 0x028f:0x0c86 (bp=a904) 15 0x0287:0x00e0 (bp=0000) 0x400a47d6 (GlobalLock+0x1a [global.c:1090] in libntdll.so): cmpw $0x5342,0xfffffffe(%eax) 1090 if(pintern->Magic==MAGIC_GLOBAL_USED) Wine-dbg>First chance exception: page fault on read access to 0xc032090d in 32-bit code (0x400a47d6). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0277 GS:0000 EIP:400a47d6 ESP:40ca69ac EBP:40ca69b0 EFLAGS:00010202( R- 00 I - - 1 ) EAX:c032090f EBX:40100ef8 ECX:000003e7 EDX:c032090d ESI:c032090f EDI:40ca6a10 Stack dump: 0x40ca69ac (_end+0x237d58): 406c1c84 40ca69c8 406266c6 c032090f 0x40ca69bc (_end+0x237d68): 406c1c84 080745a8 40ca6b70 40ca6a84 0x40ca69cc (_end+0x237d78): 4062f205 000003e7 c032090f 40ca6a10 0x40ca69dc (_end+0x237d88): 40ca6a14 406c1c84 080745a8 40ca6b70 0x40ca69ec (_end+0x237d98): 00000000 00000000 00000000 406911ae 0x40ca69fc (_end+0x237da8): 406c1c84 00010021 00000000 00000000 0x40ca6a0c (_end+0x237db8): 004e: sel=0277 base=40cb7000 limit=00000fff 32-bit rw- Backtrace: =>0 0x400a47d6 (GlobalLock+0x1a(hmem=0xc032090f) [global.c:1090] in libntdll.so) (ebp=40ca69b0) 1 0x406266c6 (UnpackDDElParam+0x46(msg=0x3e7, lParam=0xc032090f, uiLo=0x40ca6a10, uiHi=0x40ca6a14) [misc.c:130] in libuser32.so) (ebp=40ca69c8) 2 0x4062f205 (post_dde_message+0x35(dest_tid=0x80745a8, data=0x40ca6b2c, info=0x40ca6b70, data=0x40ca6b2c, data=0x40ca6b2c, data=0x40ca6b2c) [message.c:1142] in libuser32.so) (ebp=40ca6a84) 3 0x4062ff94 (put_message_in_queue+0xc8(dest_tid=0x80745a8, info=0x40ca6b70, reply_size=0x0) [message.c:1587] in libuser32.so) (ebp=40ca6b50) 4 0x40630b0e (PostMessageW+0xba(hwnd=0x10029, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [message.c:1995] in libuser32.so) (ebp=40ca6b94) 5 0x4063173a (PostMessage16+0x66(hwnd16=0x29, msg=0x3e7, wparam=0x27, lparam=0xc032090f) [msg16.c:89] in libuser32.so) (ebp=40ca6bc4) 6 0x4061f4e9 (USER_CallFrom16_p_word_wwwl+0x29(proc=0x406316d4, args=0x403b613e) [user.spec.c:1052] in libuser32.so) (ebp=40ca6be0) 7 0x4008f14a (__wine_call_from_16_word+0x8e [relay16.s] in libntdll.so) (ebp=40ca6c10) 8 0x03af:0x5a71 (bp=a5ae) 9 0x03af:0x38e8 (bp=a5cc) 10 0x03af:0x3617 (bp=a5f0) 11 0x03af:0x150a (bp=a618) 12 0x033f:0x1dec (bp=a640, far call assumed) 13 0x033f:0x1f1f (bp=a668) 14 0x028f:0x0c86 (bp=a904) 15 0x0287:0x00e0 (bp=0000) 0x400a47d6 (GlobalLock+0x1a [global.c:1090] in libntdll.so): cmpw $0x5342,0xfffffffe(%eax) 1090 if(pintern->Magic==MAGIC_GLOBAL_USED) Wine-dbg>130 params = GlobalLock(hMem); Wine-dbg>1142 if (!UnpackDDElParam( info->msg, info->lparam, &uiLo, &uiHi )) Wine-dbg>1587 return post_dde_message( dest_tid, &data, info ); Wine-dbg>1995 return put_message_in_queue( dest_tid, &info, NULL ); Wine-dbg>89 return PostMessageW( hwnd, msg32, wparam32, lparam ); Wine-dbg>1052 return proc( Wine-dbg>

2 1

Menu Item problem(was Notepad not remaining language selection)
by Sylvain Petreolle 26 Feb '02

26 Feb '02

Hi, I have implemented 2 procedures to set the language used by Notepad at startup. Now it selects language by using string key "Language" under HKCU\\Software\\Wine\\Notepad. Restore of the language functions now. But I'm new in Windows coding so I don't know which procedure is called when I click on an item in the Language menu.So saving the language in the registry is not called.The procedure is ready to use but never called. Could someone help ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

4 7

Out of process COM objects & Installshield v6
by Sander van Leeuwen 26 Feb '02

26 Feb '02

Hi, What's the current state of OOP COM objects in Wine? I've noticed a lot of related changes, but have yet to find an InstallShield 6 installer that works. (I did copy the stdole*.tlb files to the windows & system directory) After porting the OLE changes to Odin, I tried the Java 1.4 installer. It fails with error 0x80070057 (CoMarshalInterface; failed to marshal interface) Trying the same installer in Wine (built from latest CVS) results in the same error There's a fixme for NdrDllRegisterProxy for the same GUID that fails in CoMarshallInterface. Perhaps that's the cause. Before I start debugging this, I'd like to know if it is supposed to work at all. Thanks, Sander

5 7

RE: License change vote results
by Kevin Lawton 26 Feb '02

26 Feb '02

Dimi, Come on now, it isn't as if Brett is accusing Codeweavers of actually doing this. He just pointed out a potential flaw in the ballot system. The fact that you failed to comprehend the meaning of such a simple message casts some doubt on your ability to contribute much of any use to either this or any other list. The fact that you so arrogantly dismiss an other's contribution to the discussion makes one wonder just who it is who should 'do everyone a favour and bugger off' ?. There are enough adversaries out there without creating more. I can only suggest that you try to behave more like a gentleman in the future. Kevin. -----Original Message----- From: Dimitrie O. Paun [mailto:dimi@cs.toronto.edu] Sent: 19 February 2002 23:11 To: Brett Glass Cc: Roger Fujii; wine-devel(a)winehq.com Subject: Re: License change vote results On Tue, 19 Feb 2002, Brett Glass wrote: > This is an interesting point. Codeweavers could easily have > "stuffed" the ballot box by insisting that its employees > vote the way it wanted (and/or by claiming that they'd be > out of work if they did not). Well, not that I did not have enough reasons before, but this lands you in my killfile. And as far as I'm concerned, YOU ARE NOT WELCOMED on this list. So do everyone a favour, and bugger off. -- Dimi.

11 16

Re: Alternative make scripts
by Dimitrie O. Paun 26 Feb '02

26 Feb '02

On Tue, 26 Feb 2002, Andriy Palamarchuk wrote: > Does that mean we don't need alternative build scripts > in the Wine tree (probably except winetest)? I'd personally would want to see our Makefile system be portable enough to do this. When I tried porting Wine to cygwin, they were good enough, so I see no reason for a separate script. -- Dimi.

1 0

About that eeevil library naming decision...
by Andreas Mohr 26 Feb '02

26 Feb '02

Hello all, I've just had prime evidence of yet another library naming conflict: libuser.so (which is in package libuser-0.32-1). (installed as /usr/lib/libuser.so) Other examples would be libole.so or libavifile.so. So could we please *finally* rename the wine libraries to libwineuser.so or maybe even better libwine_user.so ? Thank you very much... Yeah, people told me that wine libraries would be in separate directories anyway, so no need for that naming. But believe me, I HATED that decision from day 1. Packagers simply won't always choose a separate directory for wine libraries. (especially for "global" installs without a wrapper script) Thus there'll be lots of trouble for some people. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

5 7

DTR Flow Control
by Michael Cardenas 26 Feb '02

26 Feb '02

Is DTR flow control supported? There's a comment in comm.c in SetCommState that says it's not, but EscapeCommFunction has a SETDTR case and a CLRDTR case. Below are the lines I'm talking about. I'm working on an app that asks for DTR flow control and uses overlapped IO when using a modem. It establishes a modem connection, but then it can't send any data over the connection. I'm using an external modem on a serial port. ------------------------------------------------------------------------ if (lpdcb->fDtrControl == DTR_CONTROL_HANDSHAKE) { WARN("DSR/DTR flow control not supported\n"); } comm.c line 1069 ------------------------------------------------------------- case SETDTR: TRACE("SETDTR\n"); #ifdef TIOCM_DTR direct=TRUE; result= COMM_WhackModem(fd, 0, TIOCM_DTR); break; #endif comm.c line 548

4 7

Re: GetStdHandle Problem
by Ignasi Villagrasa 25 Feb '02

25 Feb '02

>> I notice there are things I haven't understood yet. Is there any Win32 console based Winlib example. Any simple one. >> So I can see which process I should follow to get the program properly built. >the debugger is a pure winelib app, which heavily uses the console, so >you can copy the Makefiles from it >(in debugger directory from the source) I found a little application in wine directory, wcmd, that uses Win32 console functions, and specifically GetStdHandle. I though it will be easier to control that the debugger. I built the following makefile, based on the Makefile.in in wcmd source code directory: ----------------------------------------------------------------------------- DIRWINE = /opt/wine INCL_WINE = -I$(DIRWINE)/include/wine ### Dependencies: WCMD_dependencies = \ batch.obj \ builtins.obj \ directory.obj \ wcmdmain.obj # Build wcmd : $(WCMD_dependencies) c++ -o wcmd -L$(DIRWINE)/lib \ batch.obj \ builtins.obj \ directory.obj \ wcmdmain.obj \ -lkernel32 -lntdll -luser32 -lshell32 ### Rules batch.obj: batch.c gcc $(INCL_WINE) -c -o batch.obj batch.c builtins.obj: builtins.c gcc $(INCL_WINE) -c -o builtins.obj builtins.c directory.obj: directory.c gcc $(INCL_WINE) -c -o directory.obj directory.c wcmdmain.obj: wcmdmain.c gcc $(INCL_WINE) -c -o wcmdmain.obj wcmdmain.c ------------------------------------------------------------- It builds properly wcmd executable. But running it I get a Segmentation fault (core dumped). When running it using gdb, I find the exception before main in libshell32.so library. What am I going wrong ? Is it possible that I have a wrong or an outdated wine version ? I took it from codeweavers.(codeweavers-wine-20011108-5.i386.rpm). If I have to get an update, I'd like to know if there's an already built version for RH6.2 to avoid rebuilding wine package, because Codeweavers hasn't refreshed wine versions and I don't find other built versions for RH6.2. Many thanks for helping. Ignasi Villagrasa.

2 1

Re: DTR Flow Control
by Mike McCormack 25 Feb '02

25 Feb '02

Hi Michael, > Is DTR flow control supported? No. However the Win32 API uses very confusing names, so make sure the app is really asking for DTR/DSR flow control. DTR_CONTROL_ENABLE does not mean DTR/DSR flow control is enabled, it means turn on the DTR line permanently. Only DTR_CONTROL_HANDSHAKE means the serial port should use DSR/DTR handshaking. (AFAIK, DTR_CONTROL_ENABLE and DTR_CONTROL_DISABLE flags are not correctly handled in the current wine... they should actively turn on or turn off DTR). Additionally, there were some problems in the GetCommState/SetCommState code that saw DTR_CONTROL_HANDSHAKE accidently turned on, so make sure that it is really the application that is requesting it. As Marcus pointed out, the linux kernel itself does not support DTR/DSR flow control, but given the time and motivation, we could solve the problem if you really need to make this work... Mike ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

3 2

Re: Notepad not remaining language selection
by Sylvain Petreolle 25 Feb '02

25 Feb '02

Ok, but winemine uses reg to, and does not have such import. (do you have Ymessenger ?) > Registry functions are in advapi32.dll > > Add this line to your notepad.spec file to link > against advapi32 library: > > import advapi32.dll > > Sylvain, we can continue the discusion on > wine-devel. > > Andriy Palamarchuk > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - Coverage of the 2002 Olympic Games > http://sports.yahoo.com ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 2

DirectInput -> Keyboard -> GetDeviceState
by Arjen Nienhuis 25 Feb '02

25 Feb '02

The MapVirtualKey in GetDeviceState is not "the way to do it". It does not map VK_?? to DIK_??. I don't know why it does work most of the time. "ptr[i] = 0x80; ptr[i + 0x80] = 0x80;" gave double key events in a game I have. The correct way to convert the keys is by this table (attachment). I made this table by pressing all the keys on my keyboard, and record the keycodes. The code I wrote for this function is: static HRESULT WINAPI SysKeyboardAImpl_GetDeviceState( LPDIRECTINPUTDEVICE2A iface, DWORD len, LPVOID ptr ) { DWORD i; memset( ptr, 0, len ); if (len != 256) { WARN("whoops, got len %ld?\n", len); return DI_OK; } for (i = 0; i < (sizeof(vk_to_dik) / sizeof(vk_to_dik[0])); i++) if (GetAsyncKeyState( vk_to_dik[i][0] ) & 0x8000) ((LPBYTE)ptr)[ vk_to_dik[i][1] ] = 0x80; return DI_OK; } Is there an array_size() macro in wine? where should I put this table? Any other comments about my first usefull (at least for me) wine code? unsigned char vk_to_dik[][2] = { {VK_BACK, DIK_BACK}, {VK_TAB, DIK_TAB}, {VK_CLEAR, DIK_NUMPAD5}, /* Num Lock off */ {VK_RETURN, DIK_NUMPADENTER}, {VK_SHIFT, DIK_LSHIFT}, {VK_CONTROL, DIK_LCONTROL}, {VK_MENU, DIK_LMENU}, {VK_CAPITAL, DIK_CAPITAL}, {VK_ESCAPE, DIK_ESCAPE}, {VK_SPACE, DIK_SPACE}, {VK_PRIOR, DIK_PRIOR}, {VK_NEXT, DIK_NEXT}, {VK_END, DIK_END}, {VK_HOME, DIK_HOME}, {VK_LEFT, DIK_LEFT}, {VK_UP, DIK_UP}, {VK_RIGHT, DIK_RIGHT}, {VK_DOWN, DIK_DOWN}, {VK_INSERT, DIK_INSERT}, {VK_DELETE, DIK_DELETE}, {VK_0, DIK_0}, {VK_1, DIK_1}, {VK_2, DIK_2}, {VK_3, DIK_3}, {VK_4, DIK_4}, {VK_5, DIK_5}, {VK_6, DIK_6}, {VK_7, DIK_7}, {VK_8, DIK_8}, {VK_9, DIK_9}, {VK_A, DIK_A}, {VK_B, DIK_B}, {VK_C, DIK_C}, {VK_D, DIK_D}, {VK_E, DIK_E}, {VK_F, DIK_F}, {VK_G, DIK_G}, {VK_H, DIK_H}, {VK_I, DIK_I}, {VK_J, DIK_J}, {VK_K, DIK_K}, {VK_L, DIK_L}, {VK_M, DIK_M}, {VK_N, DIK_N}, {VK_O, DIK_O}, {VK_P, DIK_P}, {VK_Q, DIK_Q}, {VK_R, DIK_R}, {VK_S, DIK_S}, {VK_T, DIK_T}, {VK_U, DIK_U}, {VK_V, DIK_V}, {VK_W, DIK_W}, {VK_X, DIK_X}, {VK_Y, DIK_Y}, {VK_Z, DIK_Z}, {VK_LWIN, DIK_LWIN}, {VK_RWIN, DIK_RWIN}, {VK_APPS, DIK_APPS}, {VK_NUMPAD0, DIK_NUMPAD0}, {VK_NUMPAD1, DIK_NUMPAD1}, {VK_NUMPAD2, DIK_NUMPAD2}, {VK_NUMPAD3, DIK_NUMPAD3}, {VK_NUMPAD4, DIK_NUMPAD4}, {VK_NUMPAD5, DIK_NUMPAD5}, /* Num Lock on */ {VK_NUMPAD6, DIK_NUMPAD6}, {VK_NUMPAD7, DIK_NUMPAD7}, {VK_NUMPAD8, DIK_NUMPAD8}, {VK_NUMPAD9, DIK_NUMPAD9}, {VK_MULTIPLY, DIK_MULTIPLY}, {VK_ADD, DIK_ADD}, {VK_SUBTRACT, DIK_SUBTRACT}, {VK_DECIMAL, DIK_DECIMAL}, {VK_DIVIDE, DIK_DIVIDE}, {VK_F1, DIK_F1}, {VK_F2, DIK_F2}, {VK_F3, DIK_F3}, {VK_F4, DIK_F4}, {VK_F5, DIK_F5}, {VK_F6, DIK_F6}, {VK_F7, DIK_F7}, {VK_F8, DIK_F8}, {VK_F9, DIK_F9}, {VK_F10, DIK_F10}, {VK_F11, DIK_F11}, {VK_F12, DIK_F12}, {VK_NUMLOCK, DIK_NUMLOCK}, {VK_SCROLL, DIK_SCROLL}, {VK_OEM_1, DIK_SEMICOLON}, {VK_OEM_PLUS, DIK_EQUALS}, {VK_OEM_COMMA, DIK_COMMA}, {VK_OEM_MINUS, DIK_MINUS}, {VK_OEM_PERIOD, DIK_PERIOD}, {VK_OEM_2, DIK_SLASH}, {VK_OEM_3, DIK_GRAVE}, {VK_OEM_4, DIK_LBRACKET}, {VK_OEM_5, DIK_BACKSLASH}, {VK_OEM_6, DIK_RBRACKET}, {VK_OEM_7, DIK_APOSTROPHE} };

2 7

problem with CreateProces
by DanteAliegri 23 Feb '02

23 Feb '02

on #winehq we've been taking a look at a few programs that use CreateProcess at http://open-socket.dyndns.org/~dante/winetest.c is a simple testcase that should run notepad.exe ( verified in w98 ) in wine cvs we fail and go to the message box. unfortuantly. I don't know enough about wine internals to know what is going wrong. this test case though, should make it sufficently easy ( thanks to hax on #winehq : ) the interesting part of the error log is /media/wine/bin/wine: could not load library 'C:\winapps\NOTEPAD.EXE.so' as Winelib application: C:\winapps\NOTEPAD.EXE.so: cannot open shared object file: No such file or directory Also, this came from a application we were debugging, which may be useful, because it is open source (!) and does a lot of twiddling with win9x/nt internals. ( can't find the URL for it atm though, so I'll put the rarup next to the winetest.exe as hl_cs_ogc.rar ) it has a call to strstr where it is trying to find "hl.exe", but the string has HL.EXE in it, so it fails the strstr test, so I'm wondering is strstr supposed to be case insensitive in win32, or are we passing a path that has mixed case, and it shouldn't? --Dante

2 1

Re: GetStdHandle Problem
by Ignasi Villagrasa 23 Feb '02

23 Feb '02

>> If there's a problem in Wine to get this function work, I'd like to know >> if, apart from updating Wine, I can do any change in the source code in >> order to make the program work. >yes. At first I'd like to change my application code. I'm not thinking of changing wine code because I don't know about it. For instance. Should I initialize my console functions using any additional function ? >> In addition, I'd like to know which libraries should I add to the linker >> process to get the symbols resolved ? >well, I thought you said all your symbols were resolved, aren't they ? Yes. All symbols are resolved and the executable created. I ask this question because I have selected the libraries including at first -lkernel in my makefile linker process and solving then the remaining undefined symbols. I have not used any documentation that tells me what libraries to use. >but, first of all, since you didn't answer my previous questions, I'd ... I'm sorry. I supose you want to know if I have GetStdHandle in any constructor that runs before main routine. (Global instance). The answer is no. >I'd suggest using the prefered way for compiling winelib applications (which >should deal indeed with C++ initializations issues) >look at http://wine.codeweavers.com/docs/winelib-user/ for the details >(in peculiar, winemaker and --wrap option). I notice there are things I haven't understood yet. Is there any Win32 console based Winlib example. Any simple one. So I can see which process I should follow to get the program properly built. For instance, a Win32 Console based editor built using wine migration, and with source code to rebuild it. Many thanks for your interest. Ignasi Villagrasa.

2 1

X11DRV_DIB_[Get/Set]ImageBits in 1, 4 and 8 bit X modes.
by David Hammerton 22 Feb '02

22 Feb '02

Hi, I'm presently modifying the X11DRV dibsection code for slight speed improvements using shared memory pixmaps and the like. Im into the "clean up and make it work on all systems" stage of thing, and I have a question. Do people ever worry about what happens if the user is running in a 1, 4 or 8 bit X mode? This has some wacky code, which I am unable to test on my machine (or any machine around).. So i'm implementing what I think _should_ do the trick - but I have no idea if it will work.. Is it a big issue? Any suggestions to the problem? Thanks, David -- David Hammerton programmer and support TransGaming Technologies Inc. http://www.transgaming.com david(a)transgaming.com

4 3

Re: Fix spec definition for dplayx ordinal variable
by Alexandre Julliard 21 Feb '02

21 Feb '02

"Peter Hunnisett" <peter(a)transgaming.com> writes: > gdwDPlaySPRefCount is an exported ordinal variable might as well declare it as > such. Note that this creates a copy of the variable, so you can no longer reference it from the C code. I'm not sure this is what you meant to do. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: GetStdHandle Problem
by Ignasi Villagrasa 21 Feb '02

21 Feb '02

If there's a problem in Wine to get this function work, I'd like to know if, apart from updating Wine, I can do any change in the source code in order to make the program work. In addition, I'd like to know which libraries should I add to the linker process to get the symbols resolved ? Should I add msvcrt library ? Should I add ncurses library ? what about kernel, ntdll, wine, wine_unicode (These are the libraries tha resolve symbols by now) ? or Where could I find this information ? Thanks in advance. Ignasi Villagrasa.

2 1

db2html-winehq
by Philipp Wollermann 21 Feb '02

21 Feb '02

Hi everybody, I'm new to wine-development but I have used it for a long time now. :) Because I'm using the Crux 0.92 Linux distribution (which doesn't come with db2html, db2pdf etc.) I've used the db2html-winehq script which works quite well. Why isn't it used normally, but only in the make_winehq script? Perhaps someone could change configure.ac so, that it detects if the user has db2html and decides which one to use? I've made a patch for this script so it supports openjade/jade and the Crux distribution. Should I send it to the wine-patches mailinglist? Could someone tell me where to get these db2html etc. scripts? Philipp Wollermann

1 0

Re: Help tracing WINE funcion..
by Rick Romero 21 Feb '02

21 Feb '02

On Thu, 2002-02-21 at 10:18, lawson_whitney(a)juno.com wrote: > On 21 Feb 2002, Rick Romero wrote: > > > Hi all, > > > > I need some assistance.. I'm trying to trace a problem. The quick > > description is when I run the Visual FoxPro 5 development environment, > > and I click in a 'edit' window (like when you bring your program up, to > > edit it) the screen freezes. > > > > when I ran wine --debugmsg +win vfp.exe, my last line of trace is: > > trace:win:EVENT_Capture (0x20021) > > > > Where the heck is the code that calls setcapture for Foxpro? I didn't > > think I needed to, but do I have to get into those spec files also? > > > > Is there somewhere, other than what grep returns, that would call that > > function? I'm definately not an expert here, but I *think* I should be > > able to trace a function on my own :) > > Err, yes. The app, or a native dll used by the app can call SetCapture > itself, unless I misread the .spec files. > > > > My wine is cvs build 2/20/2002, using fake_windows. > > > > Any suggestions would be appreciated. (Should I send this to > > wine-devel?) > > > You might try if you get any joy out of --debugmsg +snoop Nope. No joy :/ > > Or try winedbg and set a breakpoint. That's probably beyond me.. but I have some time :) Thanks Rick > Lawson > ---oof--- > > > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-users -- Rick Romero IT Manager ph: 262.685.4841 Valeo, Inc. fax: 262.695.4850 rick(a)valeoinc.com

1 0

License change impact on other open-source projects
by Andriy Palamarchuk 21 Feb '02

21 Feb '02

Sorry to cross post this message, but I want to attract attention developers from other OS projects which use Wine and I'm not sure they are subscribed to wine-license. We discussed a lot how the license change will affect commercial contributors but we did not mention other open-source projects. Can you, guys, give your opinion about the matter? I'm curious how this will affect you. Anyone from ODIN? If you can, please respond to wine-license. Regards, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com

2 1

Need help tracing WINE function.
by Rick Romero 21 Feb '02

21 Feb '02

Hi all, I need some assistance.. I'm trying to trace a problem. The quick description is when I run the Visual FoxPro 5 development environment, and I click in a 'edit' window (like when you bring your program up, to edit it) the screen freezes. when I ran wine --debugmsg +win vfp.exe, my last line of trace is: trace:win:EVENT_Capture (0x20021) then the window freezes. So I saw that SetCapure() called EventCapture() in input.c, and I'm trying to trace what all (yikes!) calls SetCapture() I started with [rick@pc99 wine]$ grep -nri --include *.c setcapture * to get all the c files with SetCapture(). So after a day of picking and choosing, I've added more traces to EVERYTHING that the grep command outputs (basically): controls/button.c:234: TRACE_(win)("Calling SetCapture in button.c\n"); controls/button.c:235: SetCapture( hWnd ); controls/button.c:236: TRACE_(win)("Done with SetCapture in button.c\n"); controls/combo.c:1197: TRACE_(win)("Calling SetCapture (combo.c)\n"); controls/combo.c:1198: SetCapture(lphc->hWndLBox); controls/combo.c:1778: TRACE_(win)("Calling SetCapture (combo.c2)\n"); controls/combo.c:1779: SetCapture( hWnd ); controls/combo.c:1808: TRACE_(win)("Calling SetCapture (combo.c3)\n"); controls/combo.c:1809: SetCapture(lphc->hWndLBox); controls/edit.c:4324: TRACE_(edit)("About to SetCapture - edit.c\n"); controls/edit.c:4325: SetCapture(hwnd); controls/edit.c:4326: TRACE_(edit)("Done with SetCapture - edit.c\n"); <snipped> I havn't touched the spec files yet, but everywhere setcapture() is called, I added a trace. Mostly TRACE_(win), but sometimes 'win' wouldn't take even with DECLARE_DEBUG_CHANNEL(win); (IIRC, everything under /dlls/ was that way). So now if I run notepad I get: wine --debugmsg +win,+shell,+edit,+header,+accel notepad.exe trace:win:WINPOS_WindowFromPoint found child 10022 trace:edit:EditWndProc_common 32 bit W : WM_MOUSEACTIVATE: hwnd=00010022, wParam=00010021, lParam=02010001 trace:edit:EditWndProc_common 32 bit W : WM_LBUTTONDOWN: hwnd=00010022, wParam=00000001, lParam=002f0041 trace:edit:EDIT_WM_LButtonDown About to SetCapture - edit.c trace:win:SetCapture Calling Event_Capture trace:win:EVENT_Capture (0x10022) Window #!! -Maybe? trace:win:EVENT_Capture About to Return from Event Capture!!! Prev(0) Wnd(65570) I assume what I'm looking for is the WM_LBUTTONDOWN. Looks good. So I run FoxPro: wine --debugmsg +win,+shell,+edit,+header,+accel ../DevStudio/vfp/vfp.exe trace:win:RDW_Paint Released Window pointer --rdw_paint() painting.c trace:win:SetCapture Calling Event_Capture trace:win:EVENT_Capture (0x20021) Window #!! -Maybe? trace:win:EVENT_Capture About to Return from Event Capture!!! Prev(0) Wnd(131105) Where the heck is the code that calls SetCapture for Foxpro? I didn't think I needed to, but do I have to get into those spec files also? Is there somewhere, other than the .c files grep returns, that would call that function? I'm definately not an expert here, but I *think* I should be able to trace a function on my own :) My wine is cvs build 2/20/2002, using fake_windows. Any suggestions would be appreciated. Rick -- Rick Romero IT Manager ph: 262.685.4841 Valeo, Inc. fax: 262.695.4850 rick(a)valeoinc.com

1 0

Odin CVS repository
by Sander van Leeuwen 21 Feb '02

21 Feb '02

Today we made some changes to make it possible for Linux CVS clients to log in. CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/odin32 User: guest Password: readonly Sander

1 0

using windows libraries
by Michael Zayats 21 Feb '02

21 Feb '02

suppose I have pure mathematic (without system calls) library - either static or dynamic, how can I convert it to Linux, without loss of the speed, i.e. by converting and not layering. I have no source code for it of course. with best regards, Michael Zayats

1 0

Article about Wine license
by Roland 20 Feb '02

20 Feb '02

http://desktoplinux.com/articles/AT9068852873.html

2 1

[Fwd: Re: Oh yeah, the docu...]
by Tony Lambregts 20 Feb '02

20 Feb '02

Tony Lambregts wrote: [Snip] > Ok so its just the online doc thats not up to date. Thanks. > > http://www.winehq.com/Docs/wine-user/configuring.shtml > > also looks like the the following are also not up to date. > > http://www.winehq.com/Docs/winedoc-sgml.tgz > http://www.winehq.com/Docs/winedoc-pdf.tgz VERY OLD > http://www.winehq.com/Docs/winedoc-ps.tgz VERY OLD > > and I would suspect that these too. (did not actually download) > > http://www.winehq.com/Docs/wine-set-html.tgz > http://www.winehq.com/Docs/winedoc-html.tgz [snip] Since my last post on usenet I did download these and they are out of date too. IMHO www.winehq.com/Docs should be updated at each snapshot. Tony Lambregts

2 1

License change vote results
by Alexandre Julliard 20 Feb '02

20 Feb '02

Folks, Here is the summary of the votes I received in answer to the request to switch to a copyleft-style license: Agree Disagree Indifferent All votes: 76 (70%) 15 (14%) 17 (16%) Contributors: 39 (66%) 7 (12%) 13 (22%) Contrib. weighted: 59 (64%) 13 (14%) 20 (22%) The first line counts all the votes I received. The second line counts the votes of all people/companies who contributed some code to the project. The last line counts all contributors again but with each being given 1, 2, or 3 votes depending on the importance of his contributions (this evaluation is obviously a bit subjective, but I think the overall trend is clear). The obvious result of this vote is that my previous conclusion was wrong: there is clearly widespread support in the community for a copyleft-style license. With 2 out of 3 contributors in favor of the switch, and less than 15% opposed to it, it's clear that we are going to proceed with the change. We now have to decide the implementation details, like the exact license used, whether to require copyright assignments, etc. My suggestion is that we create a separate mailing list to discuss that, to avoid drowning wine-devel under yet another license flame war. -- Alexandre Julliard julliard(a)winehq.com

11 15

Re:GetStdHandle Problem
by Ignasi Villagrasa 20 Feb '02

20 Feb '02

2 1

Re:GetStdHandle Problem
by Ignasi Villagrasa 20 Feb '02

20 Feb '02

Thanks for answering at first to Eric Pouech. Referred to several points: >did you try to run your program with wineconsole ? >(wineconsole /usr/client/mcc_gnu/cmpm/cmpmgnu /B100 /Oaaaa-1.ovl) I don't know about this executable. I don't find wineconsole file anywhere in wine installation. >Does your program use global objects, which initialization code could invoke the >GetStdHandle functions ? Perhaps I'm going wrong in any of the steps I'm following. I'll explain what I'm trying to do.When I began to migrate this console based programs I wanted to migrate them entirely to Linux without using Wine. I could think of this because my Win32 console programs are designed in native C and C++ and most of its calls are related to ANSI C, and so the migration remains simplified. Console management is platform specific however. I use Win32 console API, and use structures such as INPUT_RECORD. So I'm using Event.KeyEvent.uChar.AsciiChar and Event.KeyEvent.wVirtualScanCode to get and manage keyboard inputs. So it's difficult for me to migrate these calls to, for instance, a ncurses layer, because I must redefine the complete user interface. So I thought of winelib library in order to integrate this part of the programs without changing source code. What I want is add to my program winelib the same way I'm adding other libraries. I don't want to run the program as a Win32 native one, but as a Linux native one. So the steps I followed are: - I installed wine package, getting it from codeweavers. - I added the include files in my source code in order to compile the programs. - I created spec file as wine documents. - I compiled it as documented. - I added the resulting .c file to my makefile. - I compiled all the modules. - I added then following libraries to my makefile linker step: -lkernel -lntdll -lwine -lwine_unicode. Tell me if that's all right. - I linked and created the executable without problems. So, as far as I know, the only place where I call GetStdHandle is in my console module and for displaying and keyboard interface purposes. conhanout = GetStdHandle(STD_OUTPUT_HANDLE); conhanin = GetStdHandle(STD_INPUT_HANDLE); I don't know if the programs may have any additional implicit call to this function. >does your program use AllocConsole or FreeConsole ? No. My program doesn't call explicitly to AllocConsole or FreeConsole. Thanks in advance. Ignasi Villagrasa.

2 1

Re: Small changes to notepad - 2
by Alexandre Julliard 20 Feb '02

20 Feb '02

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Q: Is my changelog automatically added to the > ChangeLog file in the notepad directory? If not, > should I update this file manually or we do not need > to use the local file at all? We don't need to use it, all the changes are listed in the main changelog anyway. In fact it should probably be removed. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: mt locks, fix _sopen for msvcrt
by Alexandre Julliard 20 Feb '02

20 Feb '02

"Peter Hunnisett" <peter(a)transgaming.com> writes: > * dlls/msvcrt/Makefile.in, dlls/msvcrt/console.c, dlls/msvcrt/exit.c, > dlls/msvcrt/file.c, dlls/msvcrt/heap.c, dlls/msvcrt/locale.c, > dlls/msvcrt/main.c, dlls/msvcrt/msvcrt.h, dlls/msvcrt/msvcrt.spec, > [new]dlls/msvcrt/lock.c, include/Makefile.in, [new]include/msvcrt/mtdll.h > Peter Hunnisett <peter(a)transgaming.com> > Add _lock,_unlock and header file for them. > Convert all msvcrt locks over to use _lock and _unlock > Explictly make msvcrt compile with multithreaded option > Fix flag handling in _sopen. Add W->A call for new _swopen Isn't mtdll.h supposed to be an internal header? If so, it should be in dlls/msvcrt, not in include/msvcrt. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Small changes to notepad
by Andriy Palamarchuk 20 Feb '02

20 Feb '02

This patch, submitted on Feb 15 was not applied, but other patch - "Notepad2. Command line processing" was. These two patches are independent from each other. If the patch was not understood as duplication and was not applied for some other reason I'd like to know why. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com

2 2

Concerning the boot procedure for renaming/deleting files
by Gerhard W. Gruber 20 Feb '02

20 Feb '02

Something not to do with licencing, I hope that poeple have time for this as well. :) I've submitted a patch that is the preliminary for processing the files that are installed with a setup in order to be deleted/renamed when windows boots. The files are now entered into the registry as I have seen how it is done on NT4.0. I have now some questions regarding this. 1.) When I verified this with a testprogram on NT I noticed that the MoveFileEx code enters the names like this \??\D:\test.exe[0] !\??\D:\Test_renamed.exe[0] [0] Does anybody know what the \??\ stands for and wether the '1' for the renaming entry has some function? I coudn't find anything regarding this and I hardcoded this as to now. 2.) I've looked into the program winebootup from Andreas Morh and I could finish this (at least regarding the boot processing for now). BUt I don't see the advantage of having a seperate program that does some stuff that should be done when a wine process starts up. When I check if there is something to process this takes a trivially small time, so performance can't be the issue. I don't really like the idea of having a seperate program for this because in my opinion it belongs into the wine startup code to do this sort of work. Also I think that this will lead to additional questions because people will install programms and then wonder why it doesn't work after successfull installation, so they will ask whats wrong (and I gues this will happen again and again). Furthermore I bet that most people may forget about this secondary program that is needed to run because setup is not done that often once a system is set up properly so people might tend to forget about it. The other thing could be that this secondary program will substitute the startupe program in which case there is no need for a second program in the first place. Any opinions on how to best integrate the boot processing?

3 5

Re: License change vote results
by Roger Fujii 20 Feb '02

20 Feb '02

> CodeWeavers as a single entity did receive one vote.) If we had stuffed > the ballot box as Brett suggested, the votes would have > been more lopsided, believe me. So, you're saying that it WAS possible that it could have been stuffed. Remember that the criteria was not given out when the results were posted (which is why I asked in the first place), so there was no way of knowing what the numbers meant. As it is, I think the criteria is flawed in the sense that it discounts major contributers (codeweavers and transgaming) and enhances the votes of minor ones - the ones who are least effected by a license switch (and, IMHO, the ones that understand the issues/mechanisms of licenses the least). As the argument for X11/BSD is a philosophical/commercial one, it's not unfair to say that if you discount commerical entities, you will have the effect of discounting the X11/BSD count. > I think Dimi and others have been remarkably patient, all > things considered. Being on the other side of the issue, I can say that Dimi is not a saint on the matter either - at least Brett sometimes will substantiate what he says. -r

2 1

Re: Notepad2. Command line processing
by lawson_whitney＠juno.com 20 Feb '02

20 Feb '02

On Fri, 15 Feb 2002, Andriy Palamarchuk wrote: > I *think* this patch does not depend on my previous > patch. > > Changelog: > - implemented parsing of file name, passed in command > line, loading new file on startup. This fixes bug 407 > Did you notice in testing this patch that notepad can not save a file? Never mind bug 407, that is the Real Bug that renders notepad unusable. :-). I guess this is not an urgent bug, I can use joe, jed, vi (elvis, vim) or emacs if I need to change a file. Lawson Illigitimati non carborundum.

4 3

Re: License change vote results
by Roger Fujii 20 Feb '02

20 Feb '02

Alexandre Julliard <julliard(a)winehq.com> wrote: > The obvious result of this vote is that my previous conclusion was > wrong: there is clearly widespread support in the community for a > copyleft-style license. With 2 out of 3 contributors in favor of the > switch, and less than 15% opposed to it, it's clear that we are going > to proceed with the change. As a curiosity, what % of the voters are affiliated with codeweavers? I realize that they are a significant contributer, but as you are using the word "community", it's fair to ask a) how big that number is in total b) if there are large components in that number, they should be at least quantified. -r

8 7

MIDL replacement?
by Phillip Schmitz 20 Feb '02

20 Feb '02

Some time ago there was talk of using an (msrpc/com) idl compiler and idl files to replace some of the complexity of the current COM implementation details (I imagine the main advantage would be that winelib programs might be able to use COM stuff without having to generate stubs etc using MIDL). Rather than starting from scratch people recommended finding an existing (corba) idl compiler and hacking that. Has anyone taken up the challenge? I had a look at the freedce idl compiler but I can't get it to compile. Not that I want to invite another round of "my license is better than your license" but should this be distributed independently of wine so as to avoid license problems or what could one base it on if distributed with wine (if wine was rewritten to depend on its availability this would make things tricky... ) Also, while on the topic of MIDL it seems that the emitted code contains marshaling hints/info in special strings - does wine currently understand these? (undocumented of course but not that messy - people writing their own custom DCOM-over-other-transports stuff managed to work them out quite quickly - I'm sure working with people from Microsoft Research helped though :) Would it need to be a drop-in replacement for MIDL? I suppose not but I'm not sure how much easier that would be (I know com-idl is a moving target with COM+ and new attributes etc but plain COM should be sufficient for most). Anyway - this is the result of a few days research and may all be in vain - those with more experience with COM and its implementation in wine should (if required) shoot me down now before I continue wasting my time. Phillip Trainee wine-devel lurker who marvels at the endurance of people using/implementing COM in C. PS I don't know if it is worthwhile starting a separate effort to make a "free" MIDL replacement regardless - what do people writing windows code with mingw etc do if they want to use COM?

2 1

cd programs && make install
by lawson_whitney＠juno.com 20 Feb '02

20 Feb '02

Good day! Maybe this is a local misconfiguration (only I doubt it) or maybe I am going about it wrong,...maybe I deleted winetest.pm myself and can't remember... cd `dirname winetest/__install__` && make install make[1]: Entering directory `/oof/Wine-20020122/programs/winetest' [ -d /usr/local/bin ] || mkdir -p /usr/local/bin /usr/bin/install -c winetest.so /usr/local/bin/winetest.so cd /usr/local/bin && rm -f winetest && ln -s wine winetest [ -d /usr/local/lib ] || mkdir -p /usr/local/lib /usr/bin/install -c -m 644 wine.pm /usr/local/lib/wine.pm /usr/bin/install: wine.pm: No such file or directory make[1]: *** [install] Error 1 make[1]: Leaving directory `/oof/Wine-20020122/programs/winetest' make: *** [winetest/__install__] Error 2 Lawson "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

2 1

RMS, Univerial Themes, Slashdot, and Wine
by Tim R. 20 Feb '02

20 Feb '02

Hi, This post, http://mail.gnome.org/archives/foundation-list/2002-February/msg00015.html to some GNOME mailing list got /.ed recently. Quoting from the post: >It might also be useful to organize a specific joint project, >something that would improve the coherence of a GNU/Linux system >which uses parts of both GNOME and KDE. The idea that occurred to me >was to work on unifying theme definitions, so that a user can define >a theme just once and have it work with both GNOME and KDE. Perhaps >others will have a better suggestion. I would love to see something like this happen. However, IMHO, I think something like this should be more than just KDE and GNOME. I would like to see something like that as a more or less Linux (and BSD, etc), or X11 standard. It seems to me that Wine could benifit from something like this. Basicly, Wine is just a Unix/X11 toolkit that happens to have the same API as MS Windows and includes a binary loader right? Or am I completely off base here? Anyway, GNOME programs tend to look and feel like GNOME programs, KDE programs tend to look and feel like KDE programs, and Wine programs tend to look and feel like Windows programs. So could something like this work for Wine? Could Wine programs inherit their look and feel from some kind of universal theme? That would surely help the Windows programs integrate into the X desktop. So I guess I'm asking, would this work for Wine, and if so, is anyone interested in doing it? If the first answer is yes but the second is no, could anyone provide me with some pointers for getting involved with doing some a project myself? (Both the work on Wine, and on GNOME/Gtk/KDE/Qt/etc.) Also some of the replies to RMS's post suggested this was an itch none of the GNOME people felt like scratching, because none of them used KDE programs. I thought perhaps the Wine people would feel more like scratching this itch, because most of you probably use Wine programs along side of atleast either KDE or GNOME applications, if not both. Sorry if this has been a bit off topic, or if I don't really know what I'm talking about. --Tim Ringenbach

1 0

Bye
by Gerard Patel 20 Feb '02

20 Feb '02

Ring down the curtains, the farce is over ;-) I will unsubscribe from wine lists in a few days. If anyone of the contributors has a problem with the few lines of code I wrote for Wine, they should not hesitate to send me a mail in my personal inbox, I'll try to understand what I was trying to do and if I succeed I'll explain :-) And if among the seven who voted against the changes there are enough people aventurous (I did not participate to the 'vote'), I'd be interested to hear from them and discuss a contribution to a new project under a x11 like license. As wine-license seems to be a continuation of the gpl/bsd flamewar :-//, I'd prefer to talk about a x11 project elsewhere... Thanks to all on this list who helped me. Good luck to the Wine guys for their 1.0 version. Gerard PS : And ah, well, as a parting note for Alexandre Julliard : there is a problem with your patch made on Revision 1.22 / (download) - [select for diffs] , Fri Sep 14 00:24:40 2001 UTC (5 months ago) by julliard Branch: MAIN Changes since 1.21: +8 -13 lines Diff to previous 1.21 Make sure that HWND comparisons are always done with full 32-bit handles. You included this (hardly related) change in dlls/x11drv/window.c, line 524: while (prev && !(GetWindowLongW( prev, GWL_STYLE ) & WS_VISIBLE)) prev = GetWindow( prev, GW_HWNDPREV ); This is triggering a regression in one of my test apps, webferret (www.webferret.com). The option window has its tabs covering each other. I can work around with this patch : --- winpos.c.orig Tue Dec 18 02:27:43 2001 +++ winpos.c Thu Jan 10 18:08:16 2002 @@ -880,7 +880,7 @@ if (get_whole_window(wndPtr)) /* don't do anything if X window not created yet */ { Display *display = thread_display(); - + int zorder = !(winpos->flags & SWP_NOZORDER); if (!(winpos->flags & SWP_SHOWWINDOW) && (winpos->flags & SWP_HIDEWINDOW)) { /* clear the update region */ @@ -895,10 +895,11 @@ TRACE( "unmapping zero size win %x\n", winpos->hwnd ); TSXUnmapWindow( display, get_whole_window(wndPtr) ); } + else if (winpos->flags & SWP_SHOWWINDOW) zorder = TRUE; wine_tsx11_lock(); if (bChangePos) - X11DRV_sync_whole_window_position( display, wndPtr, !(winpos->flags & SWP_NOZORDER) ); + X11DRV_sync_whole_window_position( display, wndPtr, zorder); else { struct x11drv_win_data *data = wndPtr->pDriverData;ü as far as I can understand your code and what the app is doing, your new code updates the ordering of the X window but there is a case missing when child windows are shown using for instance ShowWindow. But of course you'll have a better patch :-)

4 3

RE: License change vote results
by Patrik Stridvall 19 Feb '02

19 Feb '02

> Here is the summary of the votes I received in answer to the request > to switch to a copyleft-style license: > > Agree Disagree Indifferent > > All votes: 76 (70%) 15 (14%) 17 (16%) > > Contributors: 39 (66%) 7 (12%) 13 (22%) > > Contrib. weighted: 59 (64%) 13 (14%) 20 (22%) > > The first line counts all the votes I received. The second line counts > the votes of all people/companies who contributed some code to the > project. The last line counts all contributors again but with each > being given 1, 2, or 3 votes depending on the importance of his > contributions (this evaluation is obviously a bit subjective, but I > think the overall trend is clear). Intresting to note is that contributors that disagree are on average ranked higher (almost 2) but the contributors that agree are ranked lower (about 1.5). This means that people that has more effort to protect are less willing to do so. Very intresting. The only reasonably conclusion for this that I can think of is that people with more to protect have thought more on the drawbacks on copyleft licenses (especially the LGPL) than people with less to protect. > The obvious result of this vote is that my previous conclusion was > wrong: there is clearly widespread support in the community for a > copyleft-style license. For some copyleft-style license perhaps. I'm not entirely against copyleft-style licenses either even if I voted disagree. However don't be so sure that all that voted for it really wants a license like the LGPL that prevent (at least according to your interpretation) using for example proprietary libraries to implement some functionalility. Or for that matter prevents Transgaming to add copy protection that they can't release openly because of a NDA. Calling proprietary libraries is something that I have been trying to explain is not just something "evil" companies out to earn a profit do, but also quite reasonably people just trying to help themselves or some friends to run applications under Wine. Is it really morally or ethically right to prevent that? I also asked how that is compatible with freedom 3 of the Free Software defintion: "The freedom to improve the program, and release your improvements to the public, so that the whole community benefits." > With 2 out of 3 contributors in favor of the > switch, and less than 15% opposed to it, it's clear that we are going > to proceed with the change. > > We now have to decide the implementation details, like the exact > license used, whether to require copyright assignments, etc. I think the first thing me need to do is to properly discuss what we want to accieve with the license and even more importantly what we think is acceptable to sacrifice. Then we must vote on what is important to prevent and what is important to avoid preventing. Especially we must vote on for example whether preventing Transgamings business model is reasonable and similar specific cases. After we have done that we can see if any existing license fits something that the majority agrees on or whether it is appropriete design a license of our own that does. I'm not at all sure that the LGPL is a good alternative at least not without properly clarify what paragraph 2d means as well as making certain that the majority of contributors really wants a license that means whatever paragraph 2d means. Another thing. It is not nessary to have the whole of wine under the same license. For example the header files (wine/include/*.h) might be appropriate to have under the current license or even under public domain to facillitate sharing with other projects. > My > suggestion is that we create a separate mailing list to discuss that, > to avoid drowning wine-devel under yet another license flame war. Agreed. I have subscribed to it and are ready to continue the debate there.

3 2

languages for wine tests
by Andriy Palamarchuk 19 Feb '02

19 Feb '02

Are we going to use other languages than Perl and C for tests creation? I created a small shell test script to test other shell scripts, which are part of Wine (namely regapi scripts). It is easy to rewrite the test script in Perl. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com

2 1

RE: License change vote results
by Patrik Stridvall 19 Feb '02

19 Feb '02

> > For some copyleft-style license perhaps. I'm not entirely against > > copyleft-style licenses either even if I voted disagree. > > > However don't be so sure that all that voted for it really wants > > a license like the LGPL that prevent (at least according to your > > interpretation) using for example proprietary libraries to > > implement some functionalility. > > This is a spurious argument. You tell us that you voted that you > disagree, then ask us to not assume that those who voted in > favor agree > with the LGPL -- but provide no evidence to the contrary? The evidence is that the question didn't ask the whether the voters agreed with the LGPL it asked whether they thought copyleft was good. No bait and switch tactics thank you very much. Copyleft doesn't imply that everything it uses or in the case of GPL even what uses it should be copyleft only whatever is derived from it. A proprietary library that is called from a copylefted application is obviously not derived from it. Yet the LGPL under some interpretations prevent this. So the LGPL goes further than the definition of copyleft so the question whether supporters of copyleft support the LGPL is quite valid. > In any case, the precise license chosen is an issue yet to be > hashed out; > and it seems the wine-license mailing list is the place to do that. True. But I don't think all intrested have signed up yet. I will continue cross-posting a while yet. > > Or for that matter prevents Transgaming to add copy > protection that they > > can't release openly because of a NDA. > > I'm afraid Transgaming gets no sympathy from me if a future > Wine license > prevents them from working on copy protection functionality. > The DMCA is > fundamentally broken; technological mechanisms to prevent copying are > fundamentally broken because there can be no protection for fair use > rights; and any company that uses such copy protection > mechanisms should > be thoroughly boycotted. While I don't condemn TransGaming > for trying to > support copy-protection mechanisms in Wine -- corporations are by > definition amoral -- The DMCA might be (and is IMHO) fundamently broken but NDA:s are not. The copy protection that Transgaming has implemented is just an exemple of things that might come under a NDA. I can imagine 3D accelerators and a lot of other things that might fall under NDA:s. Note that some NDA might only be temporary before a product is released. Surely it would be nice to have Wine working on the release day. > I also won't shed any tears if this particular > business model falls by the wayside. No business model can exists that requires NDA:s if disclosure of source is mandated. If it could be hidden in a external library everthing would be OK, but alas the LGPL doesn't allow that under Alexandre's interpretation.

2 1

Re:GetStdHandle Problem
by Ignasi Villagrasa 19 Feb '02

19 Feb '02

Here is the .spec I'm using: name mcwine type win32 mode cuiexe init main I compile it using winebuild -fPIC -o mcwine.c -spec mcwine.spec It generates a mcwine.c file, that I include in my makefile. I add several wine libraries and create the executable without problems. When trying to execute, I get the following message: wine client error:(nil): sendmsg: Descriptor de fichero err¾neo (In spanish, error in file handle) If I run the program using gdb, I see the following: (gdb) r Starting program: /usr/client/mcc_gnu/cmpm/cmpmgnu /B100 /Oaaaa-1.ovl Breakpoint 1, McConsole::Inicializar (this=0x80aa528) at /usr/comun/src/mc_vis32.cpp:429 429 conhanout = GetStdHandle(STD_OUTPUT_HANDLE); 1: conhanin = 0 (gdb) n 430 conhanin = GetStdHandle(STD_INPUT_HANDLE); 1: conhanin = 0 (gdb) n 431 FlushConsoleInputBuffer(conhanin); 1: conhanin = 0 (gdb) n wine client error:(nil): sendmsg: Descriptor de fichero err¾neo Program exited with code 01. (gdb) So I know the problem comes from GetStdHandle, but I don't know why, because the program links properly, and I suppose GetStdHandle, a basic Win32 function, should work. Any hint ? Perhaps the libraries I'm linking ? Compiler/linker options ? Thanks in advance, Ignasi Villagrasa.

2 1

Controls and TWEAK_WineLook
by Andrew McCall 19 Feb '02

19 Feb '02

Now that the license discussion is dying down a bit... I've been working on porting a couple of aps in house via WineLib over the past couple of days. While in general it's been great, I've decided that I would like these applications to have a more linuxy type of look and feel. (As well as other programs I run via Wine.) I started to look at the controls implementation in WineLib. (I'm a very newbie Wine Hacker here, so I had to do a bit of searching...) I've been working with the control code in wine/controls. Now, just to be sure that I'm looking at this the right way: It appears that the Win31 look is implemented in general, inside the drawcode for each control, while the WinME/NT look is implemented mostly in uitools.c. Is this correct? I've started small trying to change some of the L&F behavoir of the push buttons. (Doing simple things like creating rounded edges/etc...) I've come to a couple of conclusions while trying to do this. I think it might be a good idea to try to move more of the Win31 look inside of the DrawFrameControl function. Is there something I'm missing as to why this hasn't been done already? I have considered a few options for my app: the first being to implement the new look just as the Win31 look is implemented now. I dislike this because of the added complexity it would give the already complex button/control code. The best method that I currently see is to modify the DrawFrameControl code to be friendly toward adding different looks. A benefit of this approach is that it would allow much of the Win31 look code to be moved into the DrawFrameControl function, allowing aps using that function call to keep a similar look throughout. I believe this could be done by adding a swtich statement or using function pointers in the current DrawFrameControl and then reimplementing each of the relevant functions for my wanted new look. Perhaps each of the new sets of UITOOLSXX functions could be moved into a different file. (Win31UITOOLS, LinuxUITools, Win95UITools.) If noone else is working on this code, I'd like to see what I could do with it... It think it's a fairly nice place to start in Winehacking. Is there a codestyle guide FAQ around that I could look at? ===== ---- Andrew McCall - andrew(a)nrrds.com __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com

1 0

RE: License change vote results
by Patrik Stridvall 19 Feb '02

19 Feb '02

> > I thought that Jeremy's suggestion of wine-legal was a > better idea... > > Hmm. I had probably Uwe's requests for wine-license in mind more than > anything else, so must have missed that. But should we change the list > name now? I personally think that wine-license is a better name. There is very little reason to discuss other legal issues except for licenses and the license discussion might expand to other issues than just legal ones.

2 1

How do interrupts in wine work?
by Nog 19 Feb '02

19 Feb '02

Hi, I got this feeling that I'm absolutly wrong in this but here goes... The way that I see Interrupt handling in wine is that when a real-mode dos executable is loaded, the processor (or the os mabe?) is forced into v86 were the int xx intruction is not privilaged. In this mode an exception is issued when an int xx is encountered and is then handeld by the exception handler is dosvm.c. Which in turn checks if the we have a builtin handler for the interrupt and if so then we simply call its handler as defined in real_mode_handlers. But when the app switches to protected mode, the int xx instuction becomes privilaged and gets handeld by EmulateInstruction. In this function the 32-bit version is not implemented but the 16-bit version is (Is this correct (the one is 16-bit the other 32-bit)? If not then what does long_op symbolise?) Is it likley that this piece of code will ever get called? And if so then why does it assume that the insterrupt it is emulating is not builtin? What all of this probable garbage came from is: What will it take to emulate int xx from 32-bit code? nog.

2 6

Re: Jeremy makes a persuasive argument for LGPL (MS Kerberos stuff)
by Igor Furlan 19 Feb '02

19 Feb '02

On Tue, 19 February 2002, Sean Farley wrote: > > On Tue, 19 Feb 2002 12:17, Roland wrote: > > > At 09:07 PM 2/18/02 -0500, Anthony Taylor wrote: > > <snip> > > > >Take, for instance, Microsoft's attempted hijacking of the Kerberos > > >protocol. MS almost took an accepted standard, and almost perverted it > > > > Well, I think we are still better off as when M$ would have created their > > own protcol from scratch. They certainly have the money to do that. The way > > it is now, we just have to implement the extensions to be able to use > > M$-Kerberos. I don't see where the BSD license has brought any kind of > > disadvantage here. > > Actually, the open-sourced implementation changed their specification > and forced Microsoft into explaining what they changed, but my memory > about it is not the greatest. > > Sean > -------------- > scf(a)farley.org Yes.. they published their change... but they said in the same time that you are not allowed to implement it anywhere, because the changes are copyright-ed by them. It is basicaly the same as their "shared source" approach: you can see it but you are not allowed to use it. Igor

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 19 Feb '02

19 Feb '02

> First, and formost, we have now heard the oppinion of two big > (from Wine > POV) commercial players: Gav and Jeremy. Now, it was > painfully obvious to > me that Jeremy had the power of reason on his side, while Gav only a > strong emotional impulse. Since choosing the LGPL is a one way street, it is hard to not be emotional, when arguing against it. It is much easier for the LGPL propenents to be emotionally detached. If you lose now, ou can come back next month, next year or whenever and try again. The LGPL oppents can't for obvious reasons. > And there's reason for that -- the > LGPL make a > lot more sense for Wine. Still think that after reading my reply to Jeremy? > We've heard countless arguments why that's not that case. A > lot of them > where simply nonsense. The few that made some sense, were ALL > based on a > false premise: that Wine is a monolithic product. I have never believed that Wine is a monolithics product. > Now, this is a _fundamental_ point that is ignored over and over > again: Wine is a _collection_ of products, just like a Linux > distribution. Which means that the viral aspect of the LGPL _stops_ at > every DLL boundary. Very true and this significantly weakens any "protection" that the LGPL offers. > It is easy to see now that this does not > preclude most > commercial implementations. In fact, it encourages them givin > them a level > playing field. Just like Linux does. Perhaps, but at a terrible price. Read my reply to Jeremy. > People, for crying out loud, _think_ about it, and the conclusion will > jump right out at you. THIS IS WHAT WE WANT: > -- if a company invests a _little_ to improve a DLL, we > should have no > moral problem requireing them to contribute that back. Since > it's just a > little contribution, no business will be destroyed because of it. > -- if a company makes a huge improvement (like > Transgaming), they can > simply drop the original Wine code, and keep everything > propriatary. Now, > compared to the _huge_ improvement, the cost of > reimplementing the mostly > non-working Wine code should be trivial. > > Bottom line is: > -- are we raising the bar for comercial companies with a LGPL > licence? YES! > -- how _much_ are we raising it? BY A TRIVIALLY SMALL AMOUNT! > -- do we invalidate TG business model? NO! Somehow you seem to believe that all reasonable business models will strictly following DLL boundaries, but you have given. absolutely no proof of this, you just assume it. Face it the design of the Windows API are a terrible mess that doesn't follow DLL boundaries.

9 18

Re: Licensing Open Source in General
by Roland 19 Feb '02

19 Feb '02

At 10:03 AM 2/19/02 +0100, Bernhard Rosenkraenzer wrote: >It *IS* a fair point of view - if someone just adds a bit of value, why >should they be able to make loads of cash of the much bigger original work >without giving anything back? No one will make loads of cash by just adding a bit of value. Why? Simply because no one would pay them much for that. It would be simpler to add that bit of value yourself or hire a programmer to do that in a weekend. People would only pay for big improvements, like Lindows, they invested around 5 million AFAIK. >Selling a proprietary fork of an open source application is much more like >stealing a car, giving it a new paint, and then selling it. >The thief added value (the new paint), so by your argumentation, he >should be able to make money of it and what he's doing is perfectly ok. First of all, you cannot steal something that is already free. But lets apply the rest of your analogy: Suppose the car is under a BSD license, which means everyone can get one for free. Now, someone gets the car, gives it a new paint and sells that product. How much would you pay him? Of course, since you can get that very same car for free also, you would only pay him the amount equivalent for the paint + the work involved in painting. If he wanted to charge you 10.000 for the painted car, you would laugh on his face, get that car for free and paint it yourself over the weekend(or pay someone else to do that). But if he charged you 40 $, you would probably pay him, since he as a professional would do a better job and you wouldn't have to make your hands dirty. In effect that 40 would probably be cheaper than the money it would cost you to do the job yourself, if you also count the time investment necessary on your side. So I think this business model is perfectly ok! This is the great advantage of the BSD license. It enables business. With the BSD license applied to your analogy we soon would have lots of businesses created to enhance the car: Painting, Putting sound equipment to the car, increasing the engine power, etc...Customers interested in one enhancement or the other would be willing to pay for it. Eventually one enhancement would be so popular that a group of volunteers would integrate it into the original car. What would be the GPL equivalent in your analogy: you can have the car for free, but any enhancements you make have to be given back at 0 cost also. Now suppose a guy wants to make the paint job. He will have to make it for free! So no one would do that of course. The result of this would be that if you want to paint the car you will have to do it yourself. Or you have to wait till someone else wants to do it and give it back for free afterwards. The GPL discourages business... Of course there are still business models possible, though restricted, for example: you hire the guy for painting the car as you wish. But that means you pay him in advance. And if this has been done once...no one else has to pay for it again... > > The GPL prevents this from happening but where is the advantage in > > that? > >Forcing everyone to contribute, preventing this type of theft. As I said, you cannot steal what is already free. >They are, if they choose to go by sane licenses. >Releasing products as Open Source certainly hasn't hurt companies that >aren't scared of doing it. Hmm, that might be true in some cases, especially where the software requires some kind of specialized support, where you pay more for the support than the software itself. >The problem is that many companies refuse to even consider sane licenses, >not that they couldn't do it. I don't consider the xGPL to be that sane anymore. > > Personally I keep wondering if it would be that bad if we had a company > > producing a better version of WINE than the free one. Why should this be > > bad? > >- it would take users (and therefore potential developers) away from the > real version. If that was true no one would be making Mozilla, OpenOffice, even Linux. When Linux started the proprietary Unix was MUCH better. History showed, that the opensource Linux was capable of catching up with UNIX and even become better. >- why should someone who made just a couple of changes make lots of profit > from (mostly) someone else's work without giving anything back to that > someone else? It's certainly not fair. Read above again. If you want to make big money you will have to invest MUCH. It is fair to get a corresponding return for that. I dare to claim that Linux distributors have done a lot more for Linux >than Apple has done for the BSDs, partially because licenses forced them >to give back rather than just keeping things closed. I wonder how profitable the Linux distributions are...and will be in the long run... Roland

1 0

Jeremy makes a persuasive argument for LGPL
by dschwarz＠bellatlantic.net 19 Feb '02

19 Feb '02

Well, I'm fairly convinced after reading his argument that LGPL is the right way to go. I think it's better for the Wine project over the long term. For those companies who have built a business model on closed source enhancements to Wine, there is still a way to play the game: At some point Wine is going to improve to the point where the core code works well enough to do almost everything we need. There will always be room for improvement, but the action may shift to reimplementing Microsoft applications that have important APIs (Internet Explorer, Windows Media Player...). I'm sure that Microsoft will change its EULAs to prohibit use of applications such as MSIE on a Non-Microsoft OS. It has already started doing this for some programs. Companies could respond by selling open or closed source reimplementations of these applications, bundled with a LGPL Wine. There will always be plenty of ways to add value on top of the core Wine code. Meanwhile, LGPL ensures that core code improvements will flow back to benefit all, not just those individuals and companies that have an altruistic bent. Regards, Daniel Schwarz dschwarz(a)bellatlantic.net http://www.winecentric.com http://winecentric.com/wiki

9 11

RE: Licensing Open Source in General
by Patrik Stridvall 19 Feb '02

19 Feb '02

> On Mon, 18 Feb 2002, Roland wrote: > > > I think one of the main reason for the xGPL is that > developers have the > > fear that their project might be hijacked and their work > used to make > > profit by some companies. As Brett Glass pointed out, this > is not a fair > > point of view. After all if a companies adds value to a > project by creating > > new features why shouldn't it be allowed to sell it and > make money out of > > it? > > It *IS* a fair point of view - if someone just adds a bit of > value, why > should they be able to make loads of cash of the much bigger > original work > without giving anything back? If somebody just adds a _bit_ of value and are able to make loads of cash on it I or somebody else are very likely to be easily able to duplicate the effort. Try again. > Selling a proprietary fork of an open source application is > much more like > stealing a car, giving it a new paint, and then selling it. > The thief added value (the new paint), so by your argumentation, he > should be able to make money of it and what he's doing is > perfectly ok. First of all copyright and theft have very little to do with each other. Theft by it definition involves depriving somebody from his property. Secondly if the license is the current licence this is obviously legal. Thirdly if it just requires a little "paint" to it make money I or somebody else can duplicate that and make the money instead. > > The GPL prevents this from happening but where is the advantage in > > that? > > Forcing everyone to contribute, preventing this type of theft. What theft? There is no theft going on. With the LGPL copyright infringement might be going on but then as I have trying to explain in countless mails it is easy to circumvent it even with obviously "trickery" that is obviously legal. If you trust your lawyers there are even more "trickery" you can do. > > I think the GPL retricts software development because many good > > projects cannot be done by companies because they are not > allowed to use > > any GPL code as basis of their products. > > They are, if they choose to go by sane licenses. > Releasing products as Open Source certainly hasn't hurt > companies that > aren't scared of doing it. > > On the contrary: Stronghold used to be proprietary before Red > Hat bought > the company making it. Now it's open source and the moment > that happened, > the sales numbers actually went UP (and the price is still > roughly the > same). Stronghold was presumably a WORKING product. Wine is not. If you make comparisions compare situations that are similar. > The problem is that many companies refuse to even consider > sane licenses, > not that they couldn't do it. Well, if that is a problem a complex license like LGPL certainly isn't the answer. > > Personally I keep wondering if it would be that bad if we > had a company > > producing a better version of WINE than the free one. Why > should this be > > bad? > > - it would take users (and therefore potential developers) > away from the > real version. What potential developers? If the source is closed they can't work on it. If the source is available like Transgamings why should they work for them without pay. Why not do as Marcus did and look at the code and reimplement it in the main tree instead. :-) > - why should someone who made just a couple of changes make > lots of profit > from (mostly) someone else's work without giving anything > back to that > someone else? It's certainly not fair. Again, if somebody can make a couple of changes and make money I can duplicate it and make the money instead or for that matter post it on wine-patches.

1 0

Licensing Open Source in General
by Roland 19 Feb '02

19 Feb '02

Hello all, with the ongoing discussion about this topic has brought me to think about licensing open source(OS) in general. I think a broad discussion involving all major OS advocates is long overdue. I think there should be made a webpage somewhere to start discussing this topic on a serious basis. Two important licenses: 1. BSD-style 2. xGPL Many projects are started with the xGPL nowadays. It just seems natural. Any other license for open source looks unnatural at first glance. I think the popularity of Linux has contributed to this. But is the xGPL a good license? I think one of the main reason for the xGPL is that developers have the fear that their project might be hijacked and their work used to make profit by some companies. As Brett Glass pointed out, this is not a fair point of view. After all if a companies adds value to a project by creating new features why shouldn't it be allowed to sell it and make money out of it? The GPL prevents this from happening but where is the advantage in that? I think the GPL retricts software development because many good projects cannot be done by companies because they are not allowed to use any GPL code as basis of their products. The sad thing is that this affects mostly small companies. Big companies can allow themselves to reinvent the wheel, coding everything they need. I think a lot of small businesses could do money out of open source if the licensing allowed this. Linus Torvalds wrote: "But _personally_ I don't want to do significant work under that kind of copyright and having to wonder whether the best version of Wine will be free in the future.." http://groups.google.com/groups?q=Ingo+Molnar+group:comp.emulators.ms-windo… Personally I keep wondering if it would be that bad if we had a company producing a better version of WINE than the free one. Why should this be bad? If you don't like it, you still can use the free version. And look at FreeBSD. AFAIK there is no proprietary version better than the free version. Apple based his OS X on lots of free software and contributed back a lot: http://developer.apple.com/darwin/ This wouldn't be possible with Linux I think. Best regards, Roland

4 3

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 19 Feb '02

19 Feb '02

> At 02:19 AM 2/16/2002, Patrik Stridvall wrote: > > >> So now you've made your point, constantly, how about we just > >> take it for > >> granted that for every email sent to the list saying 'the > gpl is good > >> because...' you and Patrik will reply with 'No! It's evil, > >> RMS is satan, > >> viral licensing, noone will use it, blah blah blah'.... > > > >I have never said that. > >I do admit that Brett Glass have said that. > > No, I never have. You haven't? OK, perhaps not word by word, but I fully understand if people interpret your position that way. I'm sorry if I sound a little angry but it seems that some of people have found me guilty by association with you and that irritates me quite a bit. What you are doing IMHO is pure fear mongering, it will not help the case against LGPL. I firmly believe that the GPL and the LGPL has a place in the world. However that place is not in Wine project. The LGPL is IMHO for libraries that are pure libraries and have all functions implemented. Wine fullfills neither the pure criteria nor the have all functions implemented criteria. In such cases this allows bugfixes to go back, but new functions can be put in the application or in a new library not nessarily in the library itself that have to be under the LGPL. Then companies can choose for themselves whether they want the LGPL protection for their new functions or not.

4 6

RE: TransGaming LGPL clarifications
by Patrik Stridvall 18 Feb '02

18 Feb '02

> > My LGPL concerns are: > > > > 1) We support copy protected CDs in our WineX binary > releases. This support > > This is a valid issue, and I am sure that the Wine community > would more > than happy to provide hooks for you for exactly this purpose. > There's no > other option in this case, so I don't think it' even an issue. Hooks is not possible because it would violate the paragraph 2d of the LGPL. At least according to Alexandre's interpretation of it. Every LGPL:ed function must do what every application expects even if the application (read: execution enviroment) doesn't provide the hook function. Since the hook function in the Transgaming execution enviroment would cause copy protected games to work, according to Alexandre's interpretation copy protected games must also work in the normal Wine execution enviroment that doesn't have the hook function. Of course Alexandre's interpretation might be wrong. However in that case wrapper libraries if definitively allowed and thus the LGPL is all but meaningless for new functionallity. Just put a new functionallity in a proprietary library and add a wrapper that calls it. In that case almost everything most LGPL proponents claim is good with the LGPL is gone. > > 4) Most importantly, the LGPL is a one way road. > > But that's one of it's features, you know... :) It's what gives people > piece of mind, Peace of mind. Ha ha ha. Allow me to laugh. Please, you can weld stuck the rudder of ship and claim that now that the rudder is stuck since we needn't argue anymore and now we can have peace of mind from the endless debates on where we should go. This is not what I would call peace of mind. > and what I feel creates the level playing > field. Whether this is true or not is basicly what the whole debate is about so this is just a unsupported statement of opinion. > Just PD, > and BSD are manyway roads. That is, this is not a valid > point. If you want > to argue that, we're stuck with BSD, period. Of course it a valid point: We can always change to LGPL later it will NEVER be to late. However can you say the same about changing now? > > That said, I believe that my WineCorp suggestions address > both my concerns as well > > as the issues raised by the LGPL camp. > > I personally despise the idea, On practical, and > phylosophical grounds. > And if we go that route, I don't think I'll follow. For the record: I'm not particular fond of the idea either, but mostly for practical reasons. I'm prepared to talk about it though.

1 0

GetStdHandle problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

After having some problems, I could recompile and link my programs using Wine. When running, The call to GetStdHandle(STD_OUTPUT_HANDLE) fails. It return 0. In windows enviroment this functions returns a numeric handle I use later to print onto the console. What's happening ? Is this a bug ? Can I solve it changing code ? Thanks in advance. Ignasi Villagrasa.

3 2

Re:compiling problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

Thanks for answering to everyone. The problem came from gcc compiler version. I changed it and the problem was solved. Ignasi Villagrasa.

2 1

Re: RESUBMIT: Some more Shlwapi ordinal routines
by Alexandre Julliard 18 Feb '02

18 Feb '02

"Guy L. Albertelli" <galberte(a)neo.lrun.com> writes: > > > dlls/shlwapi/ordinal-cmap.h <--- new file > > > - Has the 32k bytes that are returned by SHGetInverseCMAP. I'm a bit concerned about this one. Do you have an algorithm for generating it, or is it simply a dump of the native dll? This might get us in trouble. -- Alexandre Julliard julliard(a)winehq.com

2 1

Request for wine-license again
by Uwe Bonnes 18 Feb '02

18 Feb '02

Hallo, somebody asked not to send more than two messages regarding this thread. So sorry for my abuse now, but a zillion messages regarding that thread have been exchanged since my last mail... Please, can we have a wine-license list? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 3

RE: Clarification on my call for license change
by Patrik Stridvall 18 Feb '02

18 Feb '02

> At 08:58 PM 2/15/02 +0100, Patrik Stridvall wrote: > > >Just because you might possibly be right as far as CodeWeavers > >are concern doesn't nessarily mean that it is good for Wine. > > > > > >Yes and it makes sense that you do because increasing > >the amount of freely available Wine code can only benifit > >you, since you can use it in other projects for other > >customers. > > > Patrik, doesn't this also benefit WINE? If we increase the > amount of freely > available WINE code this is certainly good isn't it? > So there is also a strong argument in favor of the xGPL in your post. If the code is under the LGPL it is not freely available in the same meaning as if it was freely available under BSD. For the end user it is true that it doesn't matter at least not short term. However in the long term if set of viable business models to cover the cost of producing new code are less, less code is likely to be produce. Of course this is not quite that simple because the LGPL forces companies that would have produced the improvement anyway to release it when they would have held on to it for competive advantage or whatever just in case. This amount of code coming from this group is almost impossible to measure how large it is, especially since there are ways to circumvent the LGPL if the need for competetive advantage or whatever is large enough. And no I'm not primary talking about interpreting paragraph 2d of the LGPL in clever ways. That is one way if course but it is probably to legally risky for most companies. You can for exampel build a layer between the application and Wine. Let say Windows API function Foo is not properly implemented. The you do: BOOL LAYER_Foo(DWORD flags) { if(flags & FLAGS_NOT_SUPPORTED_BY_WINE) { /* Implement flags not supported by Wine */ } else { return Foo(flags); /* Call Wine */ } } With some clever macros and/or inline functions you can transpartantly hide the existance of this layer for the application. This quite obviously do not violate the LGPL. Especially not paragraph 2d. So the LGPL will not force the, in the future, hopefully largest group of companies that uses Wine to release anything they would prefer not to release. The things that they don't care about they would anyway even under the current license to save money avoiding the work to maintain it. So frankly I can't really see the great advantages on the LGPL. I can see the drawbacks that I have meantioned before that people just seem to ignore. In short: With the good comes that bad (as always) and futhermore the good might be less than you expect.

1 0

RE: Clarification on my call for license change
by Patrik Stridvall 18 Feb '02

18 Feb '02

> On Fri, 2002-02-15 at 09:49, Roland wrote: > > At 08:19 AM 2/15/02 -0600, Jeremy White wrote: > > >Several people have asked me to clarify my original post. > > > > I just don't understand one thing: > > How does your company expect to make money once WINE is > xGPLed? If all your > > code has to be contributed back, why should I buy it from > your company? > > > > Well, for one, we have a proprietary product that links to > Wine; we would continue to sell that. > > For another, we would continue to sell services to organizations > who wish to use Wine, but can't because it isn't complete enough. > > And finally, we would sell services to organizations that need > to depend on Wine, but cannot do so without the assurance of > qualified support to back up that dependence. So you have answered the first question. CodeWeavers might survive. Good for you. But the second more important question was (in my words): Why should I buy a Wine distribution from you? If you are forced to contribute back everything I can just do: cvs update ; ./configure ; make install What I and other have been trying to say is that some business models like consulting business makes sense with a LGPL:ed Wine but others like Transgaming:s might not. Read what Gavriel wrote in his first(?) reply again.

4 3

compiling problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

I have several Win32 console applications. I want to migrate them to Linux, and have installed and configured Wine. My target is to migrate the programs via winelib. So I don't want to run my applications on the fly as windows binary code, but recompile them in Linux enviroment and use following WINE console display functions: WriteConsoleOutput SetConsoleCursorPosition GetStdHandle FlushConsoleInputBuffer SetConsoleMode ReadConsoleOutput ScrollConsoleScreenBuffer GetConsoleCursorInfo SetConsoleCursorInfo GetNumberOfConsoleInputEvents ReadConsoleInput The first step is recompile C modules, but I find unexpected errors. Here is the output I get recompiling code. In file included from /usr/comun/src/mc_vis32.cpp:201: /opt/wine/include/wine/wincon.h:25: parse error before `__attribute__' /opt/wine/include/wine/wincon.h:229: `PHANDLER_ROUTINE' was not declared in this scope . . . Inspecting code, I notice the error always relates to the typedef PHANDLER_ROUTINE. I don't find it in any include and don't know where it's implemented. But the compiler doesn't find it. Does anyone know where to find this definition ? Which include file should I add to compilation process ? Could anyone help me ? Thanks in advance. Ignasi Villagrasa. GRI S.L.

2 1

wineinstall broken
by Christian Jiresjö 18 Feb '02

18 Feb '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Downloaded the cvs this morning (2002-02-18) and found that tools/wineinstall wouldn't run properly. It will stop after the configure step since in the latest configure script generation of config.cache is disabled. Is the wineinstall script depreceated or should it be fixed? Is it the configure-script that should be fixed? A temporary fix is adding --cache-file=config.cache to CONFARGS in wineinstall to reenable config.cache generation. Mvh Christian Jiresjö Key ID / Fingerprint 0x7798D5A3 / 2743 5DC4 1618 F24C F265 3070 A070 5EF2 7798 D5A3 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBPHFBm6A7mjo2YYwkEQKYfQCaAs/wDd7MS3I62gDL/xmTSK4kSVkAoI7j TE+MfkYLdY7HGHKvJLl2RySm =karS -----END PGP SIGNATURE-----

1 0

RE: Clarification on my call for license change
by Patrik Stridvall 18 Feb '02

18 Feb '02

> First of all, let me say that my call for a change was not > based on a single mysterious event. It was triggered > by an event that I cannot discuss due to a confidentiality > agreement. More important, it is a culmination of a number > of events and disturbing trends which I can freely discuss. For the record: As far as I'm concerned, I do believe you, when you say that. This however doesn't mean that your conclusion is correct. In your case there is really two questions: Is LGPL good for CodeWeavers? Is LGPL good for Wine? Just because you might possibly be right as far as CodeWeavers are concern doesn't nessarily mean that it is good for Wine. > We've already discussed the concern with the InstallShield > related patches of Transgaming; I won't belabor > that now. But doesn't it bother anyone else that > Marcus spent 5 weeks redoing work that they already had? I think this perfectly illustrates the danger in believing that not giving back things that are not strategically important for a specific business model is a viable thing to do. That said, I do regret that Marcus had to spend time to in concrete terms illustrating that point. > Wouldn't you rather be able to better play Monkey Island instead? Actually no, I don't like Monkey Island. :-) Seriously, I don't think anybody believe that double work is good, so the answer is pretty obvious. > I have always felt that in order for Wine to progress, > it was important that changes to Wine be returned > to the Wine project. Yes, so far we agree. > It has always been clear to me > that if everyone returns the work, in the long run, > everyone benefits. I think the flaw in your thinking lies here. At first glance this seems to be an obviously true statement. However, if you analyze it more carefully, you will find that it is not nessarily so that the persons that benefits from the work are the same people that are able to do the work. This is not a problem if you have a free market, then the people that benefits for the work will hire those people that can do the work if the benefit outweights the costs. If futhermore some sort of work protection exist then you can more efficiently share the cost since you don't have to worry that somebody steals (read: copies) the work after it is done and can try to recoup the remaining, costs after you have done the work. In short: With work protection people able to do the work don't need to find enough people benefiting from a work to cover all the costs from start. The LGPL means that no work protection exists anymore you have to give the work back and thus people doing the work must have full costs covered before doing the work. You can absurdly enough compare it to a world without copyright protection. The arguments against using the LGPL for a project is basicly the same as the one for having copyright protection in the world. Now you probably think I'm a total nutcase. You will probably say: "The arguments for copyright protection can clearly not be the same as the one against LGPL." No they can't, of course not, but I didn't say that: Notice the difference of scale "for a project" compared to "in the world". This makes your statement below false, since it the dual of your statement, a IMHO good slogan for people that believes all information should be free is the following: "If everybody can use everybody else work, in the long run, everybody benefits" You see the similarity don't you? This is of course not a conclusive argument against the LGPL, I do not claim it is, but it still makes your statement false. > So, with each and every one of my major > customers over the past three years, I have had a major, knock > down, drag out fight over licensing. I have always > insisted that changes we make to Wine be returned to > Wine. This has meant (while in a sales situation) > explaining the complexities of BSD versus GPL > licenses. Yes and it makes sense that you do because increasing the amount of freely available Wine code can only benifit you, since you can use it in other projects for other customers. >From this doesn't follow that LGPL is a good license from Wine. It might marginally simplify your life at a terrible price. Some questions: Wouldn't abolishing copyright simplify your life? Probably? Right? Would you be prepared to pay the price? Probably not? Right? > Wine still requires huge capital investments to > make it work, and any company that is going to > invest hundreds of thousands of dollars is > naturally going to demand ownership of the resulting > work product. It it were LGPL, it would be > an easy negotiation - I'd just say "Sorry, can't > do it." End of story. If copyright didn't exists you could release the code anyway, but as I said you wouldn't want to pay the price would you? > I know that the naysayers will jump on this and say > "Oh, but then you wouldn't have had any customers, > they would have been scared away by the LGPL." > To this I respond very simply: bullshit. > I was there for each of these sales processes, > and each customer was primarily interested > in the end result, not in the nitty gritty > license details. The question is not whether LGPL scare away your customers, the question is whether it scares away other businesses from investing in Wine. Obviously specialist consulting services like CodeWeavers can survive in any market almost regardless of the rules of the market, as I explain in another mail. This is quite unintresting as far as LGPL is concerned though. > There is an analogy I recall from when I took > a physics and public policy class. If a physicist > stands up and says "It's a bad idea to build > chemical weapons" nobody will listen to the physicist's > opinion - they just get a different physicist to do the > dirty work. If, instead, she stands up and says "It won't work. > The inverse poleron field conclusively prevents that." > There is no more debate, and public policy moves on to protecting > chickens from acid rain or something else. Obviously, if something is impossible then it is. > So, my business is threatened, because CodeWeavers > is trying to be the best physicists in town. > If I, as a matter of principle, refuse > to work on chemical weapons, I lose business because > my customers hire different physicists who will > build chemical weapons. OK. I can see your point but that comes with as I said a terrible price. > Okay, let me drop the analogy and come back to > straightforward facts. If I believe in the LGPL, > and release all of my code to WineHQ under the > BSD despite that, then I am a fool. Transgaming, > Lindows, name your new competitor, each of them > can take the best of my work and use it in their > product. The world is not a simple place. There are few things that are 100% wrong or 100% right. Yes, you can get some "protection" but are you prepared to pay the price? > I'm sure Transgaming doesn't have any problem using any > of the great new Window management code or > Window messaging code we wrote. In fact, the > InstallShield 6 stuff wouldn't be *possible* > without that code. However, if I had it to do > over again, I would not have released that code > under the BSD license. Please note what Dimitrie O. Paun said that the LGPL only extends to the DLL boundaries. That was one of the few things everybody seemed to argee on, even Alexandre last debate. So even with LGPL, they could still have used it. the DCOM stuff they did was in another DLL. I must emphasize this. This is VERY IMPORTANT that you realize. > So, I think there are several fundamental problems: > > 1. The current license encourages forks. > > We have the WineX fork; I think that Lindows > is still formulating their strategy, but > they have publicly stated that they like > having some proprietary pieces, this certainly > suggests another fork of Wine. > > You can argue that the pain of maintaining > a separate fork is so great, and the work of > merging in the BSD code is so hard, that people will > just naturally contribute their code back. > > We do merges of six month drifts on a regular > basis; it's just not that painful (the last > one took Francois 2 days; the resulting bug > fixes probably took 3 or 4 days). The question is not how hard it is rather why they would want to waste any resources on it at all. Most companies would benefit very little from not submitting non strategic code. > If this argument held any water, then Transgaming > would have just been forced to contribute > the Direct3D and IS6 support back. The Direct3D stuff is quite seperate and the IS6 stuff are IIRC in quite seldom changed parts of Wine. Your real world example is not very good. > 2. The current license discourages competitors > from releasing their code. > > Since I believe in the LGPL, but compete with Transgaming > and Lindows, contributing my code under the current license > is like giving my competitors my very best and getting nothing > in return. > > You know, the concept of making money on Free > software is crazy > enough without enabling your competitors into the mix. > > And, much as Gav and I are friends, we do compete. I > have been > in > sales situations with embedded customers where gaming > expertise > was required. Now, Gav has the best of what I can do, and I > have > little or none of what Transgaming did. > > In hindsight, if I had it to do over again, > I would have held out all code we had done > over the past year or two. Where would Wine > and Transgaming be if we had done that? Hard to tell. But everything comes with a price. Will you pay it? And even if if you will. Should Wine? > 3. The current license is harmful to the growth > of Wine, because it creates a murky, uncertain ground. > > This is true for a lot of reasons. First, I think > we all sort of kind of hope that any corporate > Wine citizens will follow some sort of unwritten > ethical code of conduct. That is, we'd like > the corporate citizens to pitch in and help Wine > to grow. > > Having unwritten rules is foolish, IMO. > > The current license specifies: go ahead and do > anything you want - we don't care. But I think > we do care (*I* care). So corporate citizens > spend all their time worrying about this > middle ground of perception (how much time > do you think this debate is taking away from > my people, and the Wine hacking they could do?) > > Well, a Copyleft license provides potential > corporate citiziens with written rules. > > Second, it clarifies the code issues. Right now, > say I wanted to work on a game. Well, gosh, just > how should I do that? Should I work against the WineX > tree? But if I do that, I can't really talk about > it on wine-devel, and I can't really share my work > with others. Ah heck, maybe Transgaming will fix > my game. I'm just going to reboot over to Windows. > > And if you don't think that's a serious problem, > just look at the Wine project historically. Over > the past five years, game related patches have > overwhelmingly dominated wine-devel. Over the > past 12-18 months of Transgaming? Virtually dead. > > Add to that the new problem of CodeWeavers now > being unwilling to contribute their code under > the current license. > > In my opinion, all the developers will just throw > up their hands and go work on something else, and > I think that would be a great tragedy. Well we will see, however we should think both once or twice before going down the one way street that LGPL is. > I hope that helps. > > Looking back on this, I see nothing but kindling. > > If you want to raise a point or an argument that is a variation on > something we've heard before, just don't. > > And if you're not a contributor to Wine, please don't > respond at all. You can flame me privately. Or go find a different > mailing list. > > I would really prefer to hear only what Wine contributors > think about this. Well, I really hope I qualify. Read what I have written and think about it. > p.s. For the record, in my mind, Dan Kegel qualifies as a major > contributor to Wine. It is through his hard work that we > have a chance > that the U.S. court system will put into place systems that will make > Wine development easier and protect Wine from predatory action > from Microsoft. I guess that was I stab at me. As explaination I was irritated on all non-contributors that posted their crap, so I just happend to take it out on somebody whose name I didn't recognize, so I'm sorry that Dan Kegel happend to get in the way.

2 1

Scrollbar: Overflow
by Phillip Ezolt 18 Feb '02

18 Feb '02

Hi, I've been trying to fix up the code in controls/scrollbar.c to deal with overflow of a 32-bit int, but I've run into a problem. In my test application, InfoPtr->MaxVal= is 0x7FFFFFFF (The largest signed int). InfoPtr->MinVal = 0. However, in various places in the code "infoPtr->MaxVal-infoPtr->MinVal+1" is calculated. This wraps the value around and causes bad things to happen. Does anyone know if the "+1" is necessary? Something has to be done differently, because what is happening now isn't right. --Phil Compaq: High Performance Server Systems Quality & Performance Engineering --------------------------------------------------------------------------- Phillip.Ezolt(a)compaq.com Performance Tools/Analysis

1 0

Re: I've tried to change keyboard table.. No good...
by Björn Róbertsson 18 Feb '02

18 Feb '02

Please give us a solution! I see that the only "solution" for this has been Thomas' Quinots patch for x11lib, which only works for XFree 3.3.1 which is only available in some ancient ... well considering we'd prefer to run RedHat 7.X or SuSE 7.X or Mandrake 8.X running RH 5.0 is somewhat too old... I've done the Xmodmap thing and it does work for me, but I cannot suggest Linux as an alternative desktop solution. Bjorn Robertsson bjornr(a)nyherji.is

1 0

Re:compiling problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

Thanks for answering at first, Eric. I'm using gcc version 2.91.66, the default compiler for Red Hat 6.2, and this is the operative system I'm interested in.

1 0

Re:compiling problem
by Eric Pouech 18 Feb '02

18 Feb '02

> In file included from /usr/comun/src/mc_vis32.cpp:201: > /opt/wine/include/wine/wincon.h:25: parse error before `__attribute__' > /opt/wine/include/wine/wincon.h:229: `PHANDLER_ROUTINE' was not declared > in this > scope which compiler do you use? (name and version and which platform ?) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

1 0

Clarification on my call for license change
by Jeremy White 18 Feb '02

18 Feb '02

Several people have asked me to clarify my original post. I apologize for not replying sooner; to be honest, I have been hoping that the flames would die down, and I was very reluctant to fan the flames in any way. Further, I'm not sure if I have anything to add other than kindling. But, I don't mean to 'hide', so here goes. First of all, let me say that my call for a change was not based on a single mysterious event. It was triggered by an event that I cannot discuss due to a confidentiality agreement. More important, it is a culmination of a number of events and disturbing trends which I can freely discuss. We've already discussed the concern with the InstallShield related patches of Transgaming; I won't belabor that now. But doesn't it bother anyone else that Marcus spent 5 weeks redoing work that they already had? Wouldn't you rather be able to better play Monkey Island instead? I have always felt that in order for Wine to progress, it was important that changes to Wine be returned to the Wine project. It has always been clear to me that if everyone returns the work, in the long run, everyone benefits. So, with each and every one of my major customers over the past three years, I have had a major, knock down, drag out fight over licensing. I have always insisted that changes we make to Wine be returned to Wine. This has meant (while in a sales situation) explaining the complexities of BSD versus GPL licenses. Wine still requires huge capital investments to make it work, and any company that is going to invest hundreds of thousands of dollars is naturally going to demand ownership of the resulting work product. It it were LGPL, it would be an easy negotiation - I'd just say "Sorry, can't do it." End of story. I know that the naysayers will jump on this and say "Oh, but then you wouldn't have had any customers, they would have been scared away by the LGPL." To this I respond very simply: bullshit. I was there for each of these sales processes, and each customer was primarily interested in the end result, not in the nitty gritty license details. There is an analogy I recall from when I took a physics and public policy class. If a physicist stands up and says "It's a bad idea to build chemical weapons" nobody will listen to the physicist's opinion - they just get a different physicist to do the dirty work. If, instead, she stands up and says "It won't work. The inverse poleron field conclusively prevents that." There is no more debate, and public policy moves on to protecting chickens from acid rain or something else. So, my business is threatened, because CodeWeavers is trying to be the best physicists in town. If I, as a matter of principle, refuse to work on chemical weapons, I lose business because my customers hire different physicists who will build chemical weapons. Okay, let me drop the analogy and come back to straightforward facts. If I believe in the LGPL, and release all of my code to WineHQ under the BSD despite that, then I am a fool. Transgaming, Lindows, name your new competitor, each of them can take the best of my work and use it in their product. I'm sure Transgaming doesn't have any problem using any of the great new Window management code or Window messaging code we wrote. In fact, the InstallShield 6 stuff wouldn't be *possible* without that code. However, if I had it to do over again, I would not have released that code under the BSD license. So, I think there are several fundamental problems: 1. The current license encourages forks. We have the WineX fork; I think that Lindows is still formulating their strategy, but they have publicly stated that they like having some proprietary pieces, this certainly suggests another fork of Wine. You can argue that the pain of maintaining a separate fork is so great, and the work of merging in the BSD code is so hard, that people will just naturally contribute their code back. We do merges of six month drifts on a regular basis; it's just not that painful (the last one took Francois 2 days; the resulting bug fixes probably took 3 or 4 days). If this argument held any water, then Transgaming would have just been forced to contribute the Direct3D and IS6 support back. 2. The current license discourages competitors from releasing their code. Since I believe in the LGPL, but compete with Transgaming and Lindows, contributing my code under the current license is like giving my competitors my very best and getting nothing in return. You know, the concept of making money on Free software is crazy enough without enabling your competitors into the mix. And, much as Gav and I are friends, we do compete. I have been in sales situations with embedded customers where gaming expertise was required. Now, Gav has the best of what I can do, and I have little or none of what Transgaming did. In hindsight, if I had it to do over again, I would have held out all code we had done over the past year or two. Where would Wine and Transgaming be if we had done that? 3. The current license is harmful to the growth of Wine, because it creates a murky, uncertain ground. This is true for a lot of reasons. First, I think we all sort of kind of hope that any corporate Wine citizens will follow some sort of unwritten ethical code of conduct. That is, we'd like the corporate citizens to pitch in and help Wine to grow. Having unwritten rules is foolish, IMO. The current license specifies: go ahead and do anything you want - we don't care. But I think we do care (*I* care). So corporate citizens spend all their time worrying about this middle ground of perception (how much time do you think this debate is taking away from my people, and the Wine hacking they could do?) Well, a Copyleft license provides potential corporate citiziens with written rules. Second, it clarifies the code issues. Right now, say I wanted to work on a game. Well, gosh, just how should I do that? Should I work against the WineX tree? But if I do that, I can't really talk about it on wine-devel, and I can't really share my work with others. Ah heck, maybe Transgaming will fix my game. I'm just going to reboot over to Windows. And if you don't think that's a serious problem, just look at the Wine project historically. Over the past five years, game related patches have overwhelmingly dominated wine-devel. Over the past 12-18 months of Transgaming? Virtually dead. Add to that the new problem of CodeWeavers now being unwilling to contribute their code under the current license. In my opinion, all the developers will just throw up their hands and go work on something else, and I think that would be a great tragedy. I hope that helps. Looking back on this, I see nothing but kindling. If you want to raise a point or an argument that is a variation on something we've heard before, just don't. And if you're not a contributor to Wine, please don't respond at all. You can flame me privately. Or go find a different mailing list. I would really prefer to hear only what Wine contributors think about this. Jeremy p.s. For the record, in my mind, Dan Kegel qualifies as a major contributor to Wine. It is through his hard work that we have a chance that the U.S. court system will put into place systems that will make Wine development easier and protect Wine from predatory action from Microsoft.

17 29

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 17 Feb '02

17 Feb '02

> Patrik Stridvall wrote: > > > But the point I'm trying to make is that I can be in violation of > > > your RELICENSE. I can make a claim that YOUR work is > > > covered by the *GPL, so that your RElicense to me doesn't apply. > > > If this holds, then my original statement that you gave up your > > > copyright protection holds. > > > > I'm not sure I follow you. > > > > Yes, if my work is covered by *GPL, you can ALWAYS use it if you > > follow the conditions in the license. > > yes, even if it contradicts your relicense. If you "work on" > an *GPLed > product, what you do is automatically claimed by *GPL, thus you can't > make any license on your work that is *GPL free. The *GPL only claim parts that are considered a derived work of the *GPL work. So if I write a function A and use that to improve the implementation of a *GPL:Ed function B, the *GPL claims my function A under the *GPL because of the existance of code in B calling my function A and thus the work I distribute as a whole includes my function A as a derived work. However my function A in and of itself is not a derived work of the *GPL:ed work so the *GPL only claims the function A as a part of what I did above. This means that I can relicense the implementation of function A under another license and the *GPL can't claim any indepedent modifications to it since it is not by itself a derived work of the *GPL:ed work. > > Of course, if you later decide that oh well following the *GPL > > is not that bad in comparison after all, it is possible and > > even probably that I can't sue you for breaking the relicense > > as long as you follow the *GPL. > > and if your are relying on your copyright protection to allow you > to benefit on the relicense, you don't have it in this case. > Remember also that the *GPL is pretty much irrelevent so long > as you are > not distributing to the public, so it's not a great cost to choose to > go that route. If you are not distributing to the public you don't need a relicense, the *GPL only forces you to release your work if you distribute to the public. > > The point it that you must show that you follow either *GPL > > or my relicense in order to not be a copyright infringer. > > You don't have to follow both though. > > It's a little different, because I think the burden of proof is > different. Pending on the what you have in your relicense, it's > easy to show that the receiver is covered because they have the > software. On a GPL violation, you have to show that what they are > doing with the software is in violation of the license - which might > be much harder to show. I think we are coming to much of topic by discussing the burden of proof. The point is that if you distribute without the permission of the *GPL or my relicense you are a copyright infringer. Whether in pratice I can detect it or prove it, is irrellevant as far as choosing a license for Wine is concerned.

1 0

Update: Compiling with Winelib and msvcrt
by David Walser 17 Feb '02

17 Feb '02

I modified the winemaker command I issued to: winemaker --console -I/usr/include/wine/msvcrt -I/usr/include/wine/wine -L/usr/lib/wine -lmsvcrt -lkernel32 --single-target ex3 . and now: c++ -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o ex3.so ex3.o ex3.spec.o -L/usr/lib/wine -lmsvcrt -lkernel32 -L/usr/lib -lwine -lwine_unicode -lwine_uuid -lm -L/usr/lib/wine ex3.o: In function `main': /home/walser/cosc/450/ex3/ex3.cpp:25: undefined reference to `GetSystemTime' /home/walser/cosc/450/ex3/ex3.cpp:43: undefined reference to `GetSystemTime' test -e ex3 || ln -s /usr/bin/wine ex3 so that's progress. I thought GetSystemTime was in kernel32, and doing strings on it shows it is (as well as in several others). What should I be linking in for GetSystemTime? Thanks.

1 0

Compiling with Winelib and msvcrt
by David Walser 17 Feb '02

17 Feb '02

Hi, I'm trying to compile a simple Win32 console app ( http://luigiwalser.homeip.net:8080/~walser/cosc/450/ex3/ex3.cpp if you want to see it). I did: winemaker --console -I/usr/include/wine/msvcrt -I/usr/include/wine/wine -imsvcrt.dll --single-target ex3 ./configure --with-wine-libraries=/usr/lib --with-wine-includes=/usr/include/wine --with-wine-dlls=/usr/lib/wine --with-wine-tools=/usr/bin But make ends like this: gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/include/wine/msvcrt -I/usr/include/wine/wine -I/usr/include/wine -o ex3.spec.o ex3.spec.c c++ -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o ex3.so ex3.o ex3.spec.o -L/usr/lib -lwine -lwine_unicode -lwine_uuid -lm ex3.spec.o: In function `__wine_exe_main': /home/walser/cosc/450/ex3/ex3.spec.c:52: undefined reference to `__wine_get_main_args' /home/walser/cosc/450/ex3/ex3.spec.c:53: undefined reference to `ExitProcess' ex3.o: In function `main': /home/walser/cosc/450/ex3/ex3.cpp:25: undefined reference to `GetSystemTime' /home/walser/cosc/450/ex3/ex3.cpp:36: undefined reference to `_beginthread' /home/walser/cosc/450/ex3/ex3.cpp:37: undefined reference to `Sleep' /home/walser/cosc/450/ex3/ex3.cpp:43: undefined reference to `GetSystemTime' /home/walser/cosc/450/ex3/ex3.cpp:47: undefined reference to `Sleep' /home/walser/cosc/450/ex3/ex3.cpp:49: undefined reference to `Sleep' ex3.o: In function `threadWork(void *)': /home/walser/cosc/450/ex3/ex3.cpp:81: undefined reference to `Sleep' test -e ex3 || ln -s /usr/bin/wine ex3 Note: it is computer science HW but building it with WINE isn't part of the homework, so I'm not asking you to do my HW for me :o) http://facultyfp.salisbury.edu/taanastasio/COSC450/Spr02/Assignments/Exerci… is the assignment. Info about my WINE installation: It's WINE 20011226 compiled from Mandrake SRPMS, the packages I have are: wine libwine1 libwine1-devel wine-utils you can look on rpmfind.net if you want to see what they include. Can anybody please help me get this working? Last note: if this is a mailing list, I'm not subscribed to it. Thanks.

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 17 Feb '02

17 Feb '02

> > > if you have to give out an unlimited, royalty free license to your > > > work, I think it's not unfair to say that you have given up your > > > copyright protection. As the copyright holder, it's true that you > > > can relicense it to suit other licenses, but it's not clear to me > > > that you can clearly make a copyright infringment case if there is > > > an LGPLed copy in the public. > > Well if somebody uses my work in a way either not permitted by LGPL > > or explicitly permited by me through some other license I can't see > > why I can't sue. > > But the point I'm trying to make is that I can be in violation of > your RELICENSE. I can make a claim that YOUR work is > covered by the *GPL, so that your RElicense to me doesn't apply. > If this holds, then my original statement that you gave up your > copyright protection holds. I'm not sure I follow you. Yes, if my work is covered by *GPL, you can ALWAYS use it if you follow the conditions in the license. However if you for some reason can't or won't, you can ask me for a relicense. If you don't I can sue you for violating the *GPL. If you do, you have to follow the conditions of the new license otherwise I can sue you. Of course, if you later decide that oh well following the *GPL is not that bad in comparison after all, it is possible and even probably that I can't sue you for breaking the relicense as long as you follow the *GPL. The point it that you must show that you follow either *GPL or my relicense in order to not be a copyright infringer. You don't have to follow both though.

2 1

winsock.h vs. unistd.h
by Francois Gouget 17 Feb '02

17 Feb '02

Here's a patch that takes care of the current winsock.h vs. unistd.h incompatibility. I am only half happy with it as it means that winsock.h will include unistd.h if you have not done so already. This is the only way I see to support both #include <unistd.h> #include <windows.h> and #include <windows.h> #include <unistd.h> If the patch is modified to handle only the first case, then winsock.h does not need to include 'unistd.h'. Index: include/winsock.h =================================================================== RCS file: /home/wine/wine/include/winsock.h,v retrieving revision 1.39 diff -u -r1.39 winsock.h --- include/winsock.h 2002/01/29 02:55:41 1.39 +++ include/winsock.h 2002/02/17 18:53:38 @@ -63,6 +63,26 @@ # define WS_DEFINE_HTONL #endif /* __WINE_USE_MSVCRT */ +#ifndef USE_WS_PREFIX +/* One cannot include both winsock.h and unistd.h because their definition + * of gethostname() conflicts. This is normally not a problem in Winelib + * applications because unistd.h does not exist on Windows and thus Windows + * source code should not use unistd.h. + * But there are still situations where one may want to use both so we are + * taking some specific steps to avoid problems. + */ +# ifdef R_OK +/* unistd.h has already been defined */ +# define gethostname You_should_not_include_unistd_h +# else +# define gethostname unix_gethostname +# include <unistd.h> +# undef gethostname +# define WS_DEFINE_GETHOSTNAME +# endif /* R_OK */ +#else +# define WS_DEFINE_GETHOSTNAME +#endif /* USE_WS_PREFIX */ /* @@ -898,7 +918,9 @@ int WINAPI WS(connect)(SOCKET,const struct WS(sockaddr)*,int); struct WS(hostent)* WINAPI WS(gethostbyaddr)(const char*,int,int); struct WS(hostent)* WINAPI WS(gethostbyname)(const char*); +#ifdef WS_DEFINE_GETHOSTNAME int WINAPI WS(gethostname)(char*,int); +#endif int WINAPI WS(getpeername)(SOCKET,struct WS(sockaddr)*,int*); struct WS(protoent)* WINAPI WS(getprotobyname)(const char*); struct WS(protoent)* WINAPI WS(getprotobynumber)(int); -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

1 0

Re: Clarification on my call for license change
by Roger Fujii 17 Feb '02

17 Feb '02

David Elliott <dfe(a)tgwbd.org> wrote: > > but I have yet to see a successful mode that has no propriatary component. > At the moment, this is true. Most of the open source companies have at > least some proprietary software built on top of an open source foundation. [snip] > I think that in fact > it will become much more viable. The key is that in order to make this > model work you need to be selling to a market that is unable or unwilling > to provide their own support. As mentioned before, Red Hat may not be > doing great, but if you take into account that they have a very small > viable market (that is, the people actually willing to pay for support) > then they are doing pretty damn well. don't know about that. Considering their cost of goods conceptually is zero... As for support, I don't see it ever being a panacea for the industry. Various models for support have already been tried by commerical companies with varying levels of success. However, there's a really bad side to this model, as it puts the economic incentive on generating support calls - which means that there is LESS incentive for fixing bugs (even in site support, you're less apt to buy it if the program is trouble free). > > > It is these sorts of people and companies that we want to target. And > > > financially Patrik's money for his license or even the money form all > > > the wine developers would be nearly insignificant compared to a 100+ > > > seat site license. > > uh, how can you sell a N-seat site license with something that is covered > > by *GPL (since this would be a violation of the license)? If your model > > is to sell by seat, I would like you see the reasoning between the > > difference of a 10 seat license and a 100 seat license with the *GPL. > If you are selling support then you can most definitely sell per-seat. If that what they are doing (Selling a support contract for N seats). Hard to tell by the wording. > You cannot expect to sell a free product without some sort of value > added. That value can be a proprietary component or can be support for > free components or can be other stuff that no-one as yet thought of. If > your business model is to sell only what your customers can get for free > then you are really, really, really, stupid. no argument here. > > As I said before, if a copyleft is all that is needed, choose a copyleft > > that makes SENSE. LGPL may be convienient, but I have seen no rational > > argument in having the *GPL's brand of copyleft (other than it's widely > > used). I think the mozilla project would be a good place to look... > > > This is a very valid argument. Although realize that they are now > MPL/LGPL/GPL triple licensed. And the only reason I could see for having > the MPL in there was so Netscape can take the code and release > closed-source versions. maybe so, but I think that LGPL/GPL was ADDED because mozilla touched too many things under those licenses. MPL has a 1 year grace period, plus its copyleft is not nearly as viral. I'm not saying it's perfect, but is a good place to start. > This doesn't really work well for Wine as the codebase is not owned\ > by a single entity. well, that benefit wouldn't be realized, but there is more to the license. > If you have a copyleft license that you feel would make more sense for > Wine than the LGPL, please discuss it with us. There's a gazillion licenses. Haven't seen any concensus on what the license should have (just what it SHOULDN'T have). Would think anything FSF considers a weak copyleft would be something to look at IF you want a copyleft. Wonder if Gav has any opinions on a copyleft license... -r -r

2 2

Fun with argv
by Paul Millar 17 Feb '02

17 Feb '02

Hi everyone, I've been looking at the installer for Office97. You call setup.exe which runs acmsetup.exe with a bunch of options, specifically: 'E:\~MSSETUP.T\~msstfof.t\acmsetup /T Off97Pro.stf /S "D:\office\" ' Here, I've used single quotes to delimit the string. I'll carry on this convention because it will get confusing otherwise. The problem is build_argv() assumes the command line is suitably escaped (as from a bash command line, for example), and so mangles the above line to the following values: 'E:\~MSSETUP.T\~msstfof.t\acmsetup' '/T' 'Off97Pro.stf' '/S' 'D:\office" ' But, the fun continues as you can pass arguments to setup.exe, which augment the arguments passed to acmsetup.exe, so running: wine setup.exe 'a a' '"b "B' results in argv[] for setup.exe being: 'setup.exe' 'a a' '"b "B' setup.exe then calls GetCommandLineA, which returns: 'setup.exe "a a" "\"b \"B"' and then it tries to exec 'E:\~MSSETUP.T\~msstfof.t\acmsetup /T Off97Pro.stf /S "D:\office\" "a a" "\"b \"B"' A command line with both unix-style escaped quotes and normal text. The build_argv result is: 'E:\~MSSETUP.T\~msstfof.t\acmsetup' [...] '/S' 'D:\office" a' 'a "b' '"B' and subsequent call to GetCommandLineA returns: 'E:\~MSSETUP.T\~msstfof.t\acmsetup /T Off97Pro.stf /S "D:\office\" a" "a \"b" \"B' What a mess! >From what I can see, the problem is ENV_BuildCommandLine build a command line that is \-escaped (" => \" and \ => \\). Windows programs might use this as part of a WinExec call (as above), which in general is not \-escaped. The only way around this problem (I could think of) is to stop ENV_BuildCommandLine from \-escaping the command line. This implies that we cannot accept double-quotes on the command line as part of an argument. I have a patch which is a hack-and-slash to remove the \-escaping and the resulting build processes arguments consistently (and Office97 setup gets a bit further). However, someone's obviously gone to the trouble of coding in support for double-quotes, so is this needed? Is there an alternative solution? Cheers, Paul.

4 6

Re: Wine license change
by David Elliott 17 Feb '02

17 Feb '02

On 2002.02.09 18:31 Brett Glass wrote: > At 04:06 PM 2/9/2002, David Elliott wrote: > > >Yes, the purpose of LGPL is to force proprietary components to be in > seperate relinkable object files. > > I wouldn't call this its "purpose," just one of its many requirements. > The purpose of the FSF is to eliminate all commercial software and > compromise programmers' livelihoods (as Stallman specifically writes > in many places, including his "GNU Manifesto"). > Really???? The FSF's purpose is to elimnate all proprietary software???? Who'da thunk it? Is there someone who doesn't know this.. it's written all over the website.. jesus, you act like it's some big secret. > >The only symbols you'll have to export from these proprietary > > [Snip] > > Not proprietary, but commercial. > No, proprietary. You can both sell and develop free software as a commercial entity. End of discussion. Everything CodeWeavers has put into Wine is commercial, but it is not proprietary. I see you seemed to concede my point that you only need show the symbols you are exporting. > >And don't be concerned about looking at LGPL code either. I too develop > proprietary software and I develop some of that software using free > (LGPL) libraries. There is nothing preventing me from looking at the > source to these libraries I am using. > > Yes, there is. If you write anything like it -- ever -- the owner of the > copyright on the code you have perused can claim that what you wrote is > a derivative work and demand that you forfeit all rewards from it. This > is > one of the many hidden "booby traps" in the GPL and LGPL. > This is classic FUD. Fits the definition perfectly. Fear, Uncertainty, and Doubt. > As the licenses' viral spread has continued, the FSF and other zealots > have gradually gotten bolder and bolder. While they have not played this > card yet, they can -- and will -- if they see it as being to their > advantage > in their war against commercial software developers everywhere. > The FSFs purpose and goals are irrelevant. The Wine developers purpose and goals are what is relevant. I see you are clearly interested in not helping Wine, but instead making sure that Wine stays both free software and free for you to fold into proprietary products. -Dave

18 45

Re: Bug in ICO_ExtractIconExW
by Gerard Patel 17 Feb '02

17 Feb '02

At 03:01 PM 2/17/02 +0100, you wrote: >Hi, > >I have a systematic crash when browsing a folder which has a *.gz file >inside (for example using GetOpenFileName). <snip> >=>0 0x4082ba06 (ICO_ExtractIconExW+0x386(lpszExeFileName=0x403c4558, >RetPtr=0x405c59a8, nIconIndex=0xffffff69, nIcons=0x1, cxDesired=0x20, >cyDesired=0x20) [exticon.c:325] in libuser32.so) (ebp=405c5910) > 1 0x4082c1c5 (PrivateExtractIconsW+0xf5(lpwstrFile=0x403c4558, >nIndex=0xffffff69, sizeX=0x20, sizeY=0x20, phicon=0x405c59a8, w=0x0, >nIcons=0x1, y=0x0) [exticon.c:555] in libuser32.so) (ebp=405c5948) > 2 0x4082c251 (PrivateExtractIconsA+0x71(lpstrFile=0x405c5a20, >nIndex=0xffffff69, sizeX=0x20, sizeY=0x20, phicon=0x405c59a8, w=0x0, >nIcons=0x1, y=0x0) [exticon.c:578] in libuser32.so) (ebp=405c597c) > 3 0x4065ed8d (SIC_LoadIcon+0x3d(sSourceFile=0x405c5a20, >dwSourceIndex=0xffffff69) [iconcache.c:115] in libshell32.so) (ebp=405c59b8) > 4 0x4065eeb9 (SIC_GetIconIndex+0xb9(sSourceFile=0x405c5a20, >dwSourceIndex=0xffffff69) [iconcache.c:154] in libshell32.so) (ebp=405c5a00) > 5 0x4065f32c (PidlToSicIndex+0xcc(sh=0x403c48f4, pidl=0x403b6cb0, >bBigIcon=0x0, uFlags=0x0, pIndex=0x405c5b58) [iconcache.c:311] in >libshell32.so) (ebp=405c5b3c) Well, this value of 0xffffff69 is suspicious. I think that this code may be too optimist : BOOL HCR_GetDefaultIcon (LPCSTR szClass, LPSTR szDest, DWORD len, LPDWORD dwNr) { HKEY hkey; char sTemp[MAX_PATH]; char sNum[5]; DWORD dwType; BOOL ret = FALSE; TRACE("%s\n",szClass ); sprintf(sTemp, "%s\\DefaultIcon",szClass); if (!RegOpenKeyExA(HKEY_CLASSES_ROOT,sTemp,0,0x02000000,&hkey)) { if (!RegQueryValueExA(hkey, NULL, 0, &dwType, szDest, &len)) { if (dwType == REG_EXPAND_SZ) { ExpandEnvironmentStringsA(szDest, sTemp, MAX_PATH); strcpy(szDest, sTemp); } if (ParseFieldA (szDest, 2, sNum, 5)) *dwNr=atoi(sNum); ParseFieldA (szDest, 1, szDest, len); ret = TRUE; } RegCloseKey(hkey); } TRACE("-- %s %li\n", szDest, *dwNr ); return ret; } in this case, maybe you could try something like : if (ParseFieldA(szDest, 2, sNum, 5)) *dwNr = atoi(sNum); else *dwNr = 0; I'm not sure it's correct, since it would mean that Wine would always search for the icon 0 in the file. As I don't know what is the exact meaning of the icon number in the registry, I can't say more. However, it *should* not crash anymore (if I'm right) as at least dwNr would be initialized. Gerard

2 1

Bug in ICO_ExtractIconExW
by mehmet yasar 17 Feb '02

17 Feb '02

Hi, I have a systematic crash when browsing a folder which has a *.gz file inside (for example using GetOpenFileName). In my system, the icon of "gz" files are associated to an external "ico" file, I see it with --debugmsg +shell : warn:shell:ParseFieldA ("C:\\PROGRAM FILES\\POWERARCHIVER\\ICONS\\GZIP.ICO",0x00000002,0x405c574c,5) semi-stub. The crash happens in line 325 of exticon.c: RetPtr[i-nIconIndex] = LookupIconIdFromDirectoryEx( pCIDir, TRUE, cxDesired, cyDesired, 0); With Winedbg we see : i = 65386, nIconIndex = -151, nIcons = 1 and IconDirCount = 1 It seems to be linked to this bogus test (line 314): else if( nIconIndex < iconDirCount ) where nIconIndex(INT)=-151 and iconDirCount(UINT16)=1. I Hope this will help finding the correct solution. (Odd fact : when activating +relay there is no more crash ...) Mehmet YASAR --------------- Backtrace with Wine20020122 --------------- First chance exception: page fault on write access to 0x406059a8 in 32-bit code (0x4082ba06). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:4082ba06 ESP:405c5888 EBP:405c5910 EFLAGS:00210287( R- 00 I S - -P1C) EAX:00000000 EBX:408c9b78 ECX:405c59a8 EDX:00010000 ESI:ffffff6a EDI:ffffff69 Stack dump: 0x405c5888 (NTDLL.DLL.memcpy+0x31fb08): 405c58d4 00000104 ffffff69 405c597c 0x405c5898 (NTDLL.DLL.memcpy+0x31fb18): 00000020 40a29a58 40388974 403aafce 0x405c58a8 (NTDLL.DLL.memcpy+0x31fb28): 405c59cc 40a17878 00000000 4006c7ea 0x405c58b8 (NTDLL.DLL.memcpy+0x31fb38): 400aa1ba 400ae78d 401018d7 405c5a2e 0x405c58c8 (NTDLL.DLL.memcpy+0x31fb48): 40133efe 403b6cbe 405c5a24 00000000 0x405c58d8 (NTDLL.DLL.memcpy+0x31fb58): 00000000 403c40b8 408bffb5 00000f6e 0x405c58e8 (NTDLL.DLL.memcpy+0x31fb68): 0011: sel=008f base=4011a4e0 limit=00000fff 32-bit rw- Backtrace: =>0 0x4082ba06 (ICO_ExtractIconExW+0x386(lpszExeFileName=0x403c4558, RetPtr=0x405c59a8, nIconIndex=0xffffff69, nIcons=0x1, cxDesired=0x20, cyDesired=0x20) [exticon.c:325] in libuser32.so) (ebp=405c5910) 1 0x4082c1c5 (PrivateExtractIconsW+0xf5(lpwstrFile=0x403c4558, nIndex=0xffffff69, sizeX=0x20, sizeY=0x20, phicon=0x405c59a8, w=0x0, nIcons=0x1, y=0x0) [exticon.c:555] in libuser32.so) (ebp=405c5948) 2 0x4082c251 (PrivateExtractIconsA+0x71(lpstrFile=0x405c5a20, nIndex=0xffffff69, sizeX=0x20, sizeY=0x20, phicon=0x405c59a8, w=0x0, nIcons=0x1, y=0x0) [exticon.c:578] in libuser32.so) (ebp=405c597c) 3 0x4065ed8d (SIC_LoadIcon+0x3d(sSourceFile=0x405c5a20, dwSourceIndex=0xffffff69) [iconcache.c:115] in libshell32.so) (ebp=405c59b8) 4 0x4065eeb9 (SIC_GetIconIndex+0xb9(sSourceFile=0x405c5a20, dwSourceIndex=0xffffff69) [iconcache.c:154] in libshell32.so) (ebp=405c5a00) 5 0x4065f32c (PidlToSicIndex+0xcc(sh=0x403c48f4, pidl=0x403b6cb0, bBigIcon=0x0, uFlags=0x0, pIndex=0x405c5b58) [iconcache.c:311] in libshell32.so) (ebp=405c5b3c) 6 0x4065f3d2 (SHMapPIDLToSystemImageListIndex+0x72(sh=0x403c48f4, pidl=0x403b6cb0, pIndex=0x0) [iconcache.c:346] in libshell32.so) (ebp=405c5b68) 7 0x40677e61 (ShellView_OnNotify+0x3b1(This=0x403bd0c4, CtlID=0xffffff4f, lpnmh=0x405c626c) [shlview.c:1178] in libshell32.so) (ebp=405c600c) 8 0x4067850e (ShellView_WndProc+0x18e(hWnd=0x30034, uMessage=0x4e, wParam=0xffffff4f, lParam=0x405c626c) [shlview.c:1405] in libshell32.so) (ebp=405c602c) 9 0x408947a3 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405c6050) 10 0x4089483d (WINPROC_CallWndProc+0x8d(proc=0x40678380, hwnd=0x30034, msg=0x4e, wParam=0xffffff4f, lParam=0x405c626c) [winproc.c:167] in libuser32.so) (ebp=405c6080) 11 0x4089a46a (WINPROC_CallProc32WTo32A+0x8a(func=0x40678380, hwnd=0x30034, msg=0x4e, wParam=0xffffff4f, lParam=0x405c626c) [winproc.c:2439] in libuser32.so) (ebp=405c60a8) 12 0x4089aa32 (CallWindowProcW+0xb2(func=0x40b606d2, hwnd=0x30034, msg=0x4e, wParam=0xffffff4f, lParam=0x405c626c) [winproc.c:2646] in libuser32.so) (ebp=405c60dc) 13 0x40830727 (call_window_proc+0xd7(hwnd=0x30034, msg=0x4e, wparam=0xffffff4f, lparam=0x405c626c, unicode=0x1) [message.c:1351] in libuser32.so) (ebp=405c6138) 14 0x40831301 (SendMessageTimeoutW+0xe1(hwnd=0x30034, msg=0x4e, wparam=0xffffff4f, lparam=0x405c626c, flags=0x0, timeout=0xffffffff, res_ptr=0x405c61bc) [message.c:1721] in libuser32.so) (ebp=405c6198) 15 0x40831587 (SendMessageW+0x37(hwnd=0x30034, msg=0x4e, wparam=0xffffff4f, lparam=0x405c626c) [message.c:1801] in libuser32.so) (ebp=405c61cc) 16 0x4096b033 (dispinfo_notifyT+0x1d3(self=0x30035, code=0xffffff4f, pdi=0x405c626c, isW=0x1) [listview.c:330] in libcomctl32.so) (ebp=405c6234) 17 0x40971f9e (LISTVIEW_GetItemT+0x34e(hwnd=0x30035, lpLVItem=0x405c630c, internal=0x1, isW=0x1) [listview.c:5040] in libcomctl32.so) (ebp=405c62b8) 18 0x4096ed6d (LISTVIEW_DrawItem+0xed(hwnd=0x30035, hdc=0x860, nItem=0x1, rcItem=0x0, FullSelect=0x0, SuggestedFocus=0x405c67b8) [listview.c:354] in libcomctl32.so) (ebp=405c6748) 19 0x4096ffd5 (LISTVIEW_RefreshList+0x175(hwnd=0x30035, hdc=0x860, cdmode=0x0) [listview.c:3552] in libcomctl32.so) (ebp=405c67e4) 20 0x4097036f (LISTVIEW_Refresh+0xbf(hwnd=0x30035, hdc=0x860) [listview.c:3677] in libcomctl32.so) (ebp=405c6824) 21 0x4097633e (LISTVIEW_Paint+0x5e(hwnd=0x30035, hdc=0x0) [listview.c:8170] in libcomctl32.so) (ebp=405c6880) 22 0x40977a70 (LISTVIEW_WindowProc+0xdc0(hwnd=0x30035, uMsg=0xf, wParam=0x0, lParam=0x0) [listview.c:8922] in libcomctl32.so) (ebp=405c689c) 23 0x408947a3 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405c68c0) 24 0x4089483d (WINPROC_CallWndProc+0x8d(proc=0x40976cb0, hwnd=0x30035, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:167] in libuser32.so) (ebp=405c68f0) 25 0x4089aa4e (CallWindowProcW+0xce(func=0x40b604b4, hwnd=0x30035, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2650] in libuser32.so) (ebp=405c6924) 26 0x4087c494 (DispatchMessageW+0x134(msg=0x405c69a0) [message.c:1126] in libuser32.so) (ebp=405c6968) 27 0x40870b26 (IsDialogMessageW+0xb6(hwndDlg=0x20023, msg=0x405c69a0) [dialog.c:1533] in libuser32.so) (ebp=405c698c) 28 0x4086fe10 (DIALOG_DoDialogBox+0xa0(hwnd=0x20023, owner=0x10021) [dialog.c:1040] in libuser32.so) (ebp=405c69cc) 29 0x408701af (DialogBoxIndirectParamA+0x2f(hInstance=0x405e5000, template=0x40622a60, owner=0x10021, dlgProc=0x405ee730, param=0x403b7798) [dialog.c:1163] in libuser32.so) (ebp=405c69e0) 30 0x405ed76c (GetFileName95+0x10c(fodInfos=0x403b7798) [filedlg95.c:249] in libcomdlg32.so) (ebp=405c6a08) 31 0x405edc02 (GetFileDialog95W+0x352(ofn=0x1008c40, iDlgType=0x2) [filedlg95.c:467] in libcomdlg32.so) (ebp=405c6a6c) 32 0x405ed580 (GetOpenFileNameW+0x40(ofn=0x1008c40) [filedlg.c:1606] in libcomdlg32.so) (ebp=405c6a88) 33 0x01001dc1 (notepad.exe..text+0xdc1 in C:\winnt\notepad.exe) (ebp=405c6ce8) 34 0x010028bd (notepad.exe..text+0x18bd in C:\winnt\notepad.exe) (ebp=405c6d08) 35 0x408947a3 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405c6d2c) 36 0x4089483d (WINPROC_CallWndProc+0x8d(proc=0x100248f, hwnd=0x10021, msg=0x111, wParam=0xa, lParam=0x0) [winproc.c:167] in libuser32.so) (ebp=405c6d5c) 37 0x4089aa4e (CallWindowProcW+0xce(func=0x40b60640, hwnd=0x10021, msg=0x111, wParam=0xa, lParam=0x0) [winproc.c:2650] in libuser32.so) (ebp=405c6d90) 38 0x4087c494 (DispatchMessageW+0x134(msg=0x405c6dec) [message.c:1126] in libuser32.so) (ebp=405c6dd4) 39 0x01002a64 (notepad.exe..text+0x1a64 in C:\winnt\notepad.exe) (ebp=405c6e08) 40 0x01006576 (notepad.exe.EntryPoint+0x156 in C:\winnt\notepad.exe) (ebp=405c6ea4) 41 0x400d3b18 (start_process+0x1f8 [process.c:397] in libntdll.so) (ebp=405c6f38) 42 0x400d7307 (call_on_thread_stack+0x27(func=0x400d3920) [sysdeps.c:91] in libntdll.so) (ebp=405c6ff4) 43 0x400d74c0 (SYSDEPS_CallOnStack+0x14 in libntdll.so) (ebp=00000000) 0x4082ba06 (ICO_ExtractIconExW+0x386 [exticon.c:325] in libuser32.so): movl %eax,0x0(%ecx,%edx,4) 320 for( i = nIconIndex; i < nIconIndex + nIcons; i++ )

2 1

Newbie Trying To Get Ghost Recon To Install
by Joel Miller 17 Feb '02

17 Feb '02

Hello, I'm new to using WINE (and to these lists), so I apologize if this has been asked and answered already: Has anyone been able to get Ghost Recon to at least install? The autorun program came up just fine, but when I click the button to install, it promptly quits. I tried running the setup.exe program directly, and it gets as far as trying to setup and install shield wizard, and then gives me an error mesage box stating that it cannot load a certain dll. I do not recall the name of the dll, and I do not have immediate access to the GR installer -- I borrowed my friend's discs and manuals to see if it would work under WINE. When I found out last week that it wouldn't install, I returned them =-(. I might be able to borrow them again, though. I am running the latest WINE on this box: * SuSE Linux 7.1 * 1Ghz Athlon * SiS Mainboard * 256MB RAM * GeForce 2-MX (not using nVidia's drivers, just the ones that come with SuSE) * 60GB HD I am trying to set up an MS-Free game machine, so using an existing WhineDoze install just isn't gonna happen. =-) Any help offered will be greatly appreciated. Joel Miller

2 1

Re: ldconfig : ..... .so is not a symbolic link
by lawson_whitney＠juno.com 17 Feb '02

17 Feb '02

On Fri, 15 Feb 2002, Sylvain Petreolle wrote: > > ldconfig -v produces : > /usr/local/lib: libopengl32.so -> libopengl32.so libglu32.so -> libglu32.so libmsvcrt20.so -> libmsvcrt20.so libsane.so.1 -> libsane.so.1.0.7 ldconfig: /usr/local/lib/libwine_unicode.so is not a symbolic link libwine_unicode.so -> libwine_unicode.so.1.0 ldconfig: /usr/local/lib/libwine_tsx11.so is not a symbolic link libwine_tsx11.so -> libwine_tsx11.so.1.0 .... Not only that, but make uninstall make install is broken. I thought that would fix it, but I had to install the wine binary by hand, and the result is exactly the same. Where there were symbolic links before are now copies. Besides wasting file space, though, I don't see it does any harm. You get this mail by the latest Wine, ldconfig warnings and all. Lawson First shoot the arrow. Then draw the bulls-eye. - J. A. Soucy

4 5

RE: BSD, Gav, LGPL, Jeremy, and business
by Roger Fujii 17 Feb '02

17 Feb '02

> > if you have to give out an unlimited, royalty free license to your > > work, I think it's not unfair to say that you have given up your > > copyright protection. As the copyright holder, it's true that you > > can relicense it to suit other licenses, but it's not clear to me > > that you can clearly make a copyright infringment case if there is > > an LGPLed copy in the public. > Well if somebody uses my work in a way either not permitted by LGPL > or explicitly permited by me through some other license I can't see > why I can't sue. But the point I'm trying to make is that I can be in violation of your RELICENSE. I can make a claim that YOUR work is covered by the *GPL, so that your RElicense to me doesn't apply. If this holds, then my original statement that you gave up your copyright protection holds. -r

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 16 Feb '02

16 Feb '02

> > The *GPL extends the circumstances where I can take somebodies work. > > but isn't this notion rather frightening? Frightning? Have you been effected with Brett fear mongering? :-) I don't consider it frightning. Copyleft is a trade where someone was allowed distribute my work and did and as companation I can take his related work. Of course this is not always good as I have been arguing in countless mail, but that is another thing. Sometimes this is good idea sometimes it is not. > > > nor does it force you to give up your copyright (effectively). > > > > Neither does the LGPL you can still license the code to others > > under any license. You just have to give it back under the > > LGPL as well. > > if you have to give out an unlimited, royalty free license to your > work, I think it's not unfair to say that you have given up your > copyright protection. As the copyright holder, it's true that you > can relicense it to suit other licenses, but it's not clear to me > that you can clearly make a copyright infringment case if there is > an LGPLed copy in the public. Well if somebody uses my work in a way either not permitted by LGPL or explicitly permited by me through some other license I can't see why I can't sue. At least not unless you claim that Open Source == Public Domain, but that is something else entirely.

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Roger Fujii 16 Feb '02

16 Feb '02

> > while this is one *small* aspect of copyleft, the *GPL extends > > well beyond that. "fair use" does not allow you to redistribute > > work, > > Yes, it does, that it what fair use is: > The right to distribute somebody elses work or > part of work without a license under some > circumstances. you're right. I was just thinking in terms of backups and work as a whole. Good reading: http://www-sul.stanford.edu/cpyright.html > The *GPL extends the circumstances where I can take somebodies work. but isn't this notion rather frightening? > > nor does it force you to give up your copyright (effectively). > > Neither does the LGPL you can still license the code to others > under any license. You just have to give it back under the > LGPL as well. if you have to give out an unlimited, royalty free license to your work, I think it's not unfair to say that you have given up your copyright protection. As the copyright holder, it's true that you can relicense it to suit other licenses, but it's not clear to me that you can clearly make a copyright infringment case if there is an LGPLed copy in the public. -r

1 0

Re: Clarification on my call for license change
by Roger Fujii 16 Feb '02

16 Feb '02

Aric Stewart <aric(a)codeweavers.com> wrote: > The simple of it is.. you, Patrik, would not buy a Wine distribution > form us. Why would you? You are a developer, and a wine developer on top of that. What seems to be the most commercially successful mode on top of opensource is to have an opensource base and have a value-add component - but I have yet to see a successful mode that has no propriatary component. > It is these sorts of people and companies that we want to target. And > financially Patrik's money for his license or even the money form all > the wine developers would be nearly insignificant compared to a 100+ > seat site license. uh, how can you sell a N-seat site license with something that is covered by *GPL (since this would be a violation of the license)? If your model is to sell by seat, I would like you see the reasoning between the difference of a 10 seat license and a 100 seat license with the *GPL. > As a developer who has worked on far too many proprietary Wine trees and > seen all the fights the Jeremy has gone through. I want to be assured that > i can give my code back to the wine community. As I said before, if a copyleft is all that is needed, choose a copyleft that makes SENSE. LGPL may be convienient, but I have seen no rational argument in having the *GPL's brand of copyleft (other than it's widely used). I think the mozilla project would be a good place to look... -r

2 1

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 16 Feb '02

16 Feb '02

> Patrik Stridvall wrote: > > > No. If anything, it seems to be using licencing rules > > > to negate copyrights. It really wants to make a copyright > > > into "a right to copy it". Even taking what you say, if you > > > extend what is "fair" use, you obviously must be making it > > > less fair somewhere else.... > > > > As I said, very simplified. > > > > What I meant is that the mechanism that forces release of > > the extension of the LGPL (read: copyleft) is similar to the > > case where fair use is extended so I take legally take > > the work instead. > > while this is one *small* aspect of copyleft, the *GPL extends > well beyond that. "fair use" does not allow you to redistribute > work, Yes, it does, that it what fair use is: The right to distribute somebody elses work or part of work without a license under some circumstances. The *GPL extends the circumstances where I can take somebodies work. > nor does it force you to give up your copyright (effectively). Neither does the LGPL you can still license the code to others under any license. You just have to give it back under the LGPL as well. > > The copyleft mechanism forces "push" of the source code > > which is better in the case of software. > > > I by this wanted to illustrate that copyleft is not something > > inherantly "evil" as Brett Glass are apparently crusading against. > > I'll let Brett speak for himself (not like I can stop him :) ), but > I didn't see an argument that 'copyleft' was bad. It was the *GPL is > bad. Just as rms think proprietary programs are evil, Brett > and others > think that the loss of copyright protections are just as bad or worse. Perhaps. But as you said, let Brett speak for himself. > I'm not quite as concerned as Brett, as I think the viral > nature of the > *GPL will eventually be thrown out in US court. Yes, I think that too.

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 16 Feb '02

16 Feb '02

> At 02:38 AM 2/16/2002, Patrik Stridvall wrote: > > >I'm sorry if I sound a little angry but it seems that some > >of people have found me guilty by association with you > > Patrik, don't you see? We're both guilty of the same sin: > saying that everything does not revolve around the Earth. > While we have different views of how things DO work, > there's exceedingly strong evidence for what we say. Perhaps. But I think you seem to focus on worst case scenarios, many of them are IMHO unlikely to happend, which impacts negatively on your credebillity. > But because it's contrary to some people's "religious" > beliefs they would rather excommunicate us, suppress > what we have to say, or burn us at the stake than listen. I don't think it is quite that easy. I don't think most of them have an "religious" belief in the LGPL. I think they simple see it as a way to both eat the cake and have it while trivialize the price they have to pay in the order to acceive this. Note, however, that sometimes, but only sometimes, this price is actually worth paying, see below. > >What you are doing IMHO is pure fear mongering, > > No, it's not. I am making predictions based on what > has happened to other businesses in the recent past, > as well as sound economic principles. I'm not advocating > or attempting to induce fear. I do not believe that you try to induce fear, but by focusing on unlikely to happend scenarios you cause fear regarless. > But if the outcome does not > look rosy, it's because WINE really would head down a > very destructive path if it were (L)GPLed. Wine will survive regardless. However I very much fear that it might impact negatively on the willingless of companies to invest in the Wine market and thus reducing the speed which Wine develops with. Note that when Wine fully works (close to 100% of all Windows applications run) it will not matter what license we have, there will be no money in anything except support anyway and the LGPL will not hurt that. It is the way there that worries me. Note that we can always choose LGPL later, but after we have choosen it we can't go back. > >I firmly believe that the GPL and the LGPL has > >a place in the world. > > Their place, and purpose, has been stated by Stallman. > (Not in the licenses themselves, which are designed > to be deceptive, but in Stallman's words in his more > candid moments.) It is to turn publicly available > software into a weapon in his lifelong, personal > vendetta. Again, he has stated this explicitly > himself, and it is also well documented by third parties > such as Levy. Please, now you are fear mongering again. I care not whether I support Stallman or not. I care ONLY about what is good for Wine. > WINE should rise above this agenda and not become an > agent of it. What agenda? The GPL/LGPL works in ways that are almost the dual to fair use. Very simplified: It uses copyright to extend fair use. Fair use have an obvious place in the world. However trying to extend fair use to legalize (or rather rationalize) for example Napster like sharing of music clearly takes things too far. GPL/LGPL have an obvious place in the world. However it has close to the same price as fair use, it discourages investment in new works using classical business models and new business models need to be found. This is obvously not so easy, neither in music business nor in the software business. Possible, yes. Easy, no. Don't try to stretch my analogy to far. The point is this and only this: The GPL/LGPL have a place in the world for almost the same reasons that fair use have a place in the world. However if trying to extend fair use too far is not good, neither is trying it extend GPL/LGPL too far. While fair use is nessesary an author can't live of it. The same with GPL/LGPL.

3 2

RE: Clarification on my call for license change
by Patrik Stridvall 16 Feb '02

16 Feb '02

> Patrik Stridvall wrote: > > > The point is: > > - The 100+ seat company gains. (They get support). > > - Red Hat gains. (They get money). > > - I gain. (I get money). > > - But CodeWeavers, that did a lot of work on Wine, > > doesn't gain anything and they are becaused of the LGPL > > been forced to release all of their work. > > > > Sure they might gain back a few bug fixes if I had to > > do in order to fix a few small flaws, but then Red Hat > > probably would have let me release it anyway. > > A few bug fixes? If it is important enough that such a big > customer pays > Red Hat for developing something then I guess that it is not > only a few > bug fixes we are talking about here. Well, if they just want a support contract the applications they use probably works fine in usual case thanks to the works of others that I have download for free thanks to the LGPL and made a RPM for them. But OK there will probably more that a few bugfixes but somehow I think that most of the time will be spent telling ignorant users the obvious, that is what support usually is. The support money will also pay for me making new RPMs for them from time to time get even more stuff for free thanks to LGPL. Beside a simple support contract are not likely to allow for advanced fixes without extra money being paid. The point is that CodeWeavers will not get any money at all. > And that is to the advantage of > CodeWeaver then because they gain also fucntionallity they might have > needed to develop themself. Yea sure, but don't have too much hopes that it will be that much. Support means support not development. Beside Red Hat would probably have let me release the fixes back even if they didn't have too since the license was still BSD. If their applications works under Wine, there is no reason for me to implement any new functions.

1 0

RE: Clarification on my call for license change
by Patrik Stridvall 16 Feb '02

16 Feb '02

> > of it is not possible. If just somebody in the world realizes > > the flaw he can contact the companies in question and > > point this out to them and for a fee do the work of recompiling > > their application for them. > > You are assuming here, that any given customer will sit and > wait until a > suitable patch is released. That may be true for many and > that's what I > wrote about my earlier job in my previous mail. But if this is an > important feature than he will pay for it because he needs to. If this > is released for others this is no problem because for others > apparently > it may not be that vital otherwise they would have paid for it in the > first place. If you can get the fully cost from the first customer, yes. But often you can't. So you develop it for say 50% of the cost and hope that the rest of your customers will pay the rest. Usually this will work out fine. However with the GPL this is impossible. You almost must have the full cost upfront which means that you have to spend more time negotiating to get the whole cost covered. Worse sometimes you miscalculate how must something costs, but that it not that bad if the code is proprietary. Now when you know the cost you know what to charge the rest of your customers. > Another implicit assumption here is that customers pay for a > given piece > of code. In my opinion they are often not doing that. Instead they pay > for a service. They pay for the service that they have > someone whom they > can contact and who will code if neccessary. That is absolutely correct. However using the GPL would force me to charge everybody that calls the full cost for each improvement. Often the cost will not outweigh the benefit for them so no deal unless I can reduce the price somehow. With the GPL this is impossible. > So even if they use an OS > code that doesn't imply that they never again will pay for any service > based on the assumption that any given functionality they > will need will > turn up sooner or later. Of course not, but some smaller customer might not have so much money so they often hope somebody else will have the same problem and pay for it. > Most larger customers (and I think that's the > one who are intersting for business models) are not willing > to bet their > business on the fancy of some developers. They want to have plans they > can follow so they in turn can tell their customers when and > how a given > problem will be solved. That's why xGPL also works for companies. The problem is not whether it works or not the problem is the drawbacks. As I have said before sometimes this is worth it, sometimes it is not. > I was once arguing with collegues because they maintained that if MS > gave their code for Word to OS then nobody would buy Word anymore and > they couldn't make any money from it. I stil say, and that is > the point > here as well, that this is not true. Private indivudals won't pay > anymore, but usually they are not the money anyway. Really large > companies, with their own development staff might also choose > to develop > and maintain themself, and there may be some loss. But the majority of > smaller companies would still pay for the service of maintainence and > for adding features they need and I bet that even bigger companies who > could afford their own development wouldn't choose to do that. Why > should they? It's more sensible to let somebody develop that who know > about it. The code is there as an insurance should the > developer ever go > down, but not for developing by everybody else. Yes, sometimes this will work out fine, but as I said it comes with a cost and the GPL limits want and how you can offer things to market quite severly. The problem with things like Word processors is that few users use or need new features so the market for enhancements will be quite limited.

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 16 Feb '02

16 Feb '02

> Patrik Stridvall <ps(a)leissner.se> wrote: > > > > WINE should rise above this agenda and not become an > > > agent of it. > > What agenda? > > > > The GPL/LGPL works in ways that are almost the dual to fair use. > > Very simplified: It uses copyright to extend fair use. > > No. If anything, it seems to be using licencing rules > to negate copyrights. It really wants to make a copyright > into "a right to copy it". Even taking what you say, if you > extend what is "fair" use, you obviously must be making it > less fair somewhere else.... As I said, very simplified. What I meant is that the mechanism that forces release of the extension of the LGPL (read: copyleft) is similar to the case where fair use is extended so I take legally take the work instead. Of course fair use requires the use of "pull" which my be of less use if the work is compiled into a binary. The copyleft mechanism forces "push" of the source code which is better in the case of software. I observed that there are some theoretical similarites between fair use and copyleft. So seeing copyleft as some sort of contracted or licensed fair use makes sense. This suggest that a too broad fair use have similar problem that a too broad application of copyleft. And indeed both have the freeloader problem for example. I by this wanted to illustrate that copyleft is not something inherantly "evil" as Brett Glass are apparently crusading against. Like the case for fair use a little copyleft is good as long as you don't get to much.

2 1

LGPL, and real World
by Hetz Ben-Hamo 16 Feb '02

16 Feb '02

Gentlemen, I do not wish to interrupt the nice email party going on here, but I wish to bring an example in real life which might let people re-think their decision.... I'll try to be a simple as I can. The following case is totally fiction. For the sake of this email, lets say I'm a lead developer in a company caled qwerty-wine, and one of my customers want me to develop a software for his palm top tun Visio XP on it, for the field engineers. For the sake of this example, lets say I'm checking out wine cvs today. Now - lets say that now is May, Codeweavers had decided to switch to LGPL and lets say that I am their competitor and I just had become aware of a DLL which is not implemented, but it is (according to a co- developer) implemented in Wine under the LGPL tree, so it means I'm 2 "cvs" commands from getting their implementation... Now - what if my product is totally a closed source one and my client doesn't want to reveal a single source code line? then I have 2 choices regarding this DLL: 1. I can Ignore the DLL in the Wine tree and re-implement it from where it was before the license has been changed and I keep the changes since it already implemented in Wine tree (and my customer doesn't want to reveal code). 2. I can "steal" this code from the new LGPL wine tree, and saving myself 90% of headache how to implement it, and invest 10% of the time to change the code cosmetically to look different, so if CodeWeaver's wine DLL looked like: 1+2+3+4=10 Then my code will look like: 5+5=10 So the code is different, but it does same thing, and I still keep my code closed... Who's loosing here? CodeWeavers. I used their code and no one got nothing out of this. Nada. Zilch. Zero. All their investment on that DLL implementation went down, they'll have hard time to re-cap this investment. Lets say that CodeWeavers could drag me to court and I'll be happy to show the code to the Judge or any 3rd party mediator - what he'll see? he'll see completly 2 different implementations which give same results. I win the case and I can collect damages from CodeWeavers. I repeat again - all the above is a FICTION. I'm not a developer (I'm unemployed at the moment) and the whole case - I made it up (although I heard some people were interested to see Wine on Embedded). But you wouldn't know if your competitor will use this trick with your code, will you? TransGaming probably won't do it, but others? So yes, CodeWeaver have their full right to move their code to LGPL or whatever. Is it a smart move for the Wine development move? yes. Is it a smart move business wide? IMHO - no, but CodeWeavers is a private company, and it's Jeremy full right to decide what to do with their code. I support CodeWeavers (bought their crossover even if I used it for 2 days), Transgaming (I subscribed, even if their code doesn't make my games work yet), and Lindows (I'll keep my Redhat and multi user approach, thank you!) and I plan to continue to do so - but will CodeWeaver exists due to this move? for a long term - I'm not sure, although I surely hope to be wrong here.. Just food for thought... Hetz Ben Hamo

3 2

RE: Clarification on my call for license change
by Patrik Stridvall 16 Feb '02

16 Feb '02

> Patrik Stridvall wrote: > > > They turn to their respective distributor say Red Hat and > say that they > > are prepared to pay $XXX per year for a better supported Wine. > > Red Hat in turn hires me (or some other on this list) to do > this and I do: > > > > cvs update ; ./configure ; make install > > > > That is your problem. > > I fail to see why this should be a problem. Once the code is > written is > (basically) free to use by the one who wrote it (or ordered it, > depending on the agreements). Red Hat got his money in that > case because > it agreed to create that code. I was talking about the 100+ seat support contract CodeWeavers wanted. > You got your money because you > were hired > by Red Hat. If Red Hat chooses now to release the code it > still has the > money and you still have your money. The only problem would be if it > didn't release the code and some other customer would come along and > asks for the same thing to be developed. In that case it > might be worse > (but for Red Hat) because it can now get paid a second time, while it > won't get paid if the code is released. But that is a general > problem of > GPLed code and not specifically to Wine. I think that > companies working > with GPL code are well aware of that fact and their busines model must > accomodate that fact. The point is: - The 100+ seat company gains. (They get support). - Red Hat gains. (They get money). - I gain. (I get money). - But CodeWeavers, that did a lot of work on Wine, doesn't gain anything and they are becaused of the LGPL been forced to release all of their work. Sure they might gain back a few bug fixes if I had to do in order to fix a few small flaws, but then Red Hat probably would have let me release it anyway.

2 1

RE: Clarification on my call for license change
by Patrik Stridvall 16 Feb '02

16 Feb '02

> Roland wrote: > > > I just don't understand one thing: > > How does your company expect to make money once WINE is > xGPLed? If all your > > code has to be contributed back, why should I buy it from > your company? > > The same way many companies work also with their properiteary > code. You > know your code needs a feature but you don't have the time for > implementation because you have no customer who says he > really needs it. > Of course many customers may be gald to have it, but none is > willing to > pay for it. The someday a customer turns up who says he needs > that stuff > badly and he wants to know how much you charge for it. Then you > implement that feature, you might have implemented anyway > some day, and > once it is available you can give it to all your customers, or you can > charge a price that others are willing to pay even though > they wouldn't > have paid the develeopment price. I worked for a company that worked > exactly that same way Actually I work for a company that works this way as well for some of our products. > and this works also for GPL code as well. No, it won't. There is nothing save ignorance that would make the other customers pay for it when can have it for free. Granted most customers are ignorant (as far as software development is concerned). But building a viable business model of it is not possible. If just somebody in the world realizes the flaw he can contact the companies in question and point this out to them and for a fee do the work of recompiling their application for them.

2 1

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 16 Feb '02

16 Feb '02

> At 10:47 AM 2/16/2002, Patrik Stridvall wrote: > > >> If users are fully informed about what a Trojan horse REALLY does, > >> they may think twice about "running" it. > > > >Obviously everybody should be carefully before using a tool > >and study and understand for yourself what it really does > >an not rely on what other people say about it. > > > >But that doesn't mean that the tool inherits any > >"evil" purpose that the creator of it had in the > >process of creation. > > I disagree. A Trojan horse that, for example, trashes hard > disks or creates zombies for DoS attacks is fundamentally > bad. This is why it's called "malware." Compare the trojan to a weapon. It is the person that uses the weapon that does something illegal (or evil), regardless of whether the weaponed manufacturer had "evil intent. However regardless of whether the user or the manufacturer or both had "evil" intent the weapon is not "evil". A trojan for example might be used to make havoc in the enemys computer system. This is an act of war and is neither illegal nor "evil". > >I think the difference is that I don't consider Stallmans > >agenda unethical, only unrealistic. > > > >Forcing people to releasing small bug fixes is one thing > > It's a start down a slippery slope -- toward appropriating > any or all of their code at will. Well, if you are worried about the license of the C library that close to all Linux application links, you don't have to use it. I think it is entirely reasonable if a find a bug in the C library and fix it that I publish the fix as thanks for having privilage of using it for free. > >Yes, because the motor ways that can transport troups > >can also transport trade goods or people visiting > >other countries in friendship. The more trade the > >more interdepence and the less risk for war. > > Ah, but the government's terms won't let commercial > vehicles on the road. And why should they do that? And what is the analogy with either Nazi Germany or the GPL. > >> Yes, it can. You can forfeit your fair use rights via > >> a contract. And the FSF licenses are profferred contracts. > > > >That remains to be decided in court. > > Actually, no. Fair use rights can be signed away. > Non-disclosure agreements, for example, prevent people > from doing things that might otherwise be allowed > as fair use. Yes, but that have nothing to do with copyright or fair use for that matter. If you get hold of some work in trust you must of course keep that trust, but this have nothing to do with copyright at all. But claiming that some freely available work that I happend to download from site on the Internet that have a file with a license contains some obscure paragraph means that I have been entrusted that work is quite absurd and only in the US would a court even consider such absurd charges. Same if I would have bought the work in a shop. > >> >I don't think they will have much luck though, > >> >they have already tried to stretch the boundaries > >> >of copyright law with the GPL, > >> > >> This is another reason why the GPL is likely to be > >> ruled invalid. An attempt to use copyright law to > >> do anything beyond the purposes stated in the US > >> Constitution can be invalidated as "copyright abuse." > >> (This argument has been made in the Napster litigation > >> and Judge Patel has taken it quite seriously.) Certainly, > >> "turning copyright on its head" (these are Stallman's own > >> words for what a "copyleft" license does) would qualify > >> as copyright abuse. Hence, all "copyleft" licenses are > >> probably invalid and unenforceable. > > > >I think saying that the GPL is copyright abuse it taking > >it little far. > > Not at all. Read the case law. Type "copyright abuse" into > any search engine. I'm not particulary intrested. If you wish to invalidate the GPL fine, for me it is enough that Wine doesn't choose LGPL.

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Roger Fujii 16 Feb '02

16 Feb '02

Patrik Stridvall <ps(a)leissner.se> wrote: > > WINE should rise above this agenda and not become an > > agent of it. > What agenda? > > The GPL/LGPL works in ways that are almost the dual to fair use. > Very simplified: It uses copyright to extend fair use. No. If anything, it seems to be using licencing rules to negate copyrights. It really wants to make a copyright into "a right to copy it". Even taking what you say, if you extend what is "fair" use, you obviously must be making it less fair somewhere else.... -r

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 16 Feb '02

16 Feb '02

> At 03:50 AM 2/16/2002, Patrik Stridvall wrote: > > >Note that when Wine fully works (close to 100% of all Windows > >applications run) it will not matter what license we have, > >there will be no money in anything except support anyway > >and the LGPL will not hurt that. > > WINE is not likely to work more than 90% ever, due to > the facts that Windows is a moving target True, but useful application have little reason to use new Windows API unless it gives them something substantial so I don't imagine this will be a large problem once we are close to completion. As the Windows application market slow moves to Linux with the help of Wine, the Windows application writers are likely to avoid using new Windows API because of portabillity reasons. > and that > Microsoft is likely to patent defensively. That is an orthogonal problem to licenses. Of course with the LGPL various companies can't even make a deal with Microsoft, but then Microsoft are not likely to make any deals anyway. > >It is the way there that worries me. Note that > >we can always choose LGPL later, but after we > >have choosen it we can't go back. > > This is a concern. Indeed. > >> Their place, and purpose, has been stated by Stallman. > >> (Not in the licenses themselves, which are designed > >> to be deceptive, but in Stallman's words in his more > >> candid moments.) It is to turn publicly available > >> software into a weapon in his lifelong, personal > >> vendetta. Again, he has stated this explicitly > >> himself, and it is also well documented by third parties > >> such as Levy. > > > >Please, now you are fear mongering again. > > No, I am stating historical fact. A tool is a tool. As every tool it can be use for good or evil. The purpose of the creator is irrelevant in the real world. Only in fairy tales like the Lord of the Rings can tools be inherently evil. Like the One Ring that answers to his master Sauron alone and corrupts everybody else to evil. Therefore I have a half serious question to you: Do you believe that the GPL is like the One Ring that answers to his master Stallman alone, and corrupt everybody else to evil? "One License to rule them all, One License to find them. One License to bring them all and in darkness bind them" You don't seriously believe this do you? > >I care not whether I support Stallman or not. > >I care ONLY about what is good for Wine. > > Ethics, consumer choice, and the future of programming > as a profession all matter as well. It is not ethical > to focus only on the interests of one project. Ah, perhaps I shouldn't have formulated myself better. What I meant was that just because somebody is "evil" supporting _some_ of the things they support doesn't make you "evil" or unethical. Hitler supported building new autobahns (motor ways). I support build new autobahns (motor ways). However this doesn't make me "evil". > >The GPL/LGPL works in ways that are almost the dual to fair use. > >Very simplified: It uses copyright to extend fair use. > > The opposite is true. It attempts to deny fair use by programmers. No license can deny fair use. I think even in people in the LGPL camp agrees with me in this. > And GPL V3 will attempt to deny fair use by ASPs. I'm not sure that "fair use" is the correct term. First of all I personally make a difference between non-infringing use and fair use. At lot of people call both things fair use. What they are trying to do is to make some use that is tradionally considered non-infringing use to be infriging use. I don't think they will have much luck though, they have already tried to stretch the boundaries of copyright law with the GPL, so I predict that they will fail, it is not no much a question on how they formulate the license, it is more question on where the boundaries of copyright really is.

3 3

wine and debian - what's up?
by Dan Kegel 16 Feb '02

16 Feb '02

http://lwn.net/daily/woody-release.php3 says > From: Anthony Towns <aj(a)azure.humbug.org.au> > To: debian-devel-announce(a)lists.debian.org > Subject: [2002-02-16] Release Status Update > Date: Sat, 16 Feb 2002 12:23:18 +1000 > > Hi guys, > > The good news, and the bad news. > > The good news is that base is back in good shape. glibc, base-passwd and > rsync have all had their RC bugs fixed which is very pleasing. ... > > The bad news is that this means we're probably releasing soon, and that of > the hundreds of less important packages with RC bugs (eg, bugzilla, craft, > crossfire-{client,server}, epic4, fvwm95, gmc, gnome-admin, intuitively, > kdepim, moon-lander, tkdesk, wine, and xosview) will be getting randomly > ripped out of testing (in the case where bugs apply to the version in > testing, anyway). What this means, is that if packages you're interested > in have accumulated RC bugs (ie serious, grave or critical) you've almost > run out of time to get them fixed if you want them released. What bugs are they talking about with wine? I only saw one marked as grave: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=133540&repeatmerged=yes but this one looks worth responding to, too: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=98661&repeatmerged=yes It might be good for wine developers who like debian to have a look at the debian bug tracking system. The main problem appears to be being addressed, but a little overkill never hurt. - Dan

3 2

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 16 Feb '02

16 Feb '02

> >A tool is a tool. As every tool it can be use for good or evil. > >The purpose of the creator is irrelevant in the real world. > > Not so. When one is reverse-engineering a virus or Trojan horse, > for example, it helps a great deal to know what the creator > intended. > > And the GPL is, in many ways, a Trojan horse. (It's viral, too, > but that's another issue.) > > Programmers see the rhetoric at the top claiming that the license > will promote "freedom," and place it upon their code -- whereupon > its terms and conditions promote Stallman's agenda instead. > > If users are fully informed about what a Trojan horse REALLY does, > they may think twice about "running" it. Obviously everybody should be carefully before using a tool and study and understand for yourself what it really does an not rely on what other people say about it. But that doesn't mean that the tool inherits any "evil" purpose that the creator of it had in the process of creation. Sure there are trojan horses in the world intend or not intended and you should be careful what you use, that goes without saying. > >Therefore I have a half serious question to you: > >Do you believe that the GPL is like the One Ring that > >answers to his master Stallman alone, and corrupt > >everybody else to evil? > > You're being overly dramatic (and a bit silly) here. It was meant to be. I was just testing you. If you had answered yes, I would have known that further discussion was meaningless. > >> >I care not whether I support Stallman or not. > >> >I care ONLY about what is good for Wine. > >> > >> Ethics, consumer choice, and the future of programming > >> as a profession all matter as well. It is not ethical > >> to focus only on the interests of one project. > > > >Ah, perhaps I shouldn't have formulated myself better. > > > >What I meant was that just because somebody is "evil" > >supporting _some_ of the things they support doesn't > >make you "evil" or unethical. > > Alas, by using Stallman's licenses -- which are designed > to further his agenda to some extent no matter WHERE > they are used -- one is promoting something unethical. > One may not be doing so intentionally (just as one is > not being unethical if one votes for a corrupt politician > whom one does not know to be corrupt). But if you know > that you're supporting unethical activities and continue > to do so, then you are yourself not acting ethically. I think the difference is that I don't consider Stallmans agenda unethical, only unrealistic. Forcing people to releasing small bug fixes is one thing but forcing people to contribute considerably more will soon find that the willingless to contribute will decrease unless some external factor exists. > >Hitler supported building new autobahns (motor ways). > >I support build new autobahns (motor ways). > > > >However this doesn't make me "evil". > > I could invoke Godwin's Law here, but I won't. ;-) > > In the analogy above, suppose you find out that the > autobahns in question won't actually go anywhere that > citizens (including you!) want to go, but are designed > to support military invasions of other countries in > which many innocent people will be needlessly hurt > or killed. Do you still support them? Yes, because the motor ways that can transport troups can also transport trade goods or people visiting other countries in friendship. The more trade the more interdepence and the less risk for war. You can't have the good without the bad. > >No license can deny fair use. > > Yes, it can. You can forfeit your fair use rights via > a contract. And the FSF licenses are profferred contracts. That remains to be decided in court. Anyway such considerations are close to meaningless a license can only binding to anybody buying or downloading a work. IIRC a judge suggested that if somebody found a piece of work lying on the street he could do whatever he pleased with it. I can for example have my friend do it and access the work over the network on his computer or however. As far as fair use is concerned it will not consider how you got hold of whatever you claim fair use on. > >I don't think they will have much luck though, > >they have already tried to stretch the boundaries > >of copyright law with the GPL, > > This is another reason why the GPL is likely to be > ruled invalid. An attempt to use copyright law to > do anything beyond the purposes stated in the US > Constitution can be invalidated as "copyright abuse." > (This argument has been made in the Napster litigation > and Judge Patel has taken it quite seriously.) Certainly, > "turning copyright on its head" (these are Stallman's own > words for what a "copyleft" license does) would qualify > as copyright abuse. Hence, all "copyleft" licenses are > probably invalid and unenforceable. I think saying that the GPL is copyright abuse it taking it little far. As far as the viral aspects of it maybe, but not as a whole.

2 1

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 16 Feb '02

16 Feb '02

> My only issue is that both you and Patrik have made your > views more than > known, and it's obvious you hate the GPL and GPL-style licenses with a > vengance.. for whatever reason (which, as someone who has worked on > commercial projects involving the GPL, are not - in my experiance and > opinion - based in any substanciated fact whatsoever).. Please do not find me guilty by association. I'm sorry to say it but I don't think Brett Glass have helped my case at all, rather the opposite, because it seems obvious that many people seem to have a hard time seperating the various anti-LGPL view. I personally do not hate the GPL nor GPL-style licenses, I think they have a place in the world, but that place is not nessarily in the Wine project. I have tried to explain why throught countless mails so I will not do it again, just say that I'm not in the I-hate-the-GPL-club rather in the I-don't-think-your-understand-the-price-you-have-to-pay-club or the I-don't-wish-to-pay-the-price-club if you prefer. > So now you've made your point, constantly, how about we just > take it for > granted that for every email sent to the list saying 'the gpl is good > because...' you and Patrik will reply with 'No! It's evil, > RMS is satan, > viral licensing, noone will use it, blah blah blah'.... I have never said that. I do admit that Brett Glass have said that. However _I_ do not agree.

3 3

RE: Clarification on my call for license change
by Patrik Stridvall 16 Feb '02

16 Feb '02

> On Fri, 15 Feb 2002, Daniel Walker wrote: > [...] > > Wine is a _re_implementation .. 90% of the code we > write is double > > work, triple work sometimes .. It doesn't bother me that we had to > > rewrite something, since after all that is what we do.. > Wouldn't we have > > it easy is Microsoft would just release their source? The > real question > > is, if Wine was GPL'd would TransGaming have written the > DCOM code in > > the first place? > > No, the real question is whether Transgaming would have written the > DCOM code if CodeWeavers had not released its typelib code in > the first > place. Is typelib code really in the same DLL as DCOM code? Note, I haven't checked, just asking. > Because it seems to me that one of the main arguments of the BSD > proponents is that we are stupid and that we should have kept all the > code for ourselves. Maybe they are right. What I mean is that you, as every other company, must formulate a business stratergy and from this decide what code is strategic and what code is not. If you decide for example to be a pure consulting company, releasing all code might make sense since you get paid anyway and a better Wine means larger potential market and thus potentially more customers for you. If like Transgaming you wish to improve DirectX, it might makes sense to release non-DirectX code since they don't really have a business model that makes it possible to recoup such costs. This I think was made painfully obvious for Gavriel by Marcus reimplementation of what they did. > But which of the > following two > scenarios leads to the more healthy Wine and Wine marketplace? It depends on what the market want and are prepared to pay for. Since the market is unlikely to pay for random bug fixes, except in some circumstances like support contracts, random bug fixes have limited value. However releasing them for free, increases the value of other products in the market, including your own. Not only because some application will work better, but because a more stable "ground" increases the trust in that even seemingly working application really works. > * The one where we released our window-management code, did dll > separation work, added cross-process handle support, added > cross-process > messaging, released our typelib code (essential for InstallShield/COM > support), released our true-type support, improved winelib > and released > countless bug fixes. > > * Or the one where the public Wine has none of the above (unless new > volunters had magically sprung up out of thin air). There is no reason to state the obvious. But note that since it lies in your intrest to increase the quality and public intrest in Wine it might not been a bad choice. > Where would the first scenario, which appears to be what BSD > proponents advocate, leave the Wine community? I have said that you, like any other company, must consider what is strategic and what non-strategic code for you. It seems to me that Jermemy thinks that by using the LGPL he can both eat the cake and have it and I have tried to explain that this is not the case. By using the LGPL you will force yourself in the future to release code for the benefit of Linux distributions like Red Hat, SuSE, Caldera and Mandrake that are likely to will sign support contract for Wine with 100+ seat companies by strength of already having one for non-Wine stuff. Face it you will not have a chance against them. Even Lindows will have a hard time I predict. Sure you can still live by contracting and selling your proprietary products like CrossOver, but then you can do that even with the current Wine license. > Which one do > Transgaming > and Lindows prefer? Why don't you concentrate on your own situation without worrying about others. > Do they really prefer not to benefit from > any of our > code in the future? There is no reason to ask questions with obvious answers. > The Wine competitive landscape has changed a lot in the past year, > and I believe that it is unpractical for us to continue releasing all > our code under the current license. That may be, but from that doesn't follow that the LGPL is the answer. > We could definitely turn our Wine proprietary but as the above > scenario illustrates this would be bad for the Wine > community, including > for our competitors; even if they don't realise it. And I believe that > all Wine companies need a thriving open-source Wine. Agreed. > That's why I think it is important for us (Wine community + > CodeWeavers + Transgaming + Lindows) to find a better solution. Yes, but the LGPL is not the answer. In his initial question Jeremy was talking about CopyLeft, not nessesarily LGPL. Why not continue the discussion from that point?

1 0

Re: a small patch to wineshelllink
by Michael Cardenas 16 Feb '02

16 Feb '02

forgot this: Changelog - Added a check for file type to wineshelllink. If the file is an executable, add "Type=application" to the kde entry. ----- Original Message ----- From: "Michael Cardenas" <michaelc(a)lindows.com> To: <wine-patches(a)winehq.com> Sent: Thursday, February 14, 2002 3:24 PM Subject: a small patch to wineshelllink > I put this patch together, but once I did the diff against the current > cvs, I see that somebody has already fixed it. Here's a patch that is a > little more correct. > > It checks when an application is creating a desktop link and adds the > "Type=application" line if the link points to an executable. > ---------------------------------------------------------------------------- ---- > --- wineshelllink Mon Jan 14 10:32:12 2002 > +++ /home/michael/wineshelllink Thu Feb 14 11:42:29 2002 > @@ -70,9 +70,11 @@ > [KDE Desktop Entry] > Name=$xname > Exec=wine "$path" -- $args > -Type=Application > Comment=$descr > EOF > + > +(file "$path" | grep -q 'MS-DOS executable (EXE)') && echo 'Type=Application' > + > [ -z "$workdir" ] || echo "Path=\"$workdir\"" > [ -z "$xpmicon" ] || echo "Icon=$xpmicon" > } > @@ -187,3 +189,4 @@ > fi > > exit 0 > + >

1 0

out of memory?
by David Laight 16 Feb '02

16 Feb '02

After a few games of freecell, I get the following message output repeatedly on the terminal I ran wine from. err:local:LOCAL_GetBlock not enough space in GDI heap 01c7 for 136 bytes This is running Wine-20020122.tar.gz under NetBSD. I don't think any of the wine processes have hit any unix limits. Any thoughts ? David

2 1

Wineconf attendance
by Gavriel State 16 Feb '02

16 Feb '02

Since various people have been saying "I'll go if you go", I just want to let people know that Ove and I will both be going to the Wineconf. Maybe I'll bring my fencing equipment and we can settle the licensing debate properly with a duel. 8-) http://www.fencing.net/pages/clubs/ccg/images/sn_ath.jpg -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

4 3

Wine's path VS host path
by David D. Hagood 16 Feb '02

16 Feb '02

Due to circumstances beyond my control, I have an embedded system that I am developing that uses Windows based compilers. Unfortunately, WinNT bluescreens too much for me to be able to work, so I have ported the project to using Gnu Make, with the compilers being executed via Wine. The problem is that the compilers search the path for their sub-components (just like GCC does - the driver calls the preprocessor, compiler, assembler, etc.). Now, the location of the project within the filesystem is not fixed - it depends upon where the developer checks it out. The project has the compilers stored along with the code, so the project is "self-contained". The project has a shell script that sets several environment variables describing the location of the project, and adds the needed directories to the Unix path. However, Wine (wisely) does not make that path available to the Windows program, so when the compiler driver looks for the preprocessor, it bombs. As a work-around, I've stated the the developers must install the tools into a fixed directory, and add that directory to the Windows path as defined in ~/.wine/config. However, it would be nice if the setup shell script could add the tools directory within the project automatically to the Wine path. Has any thought been given to honoring a WINEPATH (or similar) environment variable, which would be added to the Wine path at runtime? On a related note: would it be possible to have a means to tell the wineserver process to "hang around" for a few seconds after the last wine process using it has terminated? Again, in this make process you get lots of "start wine, start compiler, compile, exit. Start wine, start compiler, compile, exit" operations - if the wineserver stuck around for 2 seconds after the last wine process terminated, this would aviod starting and stopping the wineserver process.

5 9

Re: a small patch to wineshelllink
by Alexandre Julliard 16 Feb '02

16 Feb '02

"Michael Cardenas" <michaelc(a)lindows.com> writes: > - Added a check for file type to wineshelllink. If the file is an > executable, add "Type=application" to the kde entry. You can't do it that way, there is no guarantee that 'file' will return the same description on all machines. -- Alexandre Julliard julliard(a)winehq.com

2 1

brett glass
by Shane Shields 15 Feb '02

15 Feb '02

>The words of a man who has no intention, interest or desire to compromise. >"There is no need to compromise because my way is the right way." Brett, no >one >on this list that has read your posts fails to see your point. Some of them >disagree, some of them agree, but a) you have no formal say in the decision >(of >course, you're free to do as you've done and bemoan the issue) and b) you >have >shown no willingness to look at the points of view of the other members of >this >list who don't think the same way you do. >I think it's time you, to use a phrase, either put up or shut up. If you >want >people to listen to you more than you've listened to them, then write some >code. > Then, people might be more interested in what you have to say. Saying >"Well, >I *might* contribute, so long as you don't change the license" and presuming >that your vapourware-work is any sort of argument for people to listen to >you >and do what you want, is ridiculous, childish and egotistical. >We've heard your arguments and attacks on the FSF and RMS. Fine, you've >stated >your case and made your point. Now let the people that can actually make >the >decision make it. hear hear im glad that you said it. cause if you wasnt going to i was. some people like arguing for arguments sake but it takes two (or more) people to have an argument. if no-one was to reply to an unwanted solicitation then that outlet of expression will die a limp death. for people who enjoy vendettas and slander the best medicine is to deny them the satisfaction of knowing that they have produced a response. in other words dont respond to useless verbatribe and it will dissapear like butter on a hot plate. this is the only mail that you will see from me about this subject (no need to regurgitate useless code) best regards Shane Shields -- To drink the WINE of success you must first seek the sayings of source _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

RE: Clarification on my call for license change
by Patrik Stridvall 15 Feb '02

15 Feb '02

> > But the second more important question was (in my words): > > Why should I buy a Wine distribution from you? > > > > If you are forced to contribute back everything I can just do: > > > > cvs update ; ./configure ; make install > > > > What I and other have been trying to say is that some business > > models like consulting business makes sense with a LGPL:ed Wine > > but others like Transgaming:s might not. Read what Gavriel wrote > > in his first(?) reply again. > > > I have been avoiding this debate although reading it closely. > However i > thought i would step up to the plate on this one, as someone whose > salary depends on Jeremy's vision. > > The simple of it is.. you, Patrik, would not buy a Wine distribution > form us. Why would you? You are a developer, and a wine > developer on top > of that. If your critical app crashes you can just hack on > the code and > make it work. In fact we dont really expect anyone on this > list to buy a > Wine distribution from us. Yes, that is pretty obvious. > However if a company unfamiliar > with Wine, or > even linux wants to get a critical app working on Linux using > Wine they > have to choose. The could hire a developer and have that person figure > out wine and do the work, or buy a distribution of Wine supported by > proven Wine developers. > > It is these sorts of people and companies that we want to target. And > financially Patrik's money for his license or even the money form all > the wine developers would be nearly insignificant compared to a 100+ > seat site license. The problem is not that I or the other Wine developers don't pay. The problem is that the company needing a 100+ seat license runs Red Hat, SuSE or Mandrake or some other Linux distribution. They turn to their respective distributor say Red Hat and say that they are prepared to pay $XXX per year for a better supported Wine. Red Hat in turn hires me (or some other on this list) to do this and I do: cvs update ; ./configure ; make install That is your problem. Sure Red Hat might write a contract with you instead but then perhaps they consider you a competitor and hire me instead or perhaps they believe I'm better or whatever. > As a developer who has worked on far too many > proprietary Wine trees and seen all the fights the Jeremy has gone > through. I want to be assured that i can give my code back to the wine > community. Assurance about some things can be given but everything has a price. Will you pay it? Will it really do what you expect it does?

2 1

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 15 Feb '02

15 Feb '02

> On Fri, 15 Feb 2002, Patrik Stridvall wrote: > > > Still think that after reading my reply to Jeremy? > > Yes, I do. > > Listen Patrik, in the past you seemed to be a reasonable > person. Now you > are indistingushible from a troll. Really. It seems that whatever is > argued, you have a psychotic tendency to invent a counter-argument, no > matter how silly it is. Yes, I'm quite aware that some people consider my tendency of almost never giving up irritating. :-) But what do you expect me to do when I have a feeling that going to LGPL is a terrible mistake? If you don't understand it if I explain it one way, perhaps you will if I explain it another way, of course often I hope invain... > Now, that fun sometimes, but it has > gone too long, > too often in this bitter thread. For this very reason I have > avoided to > argue with you, but I will make this one exception, since the > thread has > progressed past useful long time ago. If you have made up your mind you have, but I'm arguing for people that haven't. > > Very true and this significantly weakens any "protection" > > that the LGPL offers. > > Which is a feature, and which should silence all reasonable BSD > supporters. BSD has the same feature so when comparing pros and cons this certainly doesn't weight in favour LGPL. > The ones that are left, simply ignore this very > important FACT > (It's emphesised since I don't want to argue it, let's assume > it for the > purpose of this discussion). Their is nothing to argue, BSD has the same feature. Obviously we should concerntrate on the relative pros and cons. > > Perhaps, but at a terrible price. Read my reply to Jeremy. > > Crap. What terrible price, WTF are you guys smoking, 'cause I > want some of > it! Once again: Wine is isomorphous to a Linux distribution. They are > growing MUCH faster than Wine ever did. They have a lot of commercial > backers. No Wine is not isomorphous to a Linux distribution. Wine will be an essential part of EXISTING Linux distribution. Sure there might be a market for new specialized ones like Lindows but don't have to large hopes. I'm sure there will be Linux distributions willing to offer proprietary extension to Wine if some company offers it. There is nothing strange about that, some distributions already bundle proprietary applications. > Stop this stupid, idiotic, "LGPL will kill all > business" argument. I have never said, that LGPL will kill all business models, now you are claiming things I never said. There are some people, none named, none forgotten in the BSD camp that he made similar claims, but please don't make me guilty by association. I have said that it will limit the possible business models severly. For example read Gavriels first reply or for that matter read my last reply to Jeremy again. Since the LGPL removes the work protection that the work have from copyright, it is almost essential that you get assurances that you get paid before doing the work. This is in most markets called contracting. > > Somehow you seem to believe that all reasonable business models > > will strictly following DLL boundaries, but you have given. > > absolutely no proof of this, you just assume it. > > Patrick, you are incorrigible. Yes, our purpose in choosing a > license is > not to support as many business models as possible. No. It is > to find a > licence that _overall_ is best for Wine. My point is that since the Microsoft DLL in general have no clear design the LGPL will articially for no good reason prevent some business models that you otherwise have been possible. This means that Microsoft arbitrary choices will prevent many otherwise possible business models. Is that good? Of course this requires that Alexandres analysis of the LGPL is correct, if he is not, you will lose most of the rest of the protection that the LGPL might provides. In that case you will have Wine under a close to meaningless license that will potentially scare away people not wishing to try their luck in court. > Now, we all agree that some > commercial involvment is good. The question is, how much? All possible > one? Like everything is life, the answer must lie in the > middle, not at > axtreme. Obviously. I have never claimed anything else. > So we must sacrifice a few business models to > benefit Wine. It's > just fare. An LGPL licence will keep most of them still > viable (such as > TransGaming, for example). WTF is your problem with it? My biggest problem is that because of way Microsoft have designed the Windows the sacrifice will be complete arbitrary. I'm not entirely against some sort of "copyleft", that is why I in my debate with David Elliot proposed that we could possibly have a license that makes it clear that linking to proprietry libraries are allowed. Possible we could add some paragraph about that the functionality must be a seperate part of DLL in some way. I don't really like it, but you were speaking about compromises....

1 0

Question concerning internal string usage
by Gerhard Gruber 15 Feb '02

15 Feb '02

Some functions are duplicated with their only difference being that one of them is wide character (W) and the other is ASCII (A). Of course it makes sense to convert one of them into the other and reuse the existing code. What I was wondering about, though is that, at least in the exmaple of files/profile.c the W functions are converting to A instead the other way around. Shouldn't we expect some problems with systems using wide characters or is this handled such that these characters are represented as more then one characters in ASCII? In Windows I'm pretty sure that A is always converted to W for such functions.

3 2

Re: BSD, Gav, LGPL, Jeremy, and business
by Roger Fujii 15 Feb '02

15 Feb '02

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > Can't you see that most Linux distributions _are_ made mostly of > xGPLed code, and that hasn't stoped a lot of proprietary companies such as > Oracle, SAP, IBM, etc. to release and develop code on this platform? This is an apples to oranges comparison. Things that CALL LGPLed libraries are safe. The problem is that things that work WITHIN a library is not. You can *say* that it stops at the DLL boundaries, but the license does not back what you say. The LGPL has a "work as a whole" clause that can easily be argued that it applies to anything within wine. So, while an installer for wine won't be affect by LGPL, any DLL that wine uses can arguably be considered a part of wine (unless you go through the pains of making sure that your DLL was added AFTER wine, and that the new wine works without your dll. If you want a LINUX analogy, look at device drivers. The *GPLness of the kernel means that no propriatary driver can be shipped as a part of any distribution. Steve Langasek wrote: > Since Jeremy has stated his intention to release future code changes only > under Copyleft, the decision for Wine contributors to make is a simple > one: do you believe that the benefits of potential additional corporate, > closed-source adopters of Wine outweigh the certain loss of code > contributions from Codeweavers, a known active contributor? ok... finally, a reasonable place to start, as it's finally an admission that the choices are exclusionary to some respects. re jeremy's posting: It's pretty obvious that there's animosity between transgaming and codeweavers. Peronally, I think the main problem here has very little to do with licensing, but rather that the commerical pie for wine is really only large enough to support 1.3 companies. So, let's just go over some of the points: > 1. The current license encourages forks. a) the forks already exists - do you think changing the license will fold in any of the forks? b) the forks are also signs of (new) development. Presumably, no one would fork something just for having a fork. > 2. The current license discourages competitors > from releasing their code. s/discourages/does not encourage/ > Since I believe in the LGPL, but compete with Transgaming > and Lindows, contributing my code under the current license > is like giving my competitors my very best and getting nothing > in return. So, are you saying that Gav is an insignificant contributer to wine? and that all the code inside with is 100% written by codeweavers? > You know, the concept of making money on Free software is crazy > enough without enabling your competitors into the mix. Think the problem here is that you guys are competing in the first place. If you were in different markets, one would think you could "trade" components into open source, thus reducing redundancy without having to risk your business. Also, I don't think it's unreasonable to ask (as a switch to LGPL might discourage Transgaming from ever releasing the dcom code - gav, will this affect your decision?) what exactly is codeweavers going to release LGPLed in the short term and why the urgency? > 3. The current license is harmful to the growth > of Wine, because it creates a murky, uncertain ground. > Well, a Copyleft license provides potential > corporate citiziens with written rules. LGPL is not the only license that's a copyleft. Just from cursory reading, MPL seems more reasonable that LGPL since section 3.7 makes a distiction between "covered code" and "larger work". Personally, if a simple "requirements" list is made, some choice can be made that isn't disagreeable to too many people (unless you have philosophical restrictions like "it can/can't be GPL compatible"). If copyleft and commercial viability is the only requirement, MPL would be a reasonable compromise. -r

2 1

Re: Jeremy makes a persuasive argument for LGPL
by dschwarz＠bellatlantic.net 15 Feb '02

15 Feb '02

Brett, Thanks for the email. I've read your argument, many times over on the wine-devel list. I don't buy it. Regards, Daniel Schwarz dschwarz(a)bellatlantic.net

1 0

BSD, Gav, LGPL, Jeremy, and business
by Dimitrie O. Paun 15 Feb '02

15 Feb '02

People, I am sorry I have to fuel the flames, but I have to say what I have to say. First, and formost, we have now heard the oppinion of two big (from Wine POV) commercial players: Gav and Jeremy. Now, it was painfully obvious to me that Jeremy had the power of reason on his side, while Gav only a strong emotional impulse. And there's reason for that -- the LGPL make a lot more sense for Wine. We've heard countless arguments why that's not that case. A lot of them where simply nonsense. The few that made some sense, were ALL based on a false premise: that Wine is a monolithic product. Now, this is a _fundamental_ point that is ignored over and over again: Wine is a _collection_ of products, just like a Linux distribution. Which means that the viral aspect of the LGPL _stops_ at every DLL boundary. It is easy to see now that this does not preclude most commercial implementations. In fact, it encourages them givin them a level playing field. Just like Linux does. People, for crying out loud, _think_ about it, and the conclusion will jump right out at you. THIS IS WHAT WE WANT: -- if a company invests a _little_ to improve a DLL, we should have no moral problem requireing them to contribute that back. Since it's just a little contribution, no business will be destroyed because of it. -- if a company makes a huge improvement (like Transgaming), they can simply drop the original Wine code, and keep everything propriatary. Now, compared to the _huge_ improvement, the cost of reimplementing the mostly non-working Wine code should be trivial. Bottom line is: -- are we raising the bar for comercial companies with a LGPL licence? YES! -- how _much_ are we raising it? BY A TRIVIALLY SMALL AMOUNT! -- do we invalidate TG business model? NO! I'll say this: if Alexandre will start maintaining a LGPL tree, I will submit my code only as LGPL. Everybody who believes even _a_little_ in an LGPL solution should do the same. -- Dimi.

2 3

RE: Clarification on my call for license change
by Patrik Stridvall 15 Feb '02

15 Feb '02

> Since Jeremy has stated his intention to release future code > changes only > under Copyleft, the decision for Wine contributors to make is > a simple > one: do you believe that the benefits of potential additional > corporate, > closed-source adopters of Wine outweigh the certain loss of code > contributions from Codeweavers, a known active contributor? Even so, since the LGPL is a one way street, remember that it might not always be so in the future. If we choose LGPL there is no turning back. Remember that always.

1 0

RE: Jeremy makes a persuasive argument for LGPL
by Patrik Stridvall 15 Feb '02

15 Feb '02

> Well, I'm fairly convinced after reading his argument that LGPL is the > right way to go. I think it's better for the Wine project > over the long > term. Read my reply the Jeremy. Do you are really think the price is worth paying? > For those companies who have built a business model on closed source > enhancements to Wine, there is still a way to play the game: > > At some point Wine is going to improve to the point where the > core code > works well enough to do almost everything we need. There will > always be > room for improvement, but the action may shift to > reimplementing Microsoft > applications that have important APIs (Internet Explorer, > Windows Media > Player...). > > I'm sure that Microsoft will change its EULAs to prohibit use of > applications such as MSIE on a Non-Microsoft OS. It has > already started > doing this for some programs. I don't think such paragraph are worth the paper they are written on and as long as the Microsoft trial is going on thet wouldn't dare even try. > Companies could respond by selling open or closed source > reimplementations > of these applications, bundled with a LGPL Wine. There will always be > plenty of ways to add value on top of the core Wine code. Will it? You don't think most of the market will be eaten up by the traditional Linux distributions (Debian, Red Hat, SuSE, Mandrake etc) and possible Lindows? > Meanwhile, LGPL ensures that core code improvements will flow back to > benefit all, not just those individuals and companies that have an > altruistic bent. Yes, but at a terrible price.

1 0

Re: Scrollbar Fix
by Alexandre Julliard 15 Feb '02

15 Feb '02

Phillip Ezolt <ezolt(a)perf.zko.dec.com> writes: > It converts the intermediate variables to floats instead of > int, which guarantees that multiplication of large values of don't > overflow. (with a small sacrifice of accuracy) You should probably use MulDiv() instead of floats. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: BSD, Gav, LGPL, Jeremy, and business
by Brett Glass 15 Feb '02

15 Feb '02

Correction to the message I just sent: "Finally, because the (L)GPL makes product differentiation at best and often infeasible or impossible" Should have been: "Finally, because the (L)GPL makes product differentiation at best difficult and often infeasible or impossible" --Brett

1 0

WINELIB is not defined
by Andriy Palamarchuk 15 Feb '02

15 Feb '02

To check whether an application is compiled under Wine I should use WINELIB macro, right? It seems the macro is not defined if I try to check on it in programs/notepad. Should I define it in the Makefile.in explicitely? I see that other programs, specifically winhelp, wcmd, progman, use conditional compilation blocks, based on the macro, but I did not find it defined in their Make files. Sorry for the newbie question, but I'm not sure how this is supposed to work. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Got something to say? Say it better with Yahoo! Video Mail http://mail.yahoo.com

2 1

RE: Clarification on my call for license change
by Patrik Stridvall 15 Feb '02

15 Feb '02

> > >Several people have asked me to clarify my original post. > > I just don't understand one thing: > > How does your company expect to make money once WINE is > xGPLed? If all your > > code has to be contributed back, why should I buy it from > your company? > > Hi, > > Companies will pay because they want certain functionality to > be implemented > that isn't there. For example, let's say you are company > Foo, who wants > their product "FooBar for Windows 2000" to work in Linux using WINE. > It makes use of some COM related functionality not currently in WINE > (like Out-of-proc objects or something) What do you do? > I mean, you can't just post on wine-devl and say "hey guys, > stop making > patches for DirectX, we want you to fix this COM stuff and NOW!" > No way. Do you get your internal staff to do it? Maybe. However, > most likely none of them know anything about WINE, so there is a big > ramp up time. Or do you hire an outside company to help you out, > a WINE developer-for-hire so to speak. That's why companies like > Macadamian and CodeWeavers get hired by clients, to get functionality > into WINE that would otherwise not get done. It allows the > client to focus > the fixes in the areas they need for their particular > application. Congratulations, you have just explained is why specialized consultants can make a living in the Wine market. However since this with a similar explaination is true in almost any market, I can't say I'm impressed. Sorry. That was perhaps a little rude. I was trying to illustrate a principle not insult you. It was not really aimed at you. > Sure, these > changes (optionally for BSD license, "required" for GPL) are > made available to > competitors, but as far back as I remember and for a while > yet I imagine > any moderately complex app will always require some fixes to > WINE to get > it to work perfectly. Yes, but sometimes this is what your client wants, sometimes it is not. Sometimes that client doesn't understand what is good for him and then you have the choice of explaining why or keeping you mouth shut. Your choice, sometimes this is better for you, sometimes it is not. Note however, what is good for you is not nessarily the same thing that is good for your client. Longterm that is. Short term the client pays you for your work regardless.

2 1

RE: ldconfig : ..... .so is not a symbolic link
by Medland, Bill 15 Feb '02

15 Feb '02

> -----Original Message----- > From: Sylvain Petreolle [mailto:spetreolle@yahoo.fr] > Sent: Friday, February 15, 2002 12:26 AM > To: wine-devel(a)winehq.com > Cc: wine-users(a)winehq.com > Subject: ldconfig : ..... .so is not a symbolic link > > > After updating this morning > cvs udpate -APd > rm config.cache > ./configure > make depend && make > > i get this when 'make install' : > what should i do ? (think i won't be the only one) Ah! I wasn't the only one. I went home last night and built a fresh wine and had the same thing happen to me. I thought it was because I had a screwed up system. As far as I understand it (google *IS* your friend) this is raised by ldconfig on occasions when it finds two identical so's that are explicitly saved rather than symbolically linked. However not always. In my case having removed all those messages (which I presume are actually warnings) ldconfig still didn't seem to detect my libuser.so for some reason (and possibly some others). (Actually they can't be warnings; initially it couldn't find libwprocs.so but that disappeared when I linked it to libkernel32.so, I think). Hopefully someone who knows what they are talking about will help us both out. Bill P.S. I don't suppose you tried a make uninstall and make install. DONT. make install won't work since the wine gets copied after the windedbg tries to copy from it.

1 0

Re: wine-devel digest, Vol 1 #745 - 13 msgs
by Roger Fujii 15 Feb '02

15 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > > I'd like to. But I will not release code under an FSF license, so I can > > only do so if I know that the project won't try to xGPL my work. > > You believe in releasing code under BSD-style licenses, but you refuse to > do so unless you have assurances that no one will create a GPLed product > from that code as allowed by the BSD license? I think there is a distinction to be made between RE-licencing and the "original" license. Given that we are possibly in an imminent change of the license, it is conceivable that a patch made now might not come out under a BSD license (really would depend on how the switchover would occur). Just as some people won't contribute to anything BUT *gpled projects, it's not unreasonable for other to have the opposite position. -r

1 0

ldconfig : ..... .so is not a symbolic link
by Sylvain Petreolle 15 Feb '02

15 Feb '02

After updating this morning cvs udpate -APd rm config.cache ./configure make depend && make i get this when 'make install' : what should i do ? (think i won't be the only one) /sbin/ldconfig: /usr/local/lib/libwine_unicode.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libwine_tsx11.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libwine.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libwineps.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libw32skrnl.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libsetupapi.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/liboleaut32.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libole32.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libmsvfw32.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libkernel32.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libgdi32.so is not a symbolic link /sbin/ldconfig: /usr/local/lib/libcomdlg32.so is not a symbolic link ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr

1 0

Re: Wine License change: Open question to Jeremy White
by Sylvain Petreolle 15 Feb '02

15 Feb '02

Hi, Last time you just said you had personal problems. Now you are just hiding away. When a company wants to have the money, there are not days or weeks, only hours. Re: Wine License change: Open question to Jeremy White From: Jeremy White (jwhite(a)codeweavers.com) Date: Fri Feb 08 2002 - 18:23:23 EST Next message: Andreas Mohr: "Re: Dr. Seuss, licensing, and WINE" Previous message: Andreas Mohr: "Re: Dr. Seuss, licensing, and WINE" In reply to: Roland: "Wine License change: Open question to Jeremy White" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] -------------------------------------------------------------------------------- Roland, I've just hit a very busy patch in my personal life. You've asked a fair question, and I will try to address it, but please give me a day or two. Thanks, Jeremy ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr

1 0

OT: Wine build system tech info
by Vassilis Virvilis 15 Feb '02

15 Feb '02

Halo wine-devel people, Although I understand you probably "enjoy" one of the best or worst f^H debates of all times (who said wine devel is immune to flamewars after all? :-) I would like to pose a somewhat off topic question but still quite technical. As part of a private investigation I noticed that both WINE and LINUX kernel build systems have a mkdep utility which generates in clude file dependencies. What I am looking for is to understand the reasons behind this decision for the two very popular projects instead the recipe suggested by GNU make documentation. Here is what GNU MAKE suggests as the preferred way to handle dependencies. #---------Makefile Start TARGET=a SOURCES=a.c b.c CFLAGS=-ansi -pedantic -Wall OBJECTS=$(SOURCES:.c=.o) DEPS=$(SOURCES:.c=.d) %.d: %.c set -e; $(CC) -MM $(CPPFLAGS) $< \ | sed 's/$$*$\.o[ :]*/\1.o $@ : /g' > $@; \ [ -s $@ ] || rm -f $@; $(TARGET): $(OBJECTS) include $(DEPS) #---------Makefile End This method has the several disadvantages: i) It is GNU specific (unportable): a) Needs accumulative dependencies. That means a.o: a.c a.o: a.h does not override the first entry but it means a.o: a.c a.h b) It requires the include statement c) It requires that MAKE will reload the Makefile as soon as it realizes that the Makefile or any of included file has been changed. d) It uses compiler specific features. ii) Speed. a) Files has to be parsed twice during compilation. b) Slight changes to config.h may result in unnecessary, uncontrolled compilations. --------------- I would like to know if there are any other reasons that is not listed here and or if any of the reasons listed above is more significant than the others. Thank you for your time. .Bill __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com

3 4

FW: Patch: Double-click support
by Michael C. Maggio 15 Feb '02

15 Feb '02

It looks like this patch wasn't applied to CVS and I didn't see any comments here in wine-devel. Before I resubmit I just want to make sure that it wasn't turned down for any particular reason. =Michael C. Maggio http://www.voyd.net/ -----Original Message----- From: Michael C. Maggio [mailto:voyager@voyd.net] Sent: Tuesday, January 15, 2002 1:27 AM To: wine-patches(a)winehq.com Subject: Patch: Double-click support This patch adds support for double clicking in Wine. The added function, _is_dblclick(), is invoked with each button-down mouse event. The event must be the same button (left, middle, or right), at the same X,Y position, and occur within 500 milliseconds from the previous event. The original button-down event is still invoked regardless of the double-click. Tested in Starcraft. :) Ideally, we may eventually want to determine the double-click delay time from the registry, as it is a configurable Windows setting. But this should serve the purpose in the mean time. One last tidbit of info - I did not add a function prototype to any header files given the limited scope of this function. Whether this deviates from the Wine Development Standard (tm), I do not know. Perhaps a local prototype is more suitable in this case for the sake of ANSI-C compliance. I would appreciate knowing, at least, what the preferred method of prototyping is. ChangeLog: Adds support for double-click events via _is_dblclick(). =Michael C. Maggio http://www.voyd.net/

2 1

Re: Dr. Seuss, licensing, and WINE
by Brett Glass 15 Feb '02

15 Feb '02

Rick Romero (rick(a)valeoinc.com) writes: >As long as I'm sending this, I might as well make a comment on the >license. We all know money makes the world go round. If the current >license makes WINE more enticing to businesses, it should stay with that >model. If the LGPL encourages investment (time or money), then WINE >should move that way. IMHO, it appears the current license is best in >the long run. I agree. >The biggest issue I've seen so far is people ego's going >out of control when they've shared their work with the public, and >someone else hasn't returned their share (and possibly making money off >of it). Perhaps a simple economic analysis would help to assuage those egos. If WINE is available at no cost to any user, its market value as a product (defined as what a willing buyer would pay a willing seller for a license to use it) is zero. No one will pay money for something that's readily available for free. (They might pay a small amount for the service of pressing it onto a plastic disc, but with today's Internet there's no need even to do that.) Yes, its intrinsic value is higher, but what matters to users is market value -- what they have to pay to get it. Given that the market value of WINE, as distributed at no cost over the Net by the WINE project, is zero, anyone who hopes to sell a version for money must add sufficient value to get users to pay for it. This added value must not only be worth the money that customers pay (or word will get around and the company will make no sales) -- it must also be enough to overcome the transaction costs that the user incurs (filling out a Web form, paying shipping costs, waiting for delivery, worrying about credit card fraud, picking up the package at the post office, etc). And the seller of the value-added product will have a tough time convincing the user that the added value is sufficient to warrant the purchase. Is the no-cost version "good enough?" As WINE improves, it will be -- for more and more users. Thus, anyone who hopes to create a value added version of the product has a tough row to hoe. He or she must add a LOT of value -- and also provide support services, infrastructure for distribution, a sales staff, marketing, and much, much more. And he or she must stay ahead of the no-cost version, which over time will likely duplicate the most important value added features of the commerical release. Finally (and most importantly), if users DO buy the value added product, every cent they pay will be not for the original product (whose market value, as entioned above, is tautologically zero) but for the value added by the vendor. Thus, no developer of WINE can claim that the vendor is "making money off of" WINE. EVERY CENT will be due not to what the WINE project did, but to the value added. If the vendor is able to make money at all (and it's a long shot), he or she thoroughly deserves it. And every copy sold will benefit the WINE project, because the project's reputation will be enhanced by the vendor's success and the vendor will become more and more able to contribute code back to the project. (The vendor MUST, of course, retain some of its code so as to provide unique value; otherwise -- again -- no one will pay and everything falls apart. But at the same time, it benefits from contributing code with less strategic value, because the project will maintain it.) It may be that the vendor won't be equal to the task of adding sufficient value to stay in business. But if he or she does, it's a win/win. The project benefits from an enhanced reputation and from code that's returned to it because it's in the vendor's interest to do so. It's thus in the project's interest to help, not hurt, the vendor. The (L)GPL destroys this delicately balanced symbiotic relationship by making it impossible for the vendor to add unique value. As a result, the scenario described above can't happen, and it's a lose/lose rather than a win/win. The only entity that wins is the FSF, whose stated purpose is to prevent any commercial software vendor from surviving. --Brett Glass

6 14

Re: Licensing response and an idea
by Lean Fuglsang 15 Feb '02

15 Feb '02

Thanks for an enlightening post, Gav. //DISCLAIMER - I AM JUST AN ORDINARY USER - SO DON'T READ IF YOU DON'T FEEL LIKE I am not a developer (yet). But I truly believe in the spirit of OpenSource Free software. I have reported some bug reports, but I would really like to contribute more. When I first heard about a (very) possible licens change to GPL I thought it was a great Idea, because I hate companies who take code and don't contribute back. With the current license this is possible. But I also think it would be a shame for companies with good intentions (as Transgaming) who (maybe:) will contribute all there code back, and make very fast directed code to wine. I would also be very delighted to pay money directly to the wine project because I like it and use it. An important note is that this is what I do with everything that I buy. When I by music, it is because I like it and have heard it and want's to support the artist. Same with movies. I know this is not the way the corporate world works at the moment, but I can pirate music/video/software very easily and therefore they have to trust me to pay for what I want's to pay to. Phew, hope I didn't confuse all of you (like I confused my self:) But the point is, I really like to make contribution to a gratis project if it is GPL'ed or dual licensed (for 'good' corporations). Many of the people I know has the same 'Ideology' as me, and don't pirate things they think aren't sh**t. And after I have changed to linux and opensource, I have actually pirated a lot less, because all stuff are free, and the things that aren't 'stands out', so to speak. Just my .02$ (and maybe more if it goes as I hope:) //lean Ps. Hope I send this mail to the right place

8 14

Re: Wineconf attendance
by Michael Robertson 15 Feb '02

15 Feb '02

We currently have 35 registered people not counting the inquisitive reporter who signed up. I believe all are from wine-devel list since that's the only place I've seen it mentioned. Companies represented include: - Codeweavers - Transgaming - ReactOS - Macadamian - Xandros - Cadlink Technologies - Caldera - DSSD Software Inc. - 2 Geeks Computer Systems - DeviceForge - Some big OEMs - Other companies - A bunch of unaffiliated people If you would like to do a company presentation, please let me know and we'll do our best to accommodate. On the technical track, since attendees will be the speakers please think about the topic that would be interesting that you are knowledgeable about. This is all about people leaving smarter than they came and that happens best with everyone sharing their information and ideas. One of the 3 people on the Frankfurt/San Diego express, Dr. Ulrich Weigand has volunteered to speak on the following two topics: - 16-bit Windows: how does the support for 16-bit in Wine work, how much 16-bit code is still there in Windows 95/98/ME, how are the various types of thunks etc. implemented, what are the chances of running native Windows 95/98/ME 16-/32-bit DLL pairs under Wine (this would include the user.dll question Uwe suggested) - Debugger: how does the Wine debugger work, details about the various debugging formats (including the undocumented .PDB format) ... The biggest request is to hear from Alexandre Julliard who is working on his keynote to open the event now which rumor has it is better than the opening ceremonies of the Olympics. Only one request for "fencing and WINE". Sorry Gav. :) -- MR Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

2 2

RE: drawtext should not split words on clipping
by Medland, Bill 14 Feb '02

14 Feb '02

> -----Original Message----- > From: Joerg Mayer [mailto:jmayer@loplof.de] > Sent: Thursday, February 14, 2002 2:42 PM > To: Medland, Bill > Cc: Wine patches (E-mail) I think we're supposed to discuss these on wine devel > Subject: Re: drawtext should not split words on clipping > > > I've only read the description, so maybe I'm guessing wrongly what the > path does. Sometimes it is preferrable to split a word in the > middle to > not splitting very long words (like URLS). Yes, but you don't split it by saying it should be clipped; you split it by specifying, for example, DT_WORDBREAK | DT_EDITCONTROL (which results in breaking within the word if the whole word doesn't fit) This is a small part of a long sequence of changes that, I believe, are required to make DrawText work correctly overall, especially when it comes to ellipsification and word breaking on multiple lines. (The current version believes that ellipsification is only done if DT_SINGLELINE is specified!!). Maybe there is some case where the existing code "worked" by accident and it doesn't now but if so then I believe it should be fixed properly (which won't really be possible until I've submitted a couple more major reworks). Actually it's getting difficult to figure out how to do the next stage without a 500 line delta, because somewhere along the line I think it requires a complete revamp of the core routine (and, tempting as it may be, I am not happy submitting 250 lines of code that aren't yet called but will be when I submit the next delta). I am perfectly happy to discuss this with anyone who wants to; otherwise please bear with me. I honestly believe I know what I am doing. Regards Bill

1 0

Re: WineCorp (was Re: Wine license change)
by Roger Fujii 14 Feb '02

14 Feb '02

David Elliott <dfe(a)tgwbd.org> wrote: > Thus what we really need is some entity that will always have an unlimited > license to the complete wine codebase to do with it as it decides. I > question assigning copyrights away from myself and to anyone else, is > there some reason why signing an unlimited use license wouldn't be > acceptable (and thus developers would still retain their own copyright) or > is that effectively how it works anyway? This scheme would make the license awkward, because you have to add in "oh, by the way, all the contributions you make will be given to winecorp with an unrestricted license" clause. It is far cleaner and simpler to require contributions to assign the copyright. OpenOffice does this. > Wine cannot stay X11 free-for-all forever. Reminds me of one of Roger > Ebert's columns about the movie "It's a Wonderfull Life". Because the > movie is now public domain, anyone can use the original print for whatever > purpose. This includes colorizing it and then selling the colorized > version for a lot of cash (thanks Ted... yeah right). The colorized > version is a bastardization of the movie and is one of those cases where > you almost wish that copyrights didn't expire. Especially considering that > the director and the much of the cast were still alive to see this > horrible, horrible thing. Wine is very much in the same position here. > While we are not quite public domain we are so close that any distinction > is a moot point. *GPL wouldn't prevent the above either. Any "open source" license would let the above happen. As I said before, "freedom means others can do what you don't like" -r

2 3

Re: shellexecute patch
by Andreas Mohr 14 Feb '02

14 Feb '02

On Thu, Feb 14, 2002 at 11:57:55AM +0100, Rein Klazes wrote: > > Needed for Visual Studio.NET installer. > > Changelog: > > dlls/shell32 : shell.c > In ShellExecute16, make sure there is a space between command > and parameters. Hmm, I suspect that might be wrong. (in case your ShellExecute16() is being called by ShellExecute(), that is) ShellExecute() was supposed to call WinExec() instead of WinExec16() (long filename support). I wrote a ShellExecute patch some weeks ago that didn't get applied, probably because there were compile warnings. But I might be wrong and your patch is completely independent of mine. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 2

Re: Wine license change
by Roger Fujii 14 Feb '02

14 Feb '02

Ian Schmidt <ischmidt(a)cfl.rr.com> wrote: > On Wednesday 13 February 2002 01:28 pm, Brett Glass wrote: > > > business. So, if the company was profitable at all, it was just squeaking > > through. (And $20M in annual revenues after ten years of existence is no > > one's idea of "good money" for a company that size.) > Sure, but they did stay in business for 10 years and were in no reported > danger of going out of it. Not bad by any metric for a license you can't > make money off of ;-) but I wouldn't use the word 'thrive' to describe a company that is barely profitable (which is what the original poster used). It's not my opinion (and probably not even Brent's) that it is *impossible* to eek out a living. I think the point is that it is DIFFICULT to do so. I don't mind hearing GPL advocates say that it is more socially desirable, equitable... (not that I necessarily agree with it, but it is a valid point of view). But I don't see any evidence that it is helpful to commerical entities (which is some of the reasoning behind a license switch). > Anyway to steer back toward my point, can you name any pure-BSD/X11 players > that are profitable? well, depends on what you mean by "pure". X.org presumably is. Usually, the business model for this is a common group that publishes a reference port for other vendors, which can build propriatary value adds on top of the reference port. Ximian's 'mono' model is based on this logic (I think). A better way of looking at it is companies that have 'free' licenses that are NOT *GPL. sendmail.org has a modified license and they seem to be doing ok. Apache would a another one. > See, I think there's a more basic problem, which is that no known business > model works really well for source-available software when the software is > targeted at technically savvy users. Things like the Aladdin license are a > nice compromise, but ultimately won't lead to Microsoft levels of > profitability. No one here is advocating for M$ levels of profitability (at least, not for wine :) ), but the point is correct. The problem is the *GPL highly limits what models can be tried. > The solution as I see it is for GPL/BSD/whatever programmers to actually > cough up something non-technical users not only would use, but would > *prefer*. *Then* support and selling binaries becomes a worthwhile > proposition. you cannot sell *gpl binaries. You can sell the media, but not the content. Think sun has a good idea with dual licensing and having assignment of the copyright. This allows them to change the license so that they can make a productized version. > Codeweavers is leaning in this direction with CrossOver - even > though you could probably duplicate their work eventually with the current > Wine CVS, the installer and overall ease of use make it well worth paying for > if you value your time at all (I bought it and I love it, if you can't tell). Isn't the whole reason this discussion was opened up again was because they want to release LGPLed code (the inference was that they thought that their code released under X11/BSD would harm them materially). The obvious extrapolation is that a more complete wine under X11/BSD is not in codeweaver's interest, regardless of where the code came from. > To put this back on topic, I don't see any immediate benefits from a LGPL > license. If we knew what the threat to Wine Jeremy hinted at was, it might > make for a more informed discussion. I also liked Gav's idea about WineCorp > a lot as a compromise, and I'd love to see more dicussion of that and less > licensing flaming. MORE?! AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!! :) -r

5 6

[patch] - add several structs to ntddk.h
by Ron Gage 14 Feb '02

14 Feb '02

Hi folks... I just sent the following patch to wine-patches. I thought it would be a good idea to let you folks beat it up before someone actually commit's it to CVS... The patch adds several struct definations to include/ntddk.h to assist getting the NtQuerySystemInformation routine working. It also adds several enumerations for the System Information Class. By far, these are not complete, and I can only hope that they are accurate. One thing you may notice is that HANDLEINFO and THREADINFO have been defined. I believe there is already a less complete defination of the THREADINFO struct (called THREAD_INFO) in the code already. This has been left untouched so that this patch minimizes the potential side effects. These are untested in that I have not tried to recompile with these changes in place. My only concern: do FILETIME and LARGE_INTEGER data types exist? Google is your friend - use it wisely! -- Ron Gage - Owner, Linux Network Services - Saginaw, Michigan - 989-274-8088 Your one-stop source for Reliable, Secure and Affordable Networking Solutions --- ntddk.h~ Wed Dec 19 14:16:29 2001 +++ ntddk.h Thu Feb 14 07:32:31 2002 @@ -147,6 +147,21 @@ MaxThreadInfoClass } THREADINFOCLASS; +typedef struct { +/* This is used by NtQuerySystemInformation */ + FILETIME ftCreationTime; + DWORD dwUnknown1; + DWORD dwStartAddress; + DWORD dwOwningPID; + DWORD dwThreadID; + DWORD dwCurrentPriority; + DWORD dwBasePriority; + DWORD dwContextSwitches; + DWORD dwThreadState; + DWORD dwWaitReason; + DWORD dwUnknown2[5]; +} THREADINFO, *PTHREADINFO; + /* file information */ typedef enum _FILE_INFORMATION_CLASS { @@ -220,12 +235,124 @@ /* system information */ typedef enum SYSTEM_INFORMATION_CLASS -{ Unknown1 = 1, - Unknown2, - Unknown3, +{ SystemBasicInformation = 0, + Unknown1, + SystemPerformanceInformation, + SystemTimeInformation, Unknown4, - SystemPerformanceInformation + SystemProcessInformation, + Unknown6, + Unknown7, + Unknown8, + Unknown9, + Unknown10, + SystemDriverInformation, + Unknown12, + Unknown13, + Unknown14, + Unknown15, + SystemHandleList, + Unknown17, + Unknown18, + Unknown19, + Unknown20, + SystemCacheInformation + } SYSTEM_INFORMATION_CLASS, *PSYSTEM_INFORMATION_CLASS; + +typedef struct { +/* System Information Class 0x00 */ + DWORD dwUnknown1; + ULONG uKeMaximumIncrement; + ULONG uPageSize; + ULONG uMmNumberOfPhysicalPages; + ULONG uMmLowestPhysicalPage; + ULONG uMmHighestPhysicalPage; + ULONG uAllocationGranularity; + PVOID pLowestUserAddress; + PVOID pMmHighestUserAddress; + ULONG uKeActiveProcessors; + BYTE bKeNumberProcessors; + BYTE bUnknown2; + WORD wUnknown3; +} SYSTEM_BASIC_INFORMATION; + +typedef struct { +/* System Information Class 0x02 */ + LARGE_INTEGER liIdleTime; + DWORD dwSpare[76]; +} SYSTEM_PERFORMANCE_INFORMATION; + +typedef struct { +/* System Information Class 0x03 */ + LARGE_INTEGER liKeBootTime; + LARGE_INTEGER liKeSystemTime; + LARGE_INTEGER liExpTimeZoneBias; + ULONG uCurrentTimeZoneId; + DWORD dwReserved; +} SYSTEM_TIME_INFORMATION; + +typedef struct { +/* System Information Class 0x05 */ + DWORD dwOffset; + DWORD dwThreadCount; + DWORD dwUnknown1[6]; + FILETIME ftCreationTime; + DWORD dwUnknown2[5]; + WCHAR* pszProcessName; + DWORD dwBasePriority; + DWORD dwProcessID; + DWORD dwParentProcessID; + DWORD dwHandleCount; + DWORD dwUnknown3; + DWORD dwUnknown4; + DWORD dwVirtualBytesPeak; + DWORD dwVirtualBytes; + DWORD dwPageFaults; + DWORD dwWorkingSetPeak; + DWORD dwWorkingSet; + DWORD dwUnknown5; + DWORD dwPagedPool; + DWORD dwUnknown6; + DWORD dwNonPagedPool; + DWORD dwPageFileBytesPeak; + DWORD dwPrivateBytes; + DWORD dwPageFileBytes; + DWORD dwUnknown7[4]; + THREADINFO ti[0]; +} SYSTEM_PROCESS_INFORMATION; + +typedef struct { +/* System Information Class 0x0b */ + PVOID pvAddress; + DWORD dwUnknown1; + DWORD dwUnknown2; + DWORD dwEntryIndex + DWORD dwUnknown3; + char szName[MAX_PATH + 1]; +} SYSTEM_DRIVER_INFORMATION; + +typedef struct { +/* System Information Class 0x10 */ + USHORT dwPID; + USHORT dwCreatorBackTraceIndex; + BYTE bObjectType; + BYTE bHandleAttributes; + USHORT usHandleOffset; + DWORD dwKeObject; + ULONG ulGrantedAccess; +} HANDLEINFO, *PHANDLEINFO; + + +typedef struct { +/* System Information Class 0x15 */ + ULONG CurrentSize; + ULONG PeakSize; + ULONG PageFaultCount; + ULONG MinimumWorkingSet; + ULONG MaximumWorkingSet; + ULONG unused[4]; +} SYSTEM_CACHE_INFORMATION; /* reading coffee grounds... */ typedef struct _THREAD_INFO ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

1 0

Request for wine-license list
by Uwe Bonnes 14 Feb '02

14 Feb '02

Hallo, I repeat may proposal, as the license wars will probably rage on: Let us create a wine-license mailing list and discuss licenses there. Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: Licensing response and an idea
by Roger Fujii 14 Feb '02

14 Feb '02

Tony Bryant <brd(a)paradise.net.nz> wrote: > > The (L)GPL is thus extremely discriminatory against programmers. > It just forces a different way of making money - charging for your > time, not charging for your IP. Revolutionary concept - charge for > work done. Doesn't exactly fit with the bill gates of this world, > but for small programmers like myself, most of my work is one-offs > anyway. what is so "revolutionary" about that idea?! Consulting services where they charge by the hour has been around for quite a while. The PROBLEM with this model is that it forces all the costs up front, thus making it unafforable for people without a large budget. A simple example goes as follows: Let's say I want a device driver for a scanner. I find a relatively proficient programmer and s/he said it's about $1000 worth of work. Under the *GPL model, I have 3 choices: 1) Pay him/her $1000 for a driver for a $200 scanner 2) Go out and play salesman and find others to defer the cost. 3) Write it myself (and for the sake of argument right now, let's say this isn't an option) Under the normal commercial route, you can make up other options that try to keep the per user cost down. > (L)GPL just doesn't suit business people. i.e. those expecting to sit > back and watch the money roll in. I really hate it when things are characterized in this fashion because it shows a fundamental misunderstanding of how normal businesses work. Companies that don't have monopoly power survives by accepting risks and deriving benefit from their success(es). If I spend $10M developing a software project, I'm not "sitting back and watching the money roll in" when the product starts selling. If you're good, you'll have more money at the end than when you started. If not, you'll fail. This is the main concept behind "free enterprise". > One has to wonder why it matters what other people do with Wine. Wasn't > Wine developed because we wanted to run some windoze apps on linux? > Who really cares what codeweavers, transgaming etc do to it. Just as > long as I can still run my windows apps on linux, I'm happy. If lindows > sells a few copies of what is effectively free, what skin is it off > our noses? I was wondering that too, and have come to the following conclusion: Either 1) They believe like the FSF and don't think propriatary software should exist 2) Are not comfortable with the idea of giving up code freely for the good of all. 3) Misunderstand the effects of the *GPL 4) Expect to be paid in other people's work. -r

1 0

Re: Wine license change
by Claus Fischer 14 Feb '02

14 Feb '02

Issue 1: On corporations' dealing with GPL Basically all big companies in the software industry know about the GPL. It's a known quantity. Even if it may not have been publicly enforced, companies have spent lawyers' time finding out the core implications. They know its `spirit', and they mostly equate it with its spirit, i.e. they deal with GPL code according to its spirit. This is true whether they are pro or contra GPL in a particular situation; hardly have big companies ever tried to sneak around it. (Or was there some good enforcement?) GPL'ing code may not fit everybody's needs but it can make a lot of sense for corporations whose core business is not Wine. Imagine some big hardware vendor (Intel), software vendor (IBM), bank, fortune 500 company, considering the use of Wine for some internal or external product. They don't want to get into the Wine business at all. It's much easier for them to hire external consultants, Codeweavers, whoever, to implement some stuff for them and give back to the public if they don't run the risk of a) the competition taking the code b) the competition improving it c) the competition getting better products d) the competition not giving anything back Even if the causal connection between the little money you spent and the success of your competition is very weak, you don't want to read that kind of implication in a newspaper. Rather spend 10 times the money and do it closed-up in-house. Whereas using the GPL, by this time a very well known quantity in most of the above mentioned companies, you can rule out this kind of embarrassment and explain fair and square to your shareholders that a Windows compatibility layer is not a means of competition to you, and that you are just playing by the general rules of the community, and those ensure that your competition will not take advantage of you. For an enabling technology like Wine that will perhaps never become the one big bread and butter product of a fortune 500 company (sorry Lindows guys), this carries a lot of potential for consultants, both individual and incorporated, whose goal is to offer a Windows compatibility layer and to improve Wine. (1) `We need something like Wine' (2) `We need some enhancements' (3) `We have to give back the source code anyway' (4) `So we can as well outsource that and consult with experts' In contrast an X11 style license would modify this: (1) `We need something like Wine' (2) `We need some enhancements' (3) `We do not want our competition to know' (4a) `Let's do it in-house', or (4b) `Let's make a contract with our external consultants that disallows them to reuse the code' Issue 2: On developers discussing licenses You shouldn't. You can't convince others, and you shouldn't try to. You have the power. Just pick one that fits your goals for yourself and for the project, and move on. Claus -- Claus Fischer <claus.fischer(a)clausfischer.com> http://www.clausfischer.com/

2 1

RE: Wine license change
by Patrik Stridvall 14 Feb '02

14 Feb '02

> To give a concrete technical example (but not an > authoritative legal one, > as IANAL), it is my understanding of the LGPL that if someone > has released > a library under the LGPL, a third party cannot distribute a modified > version of this library that has been linked against a proprietary > library[1]. I think because of the reduced scope of the LGPL, there's > also less room for ambiguity on questions of aggregation vs. derived > works. [snip] > [1] The reason for this lies in section 2d of the LGPL: > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > A library that is linked against a proprietary library cannot be used > without the proprietary library; it will fail to load at > runtime with a > complaint of "No such file or directory". If that was the only problem: BOOL (*PROPRIETARY_Foo)(void) = NULL; void call_this_init_on_dll_load(void) { HANDLE h = LoadLibrary("PROPRIETARY.DLL"); PROPRIETARY_Foo = (void *) GetProcAddress(h, "Foo"); } BOOL WINAPI Foo(void) { if(PROPRIETARY_Foo) { return PROPRIETARY_Foo(); } else { /* The old implementation goes here */ } } So no runtime failure any more. At least not anymore than happend before. > If "application > program" as > used above is understood to include other libraries (the > distinction is > artificial, and the LGPL 2.1 does not define "application program" to > exclude this interpretation), then trying to hide proprietary > functions in > a separate library that an LGPLed library is made to depend on is not > permitted under the LGPL. Well, the the requirement if the function didn't exist was "the facility still operates, and performs whatever part of its purpose remains meaningful." Observe the words "remains meaningful". It doesn't have to do the same thing as Alexandre claimed in the last discussion. Yes, I can see why he thought that since the example below paragraf d (not included in your cut) was missleading. It should just do something that in the context of the missing function remains meaningful. It could mean using the old Wine implementation but I guess it could also mean that just doing: SetLastError(ERROR_NOT_IMPLEMENTED); return FALSE; since doing that is ALWAYS meaningful for a Windows API. Sure the application might not check but then this is the responsebillity of application not our problem. Beside since the Wine likely didn't have a non-stub implementation anyway, it was probably was what it already did, so the application crashed anyway without the patch and the proprietary library.

3 2

Re: Wine license change
by Brett Glass 14 Feb '02

14 Feb '02

At 05:44 PM 2/9/2002, J.Brown (Ender/Amigo) wrote: >Sorry, let me clarify that point... the major work that was lost was done >by a COMMUNITY project, not one of ID's in-house ones. His point is that >as the xGPL forces the release of source code with any binaries, so any >valuable work like this won't be lost to the community. In that case, it seems to me that his remarks are a complete non sequitur. The source code of "community" projects that license their work under the MIT X or BSD license is every bit as publicly available as that of projects that use the GPL. In fact, the GPL would actually reduce the likelihood of recovering the code from someone's box, because commercial programmers such as myself won't look at it or download it. --Brett

7 12

Re: Wine license change
by Roger Fujii 13 Feb '02

13 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > When you buy a book, are you paying for the physical paper, or are you > paying for the information contained within its pages? If you are talking about publications by the US government, or books that are in the public domain or have an expired copyright, then I am just paying for the paper. For something with an active copyright, you are also paying for copyright access for the publisher. > How is this anything more than a semantic difference? we are talking about licenses, aren't we? > Just because I can build a greenhouse, plant the seeds and grow my own > 'copies' of the fruit doesn't mean I'm not paying for fruit. bad example, because fruit still has value. And if you want really scary permutations of this, start looking at genetically modified corn and what companies like monsanto are doing.... > > How I read that is that you can charge for the _service_ of copying, but you > > are NOT charging for the content. > Semantics. we are talking about licenses and the law. How can you ignore semantics in this context? > Whatever the license governing the software in question, I'm > buying the same thing when I buy a CD -- and usually less when it's a > proprietary license. If one of these vendors is "selling binaries", then > so is the other. just because you aren't willing to see the distinction, doesn't mean that there isn't one. Why do you think the phrase "Right To Use" exists (you didn't buy the binaries in that case either)? > Or, if the only thing I'm buying from RedHat is the service of copying, > then the only thing I'm buying from Microsoft is insurance against legal > harrassment -- since Windows binaries are just as easy to come by, and > just as easy to copy, as Linux binaries are... what does availability have to do with anything? What am I missing? -r

1 0

Re: Wine license change
by Brett Glass 13 Feb '02

13 Feb '02

At 12:26 PM 2/13/2002, Paul Millar wrote: >> It's hard to conceive of a rational business model that did not recognize >> the advantage of offloading maintenance of non-strategic code to an >> open source team. > >True for non-strategic code, but what about _strategic_ code (strategic in >the sense that the business model assumes the retention of IP-rights). If >this is based on BSD-licensed code then there is no incentive to release >the code back to the community. Whether or not it's based on BSD-licensed code, it's a good idea for the business not to release it for everyone to use. If it's of real value, though, it will probably have a lot of originality to it. --Brett

2 1

Re: Wine license change
by Roger Fujii 13 Feb '02

13 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > > you cannot sell *gpl binaries. You can sell the media, but not the content. > > Think sun has a good idea with dual licensing and having assignment of the > > copyright. This allows them to change the license so that they can make > > a productized version. > > Since this is not the first time this mistruth show up in the discussion > here, I think a clarification is warranted. it is NOT a mistruth. Maybe I should have said, "you are not really selling *gpl binaries", but the meaning is the same. By the license, the source and binaries are freely distrubutable, thus they have no monetary value. So assuming the people in a commerical transaction don't give something for nothing, the monies paid must be for cost of copying, media... > The second paragraph of section 1 of the GPL (v.2) states: > > You may charge a fee for the physical act of transferring a copy, and > you may at your option offer warranty protection in exchange for a fee. How I read that is that you can charge for the _service_ of copying, but you are NOT charging for the content. > The only limits that the GPL places on sales is that once someone has > received a copy of binaries from you, you can't sell them the SOURCE at an > additional cost that's higher than your distribution cost. Up to that > point, you can charge people whatever you want to for access to GPLed ^^^^^^^^^^ > *content*. You just don't have any power to make sure that others don't > sell that same content at a price lower than yours, or even give it away. no disagreement here. But nothing you said so far contradicts what I have said. > And although the LGPL is a different license (which is important to keep > in mind when talking about '*gpl'), the same permission is granted by the > LGPL to charge a fee (an arbitrary fee) for copies of the software. you are confusing the what was said. I did NOT say "you can't charge for GPLed stuff; they must be distributed free". What I said was "you can't charge for the *gpled binaries" because by the license, by section 1, the receiver can make as many copies as s/he wants (providing it falls within the *GPL). The by-product of all this is that the *GPL makes content "zero cost", thus you can only make money by focusing on something other than content. Another way to look at it is like getting a can of compressed air. Do you think you are buying air, or do you think you are buying the process the compressed, canned and distrubuted the air? -r

2 1

RE: Wine build system tech info
by Patrik Stridvall 13 Feb '02

13 Feb '02

> As part of a private investigation I noticed that both > WINE and LINUX kernel > build systems have a mkdep utility which generates in > clude file > dependencies. What I am looking for is to understand > the reasons behind this > decision for the two very popular projects instead the > recipe > suggested by GNU make documentation. For us because we do not wish to depend on GNU Make. For Linux kernel, no idea.

2 1

RE: DLL specific defines
by Patrik Stridvall 13 Feb '02

13 Feb '02

> > With the patch below this is added as EXTRADEFS > > flags so I can pick it up from the Makefile_in's > > and convert to .dsp compile rules. > wouldn't it be better to add them to another specific define > (like EXTRAWINDEFS or something) just to really know what > they are for ? If you wish. I don't care either way. I just want the defines somewhere so I can find them in the Makefile.in to .dsp/.dsw convertor.

1 0

Re: DLL specific defines
by Eric Pouech 13 Feb '02

13 Feb '02

> With the patch below this is added as EXTRADEFS > flags so I can pick it up from the Makefile_in's > and convert to .dsp compile rules. wouldn't it be better to add them to another specific define (like EXTRAWINDEFS or something) just to really know what they are for ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: Wine license change
by Brett Glass 13 Feb '02

13 Feb '02

At 12:09 PM 2/13/2002, Paul Millar wrote: >This is the crux of the issue. What if the business model relies upon >retaining the IP-rights associated with the in-house written code? There >the cost/benefit balance would be tipped towards non-disclosure. It's hard to conceive of a rational business model that did not recognize the advantage of offloading maintenance of non-strategic code to an open source team. --Brett Glass

2 1

Modified makedep to handle #include <>
by Patrik Stridvall 13 Feb '02

13 Feb '02

I have been working some more on a Makefile.in to .dsp/.dsw converter for working in Microsoft Developer studio and it is comming along fine. Anyway one of the the problems compiling with MSVC using the Microsoft headers is that all Wine only includes in wine/include can't use for example: #include "windef.h" it must use #include <windef.h> otherwise Wine's windef.h in the same directory is used. The problem as you pointed out is that makedep.c can't handle this. Here is a patch so it can. BTW. If you apply this patch or a similar should all .h and .c files be converted or should I just do the absolute minimum ie the Wine specific include (.h files) under wine/include. Files like heap.h for example. * tools/makedep.c: Modified makedep to handle #include <> for the Windows includes correctly. ---8<--- Index: wine/tools/makedep.c =================================================================== RCS file: /home/wine/wine/tools/makedep.c,v retrieving revision 1.7 diff -u -u -r1.7 makedep.c --- wine/tools/makedep.c 2000/12/13 21:27:26 1.7 +++ wine/tools/makedep.c 2002/02/13 16:40:21 @@ -4,6 +4,8 @@ * Copyright 1996 Alexandre Julliard */ +#include <sys/types.h> +#include <sys/stat.h> #include <ctype.h> #include <stdio.h> #include <stdlib.h> @@ -185,6 +187,31 @@ return file; } +/******************************************************************* + * find_include_file + */ +static int find_include_file(char *name) +{ + INCL_PATH *path; + int found = 0; + + for (path = firstPath; path; path = path->next) + { + struct stat buf; + char *filename = xmalloc(strlen(path->name) + strlen(name) + 2); + strcpy( filename, path->name ); + strcat( filename, "/" ); + strcat( filename, name ); + if (!stat( filename, &buf )) + { + found = 1; + } + free( filename ); + if(found) break; + } + return found; +} + /******************************************************************* * open_include_file @@ -260,6 +287,7 @@ while (fgets( buffer, sizeof(buffer)-1, file )) { + char qoute; char *p = buffer; line++; while (*p && isspace(*p)) p++; @@ -268,9 +296,11 @@ if (strncmp( p, "include", 7 )) continue; p += 7; while (*p && isspace(*p)) p++; - if (*p++ != '\"') continue; + if (*p != '\"' && *p != '<' ) continue; + qoute = *p++; + if(qoute == '<') qoute = '>'; include = p; - while (*p && (*p != '\"')) p++; + while (*p && (*p != qoute)) p++; if (!*p) { fprintf( stderr, "%s:%d: Malformed #include directive\n", @@ -278,7 +308,9 @@ exit(1); } *p = 0; - add_include( pFile, include, line ); + if (qoute == '\"' || find_include_file(include)) { + add_include( pFile, include, line ); + } } fclose(file); }

1 0

wineconf 2002 user submitted agenda topics
by Michael Robertson 13 Feb '02

13 Feb '02

Here's a list of some of the suggestions people have sent in for wineconf 2002. http://www.lindows.com/wineconf It demonstrates where people's interest is and not a confirmation of the agenda or that the proposed speaker has even confirmed. Some have not responded to my email (like Dr. Ulrich Weigand). As you can see, there's no shortage of interesting topics. Please keep sending me your input and I'll incorporate. I haven't made it through everyone's suggestions yet. Company Presentations: ---------------------- Transgaming, Success To Date [Transgaming/State] ReactOS - Where it's at, where it's going [ReactOS/Filby] Corel, A Look Back [Xandros/Tranter] Crossover Strategy [Codeweavers/JW] Macadamian - Making It As A Software House [Macadamian/???] Business -------- WINE's "Most Wanted": Features To Make WINE Great [???] Developer Funding, Who Pays The Rent [???] Future of WINE licensing [CW/White] Technical --------- Development Model [CW/AJ] NORM - The secret weapon [Codeweavers/???] Making Fonts Not Look Like Crap [CW/Timoshkov/Davies] Multimedia And WINE [eric.pouech(a)wanadoo.fr] Regression Testing [???] How To Improve The Debugger [Meissner/marcus(a)jet.franken.de] Maximizing performance of WINE [???] Package streamlining of WINE [???] WinNT APIs (Odin, ReactOS, winNT wine, WINE) [???] DirectX [Transgaming/Kaaven] WINE as a porting tool [Macadamian/Jacques] Native user.dll [Dr. Ulrich Weigand] API Standardization [???] Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

6 5

Licensing response and an idea
by Gavriel State 13 Feb '02

13 Feb '02

Hi everyone, As I mentioned, I have been considering the license issue for the last several days. It is a matter very near to my heart, as I believe that it affects not only TransGaming, but really the entire software industry. This posting is somewhat lengthy, but please bear with me. Open Source software has made enormous strides in the last several years, and incredible amounts of great code have been produced. At the same time, it has been unable to compete effectively with proprietary software vendors like Microsoft, except in those areas where sufficient well financed companies have been able to direct full-time developer resources to the problem. With the wellspring of dot com VC funding going dry, the question arises: where will the money come from to pay full-time Open Source developers? Just imagine where Wine would be without the code contributed by the half-dozen or so companies that have been involved. Imagine where Linux would be without the efforts of the companies paying for dozens of full-time Kernel hackers. And imagine where we could be if just one or two percent of Microsoft's annual $25 Billion in revenue were being directed at Open Source projects. The business models capable of supporting traditional Open Source projects are really rather limited: consulting services, technical support, and selling ancilary products with the software. None of these come close to delivering the levels of revenue that traditional mass-market shrinkwrap software can. So far, it is unclear whether they can support much profit at all for their proponents: RedHat, VA, and others bear witness to that. TransGaming, for one, is working with some new ideas on how to do things differently, and profitably. There are a number of interesting possible approaches out there, and it is important to the entire world that we find models that work. Otherwise we are going to be stuck with the kind of information police states envisioned by the RIAAs, MPAAs, and Microsoft's of this world. Now we are all here because we think that there are better ways to do software than the wholly proprietary approach. We want to be able to look at the code, tear it apart, fix the bugs, and make it cooler. And we want others to have the freedom to do the same. Ultimately, the questions that need answering are these: o What freedoms are important to the community? o Can those freedoms be achieved without sacrificing other goals? o What is the best mechanism for ensuring those freedoms, and ensuring the continued development of the code? The Wine X11-style license essentially allows the code to be used anywhere, in any way. Users don't need to pay, Developers can take bits and pieces as they deem appropriate, and corporations can sell the product in whatever way they feel like. But it also has no legal mechanism to try to coerce further development of the project. Current proponents of an LGPL license switch believe that a legal mechanism is important to protect the project. Frankly, I am at a loss to understand the reasoning behind such a switch. I don't see any way in which any company could maintain their own fully proprietary fork of Wine without doing periodic merges into the public project. It's hard enough for TransGaming to do it despite the fact that we deal mostly in very specific areas. And even if someone was able to do so, how does it affect the Wine project any more than the existence of Windows or MainWin does? At most, it would affect the userbase, but in the current model that doesn't matter, since that userbase doesn't contribute significantly to the project. Only the developers contribute, and it is not at all clear to me that they would stop. Marcus Meissner has already shown that the existance of our AFPLed DCOM code didn't stop him from going ahead and doing it himself. On the contrary - it helped him, since he got hints from our design. It's a shame that he had to, since we've been working hard to find a way to contribute that code back, and now we may have no way to recoup our investment. We still have a 2nd pass, more complete DCOM implementation under development, so it is possible that we be able to get a sponsor for that. But regardless, it clearly shows that having code outside the WineHQ tree is no impediment to the community reimplementing it if necessary. The LGPL would severely limit a number of possible commercial applications of Wine, such as: o Companies or groups that might want to take a small bit of Wine code here and there without taking the whole thing. IE: Corel's Mac porting work, or projects like MicroWindows or Odin (similar projects like Xine and ReactOS use parts of Wine this way, though they're GPLed, and thus would not be affected). o Porting Wine to platforms with NDAed APIs. Or commercially oriented ports to other platforms which might not be viable under the LGPL. o The work that TransGaming has done to support copy protection. Releasing that code all at once - as would be required under the LGPL - might violate the DCMA, since it reveals something of how the copy protection systems work. o New business models like TransGaming's, with conditional-future- release of code. While I am open to considering license changes that have the potential to benefit the project, I am very very concerned about the LGPL. Going that route is a one-way street with no turning back. I've been thinking about these problems for a long time. As much as for any other reason, I started TransGaming with the desire to try to find good long-term solutions to the problem of how to fund Open Source development through the people who are actually using the code. I have the germ of an idea that might be useful to address some of the concerns that the LGPL-license-change camp has had, while at the same time leaving the doors open for a much wider variety of different commercial activities. I have been trying to flesh it out while at the same time working to some very tight deadlines, and I have not had time to really think through some of the the possibilities that it entails. I am posting it to the list now anyway so that it's out there for people to think about. Here's the quick and dirty version: o A new non-profit company is created: WineCorp o Developers contribute their work to WineCorp - possibly assigning copyright, or at least giving WineCorp the rights to do with the code whatever it pleases. o WineCorp distributes the code under an AFPL-like license - no commercial redistribution allowed. o WineCorp has a set of standing licenses allowing for commercial redistribution. A company can redistribute commercially if it does one of the following things: - Releases source modifications to WineCorp immediately. - Releases source modifications within a preset timeframe (maybe one year). - Releases source modifications with some appropriate prearranged condition (ie: the TransGaming subscriber limit). - Pays WineCorp a pre-set royalty, which WineCorp can then use to sponsor other Wine development o For cases that don't fall into the above conditions, the WineCorp board of directors can vote to allow some other licensing arrangements. This helps prevent the kind of one-way ticket we have with the LGPL. o WineCorp could also serve as a way for the userbase to direct funding and attention to different parts of Wine. To my mind, this is one of the biggest problem Open Source projects have. The end users get everything, but many don't contribute: no code, no money, no bug reports, nothing. The more they can be encouraged to contribute, the better off everyone is. WineCorp could solicit donations from users who can't contribute otherwise and possibly institute a subscription/voting system similar to TransGaming's. One hard question the above idea creates is how does money gets split fairly amongst different developers working on particular parts of the code? I am sure that there are other problems as well. That said, I think that the importance of new models like this go far beyond the Wine project. Ideally, I hope that methods like these can be profitable enough to make proprietary software companies begin to consider opening up their code in a similar fashion. Just imagine the day that Microsoft makes their first contribution to Wine, openly and without coersion by the government, because they recognize that doing so is in their own best interests. Food for though, anyway. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

3 3

Re: Licensing response and an idea
by Roger Fujii 13 Feb '02

13 Feb '02

Gavriel State <gav(a)transgaming.com> wrote: > > You did not mention whether you want to have this > > license only or to have Wine licensed also with some > > open-source license? > > > > I think in this case even GPL can be a choice for the > > second license. > > Under the WineCorp approach, the AFPL + an allowance > for commercial redistribution if Wine code is returned is > essentially equivalent to the LGPL. It's more flexible though, > since it allows for the possibility of other unforseen ways in > which commercial redistribution without immediate release > of source would be possible. > > It would also be possible for the WineCorp to allow certain > portions or all of the code to be dual-licensed under the LGPL > and mixed with other GPL or LGPLed projects. I think that you'll find considerable resistance from the *GPL people, but you do bring up a good point. If there is going to be a license change, it would probably be wise to require that the copyright of future submissions go to a single (or small #) of people. That way, you can revert the licensing terms if you change your mind. -r

1 0

Re: Wine license change
by Roger Fujii 13 Feb '02

13 Feb '02

>On Tue, Feb 12, 2002 at 04:21:59PM -0500, Roger Fujii wrote: > > Read: http://www.uwsg.iu.edu/hypermail/linux/kernel/0105.3/0203.html > > I don't think that LGPL and GPL differ in this regard. > > [Summary of link: discussion of whether including binary-only firmware in > the Linux kernel is a violation of the GPL.] > > In this regard, they do not differ. However, whereas the GPL is mostly > 'symmetric', placing the same limitations on anything that's linked to GPL > code (except for the "standard system facilities" exemption), the LGPL > quite explicitly only places limits on the licensing and > source-availability of other code on which the LGPLed code is made to > depend. it also restricts the ways and means of binary distribution. > To give a concrete technical example (but not an authoritative legal one, > as IANAL), it is my understanding of the LGPL that if someone has released > a library under the LGPL, a third party cannot distribute a modified > version of this library that has been linked against a proprietary > library[1]. I think because of the reduced scope of the LGPL, there's > also less room for ambiguity on questions of aggregation vs. derived > works. I believe your case falls under the "work as a whole" clause. The problem in the wine context is that it is NOT clear that any propriatary library doesn't fall under that clause unless you make it as a dropin replacement for something that's already there. And, if it's NEW functionality you're adding, you must do it in such a way that it can be removed at runtime. So, if your business model is to develop a value-add, LGPL is not your friend. > > yes, but studying can be done in a non 'open source' license too (like AFPL). > > This is why using the word "contribute" is really a misnomer which is > > why I said "show your work". > The difference is that in the case of the LGPL, a third party can only > erect certain limited sorts of technical barriers to reintegrating the > sources, at some cost to them in terms of programmer time; whereas under > the BSD license, a third party can erect legal barriers to reintegration. if you can make a propriatary extension, it holds that you can license the source code for it some other way too. If the point was that with enough effort, you can roll (some of) the changes back in, then I agree. But is this practical? > There is an important difference between LGPL/GPL and standard EULAs for > proprietary software. An EULA requires a user to give up freedoms they > would otherwise have; the LGPL and GPL give additional freedoms TO users > which under copyright law would normally be reserved for the author. this is a perceptual difference. the legal mechanism for both is simply conditions of the transfer of the copyright since neither case makes any difference to anyone who doesn't distribute what they have to the public. > If a third party does not accept the terms of the GPL, and they have been > granted no other license to modify/redistribute, then they're guilty of > copyright infringement -- and copyright infringement is far easier to > prosecute than tort or breach of contract. well, not according to that calif. ruling (in certain cases). > Eben Moglen has expounded on this point quite persuasively in the past. > Whatever flaws the xGPL licenses might have, I assure you that > unenforcability is not among them. I don't believe anyone has said there is NO legal basis. What has been said is that there is little legal PRECEDENT. There are various parts to *GPL that are quite arbitrary (like, why is it legal to link with a .so, but not a .a, or a .o? what is being linked is the same) and is not clear it will stand a good challenge. As such, it's pointless to argue what it means except in the cases that it's absolutely clear on. For all other cases, you are in untested territory. > To the question of the LGPL being unclear: your example at the top cites > discussion among a number of non-lawyers. The fact that they disagree > about the meaning of "aggregation" may merely be a reflection of the fact > that no party to that discussion is an expert in IP law. until there is case law, what those words mean in the software context is open to interpretation. "Aggregation" of books may not be considered the same as aggregation of programs. If you need convincing of this, look at the consent degree between the justice dept and M$ with IE in win98. > Any company that's considering working with Open Source software as any part of their > business model should seek legal advice; just because the BSD license > seems clear to most informed laymen doesn't guarantee that it's free from > legal pitfalls. would you care to enumerate one that is the result of the license? > So while an easily understandable license may be helpful > to some, it doesn't eliminate the need for corporate lawyers. you must know some INCREDIBLE lawyers. The ones I have dealt with always makes something simple really complicated. If you know of someone that can make something complicated simple, I'd like to have their #. > > > If the company is one like, say, Lindows.com, and they have a business > > > model based on selling a branded, enhanced version of Wine, there are > > > rational reasons for possibly not wanting to use an LGPLed code base. > > > There are several different options for such a company. Some might choose > > > to risk the LGPLity, and decide to see if they can make a profit just from > > > selling people something they can already get for free. This is not out > > > of the question; every Linux vendor is doing this today, and if 90% > > > marketing + 10% programming works for Microsoft, it should work for others > > > too, right? > > > a) M$ can charges for their work > > b) it works for linux (I presume you mean distributions) vendors because > > most others sell a propriatary value add (like transgaming) which does > > not fall under your description for this case. The linux vendors have > > an advantage that what they are replacing (nt, solaris, aix...) are > > a rather expensive. The problem wine solves (for most people) is the > > cost of a PC (US$400). There isn't much of a margin here. Can you > > show me any example of successful companies using this business model? > > Judging by his posts here, it sounds like Michael Robertson believes his > own company's business model is already very close to this. If lindows was just a branded version of wine, why are people getting so bent out of shape about them contributing? > I wonder if he would say Lindows.com's hopes for profitability stand on the ability to > maintain a competitive advantage over other Wine vendors by keeping their > changes proprietary, or on value-added features such as integration into > an easy-to-install product? I would presume a little of both. > There's still lots of room for proprietary value-add with an LGPL Wine; > and I'm not arguing that this is a bad thing. I just think that having > companies create value-added products by making closed-source > modifications to the Wine *core* is a bad thing. 'lots of'? I really think you are overstating the case. Gav doesn't think so. I think Michael Robertson has implied he didn't think so either - the pie just isn't that big... > > (I just love how people use 'steal' in reference to something freely > > given away - I guess the same people ask for interest when they do > > charity work) > As someone who gave his assent (however insignificant) to the current Wine > license, *I* do not use the word "steal" to refer to the actions of such > companies. you may not have, but this statement has either been said or implied by many in the *GPL camp. It is a pervasive attitude that always makes this topic more imflamatory than it needs to be. > > So, given the world of (using "contribute" meaning code that can be easily > > worked back into the common tree): > > 1) Evil companies that won't contribute no matter what > > 2) Companies that contribute some, but not all of what they do > > 3) Companies that contribute > > > The only thing a license change will do is stop #2. If this is what you want, > > we can stop arguing now. > > I disagree with this breakdown. Assuming there are "evil" companies > involved[2], they will find it more difficult to do evil things with Wine > under the LGPL than they would under the BSD license; this is a given, but they CAN still exist. The notion that LGPL will prevent that kind of behavior is just not true. > and at least some of the companies that don't contribute at all do so > because they're misguided, not because they're evil, so the LGPL would cause them to > contribute back to our mutual benefit. Both of these results are wins. the misguided ones I think (MHO) eventually will contribute back, for the very same reason you have stated (problems with keeping the trees synced). Regardless, the whole point boils down to this: Is the code you are going to coerce out worth the code that is lost by entities either unwilling or unable to abide by *GPL? There has been ample statements made saying that the latter part of the question is not insignificant. > [2] Not a very sustainable business model, btw; on the whole, being evil > is no more profitable than being altruistic. I agree that it's self-defeating, but there is nothing altruistic if you EXPECT to be paid, whether it's cash, or code. I haven't seen any arguments for *GPL made here on altruistic grounds (not to say that *GPL can't be used for such purposes - take quake from Id software for example, but this is when you take something propriatary and *GPL it). All I see are pretty selfish - which is fine, as long as it's not being passed as being altruistic. -r

1 0

DirectX implementation on top of OpenGL
by Jakob Eriksson 13 Feb '02

13 Feb '02

DirectX on OpenGL. http://sourceforge.net/project/showfiles.php?group_id=44365&release_id=70636 Seems to BSD style license, but only some files say that. Most files have no copyright information. Warning: a whole slew of files are Copyright Microsoft. (Only include files though.) regards, Jakob Eriksson

1 0

Re: Wine license change
by Roger Fujii 13 Feb '02

13 Feb '02

> The LGPL and the GPL have different restrictions on the creation of > certain types of derivative works. The thing about Wine is that it's not > *a* library, it's a *set* of libraries -- reimplementations of DLLs. How is this any different from the linux kernel and its device drivers? Read: http://www.uwsg.iu.edu/hypermail/linux/kernel/0105.3/0203.html I don't think that LGPL and GPL differ in this regard. > > I have no clue what you are talking about. I didn't say anything until > > the "Here we go again". And Yes, I have read the *GPL, many, many, many > > times. > > 'Effectively license your software to the FSF'. The LGPL, as a license, > is designed to be idempotent, just as the BSD license is; under each > license, everyone is granted the *same* freedoms. There's nothing in the > text of the LGPL that can be interpreted as licensing your software to the > FSF that isn't already present with the existing license. I can change the BSD license. I cannot (or at least, not without a fair amount of work) do this with *GPL. It forces me, the copyright holder of the contributions, to contribute as *GPL, even if I may prefer a freer license. This lack of ability of changing the license is why I say "effectively license to the FSF". > > This AFAIK, fulfills the technical requirement > > of the *GPL, but it certainly isn't a usable form. > In that respect, you're correct that no one has to release the source > code in a form that's easily reintegratable with the main Wine tree. And > if someone wanted to be spiteful, they could do what you describe -- but > they would still have to release the source code in the form that THEY use > it when working on and compiling Wine, which means their changes are still > visible for others to study. yes, but studying can be done in a non 'open source' license too (like AFPL). This is why using the word "contribute" is really a misnomer which is why I said "show your work". > > we can quibble about what "free" means, but saying GPL is "more free" than > > X11/BSD doesn't make any sense. Given the current license is X11/BSD and > > the argument is for changing it to LGPL, I can't see how one can use the > > "freedom" argument in this case. > > > geez. no need to get bent out of shape. I'll rephrase and say BSD is > > MORE free than GPL. Happy? > > I don't believe anyone has argued that Wine should be placed under the > LGPL because the LGPL is more free than the BSD license. er, that was what I was responding to - someone did. > I disagree with the idea that what users are allowed to do with the code is the only > metric of freedom that's important to consider, but since this relicensing > discussion wasn't brought about by concerns that the current license is > non-free, I don't think it's relevant, either. You're correct that the > BSD license is more free than the GPL per this particular metric. The claim that moving to *GPL would make it MORE free (which implies that the current license is LESS free). My point is that this is a non-argument (and you seem to be agreeing with me here) > > The problem with that particular argument is that it makes the fundamental > > assumption that all people who don't contribute back NOW is evil foreever. > > You just don't know what will happen in the future. Maybe Sun/IBM buys out > > lindows.com in 6 months when they are broke, and opens the source. Or, > > maybe in a year, they have a change of heart (has happened before with other > > companies). The point is that it's arguably better to have more players. > > Actually, I don't think that assumption is key to my argument. Consider > that a company which takes without giving back will either spend a lot of > developer time re-merging upstream fixes into their local product, or will > create a product which diverges significantly from the main tree. Either > scenario, when considered by itself (that is to say, setting aside any > reasons this might be profitable), constitutes an inefficient use of > programmer time; the cost of keeping a private tree is higher than the > cost of letting the community maintain the tree for you. ok.. but this argument works for the current license too.... > If the company is one like Corel, who profits not by selling Wine but by > selling products that run under Wine, then trying to keep their changes > private is misguided -- most such companies would still see the advantage > of a Windows implementation that they didn't control exclusively, so long > as Microsoft didn't control it either, and would not be turned off by the > LGPL -- in fact, both we and they would benefit from the LGPL, because of > the more efficient use of developer time. this is still true for the current license. > Other companies in that situation might indeed shy away from an LGPLed Wine; > but I can't think of a rational reason for doing so, and companies that make irrational > business decisions don't strike me as a good reason to avoid a licensing > choice that benefits the rest of us. here is where we differ. The problem with *gpled stuff is that because certain things are unclear, even well meaning people can end up in violation. If you read the kernel arguement at the beginning, we see that there is a difference in interpretation between alan cox and the FSF. It is not irrational to say that the legal risks are greater than the economic gain. And for those of you who say *GPL is on strong legal ground, look at slashdot today. A calif court just threw out a significant section of a EULA and may affect the GPL. Don't know if it is going to be upheld (might make it to the supreme court), but the point is that it is definitely not in settled law. > If the company is one like, say, Lindows.com, and they have a business > model based on selling a branded, enhanced version of Wine, there are > rational reasons for possibly not wanting to use an LGPLed code base. > There are several different options for such a company. Some might choose > to risk the LGPLity, and decide to see if they can make a profit just from > selling people something they can already get for free. This is not out > of the question; every Linux vendor is doing this today, and if 90% > marketing + 10% programming works for Microsoft, it should work for others > too, right? a) M$ can charges for their work b) it works for linux (I presume you mean distributions) vendors because most others sell a propriatary value add (like transgaming) which does not fall under your description for this case. The linux vendors have an advantage that what they are replacing (nt, solaris, aix...) are a rather expensive. The problem wine solves (for most people) is the cost of a PC (US$400). There isn't much of a margin here. Can you show me any example of successful companies using this business model? [snip] > This leaves the last possibility; that such a company chooses not to enter > the market, or fails to come into being, because they can't find numbers > that make sense using either a slightly-older, BSD-licensed Wine or an > up-to-date LGPL-licensed Wine. And we do lose something by not having > such companies around, particularly if they happened to have a 'change of > heart' down the road and freed their source code. or have their participation in current development. Most well meaning companies will send in patches to parts that they are not trying to hold propriatary. You're making the assumption that companies that hold ANY software back will hold ALL the changes. > Does the loss of such companies as players in the Wine community outweigh > all of the other potential advantages described above, including the > advantage of some otherwise closed-source companies choosing to open > their source as a result? I don't think it does. I think that today, if > we look at nothing more than raw lines of code that Codeweavers > contributes to Wine that we are told would not available for use in a > BSD-licensed tree going forward, it makes sense to switch to the LGPL; and > I think the benefits only go up from there. As I said before, if you don't care about other commercial input, go *GPL. But at least be honest and say, "we don't care about companies like transgaming". It's utter nonsense to say that the license change will only affect "the evil companies that steal our source code" (I just love how people use 'steal' in reference to something freely given away - I guess the same people ask for interest when they do charity work) or that wine will benefit because evil companies will now 'contribute'. If they are that evil, they will run the obfuscator and make the merge difficult, if not impossible. So, given the world of (using "contribute" meaning code that can be easily worked back into the common tree): 1) Evil companies that won't contribute no matter what 2) Companies that contribute some, but not all of what they do 3) Companies that contribute The only thing a license change will do is stop #2. If this is what you want, we can stop arguing now. -r

3 2

Re: Copyright, derivative works, and truly free licensing (Was:
by Rolf Kalbermatter 13 Feb '02

13 Feb '02

Brett Glass <brett(a)lariat.org> wrote: >I agree wholeheartedly that such discussion shouldn't be a constant distraction >or devolve into a "flame war." I have taken great pains to express my point >of view very carefully and to make sure that nothing I've posted could be >construed as "flamage." Well, I for myself can only say that you have certainly failed in this. For me, your posts had from the first beginning the character of somone on a crusade against RMS, the FSF and anything connected with it. Although some of your remarks would have been at least interesting, that fanaticism in wording your opinion about xGPL, making claims about what someone elses intentions "doubtlessly" are, and trying to come up with the worst doom scenarios, made it virtually impossible for me to accept and listen to any of your other more serious statements. The subject of what direction Wine should go, seemed obviosly just the coat hanger on which you continued this, your personal crusade! So as far as I'm concerned you have certainly not reached your goal. I'm certainly not a xGPL fanatic, but it personally feels not right to me that people spend their time on something to work on and any company can come in and take whatever there is and make profit out of it, without contributing something back. And with that I don't mean the questionable marketing hype of letting those people say: "Hey you know, they made their great product out of our project and I'm so proud that I have spent months and months of my own time to allow them to earn big bucks!" And don't say that they earn the money only for the additional value that company has put in. If it wouldn't be for the developer in the project, that company would not have a product at all to sell as you have actually also agreed on. >I agree, as I have said above, that the developers have the right to make >the decision. But because they are doing the entire project for the benefit >of users as well as for themselves, they certainly should care about how >users feel. What's more, if they are seeking bug fixes or help with >development, they certainly should care how potential contributors feel. >Finally, they should care about how advocates of the project feel. While >advocacy does not expand the code base, it does expand the base of users >and testers. Hence, it plays an important role in any collaborative >software project. You should have started the whole discussion more in this style. This would have helped a lot more than trying to bring in your personal feelings about the FSF and xGPL. Even if the FSF is what you say, it does really not help to bring that topic up in such an emotional tone. It only polarizes everyone, and hinders the solution of the original problem, which might cause the person who is responsible to take a decision out of frustration rather than out of great consideration. >I agree. If anyone has considered any of my messages to be a "flame" rather >than rational discussion, I apologize; nothing I've written was meant to be >a "flame." I really do want to be able to continue to work with, advocate, >and (hopefully) contribute to, WINE, and this has been the reason for the >volume of passionate messages I've posted over the past few days. Well I did actually. This is probably my problem, but your apology is accepted anyhow ;-) And now I go back and continue to work on my first of hopefully a series of contributions to Wine! Rolf Kalbermatter

2 1

Re: Licensing response and an idea
by Lean Fuglsang 12 Feb '02

12 Feb '02

Thanks for an enlightening post, Gav. //DISCLAIMER - I AM JUST AN ORDINARY USER - SO DON'T READ IF YOU DON'T FEEL LIKE I am not a developer (yet). But I truly believe in the spirit of OpenSource Free software. I have reported some bug reports, but I would really like to contribute more. When I first heard about a (very) possible licens change to GPL I thought it was a great Idea, because I hate companies who take code and don't contribute back. With the current license this is possible. But I also think it would be a shame for companies with good intentions (as Transgaming) who (maybe:) will contribute all there code back, and make very fast directed code to wine. I would also be very delighted to pay money directly to the wine project because I like it and use it. An important note is that this is what I do with everything that I buy. When I by music, it is because I like it and have heard it and want's to support the artist. Same with movies. I know this is not the way the corporate world works at the moment, but I can pirate music/video/software very easily and therefore they have to trust me to pay for what I want's to pay to. Phew, hope I didn't confuse all of you (like I confused my self:) But the point is, I really like to make contribution to a gratis project if it is GPL'ed or dual licensed (for 'good' corporations). Many of the people I know has the same 'Ideology' as me, and don't pirate things they think aren't sh**t. And after I have changed to linux and opensource, I have actually pirated a lot less, because all stuff are free, and the things that aren't 'stands out', so to speak. Just my .02$ (and maybe more if it goes as I hope:) //lean Ps. Hope I send this mail to the right place

1 0

Direct 3D 8.0 Wrapper for OpenGL Open Sourced
by Damjan Lango 12 Feb '02

12 Feb '02

Hi, Just found this on http://www.osnews.com/: Direct 3D 8.0 Wrapper for OpenGL Open Sourced http://www.osnews.com/story.php?news_id=613 Not sure what is the license, but maybe it could be incorporated to wine as an alternative to the transgaming's version. ciao Damjan

3 2

wine license vote
by Shane Shields 12 Feb '02

12 Feb '02

hello after having contributed a couple patches (more to come im working on getCalenderInfo now) i feel i can say a couple of words. i have been following the current "discussion" on the license change with avid interest (not to mention a few laughs). just to make sure im not speaking out of a red hat (i compiled my own linux) i downloaded a copy of the licenses in question and compared them side by side. as everything that i wanted to ask has been discussed on the list with good points from both sides of the fence im not going to go over old ground. i think that the lgpl license would be a better choice for WINE than the bsd license. i know that some would disagree and some would agree thats the way the cookie crumbles. but i think that the most important thing is for people to make a decision for themselves and not to try to convince people that dont want to be convinced. its a waste of programming time and cpu cycles (sound familier m$). Shane Shields -- To drink the WINE of success you must first seek the sayings of source _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Greetings and a question
by Michael Cardenas 12 Feb '02

12 Feb '02

Hello everyone. My name is Michael Cardenas and I'm working on Wine for Lindows.com. I'd like to start a lot more communication with all of you and I have a couple of questions. I'm working on an app that uses a custom dll which requires msvcp60.dll to be loaded at launch time and won't launch without it. Currently there's no implementation of msvcp60.dll in wine. Is that just because no one has needed it yet? Or has someone looked into this and seen that it's too large to do? Or is it just not needed and there's some substitute dll? Doing some research, I see that on a fresh install of Windows98, the dll is present, so it seems to be a common windows dll. MSDN mentions the dll in this article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html… "A good example of this is the Microsoft Visual C++ Runtime assembly, which includes atl.dll, mfc42.dll, mfc42u.dll, and msvcp60.dll." Also, there's been basically no discussion of this dll on this mailing list. So, to proceed, I'm going to create a stub dll and hope the app will launch and not need many functions from that dll. I'd like to know if there's a good way to make a complete stub for the dll. Right now, I just made a stub dll with one function. Thanks, Michael

4 3

ping
by lawson_whitney＠juno.com 12 Feb '02

12 Feb '02

Good day! Anybody know a current email address for Mike McCormack? Did he ever show up at Codeweavers? Regards, Lawson

2 1

Re: RFC: Re: Problem with COM (fwd)
by Gerard Patel 12 Feb '02

12 Feb '02

At 10:05 PM 2/11/02 -0500, you wrote: <snip> (original poster) >I must use 5726, 5760 and 9600. My app need this to work. On 4800 >and 9600 I got error. <snip> (Lawson) >Now nobody is going to convince me there is any software that will make >a normal 16550a run at 5726 <snip> You still don't have access to the world wide web ? If you have access to Google, search for the following Usenet posting, for example : UnHy6.600095$JT5.16435354(a)news20.bellglobal.com If you can't use Google, you could see that this is a common request under Windows. quite a few programmers need to access devices with non-standard crystals, or even non 8251 chips with specific drivers. In this post, you could see that SetCommState accepts any baud rate up to 9600 bauds, and that over 9600 bauds the idea is that the Windows driver should accept values that are inside a +-1% interval of the 'correct' value (although the poster says that the calculation is bugged and works only for negative differences). The Windows code for the 8251 family is probably always rounding to the next integer value under 9600, and if the wanted rate falls to +-1% of the 'normal' value over 9600. As I understand it, the 1% tolerance is explained because such a small difference don't matter for asynchronous serial communication. Gerard

2 1

Lindows.com and open source
by Michael Robertson 12 Feb '02

12 Feb '02

Claude, >From: Claus Fischer ("claus.fischer(a)clausfischer.com) >If the current license allows Lindows to make proprietary >modifications and not give anything back, it certainly >allows Codeweavers/whoever to make proprietary modifications >and give back under LGPL. > >Those who don't want to even read LGPL code for reasons of >'contamination' just shouldn't read it. You can't read Lindows >code either. > >Why should Codeweavers be morally pressured to contribute under a >steal-me license when steal-it companies don't contribute at all? Just to set the record straight. Lindows.com has had a partner company producing the majority of our WINE code. The vast majority of the code that came from that partnership is in the public tree already. Lindows.com has contributed code to open source projects. We have hired open source companies (spending over 500K) to help us reach our goals with the majority of the code going back to open source. Lindows.com has given financial support to several open source initiatives (such as KDE). Lindows.com has made significant investments in linux companies. All told, we've spent about 2 million in the 5 months that we've been a company. Linux (and all the other pieces) does 95% of what people want to do today, but only has 1% market share. Our belief is that the code is largely not the limiting factor for adoption now. It's all the pieces that go around the code. It's education, it's marketing, it's lobbying, it's business development, etc. These are big tasks which are critical to success, even more so than the code itself (think AOL). I know this won't be a popular thing to stay on a mailing list with "devel" in the title, but it's where we believe linux is and what we believe needs to happen to get to the next level. This doesn't mean the code isn't important, it is but there are other critical elements. We need Lindows.com and 10 more thriving companies to help with the expense of educating, lobbying, marketing, etc. desktop solutions. It's expensive to do those things and a burden that needs to be shared by several companies because the job is so enormous and the competitor so strong. The Linux community, especially the desktop community needs healthy ongoing companies to put in capital, organization, and other support. If we can put a few million more people running Linux on the desktop, then magical things will happen. Drivers for linux will be available, higher quality linux software will emerge, more OEMs will offer linux as an option, devices will have linux interfaces, governments will view linux differently, etc. There are some small, but meaningful for-profit companies out there today in linux (such as codeweavers and transgaming). The more companies in the linux desktop space there are, the more companies that will be able to pay their rates on an ongoing basis and hire them to code great products. There's tremendous opportunity and the more companies out there the better. As for our marketing message, it's designed for my Grandma. Anytime there's a word on the website she doesn't understand she calls me up. Try explaining a recursive acronym to your Grandma. Yikes. Our goal with Lindows.com is to bring Linux to the segment of the world who thinks linux is spelled with a 'y' and is a small bobcat. -- MR Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

2 2

Keep filling my mailbox please
by Alexandre Julliard 12 Feb '02

12 Feb '02

Folks, First I thank everybody who mailed me in reply to Jeremy's request, I now have a clearer picture of where the community wants to go. However, I still haven't heard from a number of contributors; so if you haven't sent me your opinion yet, please do it now, so that we can reach a conclusion soon and hopefully return wine-devel to its original purpose. As a reminder, the question Jeremy asked is the following: > Should the Wine project switch to a license which has as > its goal to attempt to secure some form of Copyleft > protection for Wine while still permitting proprietary > software to link and bind with Wine? Just let me know privately whether you agree with that or not. If you don't care either way, or aren't decided yet, please tell me that too, I want to make sure I know where everybody stands on this issue. Thanks. Note: everybody is welcome to send me their opinion, even people who didn't contribute code. Of course the opinion of people who have contributed will carry more weight in the final decision, but I think everybody should have a voice. -- Alexandre Julliard julliard(a)winehq.com

4 3

RE: Direct 3D 8.0 Wrapper for OpenGL Open Sourced
by Patrik Stridvall 12 Feb '02

12 Feb '02

> Just found this on http://www.osnews.com/: > > Direct 3D 8.0 Wrapper for OpenGL Open Sourced > http://www.osnews.com/story.php?news_id=613 > > Not sure what is the license, but maybe it could > be incorporated to wine as an alternative to the > transgaming's version. Some of the file have the following copyright: ; * Copyright © Realtech VR 2001 ; * ; * Permission to use, copy, modify, distribute and sell this software ; * and its documentation for any purpose is hereby granted without fee, ; * provided that the above copyright notice appear in all copies and ; * that both that copyright notice and this permission notice appear ; * in supporting documentation. Realtech makes no representations ; * about the suitability of this software for any purpose. ; * It is provided "as is" without express or implied warranty. But some of the files have another copyright: * Copyright (C) 1995-2001 Microsoft Corporation. All Rights Reserved. Yet some files contains no copyright notice at all. I wonder the license status of the whole thing really is. We should be very careful before including something like this. Beside it is for most parts in C++. That can of course be fixed but it would require some work.

1 0

RE: Wine license change
by Patrik Stridvall 12 Feb '02

12 Feb '02

> Patrik Stridvall wrote: > > > > > Francois describes the central issue well: the LGPL will > > > provide a way for the vendors to trust each other. > > > > > > Let those of us who understand this simply start releasing > > > our Wine changes under the LGPL, regardless of what anyone > > > else does. That should make it clear which way the main > > > tree should go. > > > > First of all what "those of us"? You mean "those of you"? > > Searching the mailing lists I see that you from time to > > time have provided various testing, suggestions or > > other information but I can see no patches. > > Ask Jeremy White if he thinks I've been contributing to the cause > lately; I bet he considers the stuff I've written lately to > be helpful, > even if it doesn't appear in the tree. OK. I got a little carried away. Sorry. > > Secondly understand what? > > Understand that the LGPL enables competitors to trust each other. Yes, I understand that you think the LGPL will enable competitors to trust each other. However if wrapper libraries are allowed all such bets are off. You could just implement whatever you think gives you the competative advantage in a seperate library under a proprietary license and just release the wrappers. In fact some things actually makes sense to have in a seperate library maintained seperately from Wine. Of course it would be preferable if such library was under a Open Source license, but then if the LGPL can't enforce this then I can see how you can claim that any trust must exists. Consequently you must believe that the LGPL can enforce this and since you claimed not only you believed that it would, but used the word understand, I assumed that you REALLY understand how the LGPL works. But from the statement below it seems that you don't, do you? > I can't address your and Roger's concerns about the LGPL > effectively because we seem to have such different world > views that communication is difficult. My apologies; I'm > just not a good communicator sometimes. What different worlds view? If the LGPL in unambigeous it means one and only one thing in the world of law, the only world that counts. So never mind what I believe or see the world, explain what the LGPL means the world of law. You said you understand it enforces trust, so please explain why? Never mind that you seems to believe that we wouldn't understand it. Please explain it to the world, I'm sure somebody will understand it.

1 0

Re: Lindows.com and open source
by Michael Robertson 12 Feb '02

12 Feb '02

>John Alvord <jalvo(a)mbay.net> At 02:11 PM 2/11/2002 -0800, you wrote: >Maybe you could shed some light on the current License flamefest. >Would BSD versus LGPL have made any difference to you progress as a >company? You have contributed so much in the past, a formal statement >of intentions could reduce the perceived problem... I'm not sure Lindows.com has earned a voice in the license debate yet or even if we had a voice could add anything meaningful that hasn't already been said. There are many others who have for years shepherded WINE to this stage. I'm confident they'll do the right thing. Licensing is a topic on the wineconf 2002 agenda. I'll be sending a list of topics to the list shortly for feedback. Thanks to those who have offered suggestions. From a more general perspective though, I believe there needs to be much more investment in many areas of WINE and more broadly Linux to get to the next level (say from 1% penetration to 10%). Anything that gets more people involved, more organization, more developers, more capital, more companies, and more ideas will ultimately be a good thing. When I was at MP3.com, we had the MP3 summit every year. We invited everyone including our direct competitors, tangentially related industries and even our antagonists. We'd not only invite them, but also encourage them to speak. Our thinking was the more people that we got making "neural connections", the more success MP3 would have (and ultimately MP3.com). Companies were created, merged, and bought because of the MP3 Summit. Products were dreamed up and built because of the MP3 Summit. It wasn't about our company, it was about bringing all the smart, passionate people together (even if they had opposing viewpoints) and watching the magic happen. I believe Linux and WINE (at least on the desktop) are at similar stages. -- MR Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

2 1

RFC: Re: Problem with COM (fwd)
by lawson_whitney＠juno.com 12 Feb '02

12 Feb '02

---------- Forwarded message ---------- Date: Sun, 10 Feb 2002 21:32:31 +0100 From: "[iso-8859-2] Du¹ko Rusmir" <drusmir(a)gmx.ch> Reply-To: wine-users(a)winehq.com To: wine-users(a)winehq.com Subject: Re: Problem with COM Dana nedelja 10. februar 2002. 04:11 napisali ste: > On Sun, 10 Feb 2002, [iso-8859-2] Du¹ko Rusmir wrote: I must use 5726, 5760 and 9600. My app need this to work. On 4800 and 9600 I got error. With other app I can use 38400, 57600 and 115200 wery well. I thing the handling of COM Port on these BaudRate is't good. Thanks -- trace:comm:BuildCommDCBAndTimeoutsA (COM1: baud=5760 parity=N data=8 stop=2,0x405608ac,(nil)) trace:comm:SetCommState handle 64, ptr 0x405608ac trace:comm:SetCommState bytesize 8 baudrate 5760 fParity 0 Parity 0 stopbits 2 trace:comm:SetCommState ~IXON ~IXOFF err:comm:SetCommState baudrate 5760 Now nobody is going to convince me there is any software that will make a normal 16550a run at 5726, but with effort I managed to explain the linux setserial spd_cust kluge, and at last report the app was working: /dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4 Baud_base: 115200, close_delay: 50, divisor: 20 closing_wait: 3000 Flags: spd_cust skip_test trace:comm:BuildCommDCBAndTimeoutsA (COM1: baud=38400 parity=N data=8 stop=1,0x405608ac,(nil)) trace:comm:SetCommState handle 76, ptr 0x405608ac trace:comm:SetCommState bytesize 8 baudrate 38400 fParity 0 Parity 0 stopbits 0 trace:comm:SetCommState ~IXON ~IXOFF trace:file:ReadFile 76 0x405607d0 255 0x405607c4 (nil) trace:file:ReadFile 76 0x405607d0 255 0x405607c4 (nil) trace:comm:EscapeCommFunction handle 76, function=3 trace:comm:EscapeCommFunction SETRTS trace:comm:EscapeCommFunction handle 76, function=4 trace:comm:EscapeCommFunction CLRRTS Now I am not particularly fussed that Wine should be exactly as Windows, and I am willing to try to explain (again) the spd_cust kluge in Wine doco, if I don't have to use sgml, but I wonder if it wouldn't be better in the long run to figure out what Windows does with off-brand speeds like this (little help? I don't have any Windows.) and cobble up a TIOCMGSERIAL/TIOCMSSERIAL to handle them, at least for Linux. Anybody know how to do a ./configure test for an ioctl? Oh.. looks like we already have some. I guess I can figure it out. 5760 is easy, I believe that is just a divisor of 20, but 5726? Does it round up to the next possible speed? Round down? Count the feet and divide by 4? Lawson

1 0

Re: Wine License Change
by Claus Fischer 12 Feb '02

12 Feb '02

As a non-developer, I think this discussion can be considerably shortened by just forking and starting to work on the LGPL branch. If the current license allows Lindows to make proprietary modifications and not give anything back, it certainly allows Codeweavers/whoever to make proprietary modifications and give back under LGPL. Those who don't want to even read LGPL code for reasons of 'contamination' just shouldn't read it. You can't read Lindows code either. Why should Codeweavers be morally pressured to contribute under a steal-me license when steal-it companies don't contribute at all? Just let Codeweavers use their rights that you defend so vehemently for others, and don't critizise them for doing something your favourite license permits. ****** I personally tend to think that GPL style licenses attract more developers and create a level playing field even for companies as contributors. Put a snapshot of current CVS somewhere for X11 freaks and start checking in LGPL. And don't discuss with morons, especially non-developers ... :-) Claus -- Claus Fischer <claus.fischer(a)clausfischer.com> http://www.clausfischer.com/

2 1

RE: Wine license change
by Patrik Stridvall 12 Feb '02

12 Feb '02

> Francois describes the central issue well: the LGPL will > provide a way for the vendors to trust each other. > > Let those of us who understand this simply start releasing > our Wine changes under the LGPL, regardless of what anyone > else does. That should make it clear which way the main > tree should go. First of all what "those of us"? You mean "those of you"? Searching the mailing lists I see that you from time to time have provided various testing, suggestions or other information but I can see no patches. Secondly understand what? If you are so clever that you REALLY understand what the LGPL means, please enlighten us poor ignorant people. In particular answer Roger Fujii's challenge: I challenge anyone to show me what "work that uses the library", "work based on the library", and "whole" means in the context of wine. The problem is that I'm pretty sure you can't. In any case the trust mechanism of LGPL is dependent on the how the license is interpreted. If you are not certain or pretty sure how a judge or jury will interpret the license, all trust issues are meaningless. Futhermore I have tried to show that you can't both have the cake and eat it. In order for the LGPL or for that matter any license to provide the "trust" that you are after you must also prevent things that are quite reasonable to assume are legal. Like Joe Hacker using his proprietary library to get another proprietary application to run under Wine in order to avoid dual booting and share it with fellow hobbyists. Even if you dismiss this as "Oh well, even so I think it is worth it.", I have another question: How is this compatible with freedom 3 of the free software definition? Free Software Definition (freedom 3): The freedom to improve the program, and release your improvements to the public, so that the whole community benefits.

2 1

Wine Developer License Test
by Ove Kaaven 11 Feb '02

11 Feb '02

Take this test and find your preferred license. A few simple questions can reveal your stance. Fun for the whole family! 1. Do you maintain that information (code) should always be free, no matter how expensive or difficult that information was to come up with, no matter how limited applicability it may have, and no matter how damaging freeing that information might be for the industry, both good and bad? a) yes b) no c) maybe points: a = 2, b = 0, c = 1 2. How should people that come up with such information (coders) be rewarded for their efforts? a) tangible goods (money) b) name recognition in the liberation army (free software enthusiasts) c) name recognition in the rest of the world d) feeling good about themselves (no reward at all) e) I really don't care about them, I just want the code points: a = 0, b = 2, c = 0, d = 1, e = 2 3. Would you like it if your work was incorporated into cheap, mass-produced, proprietary, commercial consumer devices, like cell phones, game consoles, microwave ovens, or home-grown nuclear power plants? a) yes b) no c) I don't care points: a = 0, b = 2, c = 1 4. Do you care about users? a) yes, I would like to have many users, and listen to their needs b) no, I'm the developer, I do the work, it's my way or the highway c) mostly, but not at all costs, I don't mind losing a few points: a = 0, b = 2, c = 1 Results: 0-1: I feel the X11 (BSD) license makes the world a better place 2-3: While not perfect, I think the X11 (BSD) license does give users a fair choice and encourage wide use 4-6: I am somewhat suspicious of my users, so I think the LGPL license makes it easier to herd them 7-8: Freedom above all; I elect RMS for president, and prefer the GPL

2 2

ScrollBar/Cannot use first megabyte
by Phillip Ezolt 11 Feb '02

11 Feb '02

Hi All, Here's a little break from the license wars. When I run the example contained in 1902.exe from: http://msdn.microsoft.com/library/en-us/dnwui/html/msdn_scroll32.asp?frame=… I receive the following error: "err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report" Interestingly enough, the test program for scroll bars works much differently on Windows NT than on Wine. The scrollbar example includes both source and executable as well as documentation about some Windows scrollbar bugs. If I knew a little bit more about windows programming and/or Wine, I'd fix it.. --Phil Compaq: High Performance Server Systems Quality & Performance Engineering --------------------------------------------------------------------------- Phillip.Ezolt(a)compaq.com Performance Tools/Analysis

1 0

Re: Wine license change
by Roger Fujii 11 Feb '02

11 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > On Thu, Feb 07, 2002 at 05:45:36PM -0500, Roger Fujii wrote: > > If you are using marketing speak for "contribute". GPL requires 1) > > for you to show your work 2) You effectively license your software to > > the FSF. It doesn't say it has to be in any useful form to be worked > > back into the originating project (if any). > We're talking about the LGPL, not the GPL. true with either. Your "contributions" must be licensed as LGPL/GPL. > The rest of this paragraph shows a serious disconnect with the text of > the LGPL. Have you actually read the license in question? I have no clue what you are talking about. I didn't say anything until the "Here we go again". And Yes, I have read the *GPL, many, many, many times. > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control > compilation and installation of the library. If you are contesting the "useful form", let's say I did this: Took the original GPLed code and run it through a lexical translator so that all labels and such are changed. Make my changes with respect to THIS codebase. Now publish this. This AFAIK, fulfills the technical requirement of the *GPL, but it certainly isn't a usable form. > > Here we go again.... If this is *all* it did, LGPL is far less objectionable. > > The problem with *GPL is that it also regulates the UNMODIFIED use of the > > software. > > The creation of derived works does not constitute "unmodified use of the > software" under any legal definition I've ever seen, if that's what you're > referring to. no, it's this phase: Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. > > Freedom means allowing people to do things, even things that you don't > > agree with. BSD = Free. GPL is not. Call a spade a spade.... > > Nonsense. To extend your definition to the proper conclusion, it's not > Free unless it's placed in the public domain, you are ABSOLUTELY right. The spectrum is PD->BSD->GPL-------->Propriatary. But then, things in the PD really isn't licensed, so X11/BSD is probably as close as one can get. > and any software license that permits you to maintain any portion of your > copyright is a fraud if it claims to be Free. If you really cared about > giving absolute freedom to the users of code that you write, you would > place all of your code in the public domain. we can quibble about what "free" means, but saying GPL is "more free" than X11/BSD doesn't make any sense. Given the current license is X11/BSD and the argument is for changing it to LGPL, I can't see how one can use the "freedom" argument in this case. > Not planning to do that any time soon? stuff that I have put back into projects go with the license that it's under. All of the changes I've put back goes back with *no* restriction (ie. it's PD as far as I'm concerned). > Then spare us the bullshit arguments about the BSD being Free and the GPL not. > (Yes, it is bullshit. Call a spade a spade, right?) geez. no need to get bent out of shape. I'll rephrase and say BSD is MORE free than GPL. Happy? > All Free Software licenses attempt to find an equitable balance between the > freedoms and rights of the authors, and the freedoms and rights of the users. this statement is true of licenses in general, with the freedoms/rights of the user declining along that freedom spectrum. In the US (forgetting the DCMA for the time being), the freedoms and rights of the authors are guarenteed by law (1st amendment/copyright). What I philosophically object to is using the freedom argument WRT GPL, since the freedom of the author is never in question, while the freedom of the user is curtailed. I have no problems in saying it's equitable, fair, desirable <insert socially desirable adjective here>, even "right" - just not 'free'. > You are free to favor one balance point over the others, but that doesn't make > other licenses and other balance points non-free. my dictionary says one of the definitions of freedom means "unrestricted use". So it's fair to say something that has MORE restrictions is LESS free, or are you arguing that GPL is more "free" than PD? > But neither philosophy nor politics is the issue at hand. The issue at > hand is whether the LGPL, or a similar license, would be better or worse > for growing the Wine community. For that, there are good arguments on > both sides. we agree. > On the other side, companies like Lindows.com don't impress me as bringing > any added value back to the community -- they may succeed in increasing > the percentage of non-Windows desktops in the world, but the current Wine > license makes it possible for all the profits from their OS to pad the > wallets of marketroids, sales critters and smooth-talking business execs, > without contributing anything back to the Wine tree. I have no problem at > all with the idea of eliminating that particular business model. The problem with that particular argument is that it makes the fundamental assumption that all people who don't contribute back NOW is evil foreever. You just don't know what will happen in the future. Maybe Sun/IBM buys out lindows.com in 6 months when they are broke, and opens the source. Or, maybe in a year, they have a change of heart (has happened before with other companies). The point is that it's arguably better to have more players. > > If this is the goal (it certainly is mine), then *GPL is not a good choice, > > because it would interfere with deployment (*GPL wouldn't allow being bundled > > with the playstation2 or other HW platforms as an example). If acceptance > > is the goal and you care about wine in a non-linux context, stay with > > BSD/X11. If you don't care about expanding the pie, go *GPL.... > > Please write what you mean, which seems to be "Sony would never accept the > terms of the LGPL, which would prevent them from being able to bundle Wine > with the PlayStation2". Again, I don't see where this would be a loss. > Companies that are unwilling to contribute back to the community are not > any concern of mine; if they want to compete with Microsoft on the > desktop, let them fund their own software development instead of leeching > off of the community. My only concern with the LGPL is making sure that > well-intentioned companies that DO give back to the community aren't > caught in the middle. Let's say the playstation distributed wine for every PS2 that shipped. If only .001% of its users (and these are gamers) get interested in wine, that's 200 additional contributers. Most people get involved with a project because they USE it initially. So, it's reasonable to say that wine is still better off if sony distributed it without contributing *anything* (maybe had had to make NO changes, who knows) because of the additional interest. You might not consider this a loss, but to me, it seems like it is. -r

3 2

Yet the parameters problem (WAS: CreateProcess API - undocumented use)
by Ricardo 11 Feb '02

11 Feb '02

Ok, I've tried everything. Change the API used (GetStartupInfoA to GetStartupInfoW), changed the code, but I have no idea where to change in wine to, when I have 2 programs, doesn't loose the passed parameters. Here's how it works: PGM1 starts and ask the username and the password. If it's ok it writes FILE1.DAT and FILE1.IDX with settings to PGM2 to run. These files are wrote correctly, but PGM2 can't read them. When PGM1 finish wine seems like "closing" and than star over with the PGM2 (called by PGM1 with the parameters writen (API CreateProcess)). But PGM2 starts without any parameters (API GetStartupInfo) and without the parameters it cant run, so the program exit. I've already checked 3 files: loader/module.c, scheduler/process.c and memory/environ.c. And compared it with the MSDN Library, and the codes are the same, so no problems with it. How does WINE deal with a program calling another one? thanks Ricardo

2 1

Re: Make Home, End and Enter on the keypad work in the debugger
by Eric Pouech 11 Feb '02

11 Feb '02

Dmitry Timoshkov a écrit : > + {/*VK_END*/ 0x23, WCEL_MoveToEnd }, > + {/*VK_HOME*/ 0x24, WCEL_MoveToBeg }, those two ones are already in Win32KeyMapExtended, so I don't see no reasons to add them twice A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Dr. Seuss, licensing, and WINE
by Brett Glass 11 Feb '02

11 Feb '02

[Note: This is a slightly revised version of some material which I've posted to Slashdot. Copy replies to me, as I am not on the wine-devel list (though I have been an active advocate of WINE and will continue to be so long as it is not licensed under a viral license such as the LGPL). -BG] This entire issue is reminiscent of the well known Dr. Seuss story "Horton Hatches the Egg." In the story, a bird lays an egg and then convinces a kindly elephant named Horton to sit on it. Horton braves all manner of hardships -- heat, cold, even the indignity of being captured and displayed as a freak in a circus -- to remain with his charge until it hatches. Whereupon, the bird immediately demands that Horton return the fruits of his labor to her. (Were she a modern Richard Stallman, she might have declared that it was a GPLed egg.) Writing a program -- like laying an egg -- isn't necessarily an easy task. However, bringing it to the marketplace and successfully selling it as a product -- especially in the presence of a free alternative -- is a much more difficult and dangerous one. The company that hopes to sell a product that's an improved derivative of one that's available for free is taking a big risk and must make a truly Hortonian (if I may coin the phrase) effort to be successful. What Mr. Stallman and the (L)GPL would demand is that the person who manages to do this -- competing against all odds with a no-cost version and potentially infinite numbers of competitors publishing and bundling it -- get nothing. Those who wish WINE to be published under a license which is not truly free, as the current license is, appear to believe that the emergence of products such as Lindows is a threat to WINE and/or to businesses such as CodeWeavers. Nothing could be further from the truth. If the creators of derivative works act in their own best interests, they will return all but the most strategically important code from their implementations to the WINE project, reserving for themselves only what is necessary to differentiate their product from what another vendor (e.g. Red Hat) might produce. This minimizes their maintenance costs, and may -- there's no sure thing here -- provide them with sufficient value added to survive in the presence of a free alternative. (If they don't do this, there is an automatic penalty: they'll have to re-integrate changes into each new version.) To (L)GPL WINE, on the other hand, prevents such worthy products from ever seeing the light of day. It is, in essence, snatching back the egg from poor Horton after all of his hard work. And it won't benefit WINE, WINE users, or CodeWeavers. Many companies' potential contributions will be lost, and CodeWeavers and WINE will gain themselves a reputation for being hostile to business. This will cause the consulting business from which CodeWeavers hopes to make money to dry up. In short, the move is shortsighted and bad for all concerned. CodeWeavers, and other companies that hope to profit from their work on WINE via paid consulting, should look instead to the model of Wasabi Systems (http://www.wasabisystems.com/ [wasabisystems.com]), which just received a round of venture capital funding worth more than $1M to port, publish, promote, and consult on NetBSD. NetBSD is truly free; it's published not under the restrictive GPL or LGPL but under the BSD License. And Wasabi is going strong; they just published a desktop package (consisting of NetBSD plus GUIs and applications) that is competitive with the best of the Linux distributions. The WINE project, for its part, should resist falling prey to the spite and resentment that the Fascist^H^H^H^H^H^Hree Software Foundation encourages (and has made part of its licenses). If the project makes the mistake of adopting an FSF license, commercial programmers such as myself will no longer be able to so much as look at the code -- much less fix bugs or contribute. This license change would, effectively, close WINE to me and any other developer who writes commercial software... forever. Here's why. As most people already know, the GPL and LGPL require developers who create "derivative works" to give their work away for free. But what most people do not understand is that if a programmer so much as looks at GPLed or LGPLed code, and later writes some code that performs the same function, he or she is open to accusations that the code produced later is a derivative work. (The late ex-Beatle George Harrison fell into a similar trap when he heard a song and, years later, wrote one with a similar melody. A court convicted him of "unconscious" copyright infringement because he'd heard the original song.) For this reason, commercial programmers simply cannot look at source code that's published under one of the FSF's licenses without taking a tremendous risk which could destroy their careers as programmers. This may be fine with Richard Stallman -- who in the GNU Manifesto stated that programmers should code for love rather than money and that good salaries for programmers should be "banned" -- but for those of us who need to put food on the table it is simply a risk we cannot take. Thus, if WINE is (L)GPLed, I can no longer look at the code, fix bugs when something breaks, or contribute to the project. Nor can I peruse the code in order to learn from it. It will, effectively, be as closed as a closed source product to me and to any other commercial programmer. WINE will be un-free and would not be open source (since it would be licensed under a license that discriminates against a group of people and a field of endeavor). Only a truly free fork (which I sincerely hope will occur if the license is changed) will be accessible to those of us who code for a living. It would be a sad day for those of us who would LIKE to continue to recommend WINE to users who wish to free themselves from Windows, as I would immediately have to stop installing and advocating the use of WINE. --Brett Glass (Who hasn't happened to contribute to WINE yet, but may do so if it remains open source)

9 17

I see no reason to change the license
by Sean Farley 11 Feb '02

11 Feb '02

Thinking it over. I see no benefit for a change to the LGPL. The main reason was to force companies to give WINE their changes and/or additions to the code. As several people have pointed out, they can get around this by writing API wrappers. Doing so they will have removed the only reason the LGPL was proposed in the first place. It would be quite easy to keep in sync with the WINE code base. A PERL script (or whatever) could be written to output a wrapper file. Another script could be used to make changes to any future code base to make use of the wrapper calls. As someone who did this for my last company (JAVA API using JNI calls to mirror their own C library), I can say this will take a minimal amount of work. They would only need to release the changes they made to the code (just the wrapper calls). If you want to force the code out of others, a much stricter license than the LGPL or even the GPL will be required. Can anyone recommend one and have it still be open source? Sean -------------- scf(a)farley.org

2 2

Wine, enthusiasts, businesses and the agony of the license
by Fredrik Ohrn 10 Feb '02

10 Feb '02

(I'm a part time lurker on wine-devel and use Wine to run those pesky apps I can't live without. I regret that I've never mustered the courage to work on and contribute to the code.) What's lacking in this discussion is some sensible analysis of what a license need to contain to encourage future contributions to Wine and to protect the interests of the contributors. Fearmongering about Wine's future and paranoid delusions about the GPL license doesn't bring anything to the table... First, what is needed to please the enthusiasts that write code on their free time? As the variety of open source projects show, the exact license doesn't matter, as long as the source is available and there is a reasonable chanse to get your work included in what is perceived as the "main" distribution, there's plenty of people around that want to lend a hand. Ofcourse, looking at individuals they have preferences, some prefer the (L)GPL and other the BSD style and still others don't even get what all the fuss is about. The point I'm trying to make here is that there's no predominant license preference among the enthusiasts, so one can go either way. Ofcourse a change will make some people jump ship, but it also opens the door to new people who wouldn't have contributed under the old license. Now over to the $64.000 question, how can one convince companies to do the heavy lifting and still get them to share the result? There are 2 obvious ways to make money of Wine. Either you take it as is, package it and sell it as the ultimate Windows replacement (think Lindows and TransGaming). Or you use it as the base to port your existing Windows application (think Corel). And I'm sure there are several not so common ways, like cherrypicking functionality to create the greatest MS-DOS based registry editor ever made (don't laugh, I had to make something up). A viral license would more or less kill the first way. Just as Brett Glass pointed out, one has to add some secret sause that makes your product more valuable than the free version of Wine. For example, Lindows has to fix all bugs and implement everything that prevents Microsoft Office from running properly, and keep this magic patch to them selves. The BSD style is an obvious requirement for this business model to work. Unfortunatley, this is very much at odds with the community, who are working on Wine with the very same goal. To pharaphrase a previous poster, Lindows is standing on the shoulders of a giants and the current license is handing them the coat. The fact is, that neither (L)GPL or BSD style solves this dilemma, if they are allowed to keep thier changes secret it won't do anything for Wine as a whole. If you force Lindows to release their work it will remove the reason for them to do anything in the first place. TransGaming belongs to this group too. Flame me all you want, but the only difference between Lindows and TransGaming are thier long term intentions, outspoken or implied. Over to category two. Corel's source of income isn't from improving Wine, it's from selling their own work, Wine just makes their work more valuable. Here it doesn't really matter if Wine is BSD or LGPL (remember that the INTENT of the LGPL isn't to infect all and everything). A company that chooses this route may have to improve Wine here and there to fill in the missing pieces to make their port work, and by releasing this patch they will contribute to Wine as a whole. Unfortunatley they might not, don't underestimate the power of laziness. One other plausible reason is that some bean counter is afraid that someone else will pick up their work for free and make money out of it (i.e. Lindows) how'd you explain that to your shareholders? If Wine is LGPL they must release the patch if they want to reap the benefits of using Wine, and they can release it without fear of giving away money to someone else. It can even be argued that the LGPL makes Wine an even safer bet, since it guarantees that other companies in this group will chip in, this way Wine will be in even better shape when the first application was a smash hit and they decide to port their next app! :) Companies that decide to develop a new app and use Wine as the cross- platform framework also belongs to this group. Back to Wine again, the selfish motive here is to make Wine better faster. So if we get the choose between companies in group 1 or 2, who will contribute the most? Obviously the ones in group 1 will do the most work, since their living relies on a perfectly working Wine, unfortunatley they have the least to gain from contributing anything back. The companies in group 2 have the least incentive to work on Wine, just fix the bare minimum to get their application to work, but instead they can allow themselves the luxury to contribute and score some goodwill. Another observation is that companies in group 1 are in direct competition with each other, so they want closed source. If TransGaming released their DirectX work BSD style, Lindows would quickly be there to appropriate it. Companies in group 2 arn't competing directly (not to the same extent anyway, they have the entire application market to play on, not just the niche of making the perfect Windows replacement) so they would benefit from a license that enforces sharing. So what's the conclusion? Either you pick your favourite way of making business and lobby for a compatible license, or you start thinking out of the box and find the perfect balance that let's everyone keep the cake and eat it... I'll be back tomorrow with more opinions, and my stab at thinking out of the box. Regards, Fredrik -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams Fredrik Öhrn Chalmers University of Technology ohrn(a)chl.chalmers.se Sweden

2 3

Time for a Fork
by Dan Kegel 10 Feb '02

10 Feb '02

It seems clear to me that Wine is just like Unix: some people prefer a BSD license, and others prefer a GPL license. BSD can never convince Linux people to switch licenses, and vice versa. So be it. Rather than endlessly debate the issues, I suggest we simply agree on an amicable parting of ways. The current cvs tree and patch mailing lists would remain as is. A new LGPL-licensed tree and associated wine-lgpl-patches mailing list would be created to accept LGPL-licensed patches. This would put an end to a lot of bickering, and would let us see how the two license agreements work out in practice. Comments? - Dan

6 8

Re: Wine license change
by Roger Fujii 10 Feb '02

10 Feb '02

Daniel Sabo <sorry(a)nospam.com> wrote: > [snip] > > geez. no need to get bent out of shape. I'll rephrase and say BSD is > > MORE free than GPL. Happy? > [snip] > > Neither the BSD or GPL is free, only public domain is free. The problem with PD software is this screwed up litigious era we live in the US, it is conceivable that you could get sued for a bug in a PD software you wrote. So, the author isn't free from litigation in this case. The minimum you would probably want is X11/BSD which 1) says it's AS-IS 2) requires the copyright to be preserved (pretty much requried by law) 3) says you can't use the copyright holder in advertising. > BSD and GLP are both contracts with the users. a license is required so long as there is a copyright. > BSD means "you must include my licences information with anything you make". > *GPL means "if you make something from my code you have to share it with everyone". well, add the BSD portion to GPL and change the word "share" to "show" (since GPLed software cannot be shared with propriatary linkages) and add "and license it to how I originally licensed it". > Which on you use doesn't depend on freedom, it depends on your goal. true. though the point I was making was BSD *IS* freer than GPL. > I prefer GPL becuase I see getting back what others make as payment for my > work, and yes, I know I'm being selfish. no one is arguing this point (at least I don't think). The question is whether or not is this would result in a more complete wine since a *GPL license WILL drive away commerical people. > [snip] > > In case you hadn't noticed Sony let's you run _Linux_ on a PS2, did that > change to BSD without anyone telling me? Big companies like *GPL because > they know where they stand and they don't loose an advantage by giving > back. Sun and IBM both support *GPL projects, so does SGI and a lot of > other very large players. interesting, though not sure how sony gets away with (from CNET): The programming blueprints, or source code, for the kernel --the heart of Linux--is included on the DVD, Sony said. But the source code for a proprietary "runtime environment" that lets games play on the system is not. As for the BIG players, they get involved with all sorts of projects (X11, propriatary CDE...). The license they choose depends on what they are trying to promote (just like people). Also notice a lot of these large companies will also issue a multiple license scheme, since they see the *GPL as a right fit in some cases. "J.Brown (Ender/Amigo)" <ender(a)enderboi.com> wrote: > Okay. Let's look at this. > > The main objections seem to be based off two debatible premises: > a) LGPL will stop commercial development Hinder, and this is NOT debatable. Look at the last time this was discussed and Gav's response. > b) FSF > > Please, just because you hate the FSF, there is no reason not to accept > the license they use. Using the LGPL does not give the FSF -any- control > over Wine. Even less if you do not give a "or any later version" clause. No, but you may not be able to accept the terms of the license (for legal reasons). Read the paragraph of section 6. > Also the fact that LGPL will stop commercial development is a false > assumption. WINE is the main application. Wine uses several LGPL > libraries. If the main Wine executable is still BSD licensed, you can > replace the LGPLed libraries with your commercial version. Etc, etc. if one wants to go through the headache of maintaining different licenses in the same tree, I suppose this would work. However, if ALL of wine is LGPLed, it is not debatable that no propriatary additions can be made, as the spec compiler will prevent that from happening. > John Carmack made an intresting point, he releases ID softwares older > releases under the GPL. Why? Because after originally releasing an engine > after a BSD-esque license, a project done some very major work to the > engine... and then lost it in a harddrive crash. So his -main- reason for > using the GPL is to prevent work done in the community from being lost. not quite true, as he threatened to sue into oblivion a couple that violated the GPL. > There are of course other points. The LGPL is the GPL without the > restrictions which prevent useful commercial use. LGPL is GPL that grudgingly allows any non-propriatary linkages. > Thus RMS complains it isn't real "open-source"... Neither the LGPL or GPL > prevents charging for software, ??? Read 2C of LGPL. You can charge for the disk, but you CANNOT charge for the software. -r

2 1

Font issue
by Eric Pouech 10 Feb '02

10 Feb '02

latest freetype patch severly breaks Wine: - behavior between Windows TT fonts and X11 font isn't orthogonal. For example, EnumFont can return X11 fonts, while realizing a font never let you use a X11 font - this leads to very interesting effects like asking for a fixed pitch font and getting a variable pitch one so what would be the best fix ? either remove all X11 fonts in enum, or allow X11 fonts to be realized even if freetype is enabled ? any volunteer to fix it ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 4

Re: Dr. Seuss, licensing, and WINE
by Roger Fujii 10 Feb '02

10 Feb '02

David Elliott <dfe(a)tgwbd.org> wrote: > And for most free software projects I think it is morally defendable to > prevent people from even linking to them or using them in any proprietary > software. So, you're saying that GPLed software could not be distributed running under windows, macos, UNIX(TM).... Nice to know that you think linux is right for everyone. > The very nature of moving to a license like the LGPL means it will be > complex. This doesn't mean it has to be incomprehensible (and it isn't) > it just means it'll be complex. complex isn't the right word here. The problem is that it is UNCLEAR in certain places. I challenge anyone to show me what "work that uses the library", "work based on the library", and "whole" means in the context of wine. > If you take the average software company, more likely it'll be spent on a > private jet for the CEO. your "average" company must be considerably larger than any of the companies I worked with.... -r

1 0

Re: Time for a Fork (fwd)
by Roger Fujii 10 Feb '02

10 Feb '02

Has anyone actually figured out what is required for a license change? Regardless what you think of the merits, it would seem that it would make the base confusing, at best, as the current LICENSE file must STILL be distributed along with the LGPL. At minimum, you still have to come up with another license for the spec compiler, and maybe some other stuff for the stuff in the tools directory. It for sure isn't as easy as "cp LGPL LICENSE" -r

1 0

RE: Dr. Seuss, licensing, and WINE
by Patrik Stridvall 10 Feb '02

10 Feb '02

> On 2002.02.09 19:18 Patrik Stridvall wrote: > > David Elliott wrote: > > > On 2002.02.09 06:39 Patrik Stridvall wrote: > [SNIP] > > > In some ways it is. Many times when entities are violating > > > some license > > > or law a decision is partly based on what exactly their > > > intentions were. > > > Although I would not like to rely on this and I think > > > clarifying what and > > > what is not allowed is better than leaving it up to good > intentions. > > > > Yes, but in the case of copyright it doesn't really make much sense. > > For determining the punishment for any infringment, yes. > > For determining whether something infringes, no. > > > > And sure I guess hiding behind fair use is harder if you > intent is bad. > > > Sorry, should have clarified that more. It is true that > intent is used in > the punishment phase, usually not the actual trial. OK. Then you agree with me. However the fact remains that Alexandre doesn't agree. While he of course might be wrong, and probably is, it bothers me still. Because if he can be wrong, so can lawyers, especially careful lawyers, giving advise to their clients. > > However does the Joe Hacker in my earlier example that used > a propriety > > library to avoid dual booting and shared it with fellow hobbyists > > have "intent to infringe"? > > > This is pointless to discuss. I don't want a license where > no one can > possibly link wine with binary components. The LGPL does not > prohibit > that. Yes, but Alexandre (and possibly Jeremy) seems to want a license that does that. I have giving these examples to illustrate the implications if the LGPL indeed work this way. > > > > > Thus TransGaming does not hurt. Lindows really doesn't hurt > > > > > either, and > > > > > the users of Lindows win because should they need to > > > update the LGPL > > > > > components of Wine they can do so and still continue to link > > > > > to Lindows > > > > > binary only components. > > > > > > > > Exactly, but they will be able to do that without the LGPL. > > > > It is in the respective companies intrest to make it so. > > > > > > > If that is so, then why aren't they doing it already? > > > > 1. Lack of time. > > 2. Lack of insight what their users might want. > > 3. Lack of concerned users. > > > > I'm sure you can find more reasons. > > > Because the current license allows them to get away with it. Yes, but they might fix it then they find time. There is little reason to force it now. > > > Yeah, doesn't that suck. Kind of like people use proprietary > > > software so > > > they get what they deserve. We can't stop them from > using it as that > > > limits the freedom's of the proprietary software companies > > > and the users > > > who want to use that software. However what we can do is > > > remove the need > > > to use proprietary software. Wine is a first step towards this. > > > > Yes, but I never think the need for proprietary software > will disappear. > > > > Obviously not in the grand scheme of things. But basic day > to day tasks > like just being able to use your computer should not require > proprietary > software. I would extend basic tasks to basic word processing and > web-browsing functionality. Your typical Linux distribution > is already at > that point. The only thing missing is the ability to > continue to run the > Windows based programs that offer extended functionality. > Wine fills that > need and will help to transition users to a more reasonable and open > platform. Quite true, I agree. > Wine is such an important product and yet most of the > developers don't > really care about its future. Moving users from Windows to some > proprietary Windows clone isn't really helping. It doesn't? So making users aquinted with Linux in a gentle way will not help? If Lindows will not let their users hack and improve on their version of Wine, I suspect that at least some users will abandon Lindows for some other Linux distribution there they can hack Wine. In fact unless Lindows grow closer to classical Linux distribution, ie not running everything as root for example. I expect many users to abandon Lindows eventually anyway. > > Do you consider it morally or ethically defendable to > > prevent this behavior? > > > Yes, I think it is morally defendable to prevent people from > incorporating > Wine into proprietary products. And for most free software > projects I > think it is morally defendable to prevent people from even > linking to them > or using them in any proprietary software. Even if the tools you had to use say LGPL was so crude that it would additionally prevent people to help themselves and their friend avoid dual boot for example? > For Wine I think by nature we must let people link to > proprietary software. Agreed. > > > This is simply not true. This is very much Wine's problem. > > > If I need > > > some of Lindows's functionality to run my program but would > > > still like to > > > be able to hack on other parts of Wine then I, as a developer > > > and user, am > > > screwed. > > > > So complain with Lindows support or abandon Lindows and use > something > > else or whatever. Eventually they will learn to listen to their > > customers. > > > This laissez-faire attitude really bothers me. You say you > care, but in > reality you don't. No, it is rather a stupidity has its own reward attitude. I just see little reason help stupid people at the expense of other things. I do care, if I could help stupid people with little effort, I would, but I won't make any sacrifices for them. > > > We cannot > > > put our work on the line and say "Well, hopefully no one will > > > make bad > > > choices with it". > > > > You can never prevent people from doing bad choice with a product: > > "Design a product even an idiot can use and only an idiot > will use it" > > > This is not the same thing. Not exactly, no. But the proverb illustrates the same principle. > What I would like to accomplish > is to prevent > people from incorporating Wine into proprietary products. I > don't want to > depend on the users of these proprietary products. So don't use them and save yourself the money. The proverb is meant to illustrate that you are the idiot if you buy or use idioticaly designed products. > Besides > dude.. what > company listens to their customers anymore anyway. Any company that wishes to survive does. > > > > See my suggestion about the "MGPL" instead. > > > > > > > This is really the same thing as a clarified LGPL. It's not > > > necessary to > > > write from the ground up a new license, but if we need to > > > take the LGPL > > > and strike out certain sections and/or add to it then that is > > > far better > > > than writing a new license completely from scratch. > > > > No, it is not, because we want the license to be very clear > > on what is allowed and what is not. No patchwork. A clear > > license with only the absolute minimum number of paragraphs. > > > > Remember we want companies working on Wine without having > > to spend to much money on their lawyers. > > > > ARGH!!!!! Licensing software is complex. If the only > argument you have > against the LGPL is that it is complex, then tough cookies. The only > licenses that are extremely simple are the ones that either say "Do > whatever with it" or the ones that say "We'll take your > firstborn if you > reverse engineer it". > > This argument that the LGPL is too complex is a waste of > time. It reminds > me of microsofts shared source license. One of its strong > points was that > it was simple. Know why it was simple? Because you couldn't > do shit with > the source so it was simple. At the other extreme we have > the X11 which > is simple, because you can do almost everything with it. True, but I primarily wish to strive for simplicity not nessarily reach it. > The very nature of moving to a license like the LGPL means it will be > complex. This doesn't mean it has to be incomprehensible > (and it isn't) > it just means it'll be complex. Well. I just want again to point out that everybody doesn't even agree what the LGPL means. This is what primarily bothers me. > > Basicly but I very much fear that even a MGPL would be to complex. > > > > So then I nailed it. You're only real concern seems to be > that companies > may shy away from Wine if the license is so complex. I > wouldn't be that > concerned about it. Had Wine been LGPL, Lindows probably still would > exist and would be playing more nicely with us. Perhaps, but Transgaming probably wouldn't. Don't celebrate too soon. > > > They can pay lawyers to figure it out for them. Why do you > > > think lawyers > > > make all the money anyway. > > > > Because the money that they can avoid spending on lawyers could > > be spent on improving Wine instead. > > > If you take the average software company, more likely it'll > be spent on a > private jet for the CEO. I'm sure Gavriel would be delighted to have a private jet. :-) > Anyway... this mail is getting really long, and if the > biggest argument > you can come up with against the LGPL is that it's too > complex then it is > pointless to continue. I think the discussion between us is pretty ended as far as goals are concerned. Our prefered means and willingless to give up some of the goals for reduced complexity still differs. Anyway, what rely matter is what other people like Alexandre think about a license that allows wrapper library. Of course we both claim that even the LGPL does, but then other people don't. So I'm intrested in their opinion.

1 0

Macromedia Flash 5.0 ALMOST working (mouse button release bug)
by ivan 10 Feb '02

10 Feb '02

Hi I have run Flash 5 with no problems except for just _one_ annoying issue which is turning it unusable. Once the mouse button is clicked for drawing or placing an item it never gets released (it resizes the item as if you had the mouse button pressed all the time) I would like a lot if this was fixed because Flash is the only app which keeps me using Winblows sometimes. But i can't fix this myself because i don't know enough to do it. The error log which i get when running wine flash.exe is: [ivan@schnell Flash 5]$ wine flash.exe fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (Spanish keyboard layout) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. err:midi:OSS_MidiInit ioctl on midi info for device 0 failed. fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoMarshalInterface Failed to Marshal the interface, 80070057? fixme:ole:_LocalServerThread CoMarshalInterface failed, 80070057! fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:storage:StgCreateDocfile Transacted mode not implemented. fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:mdi:MDIRefreshMenu partially function stub fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:imm:ImmGetContext (0x00020022): stub // the line above happens when i click a tool button fixme:imm:ImmGetContext (0x00020022): stub // the line above happens when i try to draw with that tool // after that i can't do anything else, because the cursor don't gets released // and keeps drawing or resizing Terminated // ctrl+c, the only way to stop it Anyone knows what's happening here? Do you need more info? I will do or test whatever you want to help solve it. TIA

1 0

Richard Stallman
by Brett Glass 10 Feb '02

10 Feb '02

Plato (tom(a)redant.freeserve.co.uk) writes: >Could you give me URLs to one or more of these essays? Last time I looked, they were all on Stallman's gnu.org site, in the "Philosophy" section. Unless, of course, he has expunged them to hide his true intentions. >> Software is "proprietary" if it does not interoperate with other software, >> does not conform to industry standards, and/or uses unique file formats >> or protocols so as to lock users in or deter competition. > >That is not true. In English, `propritetary' is an adjective used to describe >something which is the property of someone. If you were to use this definition, then all of the FSF's software would be "proprietary." (It is interesting that the FSF condemns software "hoarding" and yet has one of the largest hoards of source code in the world.) >In the computing world it is >generally used to describe software which does not allow redistribution and >modification. Not true. This is the way the FSF has attempted to REdefine it, but it is not the correct definition. >Again not true. Commercial software need not be *licensed* for money, it >only need be developed or marketed as a way of business. For something to be commercial, it must be the object of commerce. >Did you read the links I posted? I post them again and suggest you do so >before posting erroneous comments. How can you hope to win an argument when >you do not understand the issues involved? > >http://www.gnu.org/philosophy/words-to-avoid.html#Commercial >http://www.gnu.org/philosophy/software-libre-commercial-viability.html I have studied Stallman's propaganda at great length, and have written essays on the misleading rhetorical techniques it uses. I not only understand the issues involved; I also understand how Stallman has attempted to distort them and mislead programmers into hurting themselves, their profession, and their projects. --Brett

1 0

Re: Time for a Fork (fwd)
by winedev＠admdev.com 10 Feb '02

10 Feb '02

Wouldn't really work... Not only the extra work for Alexandre, but the fact the trees will become totally unsyched. Then there's pollution of code and licensing from one tree to the next.. The problems are too many to count. This is really an all-or-nothing decision. If we loose developers from making a license shift, then so be it... I think its inevitable, but I also think they will slowly start drifting back when they realise that it DOES work and isn't quite the evil they thought :) Regards, | It's always bad news in computing.. and beware | of anything claming to be good news - because | its probably a virus. - Salmon Days Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org] On Sat, 9 Feb 2002, Dan Kegel wrote: > Date: Sat, 09 Feb 2002 17:42:55 -0800 > From: Dan Kegel <dank(a)kegel.com> > To: wine-devel(a)winehq.com > Subject: Time for a Fork > > It seems clear to me that Wine is just like Unix: > some people prefer a BSD license, and others prefer a GPL license. > > BSD can never convince Linux people to switch licenses, and vice versa. > > So be it. > > Rather than endlessly debate the issues, I suggest we simply agree > on an amicable parting of ways. > > The current cvs tree and patch mailing lists would remain as is. > > A new LGPL-licensed tree and associated wine-lgpl-patches mailing list > would be created to accept LGPL-licensed patches. > > This would put an end to a lot of bickering, and would let us > see how the two license agreements work out in practice. > > Comments? > - Dan > > >

3 2

RE: Dr. Seuss, licensing, and WINE
by Patrik Stridvall 10 Feb '02

10 Feb '02

> On 2002.02.09 06:39 Patrik Stridvall wrote: > > > > You might believe me or you might not, as all people > arguing against > > > > me last time. Be that as it may, that discussing is dead and I > > > > will in the future concentrate on "If the LGPL means what you > > > > say it does, we don't want the LGPL". > > > > > > > Actually, IYRC, and IIRC, I pretty much agreed with you > that the LGPL > > > actually WOULD allow one to implement proprietary code simply > > > by releasing > > > small wrapper functions as LGPL code. > > > > Yes, but you was one of the few. Alexandre in particular seemed > > to believe it depended on some strange notation of whether it > > was intentional or. > > > In some ways it is. Many times when entities are violating > some license > or law a decision is partly based on what exactly their > intentions were. > Although I would not like to rely on this and I think > clarifying what and > what is not allowed is better than leaving it up to good intentions. Yes, but in the case of copyright it doesn't really make much sense. For determining the punishment for any infringment, yes. For determining whether something infringes, no. And sure I guess hiding behind fair use is harder if you intent is bad. However does the Joe Hacker in my earlier example that used a propriety library to avoid dual booting and shared it with fellow hobbyists have "intent to infringe"? I claim that every work either violates copyright in and of itself or not at all. Nothing else makes much sense. How can you determine the intent of the author of work, if for example the author is anonymous. Sure if the author or the process of authorship is unknown you really can't claim indepent derivation if you (not the author) distribute the work and if some judge thinks it similar enough with another work to infringe. However that judgement was for obvious reason made by examination of the work in and of itself. > > > Thus TransGaming does not hurt. Lindows really doesn't hurt > > > either, and > > > the users of Lindows win because should they need to > update the LGPL > > > components of Wine they can do so and still continue to link > > > to Lindows > > > binary only components. > > > > Exactly, but they will be able to do that without the LGPL. > > It is in the respective companies intrest to make it so. > > > If that is so, then why aren't they doing it already? 1. Lack of time. 2. Lack of insight what their users might want. 3. Lack of concerned users. I'm sure you can find more reasons. > > > Now you may consider this not enough to stop the less honourable > > > companies. Yeah, you're right. Lindows can continue to > > > build upon wine, > > > add their own stuff, and release a product. The only > > > difference is that > > > now they can't just fold all the wine code into the binary.. > > > they have to > > > allow the user to update the wine code. That is the purpose > > > of the LGPL. > > > Unlike the GPL which tries to make all software free > > > software, the LGPL > > > tries to keep free software as free software, and proprietary > > > software as > > > proprietary software. > > > > Yes. But that is NOT an argument for using LGPL as I have > said above. > > > Sure it is. The LGPL's purpose in life is to make sure the > users of the > program can continue to recompile the code that was LGPL to > begin with. OK. Reformulate. There is no reason to force this to happend, since it is likely to happend eventually anyway. See below. > > > Now let's say we take the stricter interpretation that you > > > cannot do the > > > above. That is bad I think. > > > > > > How about going to LGPL and add a clause that clarifies that > > > the above is > > > in fact allowed? > > > > Why confuse the company lawyer even more? > > > > Even if I would be inclined to agree, I would rather let > the FSF lawyers > > draw up a completely new license lets call it, hmm, MGPL (Middleware > > GPL), > > for use in, hmm, what should I call it, say two-ended > libraries that Wine > > IMHO really is. > > > > This MGPL should clarify that it is legal to "plug-in" proprietary > > application/libraries in both ends while code the middle that is > > the Wine source code should have some copyleft like protection and > > additional that sublicening the code as LGPL is allowed. > > > > Note however I'm not really proposing this but it might be > a reasonable > > compromise. Perhaps something for the LGPL camp to chew on. > > > What you describe sounds to me like what I am describing. A > modified and > clarified LGPL. Essentially when you start adding or > deleting from the > LGPL you are in fact making a new license. You are saying > the same thing > I am. As you wish, this is of no moment. > [SNIP] > [Quote Dennis Miller: Y'know.. I don't want to get off on a > rant here...] > > > > When the voters give any of them support, the problem is that > > > > they didn't really support the extreme views they presented, > > > > but they are forced to do it anyway in order of not being > > > > accussed of betraying the will of the voter. > > > > > > > You can thank the "liberal" media for that one. :-( > > > > Well, that is just the symptom. > > The ignorant masses are the real problem IMHO. > > > > Unfortunately, there is no serious alternative to democracy, > > so I'm a loss what to do. :-( > > > True. Actually, I think the media is more of a symptom of > politicians > catering to them for years now. Well of course they do since that is one of the few way they can reach their voters. It is still the ignorant masses that are the real problem unfortunately. Increased education will only get you so far and it is never any substitute for logical thinking. Of course, the ignorant masses really gets what they deserve. I primarily think it is unfortunate that I live in the same world as them. > Look at the administration > now. They > don't take any shit and just tell it like it is. Bush may not be an > excellent speaker but he seems to say what's on his mind and > doesn't try > to always be the media's bitch like Billy-boy and his wife did. Sometimes the ignorant masses are lucky sometimes they are not. > > Lets return the easy problem of finding of good license for > Wine. :-) > > > Yeah, sorry, just had to get off on a little rant about the media. :-) > > > Especially see MSNBC. What a crock of shit that is.. > > > figures, it being a > > > MS product and all :-). The reporters on that station are > > > just horrible. > > > They ask a question and when they get a totally straight > > > answer that they > > > don't agree with they just ask it again and again changing a > > > few words to > > > make it seem like it's a different question. > > > > Well, people watch the shit, so they get what the deserve. > > > > Unfortunately it hurt us other as well, but then we really can't > > limit their freedom of speech, can we? > > > Yeah, doesn't that suck. Kind of like people use proprietary > software so > they get what they deserve. We can't stop them from using it as that > limits the freedom's of the proprietary software companies > and the users > who want to use that software. However what we can do is > remove the need > to use proprietary software. Wine is a first step towards this. Yes, but I never think the need for proprietary software will disappear. > > > > In the cases of Wine. I hope that the people working with the > > > > Wine project are not among the ignorant masses and thus really > > > > are able to understand the subtle differences between different > > > > positions. > > > > > > > Yeah, so far it only seems like the people who caught > this story on > > > slashdot are among the ignorant masses. :-/ > > > > I wouldn't really call them the ignorant masses but rather the > > I-can-almost-but-not-quite-understand-this masses. Since they > > don't fully understand it they assume that it is something > > bad and post their unordered thoughts in hope that other might > > make something out of it. > > > Yeah, sometimes a little knowledge is far worse than none at > all. Usually > this is only the case when people think that a little > knowledge makes them > an expert and get big-egos. Very true. > > > We should collectively think of the different scenarios and > > > ask one very > > > important question: Do we /really/ want to prevent this > scenario from > > > happening? > > > > Ah, I forgot that very important question. I intend to supply it but > > somehow > > it got lost. But perhaps the question: > > > > 1. Do you consider his or her behavior morally or ethically > defendable? > > > > sums it up pretty well as well. > > > Sounds kind of like my.. do you think it should be allowed question, > although put in a better way. Ah yes, you are right, we probably should ask the opposite question as well: Do you consider it morally or ethically defendable to prevent this behavior? > > > Personally I have warmed up a slight bit to the idea of > > > Lindows. At first > > > I was a bit like.. those dickheads took wine, added a few > > > things, and are > > > gonna sell it for $100/seat and we're not getting any of that > > > or even any > > > improvements back!? That bites. > > > > > > But now I realize that we need to put that emotion aside and > > > look at how > > > exactly lindows harms wine (which it does). > > > > > > The first thing is the issue of binary-only wine that can't > > > be changed and > > > has absolutely no source. That really bites for the user > who is thus > > > locked into Lindows complete package and cannot even change > > > the parts of > > > wine that Lindows has nothing to do with. > > > > If Lindows prevents users from updating their version of Wine > > it is really their and their users problems not our problem. > > > This is simply not true. This is very much Wine's problem. > If I need > some of Lindows's functionality to run my program but would > still like to > be able to hack on other parts of Wine then I, as a developer > and user, am > screwed. So complain with Lindows support or abandon Lindows and use something else or whatever. Eventually they will learn to listen to their customers. > > > If we were LGPL > > > and allowed > > > importing functions from non-LGPL components then Lindows > > > could still add > > > value by implementing APIs in their own DLL or DLLs and > > > loading them from > > > wine. In fact, they don't need to be DLLs. They could just > > > put all their > > > stuff in their own closed source file, compile it, and > > > distribute the .o > > > so that end users (their customers) can later take that .o > > > file plus the > > > LGPLd modifications to wine that make it use the functions in > > > that .o, and > > > link it into a newer version of wine. > > > > I don't see why we should adapt our license to cater for people > > that make bad choices and suffer because of it. Especially > > when such a license might scare other people that might help > > us away. > > > Because people make mad choices every day and don't realize > it. Indeed, but stupidity is its own reward. > We cannot > put our work on the line and say "Well, hopefully no one will > make bad > choices with it". You can never prevent people from doing bad choice with a product: "Design a product even an idiot can use and only an idiot will use it" > > Regardless of any fun you might have had. Ask this question: > > > > Would you have consider it ethically or morally defendable if the > > Wine license had prevented you from using a proprietary ASPI > > library with Wine and distributing the result to your friends. > > > YES! That is my point. I would have done it anyway even if > their was a > proprietary version. And I think it is important that we > allow people to > use and distribute proprietary components with a free software Wine. Agreed. > > > Anyway.. these are just two.. there are more I'm sure.. I > > > really need to > > > go to bed though. > > > > Different time zones. I returned from a late breakfast to > > find your mail. :-) > > > Hmm, well, I suppose about the time I sent it I could've gone > to an early > breakfast since it was like 5am. Well, my father usual gets up at that time. :-) > What was it, like noon or 1 > where you > are? I recieve that mail at 11.20 am. Speaking of time it is now 1.00 am for me. Time for bed as soon as I finish answering this. > > > Before I do so, I would like to point you to the > wxWindows website. > > > > > > According to their short license summary they use LGPL but > > > also allow you > > > to distribute a binary linking with wxWindows included. That > > > exception > > > would not be appropriate for wine (in fact, it's like the > > > main advantage > > > for us to use the LGPL I think). However we could do a > similar style > > > thing and say: "We're LGPL but we specifically allow you to > > > create stub > > > functions in our library that call out to your > proprietary component. > > > > See my suggestion about the "MGPL" instead. > > > This is really the same thing as a clarified LGPL. It's not > necessary to > write from the ground up a new license, but if we need to > take the LGPL > and strike out certain sections and/or add to it then that is > far better > than writing a new license completely from scratch. No, it is not, because we want the license to be very clear on what is allowed and what is not. No patchwork. A clear license with only the absolute minimum number of paragraphs. Remember we want companies working on Wine without having to spend to much money on their lawyers. > > > Hopefully we can get this resolved this time... It's looking > > > promising > > > given the few and far between somewhat clear posts and > > > disregarding the > > > ill-informed wanna-be-on-slashdot shit. > > > > We will see. I'm neither optimistic nor pessimistic for the moment. > > > > > Well, I /hope/ we can get this resolved since we're talking > about the same > things. Your only real concern at this point seems to be > that if we were > to move to LGPL that some companies may not like it because > it's complex. Basicly but I very much fear that even a MGPL would be to complex. > They can pay lawyers to figure it out for them. Why do you > think lawyers > make all the money anyway. Because the money that they can avoid spending on lawyers could be spent on improving Wine instead.

2 1

RE: Dr. Seuss, licensing, and WINE
by Patrik Stridvall 10 Feb '02

10 Feb '02

> > You might believe me or you might not, as all people arguing against > > me last time. Be that as it may, that discussing is dead and I > > will in the future concentrate on "If the LGPL means what you > > say it does, we don't want the LGPL". > > > Actually, IYRC, and IIRC, I pretty much agreed with you that the LGPL > actually WOULD allow one to implement proprietary code simply > by releasing > small wrapper functions as LGPL code. Yes, but you was one of the few. Alexandre in particular seemed to believe it depended on some strange notation of whether it was intentional or. > As in: > > DWORD WINAPI FooMicrosoftApi(CHAR *bar, DWORD baz) > { > return someotherdll_FooMicrosoftApi(bar,baz); > } > > Which would be LGPL, and the someotherdll_FooMicrosoftApi > would be under a > different license. > > With this situation the stated purpose of the LGPL is still > upheld. The > stated purpose is to allow one to continue to update the > parts of the code > that are LGPL while still being able to link with proprietary > components. Exactly. However I see no reason particular reason why even less honourable companies wouldn't release the wrapper code to the us whether they were forced to or not. It is in their intrest to make it easy for Wine to use their library so they can limit the support for clueless users for example. This even if LGPL allowed it, is not a strong argument for LGPL. In this case it would only primarily the confusion on whether this is allowed, for little gain. > Thus TransGaming does not hurt. Lindows really doesn't hurt > either, and > the users of Lindows win because should they need to update the LGPL > components of Wine they can do so and still continue to link > to Lindows > binary only components. Exactly, but they will be able to do that without the LGPL. It is in the respective companies intrest to make it so. > Now you may consider this not enough to stop the less honourable > companies. Yeah, you're right. Lindows can continue to > build upon wine, > add their own stuff, and release a product. The only > difference is that > now they can't just fold all the wine code into the binary.. > they have to > allow the user to update the wine code. That is the purpose > of the LGPL. > Unlike the GPL which tries to make all software free > software, the LGPL > tries to keep free software as free software, and proprietary > software as > proprietary software. Yes. But that is NOT an argument for using LGPL as I have said above. > Now let's say we take the stricter interpretation that you > cannot do the > above. That is bad I think. > > How about going to LGPL and add a clause that clarifies that > the above is > in fact allowed? Why confuse the company lawyer even more? Even if I would be inclined to agree, I would rather let the FSF lawyers draw up a completely new license lets call it, hmm, MGPL (Middleware GPL), for use in, hmm, what should I call it, say two-ended libraries that Wine IMHO really is. This MGPL should clarify that it is legal to "plug-in" proprietary application/libraries in both ends while code the middle that is the Wine source code should have some copyleft like protection and additional that sublicening the code as LGPL is allowed. Note however I'm not really proposing this but it might be a reasonable compromise. Perhaps something for the LGPL camp to chew on. > > > I think it's more of an issue of people thinking too much in > > > black/white > > > terms and people that lean strong towards one side or the other. > > > > Yes. Perhaps they are not nessarily thinking in black and white > > but their arguments are often presented that way. > > > > I'm not entirely blameless on that point either, I will try > > to do better in the future. > > > > > Look no further than the US political system for a good > > > example. You have > > > the Republicans and the Democrats. Generally they take every > > > issue to > > > opposite ends of the extreme such that 99% of congress is at > > > one extreme > > > or the other, but 99% of the population wants neither extreme. > > > > Exactly, but that is because: > > 1. They want votes so they can do that they feel is right. > > 2. The ignorant masses are not likely to understand subtle > > differences in opionion. > > > > When the voters give any of them support, the problem is that > > they didn't really support the extreme views they presented, > > but they are forced to do it anyway in order of not being > > accussed of betraying the will of the voter. > > > You can thank the "liberal" media for that one. :-( Well, that is just the symptom. The ignorant masses are the real problem IMHO. Unfortunately, there is no serious alternative to democracy, so I'm a loss what to do. :-( Lets return the easy problem of finding of good license for Wine. :-) > Especially see MSNBC. What a crock of shit that is.. > figures, it being a > MS product and all :-). The reporters on that station are > just horrible. > They ask a question and when they get a totally straight > answer that they > don't agree with they just ask it again and again changing a > few words to > make it seem like it's a different question. Well, people watch the shit, so they get what the deserve. Unfortunately it hurt us other as well, but then we really can't limit their freedom of speech, can we? > > In the cases of Wine. I hope that the people working with the > > Wine project are not among the ignorant masses and thus really > > are able to understand the subtle differences between different > > positions. > > > Yeah, so far it only seems like the people who caught this story on > slashdot are among the ignorant masses. :-/ I wouldn't really call them the ignorant masses but rather the I-can-almost-but-not-quite-understand-this masses. Since they don't fully understand it they assume that it is something bad and post their unordered thoughts in hope that other might make something out of it. > > > Essentially we could go on forver about X11/BSD vs. GPL. > It's been > > > discussed to death already folks. What we need are reasonable > > > compromises. Of course you need to have people willing to > > > compromise to > > > do that. I suspect most developers are with the exception of > > > the view > > > vocal BSD people and the few vocal LGPL all the way people. > > > I myself am > > > certainly not at either extreme. > > > > Even if perhaps some people won't believe me. I not really > > an extremist. I try to take a pragmatic view of the world. > > > > I believe that GPL has its place, LGPL has it place and the BSD > > license has its place. > > > > However my analysis of the issues at hand makes me believe that > > LGPL would be really bad in the particular case of Wine, for > > reasons that I have tried to explain. > > > Personally I think the LGPL is pretty damn good and fits wine > pretty well > but we simply need to clarify the gray areas about what is and is not > allowed (see above). That is the point we disagree on, at least partly. > > I suggest that people try to think about scenarios of circumstances > > where possible extensions to Wine might be made. This might be > > business models like Transgaming or Lindows.com or just something > > Joe Hacker or Joe Ex-Windows-Shareware-Writer or Joe I'm-Conspiring > > -With-A-Proprietary-Library-Company-But-You-Can't-Prove-It > are doing. > > Just like the examples in the my last mail. > > > > Then ask the questions: > > 1. Do you consider his or her behavior morally or ethically > defendable? > > 2. Does it violate the letter of the LGPL? > > 3. Does it violate the spirit of the LGPL? > > 4. Does it violate the letter of copyright law? > > 5. Does it violate the spirit of copyright law? > > 6. Do you think any reasonable Judge/Jury would find him or > her guilty? > > > > With the spirit of copyright law I roughly mean: > > Is it what congress intended and/or is it constitutional? > > Notice the and/or: > > It is possible for act of congress to be constitutional without > > being the intention of the congress. > > > Hmm.. y'know that's a good idea. At least it something concrete to do instead on arguing back on forth about abtract fears. > We should collectively think of the different scenarios and > ask one very > important question: Do we /really/ want to prevent this scenario from > happening? Ah, I forgot that very important question. I intend to supply it but somehow it got lost. But perhaps the question: 1. Do you consider his or her behavior morally or ethically defendable? sums it up pretty well as well. I can't think about anything except egoistical concerns that could make anybody want to prevent something they thought morally and ethically defendable. > Personally I have warmed up a slight bit to the idea of > Lindows. At first > I was a bit like.. those dickheads took wine, added a few > things, and are > gonna sell it for $100/seat and we're not getting any of that > or even any > improvements back!? That bites. > > But now I realize that we need to put that emotion aside and > look at how > exactly lindows harms wine (which it does). > > The first thing is the issue of binary-only wine that can't > be changed and > has absolutely no source. That really bites for the user who is thus > locked into Lindows complete package and cannot even change > the parts of > wine that Lindows has nothing to do with. If Lindows prevents users from updating their version of Wine it is really their and their users problems not our problem. > If we were LGPL > and allowed > importing functions from non-LGPL components then Lindows > could still add > value by implementing APIs in their own DLL or DLLs and > loading them from > wine. In fact, they don't need to be DLLs. They could just > put all their > stuff in their own closed source file, compile it, and > distribute the .o > so that end users (their customers) can later take that .o > file plus the > LGPLd modifications to wine that make it use the functions in > that .o, and > link it into a newer version of wine. I don't see why we should adapt our license to cater for people that make bad choices and suffer because of it. Especially when such a license might scare other people that might help us away. > Now, the second issue, and the one Alexandre is (or maybe > just was) most > concerned about, was companies implementing functionality > that the real > wine does not have will sometimes reduce the incentive for a > developer to > work on it. That is to say that a good portion of developers > that would > otherwise be contributing to Wine making stuff work will stop > if they can > simply by Lindows for $100 and make that work. Perhaps, but you will have to take the good with the bad and licenses preventing this also prevents other things. Whether LGPL really does this or not is another question though. > Ironically > moving to LGPL > would actually make it easier for a wine developer to use > some lindows > functionality since they could update the rest of Wine. > However, at least > for me part of the reason I like hacking on Wine is to hack > on wine to > have a version that is free software. That is, let's say > there had been a > working closed source ASPI layer then I could've used my CD-R > in Wine and > maybe I wouldn't have fixed a bunch of stuff with ASPI. But > doing that > was a lot of fun and I would have been the one missing out by > falling back > to a lindows implementation and never considering actually > fixing the real > wine implementation. Plus in the meantime at least my CD-R would've > worked so it would have been a less pressing issue and would > have avoided > numerous reboots for me in trying to create a free version. Regardless of any fun you might have had. Ask this question: Would you have consider it ethically or morally defendable if the Wine license had prevented you from using a proprietary ASPI library with Wine and distributing the result to your friends. > Anyway.. these are just two.. there are more I'm sure.. I > really need to > go to bed though. Different time zones. I returned from a late breakfast to find your mail. :-) > Before I do so, I would like to point you to the wxWindows website. > > According to their short license summary they use LGPL but > also allow you > to distribute a binary linking with wxWindows included. That > exception > would not be appropriate for wine (in fact, it's like the > main advantage > for us to use the LGPL I think). However we could do a similar style > thing and say: "We're LGPL but we specifically allow you to > create stub > functions in our library that call out to your proprietary component. See my suggestion about the "MGPL" instead. > Hopefully we can get this resolved this time... It's looking > promising > given the few and far between somewhat clear posts and > disregarding the > ill-informed wanna-be-on-slashdot shit. We will see. I'm neither optimistic nor pessimistic for the moment.

3 3

Re: Dr. Seuss, licensing, and WINE
by Brett Glass 10 Feb '02

10 Feb '02

Plato (tom(a)redant.freeserve.co.uk) writes: >> Give me a break dude. Yes, the FSF wants all software to be free and >> wants to rid the world of commercial software altogether. >[...] > >I think it is worth pointing out the the Free Software Foundation does *not* >want to rid the world of commercial software. > >Stallman has, however, stated that he would like to rid the world of >*proprietary* software. Richard Stallman most certainly does want to rid the world of all commercial software. He says so in many of his essays. One of Stallman's propaganda techniques, alas, has been to refer to commercial software as "proprietary" software. He does this because the word "proprietary" has negative connotations. He hopes to co-opt those connotations so as to convince others to join him in his drive to destroy all commercial software. To set the record straight: Software is "proprietary" if it does not interoperate with other software, does not conform to industry standards, and/or uses unique file formats or protocols so as to lock users in or deter competition. Software is "commercial" (that is, the object of commerce) if it is licensed for money. GPLed software cannot be commercial because it cannot be licensed for money (the GPL prohibits this). You can sell a disc with GPLed software on it, but only the plastic disc is a commercial product -- not the code it contains. --Brett Glass

2 1

Re: Wine license change (fwd)
by winedev＠admdev.com 10 Feb '02

10 Feb '02

(Reposted, as I just realised my Pine roles wern't sending this from the right address :) Regards, | It's always bad news in computing.. and beware | of anything claming to be good news - because | its probably a virus. - Salmon Days Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org] ---------- Forwarded message ---------- Date: Sun, 10 Feb 2002 08:44:52 +0800 (WST) From: "J.Brown (Ender/Amigo)" <ender(a)enderboi.com> To: Brett Glass <brett(a)lariat.org> Cc: wine-devel(a)winehq.com Subject: Re: Wine license change > >John Carmack made an intresting point, he releases ID softwares older > >releases under the GPL. Why? Because after originally releasing an engine > >after a BSD-esque license, a project done some very major work to the > >engine... and then lost it in a harddrive crash. So his -main- reason for > >using the GPL is to prevent work done in the community from being lost. > > He really should take the time to back up his drives. ;-) But, assuming > that he wishes to use this rather unusual backup mechanism, why would the > GPL be any better at this than a BSD-style license? Sorry, let me clarify that point... the major work that was lost was done by a COMMUNITY project, not one of ID's in-house ones. His point is that as the xGPL forces the release of source code with any binaries, so any valuable work like this won't be lost to the community. This has intresting implications for wine too. It's nice to say that Codeweavers/Transgaming/Lindows/etc might feed slice of code 'x' back to Wine at 'i' time in the future. Of course, if said company goes bust (sorry guys, but this IS the post .com era ;), there is a chance that code could be lost for good. - Ender

1 0

RE: Wine, enthusiasts, businesses and the agony of the license
by Patrik Stridvall 09 Feb '02

09 Feb '02

> On Sat, 9 Feb 2002, Patrik Stridvall wrote: > > > I think you will be able convince both the lazy person above > > as well as the bean counter that this will be the best > > long time choice. > > > > > If Wine is LGPL they must release the patch if they want > to reap the > > > benefits of using Wine, and they can release it without > fear of giving > > > away money to someone else. It can even be argued that the > > > LGPL makes Wine > > > an even safer bet, since it guarantees that other companies > > > in this group > > > will chip in, this way Wine will be in even better shape when > > > the first > > > application was a smash hit and they decide to port their > next app! :) > > > > Correct, but this is likely to be true anyway for reasons > given above. > > > > This is what I imagine the LGPL proponents are dreaming > about at night. > > Unfortunately it is a dangerous dream since it total ignores the > > drawbacks with a LGPL:ed Wine. > > > > The drawback would be that it locks out the companies from > group 1 (yes, > you have pointed out technical problems that might render the LGPL > worthless, but I'll leave the bugfixing for now, lets just assume it > actually works). > > My question is, to you and everyone else, how valuable are > this kind of > companies to the Wine community? A relevant question, unfortunately the problem is much more complex that that. Assuming that LGPL really prevents wrapper libraries have very far reaching consequences. I have tried to give example of specific cases like the Joe Hacker hobbist with his proprietary hobby related library and his proprietary Windows application and his wish not to dual boot. I asked whether doing this (or for that matter preventing) this was among other things ethically or morally defendable. You can't just focus on the companies that wish to profit on Wine in some way. But yes, short answer: I believe such companies like Transgaming is valuable for the simply reason that our resources are limited, this allows us to concentrate on improving other parts of Wine. If in the future decide that hey now that we have more developer resources, now let do a really free DirectX, we can do that. Always remember that: He who defends everything, defends nothing. In short a strategic retreat means that we get resources to defend what we have and later take it back as we grow stronger. > Yes, they may make progress fast, maby they are even required > to take Wine > from the allmost but not quite stage to actually reach that > elusive goal > of 99.9% Windows compatibility. > > But at the same time this progress may never make it back to > the community. > And as pointed out by Alexandre, in the worst case scenario > they may halt > or slow down progress in the free version, because there is > no incentive > to implement some missing peice when it already exists and > can be bought > cheaply from company X. Well and as I pointed out. Most people have a Windows license and many Micrsoft DLL work fine under Wine. Yes, I know he thought that to was bad too. But then you can't both have the cake and eat it. The same thing with other proprietary extensions, except perhaps better from Alexandres point of view, since much more people have Windows licenses than a random proprietary library. > The limited experience shows that things has worked out OK. It will be > interesting to see what Lindows ends up doing, I wish they > would skip the > maketdroid speak for a while and join this discussion. Agreed. > > > have the least to gain from contributing anything back. The > > > companies in > > > group 2 have the least incentive to work on Wine, just > fix the bare > > > minimum to get their application to work, but instead > they can allow > > > themselves the luxury to contribute and score some goodwill. > > > > Since companies in group 2 are likely to contribiute back anyway > > for reasons given above I see no reason to hurt group 1 companies. > > > > Yes, each and every one has to go back to his own motivation > for working > on Wine, does it matter if the group 1 companies get a free lunch? Well, all users of Wine already get a free lunch, and they might already profit from being able to run say Microsoft Office under Linux so if you are worried about people getting a free lunch you already have a serious problem.

1 0

Re: Wine license change
by Brett Glass 09 Feb '02

09 Feb '02

Roland (roland(a)netquant.com.br) writes: >To write it again we have two interests: > >1. People who want to make money selling WINE or derivates == anti xGPL >2. People who contribute for free or have another business model than the >above == pro xGPL There are a few more categories who would not want the (L)GPL: 3. Professional programmers who would like to fix bugs (if the code is (L)GPLed, they can't without becoming "tainted" by having read the code); 4. Anyone who objects to viral licenses or the FSF's misleading propaganda; 5. Users who want to be able to buy a commercial product with professional support, especially good integration, and possibly enhanced features; 6. Anyone who does not want to see WINE fork into truly free and FSF-licensed versions; and 7. Anyone who cares, on principle, about software freedom and choice. --Brett Glass

4 4

RE: Wine, enthusiasts, businesses and the agony of the license
by Patrik Stridvall 09 Feb '02

09 Feb '02

> What's lacking in this discussion is some sensible analysis of what a > license need to contain to encourage future contributions to > Wine and to > protect the interests of the contributors. Fearmongering about Wine's > future and paranoid delusions about the GPL license doesn't > bring anything > to the table... Agreed. > Over to category two. Corel's source of income isn't from > improving Wine, > it's from selling their own work, Wine just makes their work > more valuable. > Here it doesn't really matter if Wine is BSD or LGPL > (remember that the > INTENT of the LGPL isn't to infect all and everything). > > A company that chooses this route may have to improve Wine > here and there > to fill in the missing pieces to make their port work, and by > releasing > this patch they will contribute to Wine as a whole. > > Unfortunatley they might not, don't underestimate the power > of laziness. > One other plausible reason is that some bean counter is afraid that > someone else will pick up their work for free and make money out of it > (i.e. Lindows) how'd you explain that to your shareholders? Companies in this group have several choices: 1. Don't use new improvement in the main Wine tree, only resync then a new major version of the application should be released. 2. Maintain a tree by themselves, continually resyncing in order to make even minor version take advantage of new improvements in the new Wine tree. 3. Have some sort of wrapper library that implement all the improvments that they don't what to release, that in turns calls the Wine real corresponding Wine function. Now they can, if the designed it correctly, use new versions of Wine without any problem. 4. Release the code to the Wine project and be able to run with the latest version of Wine without any problem. (1) and (2) are not very attractive. Resyncing the trees are quite time consuming. Especially (2) will not be fun at all. Both requires continously working with Wine. In any case I guess most companies want the Wine adaption to be a ONE TIME cost not a continous one. Likely they want to hire specialists from companies like CodeWeavers. This leaves (3) and (4). If you design (3) wrongly the application will break with newer version of Wine so it is not really a that good choice either. In addition it will require extra work just to be able to hide the improvments. This leaves (4) ie they treat Wine is LGPL even if it isn't. I think you will be able convince both the lazy person above as well as the bean counter that this will be the best long time choice. > If Wine is LGPL they must release the patch if they want to reap the > benefits of using Wine, and they can release it without fear of giving > away money to someone else. It can even be argued that the > LGPL makes Wine > an even safer bet, since it guarantees that other companies > in this group > will chip in, this way Wine will be in even better shape when > the first > application was a smash hit and they decide to port their next app! :) Correct, but this is likely to be true anyway for reasons given above. This is what I imagine the LGPL proponents are dreaming about at night. Unfortunately it is a dangerous dream since it total ignores the drawbacks with a LGPL:ed Wine. > Companies that decide to develop a new app and use Wine as the cross- > platform framework also belongs to this group. Partly, but new applications can avoid using unimplemented functions so they are less likely to contribute anything back. > Back to Wine again, the selfish motive here is to make Wine > better faster. > So if we get the choose between companies in group 1 or 2, who will > contribute the most? Obviously the ones in group 1 will do > the most work, > since their living relies on a perfectly working Wine, > unfortunatley they > have the least to gain from contributing anything back. The > companies in > group 2 have the least incentive to work on Wine, just fix the bare > minimum to get their application to work, but instead they can allow > themselves the luxury to contribute and score some goodwill. Since companies in group 2 are likely to contribiute back anyway for reasons given above I see no reason to hurt group 1 companies. > So what's the conclusion? Either you pick your favourite way of making > business and lobby for a compatible license, or you start > thinking out of > the box and find the perfect balance that let's everyone keep > the cake and > eat it... Well, that would be good. However I'm pretty convinced that a very good solution would be not moving to LGPL. While perhaps not the ultimate solution, I have a gut feeling that no better soltion exists in the real world. > I'll be back tomorrow with more opinions, and my stab at > thinking out of > the box. Your welcome.

2 1

Re: Dr. Seuss, licensing, and WINE
by David Elliott 09 Feb '02

09 Feb '02

On 2002.02.09 05:32 Plato wrote: > On Sat, Feb 09, 2002 at 03:50:09AM -0500, David Elliott wrote: > > On 2002.02.08 15:03 Brett Glass wrote: > > [...] > > >taxes: It will act in its own interest, not yours. The FSF's > > >sole goal is to destroy commercial software developers, and > [...] > > Give me a break dude. Yes, the FSF wants all software to be free and > > wants to rid the world of commercial software altogether. > [...] > > I think it is worth pointing out the the Free Software Foundation does > *not* > want to rid the world of commercial software. > > Stallman has, however, stated that he would like to rid the world of > *proprietary* software. > Whoops, sorry, you are correct about that. However to the person I was replying to commercial==proprietary. Red Hat Linux is a commercial product, but not proprietary (to give an example). Though I think Red Hat does have a few proprietary products they work on. > There is an incredibly important difference. Please do not use the terms > interchangably. See > > http://www.gnu.org/philosophy/words-to-avoid.html#Commercial > http://www.gnu.org/philosophy/software-libre-commercial-viability.html > Been there long ago.. just kinda forgot. -Dave

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel