December 2005 - Wine-Devel - list.winehq.org

Re: has the LGPL licence fell through ?

by Troy Rollo

On Wed, 21 Dec 2005 09:24, Tom Wickline wrote: > Yes I have read the licence just re read it for that matter... > So why no patches from SpecOps? It is not a requirement that patches be submitted - only that source code be made available. Patches are normally submitted because it is more convenient for the developer if the change is in the canonical version. If the developer does not see the value of having their patch in the canonical tree, they will not (and are not required to) submit it. > should Wine move to GPL to keep from > being robbed of its code? What difference do you expect that to make? > If your wondering why I'm ranting : > http://news.inq7.net/infotech/index.php?index=1&story_id=60585 What version of Wine is their stuff based on? -- Troy Rollo - wine(a)troy.rollo.name

Dec. 20, 2005

Re: has the LGPL licence fell through ?

by Marcus Meissner

On Tue, Dec 20, 2005 at 05:24:40PM -0500, Tom Wickline wrote: > Yes I have read the licence just re read it for that matter... > So why no patches from SpecOps? should Wine move to GPL to keep from > being robbed of its code? I would really like to see more than speculation on this product. LGPL has similar restrictions on releasing the source with binaries too btw. Ciao, Marcus

Dec. 20, 2005

Re: has the LGPL licence fell through ?

by Tom Wickline

On 12/20/05, Tom Wickline <twickline(a)gmail.com> wrote: > > If your wondering why I'm ranting : > http://news.inq7.net/infotech/index.php?index=1&story_id=60585 http://www.specopslabs.com/projdav-framework.htm Okay, can someone from SpecOps please send me a nice .bz2 of there changes? > > Tom >

Dec. 20, 2005

has the LGPL licence fell through ?

by Tom Wickline

Yes I have read the licence just re read it for that matter... So why no patches from SpecOps? should Wine move to GPL to keep from being robbed of its code? If your wondering why I'm ranting : http://news.inq7.net/infotech/index.php?index=1&story_id=60585 Tom

Dec. 20, 2005

PATCH/RFC: defer OLE apartment window creation

by Marcus Meissner

Hi, RFC ... since its likely not the clean way Robert wants. This defers the appartment window creation until it is actually need. Ciao, Marcus Changelog: Defer OLE apartment window creation until it is actually needed. Index: dlls/ole32/compobj.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/compobj.c,v retrieving revision 1.168 diff -u -r1.168 compobj.c --- dlls/ole32/compobj.c 12 Nov 2005 19:11:21 -0000 1.168 +++ dlls/ole32/compobj.c 20 Dec 2005 22:06:39 -0000 @@ -236,9 +236,6 @@ { /* FIXME: should be randomly generated by in an RPC call to rpcss */ apt->oxid = ((OXID)GetCurrentProcessId() << 32) | GetCurrentThreadId(); - apt->win = CreateWindowW(wszAptWinClass, NULL, 0, - 0, 0, 0, 0, - 0, 0, OLE32_hInstance, NULL); } else { @@ -257,6 +254,15 @@ return apt; } +void make_apartment_window(APARTMENT *apt) { + if (apt->win) return; + if (!(apt->model & COINIT_APARTMENTTHREADED)) + return; + apt->win = CreateWindowW(wszAptWinClass, NULL, 0, + 0, 0, 0, 0, + 0, 0, OLE32_hInstance, NULL); +} + /* gets and existing apartment if one exists or otherwise creates an apartment * structure which stores OLE apartment-local information and stores a pointer * to it in the thread-local storage */ Index: dlls/ole32/compobj_private.h =================================================================== RCS file: /home/wine/wine/dlls/ole32/compobj_private.h,v retrieving revision 1.60 diff -u -r1.60 compobj_private.h --- dlls/ole32/compobj_private.h 28 Nov 2005 11:04:18 -0000 1.60 +++ dlls/ole32/compobj_private.h 20 Dec 2005 22:06:39 -0000 @@ -253,6 +253,8 @@ return COM_CurrentInfo()->apt; } +void make_apartment_window(APARTMENT *apt); + #define ICOM_THIS_MULTI(impl,field,iface) impl* const This=(impl*)((char*)(iface) - offsetof(impl,field)) /* helpers for debugging */ Index: dlls/ole32/rpc.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/rpc.c,v retrieving revision 1.72 diff -u -r1.72 rpc.c --- dlls/ole32/rpc.c 19 Dec 2005 20:24:25 -0000 1.72 +++ dlls/ole32/rpc.c 20 Dec 2005 22:06:39 -0000 @@ -257,6 +257,7 @@ TRACE("Calling apartment thread 0x%08lx...\n", apt->tid); + if (!apt->win) make_apartment_window(apt); PostMessageW(apt->win, DM_EXECUTERPC, 0, (LPARAM)params); } else @@ -498,6 +499,7 @@ TRACE("Calling apartment thread 0x%08lx...\n", apt->tid); + if (!apt->win) make_apartment_window(apt); PostMessageW(apt->win, DM_EXECUTERPC, 0, (LPARAM)params); WaitForSingleObject(params->handle, INFINITE); CloseHandle(params->handle);

Dec. 20, 2005

Re: Testing WideCharToMultiByte

by Alexandre Julliard

Bill Medland <billmedland(a)mercuryspeed.com> writes: > Has anyone ever done a proper investigation into the edges of > WideCharToMultiByte? I was quite surprised to see that given > how important it is there is no test for it (or am I blind?) There are a few in dlls/kernel/tests/codepage.c. > I am investigating a potential off-by-one in msi and want to know > very exactly what is supposed to happen in the edge cases (e.g. > specifying a length of 0 or a length that does not actually > include a terminating null character or ...). > > If no-one else is involved then I am prepared to do a little > investigation and write the tests but I guess we don't want to > start adding tests like that at this late stage, or do we? I don't see why not, it's never too late to add tests. There probably isn't much point in testing normal functionality since the function is already used all over the place, so any regression there would be spotted quickly. But if you find some interesting edge cases by all means add tests for them. -- Alexandre Julliard julliard(a)winehq.org

