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.
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(-)
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.)
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)
>>> 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.
'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'.
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.