September 2006 - Wine-Devel

Re: H. Verbeet : wined3d: Add support for native NPOT textures.
by Frank Richter Sept. 27, 2006

Sept. 27, 2006

On 27.09.2006 10:46, Alexandre Julliard wrote: > @@ -765,6 +768,12 @@ #undef USE_GL_FUNC > > gl_info->max_sampler_stages = max(gl_info->max_samplers, gl_info->max_texture_stages); > > + /* We can only use NP2_NATIVE when the hardware supports it. */ > + if (wined3d_settings.nonpower2_mode == NP2_NATIVE && !gl_info->supported[ARB_TEXTURE_NON_POWER_OF_TWO]) { > + WARN_(d3d_caps)("GL_ARB_texture_non_power_of_two not supported, falling back to NP2_NONE NPOT mode.\n"); > + wined3d_settings.nonpower2_mode = NP2_NONE; > + } > + FYI, ATI r300+ hardware has some limited support for NP2 textures - that is, 2D textures without mipmaps and repeat mode CLAMP. But since that does not fulfill the ARB_tnpot requirements this extension isn't published. Still, maybe you can exploit that feature somehow... -f.r.

1 0

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
by Michael Stefaniuc Sept. 27, 2006

Sept. 27, 2006

Thomas Weidenmueller wrote: > The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, > not unsigned int. Won't work on Win64. long is 32bits on Win32 and Win64. On Linux64 long is 64bits. bye michael > ------------------------------------------------------------------------ > > Index: dlls/rpcrt4/rpc_server.c > =================================================================== > RCS file: /home/wine/wine/dlls/rpcrt4/rpc_server.c,v > retrieving revision 1.58 > diff -u -r1.58 rpc_server.c > --- dlls/rpcrt4/rpc_server.c 30 Jun 2006 19:16:38 -0000 1.58 > +++ dlls/rpcrt4/rpc_server.c 27 Sep 2006 12:38:00 -0000 > @@ -1008,7 +1008,7 @@ > /*********************************************************************** > * RpcMgmtSetServerStackSize (RPCRT4.@) > */ > -RPC_STATUS WINAPI RpcMgmtSetServerStackSize(unsigned int ThreadStackSize) > +RPC_STATUS WINAPI RpcMgmtSetServerStackSize(unsigned long ThreadStackSize) > { > FIXME("(0x%x): stub\n", ThreadStackSize); > return RPC_S_OK; -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
by Paul Vriens Sept. 27, 2006

Sept. 27, 2006

On Wed, 2006-09-27 at 14:40 +0200, Thomas Weidenmueller wrote: > FIXME("(0x%x): stub\n", ThreadStackSize); Shouldn't that be (0x%lx) then ? Cheers, Paul.

1 0

some wineconference pictures
by Marcus Meissner Sept. 27, 2006

Sept. 27, 2006

Hi, Some Wine conference pictures from David and myself: http://gallery.kuschelt.net/main.php?g2_view=core.ShowItem&g2_itemId=100617 Ciao, Marcus

2 1

Governance revisited
by Robert Lunnon Sept. 27, 2006

Sept. 27, 2006

I note the recent flamefest, where some of this list seared yet another contributor (Roland Kaeser) Since this particular very old, very shrivelled chestnut. is one of my personal favourites (thanks to Colin Wright for the chestnut thing...). I'd like to repeat my observations about this. Feel free to flame away since I have donned my asbestos suit and have long since decided my viewpoint. The problem is that code gets rejected that is *** NOT *** Hacky because there is a, single point of review - a single opinion of what constitutes a hack, and no appeal process. For example I once submitted code to implement cpu.c using the x86 cpuid instruction directly on all x86 platforms. This was NO hack. But the code was rejected. This code replaces the OS specific code for several x86 cases with generic code. The way I see it this code removes hacks (since I consider any OS specific code fragment a hack). This just shows that opinions differ about what a hack is. This code now sits in my patch-kit, never to see the light of day on wine-hq, but happily runs in every copy of wine for Solaris for the last 4 years with ZERO issues. No hacks should not be an objective, by my definition wine already has more hacks than just about any other open source package out there. Linuxisms continue to contaminate wine every month (I can vouch for it). What we need is management, balance between function and beauty delivered by peer review. Necessary functional hacks should be allowed unless they have severe side-effects. Even application specific work-arounds can be permitted if the work around adds significant functionality per the objectives of the project, the scope of the work-around is suitably confined, and assuming the code can be maintained over time. Wine needs process... The issue is not code, It's governance. Governance to establish balance, balance between beauty and function. Bob

24 55

WineD3D: glBlend* fixes
by Roland Scheidegger Sept. 27, 2006

Sept. 27, 2006

