January 2011 - Wine-devel - list.winehq.org

Re: wined3d: Update detection of vertex blend capabilities
by Henri Verbeet 02 Jan '11

02 Jan '11

On 2 January 2011 10:52, Jeremy Chin <rekless(a)fastmail.fm> wrote: > Newer video cards have stopped reporting the ARB_VERTEX_BLEND GL capability, > but ARB_VERTEX_PROGRAM implies the same capability. > I don't think so. If this works at all it's probably because you're passing some previous value of gl_max (like GL_MAX_TEXTURE_UNITS_ARB) for the number of blend matrices.

1 0

RFC: include: Add '_ONCE' variants of DPRINTF, FIXME, WARN and ERR
by Sven Baars 02 Jan '11

02 Jan '11

Hey all, adding '_ONCE' variants of DPRINTF, FIXME, WARN and ERR is a topic that came up before on wine devel. The first version of the attached patch was submitted by Max TenEyck Woodbury, but was deferred until after wine 1.2. I still thought it was a good idea to have the _ONCE variants, so I mailed Max, but he said he backed out after finding out it was not feasible to do it right. I fixed some errors in his patch, but as Max pointed out to me, for compilers that don't support variadic macros, it's not possible to create a scope block to declare the static variable in. This is because of the (void)wine_dbg_printf call at the end of the (non-variadic) __WINE_DPRINTF_ONCE macro. wine_dbg_printf is a variadic function, any code after that function call breaks the macro (so a ';}while(0)' can't be added to close the scope). AFAIK, this is the reason why a do{...}while(0) loop can't be used as it's done in the others. Now I was wondering if there is a solution to this, or if it's ok to implement the _ONCE variants with the current patch. Using the current patch would mean that with a compiler that doesn't support C99, you would still have you at lot of the FIXMEs/WARNs where you don't want them. This would not be a problem right after the implementation, but only after replacing constructions like static int once; if(!once++) FIXME() with the corresponding _ONCE(). It wouldn't really break anything though. Also, it'd probably be better to replace #elif defined(__SUNPRO_C) with something like #elif __STDC_VERSION__ >= 199901L because that's what you're actually looking for. This would mean that the non-variadic _ONCE implementation is less of a problem, because more compilers would use the variadic __WINE_DPRINTF_ONCE macro. The #ifdef __GNUC__ would still remain because of their own implementation of variadic macros (from before C99). Have a happy new year! Sven --- include/wine/debug.h | 44 +++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 43 insertions(+), 1 deletions(-)

1 0

Re: ntdll/cdrom : implement CDROM_Verify to work on Mac Os
by James Mckenzie 01 Jan '11

01 Jan '11

maury loïc <lmaury(a)gmail.com> wrote: > >Hello Ken and the Wine community, > Please bottom post or post directly to a question. Please do not top post. > >On Thu, Dec 30, 2010 at 12:51 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > >> Hi Loïc, >> >> On Dec 30, 2010, at 4:20 AM, maury loïc wrote: >> >> > it's my first patch, and it implement the CDROM_Verify() >> > to work on Mac Os. >> >> I think most people are going to need more explanation for why this is a >> legitimate way to implement this function on Mac OS X. :) >> >> Cheers, >> Ken >> >> >For what i understood, The function CDROM_Verify(), verify if the media is >present on the device, and Wine try to open >the device(in Mac Os case), before call the CDROM_Verify(). > >But Mac Os manage the device differently from the other Os. It create the >device, only if the media >is already present. Logically, CDROM_Verify() return success, because when >we are in CDROM_Verify() >we already know the device. > >What do you think ? > This has been critically examined by several people and if the solution were this simple it would have been put in place a long time ago. Charles Davis has spend over a year looking at how to implement CDROM functionality for MacOSX. So, here is my question: How can the community be 100% certain that: 1. The device has EXACTLY the same name on every available MacOSX installation? 2. How can you be 100% certain that if the 'device' exists that the code will end up in CDROM_Verify()? James McKenzie (Another Mac User/Wine Tester.)

5 6

happy new year!
by Dan Kegel 01 Jan '11

01 Jan '11

May all your tests be green, and all your patches pass peer review :-)

3 2

Re: comctl32/tests: Add test for horizontal spacing to test_hittest.
by Marvin 01 Jan '11

01 Jan '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=8018 Your paranoid android. === WNT4WSSP6 (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === W2KPROSP4 (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === WXPPROSP3 (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === W2K3R2SESP2 (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === WVISTAADM (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === W2K8SE (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === W7PRO (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === W7PROX64 (32 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96) === W7PROX64 (64 bit listview) === listview.c:3036: Test failed: Horizontal spacing inconsistent (200 != 96)

1 0

Re: 64-bit Notepad2 crashes
by Susan Cragin 01 Jan '11

01 Jan '11

>>> Does this 'path' exist in LD_LIBRARY_PATH or equivilent? >>> >>> Otherwise ld might not be able to 'find' it when starting the program. >>> >>> James McKenzie >>> >> James... >> You've just exhausted my technical knowledge. How do I do / find that? >Susan: > >For the BASH shell: >Type in set and look for the LD_LIBRARY_PATH line. >for the CSH/KSH shell: >Type in env >Look for the LD_LIBRARY_PATH line. > >Hopefully, /usr/local/lib is there. > >BTW, to make Wine work on a Mac, I have to add this line.... > >James McKenzie Typed "set" Did word search on "library." Nothing.

4 3

re: 64-bit Notepad2 crashes
by Dan Kegel 01 Jan '11

01 Jan '11

'set' is not a good way to check the environment, since it also shows shell variables that are not yet exported. The portable way to check the environment is 'env'.

2 1

Re: NEW: Arabic Translation support in User32.dll (Basic Support)
by Andrew Nguyen 01 Jan '11

01 Jan '11

On 12/31/2010 08:41 AM, Nowres wrote: > Hello, > > here's a basic support for Arabic language in user32.dll > work in progress in other programs to complete support for this language. > > Nowres Rafid. > > > > Changes should be sent as a patch in unified diff format, preferably generated with Git. See http://wiki.winehq.org/SubmittingPatches for detailed guidelines.

1 0