Dec. 20, 2005

Testing WideCharToMultiByte

by Bill Medland

Has anyone ever done a proper investigation into the edges of WideCharToMultiByte? I was quite surprised to see that given how important it is there is no test for it (or am I blind?) I am investigating a potential off-by-one in msi and want to know very exactly what is supposed to happen in the edge cases (e.g. specifying a length of 0 or a length that does not actually include a terminating null character or ...). If no-one else is involved then I am prepared to do a little investigation and write the tests but I guess we don't want to start adding tests like that at this late stage, or do we? -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 20, 2005

Re: errors fixed with crossoffice

by Alex Villacís Lasso

Curro Amores wrote: > Hi i have a problem with wine and my access97 reports > > Letters are show separated and bigger. However using crossoffice i > dont have this problem. How can i know where is the problem > > i have installed freetype, fontconfig last versions, copied all my ttf > files... > > thanks > > > Could you please prepare a minimal self-contained Access 97 report that demonstrates the bug, or else point at the bug report where such an application was uploaded/linked? That would be the single most helpful thing that would enable somebody to look at the problem. BTW, is this the same report as the one described in http://bugs.winehq.org/show_bug.cgi?id=3909 ? Then what happened to the report that enables it to run now? Alex Villacís Lasso

Dec. 20, 2005

Re: [wined3d] Code questions

by Oliver Stieber

--- Aric Cyr <Aric.Cyr(a)gmail.com> wrote: > I just have a couple wined3d code questions/comments that I'd like to clear up > and possible submit patches if my understanding is correct. If I am > misunderstanding the code please correct me. > > 1) basetexture.c:BindTexture() > Just _before_ we call glBindTexture we call glTexParameteri and either set > GL_TEXTURE_MAX_LEVEL or GL_TEXTURE_MIN_FILTER. The comment in the code is: > > "Always need to reset the number of mipmap levels when rebinding as it is > a property of the active texture unit, and another texture may have set it > to a different value" > > However, this doesn't make any sense to me and I believe it to be incorrect. > glTexParameter affects the currently bound texture object. If the current and > next texture to be bound have different mipmaps levels or parameters it should > not be necessary to change these settings as all the state is encapsulated > correctly in the OpenGL texture object, which should have been initialized > correctly in Device::CreateTexture or BaseTexture::ApplyStateChanges. The > reason the current code is bad is two-fold: 1) unneeded state changes on a > performance critical path, as texture binding is very frequent and 2) changing > the state of a _previous_ texture object, not the current one. The next time we > go to use that texture object we will have to reapply all of it's state again, > another waste of time. I spent a lot of the weekend debugging wined3d (trying > to get anisotropic working in World of Warcraft) and just commenting out the > block of code greatly cut down on d3d trace messages and makes the code easier > to understand (and faster). > Your right the mipmap level should only ever need to be set once, just after the texture is created. The problem is that this doesn't seem to work, at least with ATIs drivers this demo (http://www.codesampler.com/dx9src/dx9src_3.htm#dx9_texture_filtering) fails, along with many games and demos without some weird code. This is one of the two regression problems that are preventing d3d8-wined3d wrapper and evict managed resources from being checked in. > 2) device.c::SetupTextureStates() > Similar to my previous remark, there seems to be an incorrect state change > here as well. glTexEnvf(TEXTURE_FILTER_CONTROL, LOAD_BIAS), glBlendColor() and > then glTexEnvfv(TEXTURE_ENV, TEXTURE_ENV_COLOR) are called. All of these are > called for each texture state update. However these are all global render > states, not per-texture contrary to the comment in the code. Since these states > are already being set in Device::SetRenderState() I'm pretty sure they don't > need to be set here as well. Again, I'm fairly sure that there are some things that don't work without reapplying the states all the time. The last time I looked at this was just after the last big patch I put out so I can't quite remember which demos/games didn't work. > > Well that's all for now. Having started to really dig into wined3d, it seems > that some effort in cleaning it up (coding style is way off) and stablizing it > before it gets much more unwieldy is due. I'm also willing to help with such a > task if there is a consensus that it should be done. > I'm just about to start tidying up directx.c, or at least the supported formats bit of directx.c and then I was going to tidyup drawprim a bit. What is the expected coding style, I just coppied that one that was being used. Thanks, Oliver. > Regards, > Aric > > > > ___________________________________________________________ Yahoo! Photos NEW, now offering a quality print service from just 7p a photo http://uk.photos.yahoo.com

Dec. 20, 2005

Re: WLDAP32: link to the reentrant version of libldap

by Alexandre Julliard

Hans Leidekker <hans(a)it.vu.nl> writes: > On Monday 19 December 2005 20:47, Alexandre Julliard wrote: > >> It's really not much more work to do it right the first time around, > > Thanks for calling me lazy ;-) I wasn't worried about the amount of > work, I was looking ahead thinking about how distro x version y might > need another check for some missing functions, and they would start > adding up. There was a time when the ldap_*_ext functions didn't > exist for example. This library has quite a long history. All the more reason to check for the functions we are actually using. If there are more library variants to check for, it won't be manageable to only check for a function or two and then attempt to guess which other functions may or may not be defined. -- Alexandre Julliard julliard(a)winehq.org

Dec. 20, 2005