wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall 19 Jun '01

19 Jun '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > No, it is enough that it is GPL compatible which the Wine > license is. > > But then the code can no longer be distributed under a non GPL > compatible license, while this is allowed by the Wine license. winedbg _binaries_ compiled with --enable-readline quite possibly. As far as the source code to winedbg is concerned maybe but probably not. It might depend on whether --enable-readline or --disable-readline is the default, but that remains to be tested in court, but it is not certain it matters at all. The court might quite reasonably rule that no linking to readline has taken place yet and thus no derived work can have been created and even if they hold that some sort of linking has taken place it might not consider it a derived work. In short linking, especially potential linking, do not always imply a derived work which is all that matters as far as the law is concerned. Also note that I'm not convinced that any court will hold that the GPL is different from the LGPL in any relevant way with the possible exception of in bad faith trying to circumvent the requirements by trying to be "clever". Of course it is a little unclear that you really can do unlawful circumvention of license requirements. This is a like claiming that somebody circumvented trespassing your land by moving around it. Either you trespass or you do not. Either you violate the license or you do not. The analogy is quite good even in other areas: Even if you are on somebodies land you do not nessary trespass either because of copyright like "fair use" requirements in the law of most countries. As a sidenote: In Sweden "fair use" concerning trespass is so extensive that I never heard about _any_ case concerning it. > I think the benefit of using readline in the debugger is much too > small to justify the potential license issues this would cause. Only the debugger (winedbg) links with readline => only the debugger can be effected. Trying to claim, even though you didn't, that Winelib is effected is absurd since it is independent of the debugger. Distributing the debugger with WineLib is merly an aggregation nothing more.

1 0

Re: PATCH: Move 16-bit COMM stuff to USER, where it belongs
by Alexandre Julliard 19 Jun '01

19 Jun '01

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Move 16-bit COMM stuff to USER, where it belongs. While the idea of the patch is correct, I think it would be much better to fix the huge code duplication while everything is in the same file. The 16-bit stuff should be implemented on top of the 32-bit stuff, instead of duplicating most of it. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Use the libreadline in Winedbg, if available
by Alexandre Julliard 19 Jun '01

19 Jun '01

Patrik Stridvall <ps(a)leissner.se> writes: > No, it is enough that it is GPL compatible which the Wine license is. But then the code can no longer be distributed under a non GPL compatible license, while this is allowed by the Wine license. I think the benefit of using readline in the debugger is much too small to justify the potential license issues this would cause. -- Alexandre Julliard julliard(a)winehq.com

1 0

Lost mail
by Alexandre Julliard 18 Jun '01

18 Jun '01

Folks, I have been forced to change ISPs over the week-end, and it seems the old and new ISP couldn't agree on when to do the switch, so any mail sent to me during the week-end probably got forwarded to /dev/null. Also could people who submitted a patch to wine-patches please send me a private copy? I know they are on the mailing list archive, but it makes my life a lot easier to have everything in my mail box. Thanks. -- Alexandre Julliard julliard(a)winehq.com

1 0

set_file_pointer and 64 bit file access
by Bill Medland 18 Jun '01

18 Jun '01

I see we are in the middle of converting set_file_pointer towards 64 bit file systems. Currently the code is confused as to when to change from unsigned to signed int for the low 32 bits. Should it happen in SetFilePointer before sending the request (which means we end up changing the request format) or should it happen within set_file_pointer (after changing the argument back to a signed int; this would also require work in SetFilePointer to get it to set up the request correctly). Any views? Bill

1 0

RE: Use the libreadline in Winedbg, if available
by Ove Kaaven 18 Jun '01

18 Jun '01

On Mon, 18 Jun 2001, Patrik Stridvall wrote: > A minor notice. Readline is GPL:ed (not LGPL:ed) which is not so good. > While it is without doubt legal for us to use and distribute, > it might cause trouble for other people. Not as long as it's optional (that patch even supported ./configure --without-readline, so no trouble, such people would just disable it).

1 0

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall 18 Jun '01