> Roderick, Mesa calls the extension "GL_EXT_blend_minmax", and so does > the spec. I don't know what exactly uses the min_max form. Is this a > typo? Apart from the blend_minmax typo, it appears to be me this patch has some other problems. >> This patch changes the detection extension detection for >> glBlendColor/glBlendEquation. The function glBlendColor is part of >> OpenGL 1.1 and is supported on all OpenGL implementations. No, it's not. Calls to it are ONLY legal on opengl up to 1.3 if either ARB_imaging or EXT_blend_color are supported (the spec says "Blend Color is an imaging subset feature, and is only allowed when the imaging subset is supported"). It is however part of OpenGL 1.4. So, a really correct detection would be to check for ogl version 1.4, EXT_blend_color, ARB_imaging. Maybe the check for ARB_imaging could be omitted, but it is possible there are drivers out there which only announce support for ARB_imaging but not EXT_blend_color, according to www.delphi3d.net there are indeed some tnt2's out there which claim support for ARB_imaging but not EXT_blend_color - if I'd have to guess I'd suspect the call to glBlendColor results in a sw fallback. >> Further glBlendEquation is part of GL_ARB_imaging aswell. For the >> same reason GL_ARB_imaging can't be used to detect glBlendEquation. >> This call isn't supported on all OpenGL implementations. Luckily it >> is part of 'GL_EXT_blend_min_max' so that is used now. This is not quite so simple. If OGL 1.4 is supported, or the version is lower but ARB_imaging itself is supported, all the blend function stuff from ARB_imaging is ok. If only either EXT_blend_minmax or EXT_blend_subtract is supported, then glBlendEquation is supported, but only different modes are valid (FUNC_ADD, MIN, MAX for EXT_blend_minmax, FUNC_ADD, FUNC_SUBTRACT, FUNC_REVERSE_SUBTRACT for EXT_blend_subtract). But if all you care is that glBlendEquation is available, you should probably detect ogl 1.4, and EXT_blend_subtract (some cards only support EXT_blend_subtract but not EXT_blend_minmax), but really for correctness EXT_blend_minmax and ARB_imaging should be checked too. Roland (not subscribed to wine-devel - include me in cc for answers)

4 8

re: shlwapi: Resupply array sizes stripped by function interface
by Dan Kegel Sept. 27, 2006

Sept. 27, 2006

Andrew Talbot wrote: >A formal parameter declared as an array is treated as a pointer; any size >specifier is ignored. So here, sizeof decimal_buffer, for example, would >equate to the size of a pointer to WCHAR, not to that of an array of eight >WCHARs. Why are you doing this? - Dan

3 8

re: start.exe: New feature allowing to specify the shell operation name
by Dan Kegel Sept. 27, 2006

Sept. 27, 2006

>The new /O[peration] command line option allows to specify a shell >operation other than "open". > This is very valuable for testing or implementing actions from shell scripts. Hmm. I don't see that option in the Win XP documentation: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en… There's already one clash (/l) between wine's start and Windows'. I hesitate to say that adding another extension is a good idea. I'd feel better if the help mentioned that this is a Wine-specific extension. - Dan

2 2

Re: Governance revisited
by jimtabor Sept. 26, 2006

Sept. 26, 2006

Hi, Dmitry Timoshkov wrote: > > > How many projects have you ever participated in? Every developers' > mailing list > of an open source I personally participated in *doesn't guarantee* not > only patch > acceptance, but even a reply with explanations why the patch has been > silently > dropped, and it doesn't matter how many maintainers a project has. Why > do you > request that from Wine, and particularly from Alexandre? > > Alexandre is not a robot, he is a human. Please take that into account. Sounds like he need more help. > > It's a metter of the fact, that if you can't cope with other people's > requirements, > you can't work in a team. > Every Wine developer needs to read this, http://www.codeweavers.com/services/ and http://www.codeweavers.com/services/wine . It is your job to provide support for this product, I spend money and I need help, where do I go? Are you going to piss me off by telling me to shut up and put up with the poor support from this mailing list? This project needs a course in technical sales support. Good idea for the next WineConf! Remember you represent CodeWeavers, start acting like it. 8^D, James

6 7

Re: cabinet: Fix NULL pointer dereference (Coverity)
by James Hawkins Sept. 26, 2006

Sept. 26, 2006

On 9/26/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Changelog: > cabinet: Fix NULL pointer dereference (Coverity). > > diff -urN a/dlls/cabinet/fci.c b/dlls/cabinet/fci.c > --- a/dlls/cabinet/fci.c 2006-09-12 23:59:28.000000000 +0100 > +++ b/dlls/cabinet/fci.c 2006-09-26 18:27:03.000000000 +0100 > @@ -176,18 +176,22 @@ > if ((!perf) || (!pfnalloc) || (!pfnfree) || (!pfnopen) || (!pfnread) || > (!pfnwrite) || (!pfnclose) || (!pfnseek) || (!pfndelete) || > (!pfnfcigtf) || (!pccab)) { > - perf->erfOper = FCIERR_NONE; > - perf->erfType = ERROR_BAD_ARGUMENTS; > - perf->fError = TRUE; > + if (perf) { > + perf->erfOper = FCIERR_NONE; > + perf->erfType = ERROR_BAD_ARGUMENTS; > + perf->fError = TRUE; > + } > > SetLastError(ERROR_BAD_ARGUMENTS); > return NULL; > } > > if (!((hfci = ((HFCI) (*pfnalloc)(sizeof(FCI_Int)))))) { > - perf->erfOper = FCIERR_ALLOC_FAIL; > - perf->erfType = ERROR_NOT_ENOUGH_MEMORY; > - perf->fError = TRUE; > + if (perf) { > + perf->erfOper = FCIERR_ALLOC_FAIL; > + perf->erfType = ERROR_NOT_ENOUGH_MEMORY; > + perf->fError = TRUE; > + } > > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > return NULL; > This last check is pointless. If perf is NULL, we bail out and return NULL a few lines up. Also, please add a test showing that native does not crash if a NULL perf is sent in. It's weird, but we need to be consistent with native, as some apps depend on such a crash. -- James Hawkins

2 1