wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So what you basicly saying is that a Crypto API that is a > part of ADVAPI32 > > can't call ADVAPI32 functions but a Crypto API in say CRYTPO32 can. > > > > Isn't that quite an absurd state to make? Or rather the > perfect illustration > > of the absurdities of LGPL. > > No, I think it makes perfect sense. If your code is sufficiently > independent that it can be put in a separate library, then the LGPL > gives you the right to release it under another license. But in order > to do that, you have to demonstrate that the code is really as > independent as you claim it to be; and requiring you to put it in a > separate library is the best way to ensure that. Somehow I guess you would say that. OK, so now are down to independence. So independence is an issue of whether something is on either side of an artifical barrier in this cases the DLL boundary? Note that you your condition: "If your code is sufficiently independent that it can be put in a separate library" can always be fullfilled with a little trickery. For example: void CryptFoo() { CRYPT32_CryptFoo(); } and release the code above under the LGPL. Note that we now return to the doctrine of derived work for nothing except for it can ever make this illegal. > You known, no matter how much you may disagree with the FSF or their > license, they are not a bunch of idiots. They have been through this > long before you, and have spent a lot of time (and lawyers) to make > sure that it worked as they wanted. You can certainly find minor > issues and border cases, but the LGPL is not the useless crap you seem > to think it is. They had a goal and I'm sure a lot of competent people did the best they could be accieve it. However, you can do the impossible no matter how hard you try.

4 3

TrueColor <16bpp modes
by François Gouget 20 Dec '01

20 Dec '01