18 Jun '01

> On Mon, Jun 18, 2001 at 04:10:14PM +0200, Uwe Bonnes wrote: > > Hallo, > > > > at present, wine uses unconditionally a self supplied readline > > function. Appended patch tries to find out if libreadline > is available > > and uses libreadline if available. I configured with and without > > libreadline and successfully compiled winedbg on my system. > > libreadline is a static library on my system and winedbg > grew 90 kByte > > stripped and 110 kByte compiled with -g. > > You are not allowed to link readline aganst non GPL code to > my knowledge. No, it is enough that it is GPL compatible which the Wine license is. Whether we should is another matter though. Just linking it to the debugger is rather harmless IMHO though.

2 1

Re: Use the libreadline in Winedbg, if available
by Marcus Meissner 18 Jun '01

18 Jun '01

On Mon, Jun 18, 2001 at 04:10:14PM +0200, Uwe Bonnes wrote: > Hallo, > > at present, wine uses unconditionally a self supplied readline > function. Appended patch tries to find out if libreadline is available > and uses libreadline if available. I configured with and without > libreadline and successfully compiled winedbg on my system. > libreadline is a static library on my system and winedbg grew 90 kByte > stripped and 110 kByte compiled with -g. You are not allowed to link readline aganst non GPL code to my knowledge. Ciao, Marcus

1 0

Dosvm not initialized for Direct port access
by Uwe Bonnes 18 Jun '01

18 Jun '01

Hallo, some license manager dll (lmgr327a) manages to read IOPORT 0x40 from 32-bit code. This results in an access to Dosvm.GetTimer() in line 297 in ioports.c, and as Dosvm isn't initialized this results in a crash. =>0 0x00000000 (ebp=404e4b38) 1 0x400cd595 (IO_inport+0x205(port=0x40, size=0x1) [ioports.c:297] in libntdll.so) (ebp=404e4b38, null call assumed) 2 0x400a7405 (INSTR_inport+0x25(port=0x40, size=0x1, context=0x404e4c50) [instr.c:328] in libntdll.so) (ebp=404e4b58) 3 0x400a888c (INSTR_EmulateInstruction+0x12cc(context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50) [instr.c:745] in libntdll.so) (ebp=404e4bc4) 4 0x400733c9 (do_segv+0x109(context=0x404e4c50, trap_code=0xd, cr2=0x0, err_code=0x0) [signal_i386.c:671] in libntdll.so) (ebp=404e4c2c) 5 0x4007368d (segv_handler+0x3d(__signal=0xb, __context=0x0) [signal_i386.c:787] in libntdll.so) (ebp=404e4d1c) 6 0x4029fb58 (__restore [sigaction.c] in libc.so.6) (ebp=405f57a0) 7 0x1c0b0004 (LMGR327A.DLL..reloc+0xbfe2004) (ebp=04007242) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

16-bit and 32-bit separation
by Patrik Stridvall 18 Jun '01

18 Jun '01

[Since the subject it up because of Dimitry's "Move 16-bit COMM stuff to USER, where it belongs" patch] My new tool winapi_fixup could without to much effort be extended to facillitate separation of 16-bit and 32-bit stuff by moving the 16-bit parts of a file (example: foo.c) to a new 16-bit only file (example: foo16.c). Of course because of dependecies, includes and such things it can only be partly automatic and it will in most cases require quite a lot editing afterwards, so the questions (primarily to Alexandre but other replies welcome to) are: 1. Will/Should Alexandre accept such patches at all? 2. Is it a useful effort to get the 16-bit stuff out of the way so we don't have to see it in the files when editing the 32-bit stuff? 3. Is it a useful effort to make it possible to have --disable-win16 configure option to compile out as much Win16 stuff as possible in order to save space in the binaries for say embedded stuff. 4. While this certainly it not a high or even medium priority effort, should it have low, very low or extremly low priority? PS. I have other stuff planed so I certainly do not lack things to do. However since the subject is up I might just as well ask.

1 0

Jump to page:

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