wine-devel December 2001

wine-devel@winehq.org

86 participants
179 discussions

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

20 Dec '01

> I see exactly what you mean. You mean a binary patch that says > things like: > * delete bytes 2294 to 2297 > * replace bytes 38455 to 39345 with "...." > * insert "...." at offset 41753 Yes. > Such a patch is very specific to a given source version > but does not > include any of the original source. Yes, but that is not a very problematic restriction. > Well, if you can legally use such a patch to work-around the LGPL > license, then you can use it to get past *any* license: GPL, AFPL, MS > shared-source, .... whatever. And this is not only true of > source files, > this is also true of binary files: you can apply such a patch to > executables, libraries, mp3s, mpegs, ... It means what you mean by get past, but OK for the sake of argument: Yes. > This has already been done and the author very quickly got into hot > water. IIRC it was less that two years ago, about a GPL game and an > individual who published a mod as a patch to the game binaries but > refused to publish his source. I'm not sure how it ended. You can > probably research it in your copious amounts of spare time, I think > there was an article on it on Slashdot at the time. I rememember. Of course it was impopular, I do not question that. The question is: Was it it illegal? > But I can assure you that no company in a 'developped' > country would > try such a thing. In the form above perhaps not so likely, but doing a proprietory Crypto API implementation with a patch to make Wine use it, much more likely. > If such a stunt were recognized as legal > then it would > spell the end of copyright of all electronic forms of songs, movies, > books, ... You can be sure that the RIAA, MPAA and all the other > entertainment companies in the world out would never allow such a > thing... and for once I say that they would be right. Please calm down. You forgot that the end user still need to legally get hold of the work somehow. For normal commercial stuff this involves paying for it and the author will get payed just like he did in the old non-digital world for _each_ copy. No particular problem, except that some companies might be greedy and want more, but hey, do you really wish to give them more? Open source is more problematic since the end user legally can get hold of the work for free and thus any distribution restrictions is meaningless since the end user doesn't distribute. But hey, do you really think this so important that you wish to give companies more power than they already have?

2 1

CryptoAPI (no, this has nothing to do with licensing! YAY!)
by David Elliott 20 Dec '01

20 Dec '01

A while ago I started hacking out an implementation of CryptoAPI. It sat idle for a while and a few days ago I decided to start doing a bit more hacking again. The basics of ADVAPI32's CryptoAPI part is that it does nothing except provide an interface for applications to call into CSPs without actually loading the CSPs themselves. At the moment the TESTCSP.EXE with its accompanying CSP.DLL is starting to work. These are from Microsoft's CSPDK and include source code. I have not tried compiling the source with Winelib, that is a later project. At the moment this code keeps track of which CSPs are loaded and which CSP an HCRYPTPROV handle uses. This allows testcsp to load up csp.dll and do a few things, but not everything. What bothers me though is that it does not get Intenret Explorer to load up the RSA CSP. The LoadLibrary fails because the DllMain function in the CSP returns FALSE. I speculate this has something to do with the fact that a real CSP needs to have its image verified before it will load. Or maybe it is something different entirely. Anyway, still left to be done are to keep track of Key and Hash handles (trivially easy) and maybe some other stuff. As far as putting this into the tree goes, I don't think it would harm anything, although I noticed that the GenRandom function had a useless implementation in it. It now has what I believe to be the correct implementation, but if loading the CSP fails that CryptGenRadom isn't going to work. Did somebodies appication actually depend on this behavior or was it implemented just to have something there? In any case, this still needs to be cleaned up a bit, but I am hoping to get some input on why I cannot load a real CSP as this is all completely useless (well, not completely, but for my purposes) if a real CSP cannot be loaded. -Dave

3 4

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

20 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > 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. > > The LGPL allows using LGPLed code from proprietary applications. It > does not allow making the LGPLed code dependent on proprietary code > for its own functionality. > > > 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. > > Of course you cannot violate the license of your own code, don't be > silly. Exactly. > But if you put this code in an LGPL library written by someone > else and distribute the end result, you have to make a good faith Yes and DISTRIBUTE the end result is the key. But why should I do that? I can for example write a script that download Wine for the end user user and apply the patch automatically. > effort to ensure that the library works properly even in the absence > of your proprietary library. This means you need to implement the > #else case and release that under the LGPL. Go read the square root > example in section 2 of the LGPL. Perhaps, but I need not distribute so it doesn't matter. The point that I have been tried to make all along that only the doctrine of can make my trickery illegal. Without it, it doesn't matter that I use Wine in a, hmm, let call it a non standard way. Anyway I think this discussion, at least the one between you and me, are running around in circles and doesn't move forward at all, so lets just end it. > > 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? > > Sure, maybe you understand the law better than all the lawyers who > looked into this issue. I'm not betting on it. It is not primarily understanding that is the issue here. I have said that I believe, and have tried to explain why, that a strong doctrine of derived work is not good for society, because it leads to all sort of absurd consequences. Therefore is believe (or rather hope) that the courts will se sanity and only constitionally allow a very weak doctrine of derived work and thus render viral licenses such as LGPL of most (all?) of its power since it will be quite easy avoid the requirements with a little trickery. Note that this will almost exclusivly effect viral open source license since normal commersial work will get their $100 or whatever regardless since there is no trickery that can legally avoid it.

2 1

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

20 Dec '01

> But, I hear you say, 'why change the license if it doesn't > give you any > protection?' Well, this is where your reasoning is flawed, because the > LGPL gives you quite a bit of protection. And this is because > there is at > least a 50% chance that it is enforceable, and this is > _good_enough_ in > practice. This is trivial to see: the market place is littered with > unenforceable EULAs, yet they seem to do the job. Why? Because big > companies will have not desire whatsoever to test these > licenses in court, > since they have to much too loose (remember, big companies = > have $$$), > while small companies can build on a business plan based on such shaky > grounds, as no one is going to fund such ventures. Add to > this the immense > public pressure, and you have Protection, with a capital P. Sure it is true that what people (read: companies) believe is true is more important than what really is true. The problem is that the example of things you could do that I consider trickery might be considered perfectly normal for some companies, in fact something are not really something strange at all if you applied to the normal world. I adjust the thing I bought a little and then resell it. Then their lawyers tell them that it is unclear if they can do it. Many might not not bother at all and thoose are lost to Wine, some might risk it a later find themselves it a situation that they can neither move forward nor backwards because of "public presure", and because of the amount of money invested they have little choice but to say the LGPL is absurd, we don't not believe we ingfringe on somebodies rights and move forward hoping that somebody doesn't sue them. > And just for shits and giggles, if you think _any_ license > will give you > absolute protection, you are sadly mistaken. And the reason > this can not > happen is rather simple: the laws change. I have said it before and I say it again: I have no illusions that something gives absolute protection.

2 1

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

20 Dec '01

> David Elliott <dfe(a)tgwbd.org> writes: > > > Okay, that makes a bit more sense. Although couldn't one argue that > > it still does work since it could fall back to the original LGPL > > createwindow? > > Sure, if this is the case it's OK. You can perfectly provide a > user32_better library that implements a new CreateWindow, and links to > user32 for the rest. But the modified user32 you ship must work > properly, it cannot be dependent on your proprietary user32_better for So as an alternative trickery: I distrubute everything just like the example above it just happends that user32 is a symbolic link to user32_orginal. This would be alright wouldn't it? So now I just can distribute a script that move the symbolic link user32 from user32_original to user32_better. Problem solved in a way even more convienient for my end user.

1 0

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

← Newer
1
2
3
4
5
6
7
8
9
...
18
Older →

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 December 2001