- Wine-devel - list.winehq.org

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(a)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