February 2002 - Wine-devel - list.winehq.org

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 16 Feb '02

16 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 16 Feb '02

16 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