There is a problem with <16bpp TrueColor modes: some windows applications will just check BITSPERPIXEL and if it's < 16 they will assume that we are running with a 2/16/256 color palette. What are the affected modes: * 15bpp: rgb555 and bgr555 * 8bpp: VNC's bgr233 mode! This patch is an ugly hack but it seems to work relatively well. The trick is to lie to the application about the screen depth. If we have a TrueColor mode but a <16bpp screen depth then we return 16bpp anyway. But then the application is going to create 16bpp bitmaps, and CreateBitmap will try to create a 16bpp pixmap... and this is likely to fail. So in CreateBitmap we reestablish the truth and put the right depth in bitmap.bmBitsPixel. Actually some X servers, especially the 4 series seem to support many pixmap bit depth so this may not always be necessary. Anyway, we then rely on the code in dib.c to do the conversions from one format to the other. The last bit in bitblt.c may not be necessary. It seemed useful once but I'm not convinced anymore. Well, if anyone's interested in hacking more on this, have fun (and let me know if you find interesting stuff or have questions :-). -- François Gouget fgouget(a)codeweavers.com Index: graphics/x11drv/bitmap.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/bitmap.c,v retrieving revision 1.34 diff -u -r1.34 bitmap.c --- graphics/x11drv/bitmap.c 2001/09/07 15:28:10 1.34 +++ graphics/x11drv/bitmap.c 2001/12/20 00:31:19 @@ -156,6 +156,14 @@ GDI_ReleaseObj( hbitmap ); return 0; } + /* In case we lied to the application wrt. the screen depth, then it's + * time to patch things up before X complains it does not support this + * color depth. Of course it means we'll have to convert depths from + * DIB to Bmp. + */ + if (bmp->bitmap.bmBitsPixel==16 && screen_depth<16 && (X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL)) + bmp->bitmap.bmBitsPixel=screen_depth; + if ((bmp->bitmap.bmBitsPixel != 1) && (bmp->bitmap.bmBitsPixel != screen_depth)) { ERR("Trying to make bitmap with planes=%d, bpp=%d\n", Index: graphics/x11drv/init.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/init.c,v retrieving revision 1.41 diff -u -r1.41 init.c --- graphics/x11drv/init.c 2001/07/29 20:25:15 1.41 +++ graphics/x11drv/init.c 2001/12/20 00:31:22 @@ -190,7 +190,11 @@ case VERTRES: return screen_height; case BITSPIXEL: - return screen_depth; + /* Some applications assume that if the bpp<16 then we are using a + * palette. This is wrong, we could be in 15bpp, or even bgr233 in VNC. + * So we just lie to them. + */ + return (screen_depth<16 && X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL) ? 16 : screen_depth; case PLANES: return 1; case NUMBRUSHES: @@ -202,10 +206,11 @@ case NUMFONTS: return 0; case NUMCOLORS: - /* MSDN: Number of entries in the device's color table, if the device has - * a color depth of no more than 8 bits per pixel.For devices with greater - * color depths, -1 is returned. */ - return (screen_depth > 8) ? -1 : (1 << screen_depth); + /* MSDN: Number of entries in the device's color table, if the + * device has a color depth of no more than 8 bits per pixel. For + * devices with greater color depths, -1 is returned. + */ + return (X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL) ? -1 : (1 << screen_depth); case PDEVICESIZE: return sizeof(X11DRV_PDEVICE); case CURVECAPS: Index: graphics/x11drv/bitblt.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/bitblt.c,v retrieving revision 1.37 diff -u -r1.37 bitblt.c --- graphics/x11drv/bitblt.c 2001/10/03 18:45:41 1.37 +++ graphics/x11drv/bitblt.c 2001/12/20 00:31:19 @@ -626,7 +626,7 @@ pdata += swap ? start+width-1 : start; if (image->depth == depthDst) /* color -> color */ { - if (X11DRV_PALETTE_XPixelToPalette && (depthDst != 1)) + if (!(X11DRV_PALETTE_PaletteFlags & X11DRV_PALETTE_VIRTUAL) && X11DRV_PALETTE_XPixelToPalette && (depthDst != 1)) if (swap) for (i = 0; i < width; i++) *pdata-- = X11DRV_PALETTE_XPixelToPalette[XGetPixel( image, i, row )]; else for (i = 0; i < width; i++)

1 0

timed-out non-overlapped ReadFile
by lawson_whitney＠juno.com 20 Dec '01

20 Dec '01

Mike, None of your recent comms pathces has made the slightest difference to my app, but this little one breaks it. It dials, the modem connects, but the app never sees RLSD AKA CD AKA TIOCM_CAR. I reversed overlapped_good.diff II, because AFAIK that is not in the CVS yet, but it didn't matter. I don't think I have any other stray comms patches, but ICBW. +comm,+file trace attached. Lawson ---oof---

1 0

Re: Add color cursor support
by Alexandre Julliard 20 Dec '01

20 Dec '01

Duane Clark <dclark(a)leewardfpga.com> writes: > The main ugly hack that is performed here is in determining whether a > pixel is a foreground or background pixel. This is done by adding the > red, green and blue values for each pixel, and testing whether they > exceed an arbitrary threshold. This should probably be a reasonably > safe method, since presumably any cursor will have a high level of > contrast between foreground and background colors. It's reasonable, but you should be doing this locally in the X image before transferring it to the server; painting the pixmap in the server pixel by pixel is going to be quite slow. And you may want to have a look at CURSORICON_IconToCursor, it does something similar. -- Alexandre Julliard julliard(a)winehq.com

4 3

Re: overlapped ReadFile should ignore EAGAIN
by Mike McCormack 20 Dec '01

20 Dec '01

Hi Alexandre, Apologies, i thought explicitly about the error handling issue, and should have made a note about why i did it that way. Since the async handler code will handle problematic fds correctly, rather than duplicating all the checks, i thought it would be easier to fall thru to the existing checks in check_async_list and FILE_ReadAsyncService. Do you think it would be better to pick up any problems early? Did you look at my async queues patch? Are you waiting for Martin to respond? The async handling code is a bit of a hacked up mess the moment... i haven't applied the fixes to WriteFile that i've applied to ReadFile, and overlapped WaitCommEvent needs to return immediately if events are already available. I don't want to fix those problems twice, so i'm waiting for the big async patch... Mike Original message from: Alexandre Julliard <julliard(a)winehq.com> > >Mike McCormack <mike_mccormack(a)start.com.au> writes: > >> This is a fix for the problem below. Since all COM port fds are >> non-blocking, if we get an error (EAGAIN) return from the initial >> read, we should just ignore it and let the wineserver poll on it. > >Shouldn't you check for EAGAIN then? It doesn't seem safe to ignore >all errors. > >-- >Alexandre Julliard >julliard(a)winehq.com ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Re: overlapped ReadFile should ignore EAGAIN
by Alexandre Julliard 20 Dec '01

20 Dec '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a fix for the problem below. Since all COM port fds are > non-blocking, if we get an error (EAGAIN) return from the initial > read, we should just ignore it and let the wineserver poll on it. Shouldn't you check for EAGAIN then? It doesn't seem safe to ignore all errors. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > There will be very little reason for companies to enter the market > > at that time and why try to make it difficult for the few > that might. > > On the contrary, there will be a lot more reasons. The main market is > not in developing Wine; frankly there isn't that much money to be made > on that. The main market is in using Wine to make money on > applications, and the more complete Wine gets the easier this will be. If the applications is are already proprietary I they can affort to pay to get the whole way to 100% functionallity. If they are open source they have an incentitive to work making Wine complete. I don't really see the problem. > But if Wine never gets complete because some parts are held > proprietary by other companies, it won't be possible to enter that > market. So you mean that all the people that are current voluntering to work of Wine won't work on Wine if it is almost complete just because somebody else have done the parts they need to run their applications and that they will happily pay for the right to use it. In that case it would be disasterous to make Wine run all Microsoft implemented non-core Wine DLL:s because then everybody would just be happy to use the Microsoft DLL:s and nothing beyond non-core would ever be implemented. You can't seriously believe this?

10 19

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 20 Dec '01

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > For example: > > void CryptFoo() > > { > > CRYPT32_CryptFoo(); > > } > > > > and release the code above under the LGPL. > > That's the square root example. If you do that, you have to make sure > that the use of CRYPT32_CryptFoo is optional and that the function > still behaves properly if your CRYPT32 function is not available. Forget for a moment I was trying to circumvent the LGPL. Lets say I just found a crypto library called CRYPTO32 under a proprietory license that I wished to use. It so happends that they had almost 100% the same functions as the Crypto API. So almost all functions would look like void CryptFoo() { #if HAVE_LIBCRYPTO32 CRYPT32_CryptFoo(); #else /* Old Wine code */ #endif } with a few minor exception. So you mean that I can't legally do that despite the fact that the LGPL is meant to allow linking to proprietary licenses. I think you have misunderstood something seriously. Please, this is the absolute worst argument from you as of yet. You can't seriously believe this. Also note that the code that I wrote above was supplied under the LGPL, so I don't see how you can claim that I violated the LGPL. The company that wrote the proprietory library neither knew about the me nor about Wine so how can they have violated the LGPL. > > They had a goal and I'm sure a lot of competent people did the best > > they could be accieve it. > > > > However, you can do the impossible no matter how hard you try. > > Strangely there are thousands of people, including lawyers, who seem > to think that the LGPL does what it claims to do. If the problems are > so obvious, how come no one else sees them? Could it be that maybe, > just maybe, it is because all these people are right and you are > wrong? Could it be that they rely on that that the dotrine of derived work will save them from people trying to use the lopeholes in the licenses?

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> Now, here's another something to mull over. We've pretty > much established > that you could statically link something proprietary with > something LGPL. > One question I have is how much of the library are you > allowed to use. > Alexandre mentioned that while the CryptoAPI example would be > a pretty > clean-cut allowed case, a proprietary CreateWindow would not > be allowed. > His argument was that because it would necessarily use > internal functions > and data structures that it would be a derived work and thus > subject to > the license. > > I think what Patrick has been trying to get at is that that > is not very > clean-cut and that in fact there is little to no precedent on > what exactly > a derived work is. If Alexandre is indeed correct then we > are pretty well > protected. If it is at the opposite extreme and anyone could > statically > link in proprietary versions of functions then we have very little > protection and it really makes it not worth it to go LGPL. At > least that > is what I think Patrick has been trying to say. Yes, approximately. > Let me put it to you the way I see it. Whether a function or data > structure is exported or not does not matter. It would be trivial to > declare an internal structure or function as exported and thus the > proprietary function is simply making use of the library and > therefore not > a derived work. Indeed... > That is my argument that avoids all of > Patrick's doctrine > of derived work crap and gets right down to the fact that > it's trivially > easy to make your work fall under the work that uses the > library category, > so long as it is a seperate object file. That is, to put it > in Slashdot > terms, a "Big Gaping Hole(tm)" ..but you are wrong that just because it falls under use, it is clear from the doctrine of derived work. That is the main problem, I have with it. That it might potentially turn somekind of uses into derivation and thus potential infringement of copyright. > Look at section 5 in the LGPL. If you use (from the header > files) only > numerical parameters, data structure layouts and accessors, and small > macro and inline functions then regardless of whether it would be > considered a derived work it remains a work that uses the library. > > So that's great, after I had pretty much convinced myself > that the LGPL > was still good despite some minor problems, I now find myself > realizing > that the LGPL has major holes written into it! Welcome to the club. :-) > And so I emphasize my original statement now. The only thing > the LGPL > really prevents is the direct use of the source code. Anyone > wanting to > release a proprietary implementation of any function can do so fairly > easily simply by 1) writing that particular function from > scratch, and 2) > keeping it in a seperate object file. Agreed. > > > Try reading section 2C of the LGPL and tell me how it's good for > > commercial > > > companies. > > > To respond to Roger: I fail to see how 2c makes any > difference. It only > applies to derived works and only means that you have to release the > code. Yes, it only applies to derived works, but since it is pretty unclear what a derived work is makes it quite unclear for commercial commpanies what that are legal forced to release or not that can't possibly be good when they are deciding whether to use Wine.

2 1

[SHrinker] gdb still doing funny things
by Robert Baruch 19 Dec '01

19 Dec '01

I got around the problem of gdb unprotecting the write protected page by not setting the breakpoint until after the write fault occurs. When I stepped through the Shrinker exception handler, I got to the point where it calls ReadProcessMemory with a handle of -1 to get the 8 bytes around the EXC_CallHandler's call. ReadProcessMemory fails with an ACCESS_DENIED, and trips a landmine. 0806d9e8:Call kernel32.ReadProcessMemory(ffffffff,4006cd38,404f489c,00000008,404f48a4) ret=0075f1c3 0806d9e8: read_process_memory( handle=-1, addr=0x4006cd38 ) 0806d9e8: read_process_memory() = ACCESS_DENIED { data={} } 0806d9e8:Ret kernel32.ReadProcessMemory() retval=00000000 ret=0075f1c3 However, when I run wine alone, without gdb, that particular landmine is not tripped: 0806d9e8:Call kernel32.ReadProcessMemory(ffffffff,4006cd38,404f489c,00000008,404f48a4) ret=0075f1c3 0806d9e8: read_process_memory( handle=-1, addr=0x4006cd38 ) 0806d9e8: *attached* 0806d9e8: *signal* signal=19 0806d9e8: read_process_memory() = 0 { data={ff,75,08,ff,d1,64,8b,25} } 0806d9e8:Ret kernel32.ReadProcessMemory() retval=00000001 ret=0075f1c3 BTW, the data returned by ReadProcessMemory is correct, and also will not trip the "Have I been called from Microsoft's NTDLL.DLL method" landmine. I'll have to think about this for a while, how to use gdb without getting ACCESS_DENIED for ReadProcessMemory. That usually means going off and doing something else until an idea hits me. --Rob

2 2

[Shrinker] Modified EXC_CallHandler
by Robert Baruch 19 Dec '01

19 Dec '01

Well, the assembly-coded EXC_CallHandler works (to my surprise), with a little modification from what I described because after all, no plan survives contact with the enemy. However, we're still getting hit by one of the landmines in Shrinker. The awful thing is that I can't debug this easily with gdb. The first exception that's supposed to take place is a write fault to the code area. But if I set a breakpoint in the process's code area, gdb is going to remove the write protection from the code area because, I guess, it needs to put a breakpoint in there (I thought it would use breakpoint registers instead of int $3?) Anyway, I don't want to release the EXC_CallHandler code until I find out which landmine we're hitting, since I can't be certain the rest of EXC_CallHandler works -- the stuff past calling the exception handler. But if you're interested in a morbid "I-love-assembler" way, here it is: static DWORD EXC_CallHandler( EXCEPTION_RECORD *record, EXCEPTION_FRAME *frame, CONTEXT *context, EXCEPTION_FRAME **dispatcher, PEXCEPTION_HANDLER handler, PEXCEPTION_HANDLER nested_handler) { DWORD tmp = 0; __asm__ __volatile__( "push %1\n\t" // ebp-1c = nested_handler "push %2\n\t" // ebp-18 = handler "push %3\n\t" // ebp-14 = dispatcher "push %4\n\t" // ebp-10 = context "push %5\n\t" // ebp-c = frame "push %6\n\t" // ebp-8 = record "push %%ebp\n\t" // ebp-4 "push %%ecx\n\t" // ebp-0 "movl %%esp,%%ebp\n\t" "movl 0x18(%%ebp),%%ecx\n\t" "pushl 0x1c(%%ebp)\n\t" "pushl %%fs:0\n\t" "movl %%esp,%%fs:0\n\t" "pushl 0x14(%%ebp)\n\t" "pushl 0x10(%%ebp)\n\t" "pushl 0x0c(%%ebp)\n\t" "pushl 0x08(%%ebp)\n\t" "call *%%ecx\n\t" "movl %%fs:0,%%esp\n\t" "popl %%fs:0\n\t" "movl %%ebp,%%esp\n\t" "popl %%ecx\n\t" "popl %%ebp\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "popl %0\n\t" "movl %%eax,%0\n\t" : "=&g" (tmp) : "g" (nested_handler), "g" (handler), "g" (dispatcher), "g" (context), "g" (frame), "g" (record) : "memory" ); return tmp; } --Rob

2 2

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> David Elliott <dfe(a)tgwbd.org> writes: > > > Now, here's another something to mull over. We've pretty much > > established that you could statically link something > proprietary with > > something LGPL. One question I have is how much of the library are > > you allowed to use. Alexandre mentioned that while the CryptoAPI > > example would be a pretty clean-cut allowed case, a proprietary > > CreateWindow would not be allowed. His argument was that because it > > would necessarily use internal functions and data structures that it > > would be a derived work and thus subject to the license. > > Actually the fact that they are internal or not doesn't make a > difference, I wasn't clear on that point. Agreed. It doesn't matter. > If your code is linked to > the library it is considered a derivative work, and by default the > whole has to be released under the LGPL. Now there are cases where you > don't need to do that: one is if your app is considered a work that > uses the library (section 6), the other is if you are placing your > code side-by-side with the library (section 7). > > So if you don't want your code to fall under the LGPL, you have two > choices: one is to put it in some part of your app that only links to > the library, but in that case you cannot have other parts of the > library depend on your code (this is the square root example). This > would work for the crypto API, probably not for CreateWindow since the > rest of user32 needs CreateWindow. Well, only if it made CreateWindow work different that it was supposed to. Note that supposed to it pretty vague, however, if you leave it out you can't even apply bug fixes since it would change the behavior. > The other solution is to put your code side-by-side in the library; > but this is only possible if your code is not covered by the license, > which means it isn't a derivative work of the library, which in turns > means it cannot use any functions or data (exported or not) of the > library. This would work for the crypto API as long as you don't use > anything from the rest of libadvapi32. So what you basicly saying is that a Crypto API that is a part of ADVAPI32 can't call ADVAPI32 functions but a Crypto API in say CRYTPO32 can. Isn't that quite an absurd state to make? Or rather the perfect illustration of the absurdities of LGPL. Of course, I assume that you by use a function mean call a function not cut and paste from a function.

3 2

RE: Installshield 6 (inter-proc) patches. LGPL hole.
by Patrik Stridvall 19 Dec '01

19 Dec '01

[David Elliott explaination snipped] > Thanks for explaining what Patrik has been going on about. Yes, it was quite a good explaination. However... > In summary: > > Consider a proprietary application which ships as a > proprietary library > which is statically linked with LGPL libraries at install > time in a way > that lets users supply new versions of the LGPL libraries. > This lets them > fix bugs in the LGPL'd code and thus in the proprietary app. > The harm you see is that a vendor could, once he found a > Winelib function > with a bug, simply do his own clean-room implementation of > that function, > and use it instead of the Winelib version of it, and keep the > improvement > to himself -- which would also deprive the user of the ability to fix > bugs in the proprietary reimplementation of that particular > WineLib function. ... while this is an entirely possible scenario there is little profit in doing what you suggest so while it is one of the holes in LGPL it is not really a problem in pratice I think. No, the problem as far as Wine is concerned, is that somebody might do proprietary extension of some important part of Winelib that enough people want so much that most people uses the proprietary extension and under such circumstances there won't be any incentive for people to work on Wine. However, I neither believe this to be true, nor do I believe that the LGPL will help to stop it other than very marginally.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> >> MS Word (to use an example) might have to dynamically link in > >> a special MS Word component to process specifics in my > >> document, it doesn't mean my document is "linked" with the > >> MS Word component does it? > > > > Ah, you are beginning to see the problem. :-) > > What problem? A GPL program is the same as any other - GPL > protects the > code, not the use of said code. Indeed. It is a not a use license. However because of the doctrine of derived work that GPL depends upon, some use (read: linking) are considered derivation and thus a possible violation of the GPL. > There's nothing to stop a > GPLed program > such as, say an amiga emulator (UAE) running the emulated non-free > software. As geoffs example rightly points out. You think (read: hope) that it is not so because it would be quite absurd wouldn't it? However if the doctrine of derived work is strong enough to prevent want the GPL hopes it will prevent namely linking, I see no reason to assume that emulation would be considered differently. After all from a technical point of view essentially that same things that happends. > And in any case, we are talking about the LGPL - a totally different > matter. Not entirely whatever power the LGPL have also derives from the doctrine of derived works eventhough is doesn't try to use it to the extent that the GPL does. > Which is my response to Rogers comment above - sure the GPL > prohibits linking with a nonfree component. Yes, but what is linking? Don't you understand it is the vagueness of linking that is the problem. This is further made worse by that fact that the doctrine of derived might possible, and are very like to do, at least to some extent, place some kind of limit on what linking legal extends to. > That 'closes' the > source and > provides far too many ways to cheat the license. > > The LGPL allows dynamic linking with a nonfree component. > Remebering that > the LGPL is meant to apply to LIBRARIES (hence allowing a > libssh library > to use nonfree crypto routines for example) not for an application. You can cheat with both the GPL and the LGPL at I have tried to illustrate in earlier mails, but the LGPL at least as applied to Wine is a gaping hole, that hardly provides any protection at all.

3 5

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > The problem is the doctrine of derived works. Nothing else. > > And to you truly believe that our choice for Wine's license > will have any > influence over the doctrine of derived works? Of course not. But it _will_ effect our abillity to attract companies. Eventually I think the courts, possibly with the help of the politicians will realize that only a very weak doctrine of derived work could every service society without introduces needless uncertainties and/or absurdities. For example I think that some cases where the doctrine of derived work has been used like IIRC in some case considering unauthorised Star Trek books. Using the Star Trek characters in a book without Paramounts(?) permission, would be much better served using trademark law instead. This might or might not require changing trademark law but that is a different issue. Don't expect it to happend soon though. > If not, there > really is no > point in discussing this any further. If yes, than even more > so should we > chose the LGPL, as it will help settle the debate the right way. See reply in previous mail.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > I'm against the fact that the GPL or to a smaller extent LGPL > > tries use the doctrine of derived work as a weapon to achieve > > their goals. It is a very dangerous weapon, since if the courts > > or the policitians decide that a strong doctrine of derived work > > is good it might be disasterous for society as a whole. > > This is a very good point which in fact _promotes_ the LGPL. Not really. See below. > Let me > explain. > > There are two possibilities for copyright law: > > 1. The copyright law becomes stronger. > 2. The copyright law becomes weaker. It is much more complicated than that, but fair enough, lets assume this for the sake of argument. > I will assume, for the purpose of this discussion, that: > > A. Wine contributors wish for 2. I, for one, am very worried about the > direction of law these days (see: software patents, DCMA, > SSSCA, etc.) and > I fully agree with Gerard that it's an unfortunate situation > B. There doesn't seem to be any negative feedback loop that > will prevent 2 > from happening. That is, it is very probable that 2 _will_ > happen sooner > rather than later. I agree. > Now, let's just go through the possibilities: > > Let's look at copyright law. If our dreams come true and 2. > will become > reality, then Wine will be in no worse situation than it is > now in. The > LGPL will effectively become BSD, i./ii. become irrelevant, > and we're all > happy. This scenario is possible, but (unfortunately) not probable. Yes, but in the mean time it is likely that we scare away potential good companies and regardless of the LGPL be effected negativly by bad companies using the lopeholes in the LGPL. > On the other hand, if society moves towards 1., then the LGPL is the > perfect tool because it turns the stronger copyright law > against itself. > In this case, it is the only moral/ethical thing to do: to > turn an evil > instrument against itself, thus provides the > _negative_feedback_loop_ that > is missing at the moment. > > Moreover, if you are worried about the fact that open source > software is > so influential that it can influence the debate over the doctrine of > derived work, then even more so should we opt for the LGPL > because in that > case we would contribute to a negative feedback that will deter > politicians from making the copyright law arbitrarily stronger. So you want Wine to be the catastrofic failure, that was used to change copyright law. You can't seriously want this.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > > Note that I said "_small_ improvements" because of the > > > modular nature of Wine. If the improvements are big, the DLL > > > separation would allow them to keep those changes proprietary. > > > > I don't think small improvements is a problem anyway and > > beginning an implementation of say DCOM is probaly not a > > small improvement and DirectX certainly isn't. > > But if it's not, it's within a small constant factor to > replace the rest > with prorietary code and not release anything. See, if the > DLL is mostly > implemented, the changes are not that big, so they should be > contributed > back. If the DLL is mostly stubs, just rewrite the entire > thing, you're > not wasting that much effort in the first place, and you can choose > whatever licence you want. DirectX and DCOM fall in this cathegory. I have use the Crypto API as an example several times that to illustrate that the DLL:s isn't a relevant protection boundary for the LGPL, even Alexandre seems to accept this. In any case if the DLL is mostly implemented there is very little reason for a company to try to enter the market, it is simply to dangerous, so I don't see the problem. > > > I fail to see _any_ moral/ethical/philosophical problem with > > > this. Do you? > > > > Perhaps you have been more enlightend now. > > Focusing on obscure issues only is anything but enlightening. :) Well, the concrete issues like do we scare potential companies that wants to help way quite hard to argue about in a objective way and I do not really like subjective arguments. I leave them to for example Gavriels that IMHO has done a good good job at that. I have been trying to approach the problem from the other side, that the LGPL doesn't provide much protection at all.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > You forget that some "independent"(*) parts like the Crypto API are > > parts of other DLL:s (like ADVAPI32.DLL) for no particular reason. > > This is ridiculous: it is one of the few exceptions, it is > simply silly to > bring the Crypto API into this discussion. If this the Crypto > API is the > only problem, we can fix it in multiple ways. It is not the only problem it is just a symptom of the gaping hole in LGPL. > > > At this point, I would like to know if people agree up to > > > this point. > > > > I don't. > > That's informative. WHAT don't you agree with? In fact, if we > can agree on > WHAT we disagree, I think it would be a great step forward. "I don't" primarily refered to the previous argument concerning "independent"(*) parts. > > > 0. Isn't Wine's best interest to evolve and develop as fast > > > as it can? > > > > Yes. > > This is a fundamental point. A project like Wine is just like > a living, > breathing creature. And being need to be selfish to survive. Not too > selfish, but it is essential that they have a certain level of > selfishness. Your analogy is flawed, Wine is not living in the meaning that it, if it is to unselfish can die. The mechinisms are entirely different compared to normal life. > In Wine's case, that has to be: 'the licence > should be such > that it would maximize Wine's development'. Yes, but I don't believe that LGPL does, that I have being trying to explain in I forgot how many mails. > > > 1. If so, isn't the LGPL _spirit_ in Wine's best interest? > > > > No, not nessararily. See different mail. > > 1 follows from 0. Period. You can not agree with 0 and > disagree with 1, no > matter what you write in other emails! :) Again, THE SPIRIT > of LGPL, not > the letter. Again, the spirit is: 'if you improve Wine in minor ways, > please contribute back your improvements'. Yes, and the key is minor ways and I believe that is a absolute non-issue as I have explained before. There is no profit in holding minor improvements. > > > 2. If so, why shouldn't we formalize it in the license? > > > > But it isn't nessarily so. > > And why is that? Quite the contrary, because: > > -- For people that contribute back, would chnage nothing > -- For people that don't contribute their changes, it's no > good to us, so > we don't care (which follows by point 0). > > Tertium non datur. That is, there's no other case. QED. OK, since you bring mathematics in to it, I will try to explain in mathematical terms: "The set of people is not invariant over a license change." In fact the set of people are likely to be considerly less. While I have no strict mathematical proof of that, I especially point to Gavriels' reply concerning Corel and Transgaming.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On 2001.12.18 05:09 Patrik Stridvall wrote: > [snip] > > Dimitrie O. Paun wrote: > > > Stop for a movement and tell me: are you against the letter > > > or the spirit > > > of the LGPL. > > > > Asking that question is like asking whether I support the spirit of > > Communism: > > "From each according to his abilities - to each according > to his needs." > > > > Well, it sound nice doesn't it? However doing a little > deeper analysis > > I realize that the price for being able to do this is not > worth paying. > > > > Note however that I'm not equating GPL or LGPL with Communism. > > It was just an example from real life, that you get more that > > you wish for. See below. > > > [snip] > > That's a piss poor example. The statement that something > would be from > each according to his abilities and to each according to his > needs sounds > to me at first glance like it would suck. And you don't have > to dig too > deeply to figure out why that would suck. But maybe that's > because I am > an American capitalist though and through and that blatantly > conflicts > with my core values that everyone should do for themselves. Perhaps. However, I think that if you move to Europe, especially northern Europe you will find that people have different opinions. While most people there certainly do not believe in Communism and to various degrees understand why is doesn't work, people are more inclined to be believe in this principle. Actually I think the reason for this is more Protestant Christianity than Communism, but why is not really that important. > And to get > off topic, why is that? Because that's what everybody will > do anyway, > might as well work with that rather than pretend that it is otherwise. So there is no such thing as morality? > This has lead me to another thought. We cannot pretend that > people are > going to release code back to Wine under the X11 license. > However we can > realize the obviousness of the truth that given the chance > people will > take whatever they can and give back nothing in return. Some > folks will > give back because it may make more sense to do so than to > not. But some > folks will be more than happy to take the whole codebase for > their own > good and provide nothing in return. > > We need to stop living in the dream world that everyone who > uses Wine will > contribute back. I have no illusions that everybody will. However there is no need to scare away potentially good companies by using a hard to understand license. > Yes, it is true that Corel, Codeweavers, > TransGaming, > etc. have given a lot to Wine. None of them was or is > required to give > anything. And yet they did. That is kind of shocking for an American Capitalist, isn't it? :-) > If the goal is to let people know that if they want to use > Wine then they > need to contribute back, then the only choice is to put that into the > license. By "use" I am obviously not referring to simply porting an > application using Winelib. I am referring to incorporating > source code > from wine into their own products. > > This is exactly what the LGPL was meant to address. And if they borrow some obscure functions, they might even supply some bugfixes in hope that at a later stage there will be more bugfixes waiting for them when they borrow again (resync) a year later. And if they don't, who has been hurt? If Wine was LGPL:ed they certainly wouldn't have borrowed at all, so no chance at all of getting any bugfixes back at all. > I recall Uwe's usual .sig which is: > Free Software: if you contribute nothing, expect nothing. Indeed and what is your hypotetical sig? "LGPL:ed Software: if you contributed something, use the law as a tool to force others to contribute as well." > Maybe we should have one for wine: > Wine: If you contribute nothing, well, there isn't shit we > can do about it > since we are X11 licensed. I don't think that one came out the way you hoped. Try again.

1 0

Installshield 6 (inter-proc) patches
by J.Brown (Ender/Amigo) 19 Dec '01

19 Dec '01

Any idea when Oves interprocess patches will be put into the main Wine CVS tree? The code currently in WineX isn't really that ugly at all, and it is a very important part of Wine to have working IS6 support. Regards, | Any significantly advanced technology is indistinguishable from | a perl script. Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org]

5 9

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Mon, 17 Dec 2001, Patrik Stridvall wrote: > > > > This has been my argument against Patrick exactly. Some > > > protection is better than none at all. > > > > As a general rule, yes. > > > > However this time the protection comes with a price. > > And what might that price be? You fear that we are going to > alienate the > commercial ventures developed around Wine? Yes. > > The problem is not whether LGPL is well written or not the > > problem it is the doctrine of derived work. That is very > > unclear because of lack of good case law. > > Oh, come on, for crying out loud! The LGPL is the best thing > we have -- we > can't wait for a good case law to adopt a license. Yes, there may be > problems, but that's life. We take our best shot -- this is what we're > doing with Wine in the first place! The main problem is that using the LGPL introduces uncertainty to what is allowed and that advantages is not good enough IMHO to outweight the disadvantages. > Patrik, your entire arguments are based on such obscure > assumptions that's > scary! I must tell you, both the GPL and LGPL have received careful > scrutiny from FSF's legal council (and a bunch of other law > professors, > I'm sure). The problem is the doctrine of derived works. Nothing else. Even if their understand of other parts of law are perfect it matters not. IIRC their arguments always seen to assume that the doctrine of derived works is unproblematic if applied to source code. > It's the best we can hope for now. You come along > with a bunch > of 'it is possible' type of scenarios (doh, everything is > possible!), and > say that 'well, everything's in vain, we're doomed, there's > no point in > doing anything, actually...'. In all honesty, it just looks > stinks. Badly. To connect again to the example of the spirit of Communism: I am sure it was very popular to dismiss to fear of the opponents by saying what you have been saying. Trivialising the problems and clinging to clean, pure and uncomplicated spirit of it.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> Patrik, > > The more I read your posts, the less I understand what you > are trying to > say. You argued over many hundreds of lines over weird > technical details > and various dubious assumptions about what courts will do in > the future. The main point is that what is legal allow is very unclear. I'm not primarily trying to explain what is legal allowed or not, just pointing out some difficulities in understand what the law really means. > Stop for a movement and tell me: are you against the letter > or the spirit > of the LGPL. Asking that question is like asking whether I support the spirit of Communism: "From each according to his abilities - to each according to his needs." Well, it sound nice doesn't it? However doing a little deeper analysis I realize that the price for being able to do this is not worth paying. Note however that I'm not equating GPL or LGPL with Communism. It was just an example from real life, that you get more that you wish for. See below. > The spirit is simple: > > Here is this thing, we give it to you for free, use it for your own > benefit however you see fit. But it's a labor of love, and > many people put > thousands and thousand of hours in it, together with their hearts and > souls. As such, they hold it dear, and they want it to survive, and > thrive. All we ask is: if you've made _small_ improvements to > it, to make > it useful to your purpose, please contribute those back such > that our baby > can grow and develop together with your business. I'm against the fact that the GPL or to a smaller extent LGPL tries use the doctrine of derived work as a weapon to achieve their goals. It is a very dangerous weapon, since if the courts or the policitians decide that a strong doctrine of derived work is good it might be disasterous for society as a whole. Various commerical intrest might (read: will) for example try to use this to stop 3rd party additions to their works and I don't want that to happend. In short: Be careful what you wish for: "The road to hell is paved with good intentions" > Note that I said "_small_ improvements" because of the > modular nature of > Wine. If the improvements are big, the DLL separation would > allow them to > keep those changes proprietary. I don't think small improvements is a problem anyway and beginning an implementation of say DCOM is probaly not a small improvement and DirectX certainly isn't. > I fail to see _any_ moral/ethical/philosophical problem with > this. Do you? Perhaps you have been more enlightend now.

5 5

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> Technicalities aside, the LGPL spirit seems to be accepted by most > people. We've heard no end of discussion of what represents > the code, and > so on, but in reality (please Patrik :)), Wine is a > _well_defined_ piece > of software. In fact, it's defined by Microsoft, and well > accepted by the > world at large. > > Now, that being said, there seems to be two camps: > -- the BSD camp, which maintains that BSD is good enough, and that > people will in fact do what the LGPL wants. > > -- the LGPL camp, which says 'well, if that's the case, why > not have it > formalized in the license'? No, I think you misunderstand. I'm not in the BSD camp as you define it. I do not nessarily believe that everybody will follow what the LGPL wants or at least that they will do things that they are certain would have been allowed if it was LGPL. And that is an important part of my objection: It makes it less clear what is allowed. > Before I go any further, I would like to stress a very important > point: Wine is in fact a collection of independent projects. > These are the > DLLs, and they nicely (and unequivocally) partition Wine into lovely > little, independent components. And this means that the LGPL is > independently contained to each and every DLL. It is the _perfect_ > position to be LGPLed. You forget that some "independent"(*) parts like the Crypto API are parts of other DLL:s (like ADVAPI32.DLL) for no particular reason. Actually large parts of the Windows API are "independent"(*). They are just helper function wrappers around other functions. (*) By "independent" mean that they just use other parts of the Windows API like normal applications do and claiming derived work for this would be absurd, just like claiming it for normal applications would be absurd. > At this point, I would like to know if people agree up to > this point. I don't. > The > discussion has been going all over the place, so I would like > to keep this > email short and to the point: > 0. Isn't Wine's best interest to evolve and develop as fast > as it can? Yes. > 1. If so, isn't the LGPL _spirit_ in Wine's best interest? No, not nessararily. See different mail. > 2. If so, why shouldn't we formalize it in the license? But it isn't nessarily so. > When answering these questions, let's try to leave the > commercial aspect > out of it for a second. That is a separate discussion. You > see, the reason > we care about the commercial aspect is that we hope (from > Wine's selfish > point of view -- as it should be!), that the commercial world will > actually _help_ in the development of Wine (that is, having a > commercial > universe around Wine would be in Wine's best interest). Now, > I claim that > the LGPL is _way_better_ for the commercial interests in the > long term, > but I will leave that to a future email (if people care to > discuss it). Claiming that it is better for Wine as a whole is one thing, but claiming that limiting commercial intrests choices is good even for them, requires a explaination.

2 1

implementation of ImageList_*Drag*
by Michael Stefaniuc 19 Dec '01

19 Dec '01

Hello, the attached patch (it's my first wine gui patch, that's why wine-devel is CC'ed) implements the dragging part of the ImageList functions. It works quite well with FreeSolitaire besides the dragged image isn't drawn semitransparent. But how do I draw a semitransparent image? IMO this isn't possible with the BitBlt functions. The ImageList_*Drag* functions shouldn't produce flickering as per the MSDN documentation, but ImageList_SetDragCursorImage (at least in Win9x) produces a short flickering when called. I implemented this function to match the behavior of the native comctl32.dll, but it would be very easy to stop the flickering. Should I change it or keep the Win9x behaviour? bye michael Changelog: Michael Stefaniuc <mstefani(a)redhat.com> fixed/implemented the ImageList_*Drag* functions -- 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

does mingw include share.h
by Bill Medland 18 Dec '01

18 Dec '01

I'm just off home now so I haven't time to learn sourceforge and download 100M. I need a share.h to go into the msvcrt (for two lousy symbols). I see that much of the msvcrt is based on mingw. Does it include share.h? TIA Bill

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