I feel like a broken record, but:
some apps don't like following symlinks, and the
native Windows way to configure what the "My Foo"
folders point to is called shell folder redirection;
These are documented at
http://support.microsoft.com/kb/242557
among other places, and I think Wine supports thes
"Lei Zhang" <[EMAIL PROTECTED]> writes:
> I was not sure if was alright to mix code with different licenses in
> the same file. I looked around and found that
> include/wine/wined3d_gl.h has both LGPL Wine code as well as MIT
> licensed code from the Mesa project. Based on that, I guess it's ok to
James Hawkins wrote:
> On Nov 28, 2007 3:39 PM, Michael Stefaniuc <[EMAIL PROTECTED]> wrote:
>> i'm unsure about this patch series. Yes this are simple wrappers around
>> HeapAlloc() that are the same as the "standard" wrappers used in Wine.
>> But they are used only as callbacks aka different usag
On Nov 28, 2007 3:39 PM, Michael Stefaniuc <[EMAIL PROTECTED]> wrote:
> Alexandre,
>
> i'm unsure about this patch series. Yes this are simple wrappers around
> HeapAlloc() that are the same as the "standard" wrappers used in Wine.
> But they are used only as callbacks aka different usage.
>
I don
Vijay Kiran Kamuju wrote:
> On Nov 28, 2007 12:34 PM, Michael Stefaniuc <[EMAIL PROTECTED]> wrote:
>> Maarten Lankhorst wrote:
>>> Stefan Dösinger schreef:
What do we do if there's a d3dx9_37.dll next month?
>>> One thing that comes to mind is: git-mv d3dx9_36 d3dx9_37 and create a
>>> fo
On Nov 26, 2007 4:49 PM, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote:
> Hi Lei,
>
> I think a new file for user dir look up in the shell32 is of no use.
> Rather than we can add it to the xdg.c and xdg.h, as it contains the
> generic xdg code for shell32.
> Its like having all xdg specific code at
On Nov 28, 2007 12:34 PM, Michael Stefaniuc <[EMAIL PROTECTED]> wrote:
> Maarten Lankhorst wrote:
> > Stefan Dösinger schreef:
> >> What do we do if there's a d3dx9_37.dll next month?
> >>
> > One thing that comes to mind is: git-mv d3dx9_36 d3dx9_37 and create a
> > forward dll for the old one.
>
Maarten Lankhorst wrote:
> Stefan Dösinger schreef:
>> What do we do if there's a d3dx9_37.dll next month?
>>
> One thing that comes to mind is: git-mv d3dx9_36 d3dx9_37 and create a
> forward dll for the old one.
Renames are "cheap" in git and we do not loose the history.
bye
michael
-
Hello Stefan,
Stefan Dösinger schreef:
> What do we do if there's a d3dx9_37.dll next month?
>
One thing that comes to mind is: git-mv d3dx9_36 d3dx9_37 and create a
forward dll for the old one.
Cheers,
Maarten
Am Mittwoch, 28. November 2007 18:14:21 schrieb [EMAIL PROTECTED]:
> Following Alexandre (and I agree with him :D ), one only needs to
> export the functions of d3dx9_36 (the latest one) to the older
> d3dx9_xx dlls.
> So, we just just need to implement the functions in the d3dx9_36 dll
> repertor
Following Alexandre (and I agree with him :D ), one only needs to
export the functions of d3dx9_36 (the latest one) to the older
d3dx9_xx dlls.
So, we just just need to implement the functions in the d3dx9_36 dll
repertory.
No wine_d3dx9 is useful.
David
Misha Koshelev <[EMAIL PROTECTED]> writes:
> The previous patch was last week I think. This fixes a Valgrind error in the
> test. This is
> correct as vtResult is just hte _expected_ return type, and this way we check
> the actual return type
> (new this version) and then the validity of the po
Roy Shea <[EMAIL PROTECTED]> writes:
> This is another revised and standalone version of the svchost patch.
> Changes in this revision include:
>
> - Only using HEAP_ZERO_MEMORY in calls to HeapReAlloc. Calls to
> HeapAlloc explicitly set the NULL terminator when required.
The realloc is overk
Robert Shearman <[EMAIL PROTECTED]> writes:
> diff --git a/dlls/ole32/tests/usrmarshal.c b/dlls/ole32/tests/usrmarshal.c
> index 9959f74..5819ec1 100644
> --- a/dlls/ole32/tests/usrmarshal.c
> +++ b/dlls/ole32/tests/usrmarshal.c
> @@ -801,9 +801,9 @@ static void test_marshal_WdtpInterfacePointer(v
Am Mittwoch, 28. November 2007 09:17:04 schrieb [EMAIL PROTECTED]:
> Anyways, where should we put the d3dx9 code? I mean, we have 13 folders to
> choose from.. Perhaps It'd be better if we create a new dll (or at least
> directory) called d3dx9 were we implement all d3dx9 stuff and let the other
>
Am Mittwoch, 28. November 2007 09:40:29 schrieb H. Verbeet:
> On 27/11/2007, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
>
> Don't you need to mark the sampler dirty if it's bound somewhere? Or
> is it guaranteed it never is at that point?
This is done by the CTXUSAGE_BLIT setup
signature.asc
Desc
On 27/11/2007, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
>
Don't you need to mark the sampler dirty if it's bound somewhere? Or
is it guaranteed it never is at that point?
On 27/11/2007, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> textures. In this case we build a texture map to read a texture from a
> lower texture unit from a higher register combiner. This texture unit
> always stays below GL_LIMITS(textures) though.
Yes, but you're checking against the sampler, n
Anyways, where should we put the d3dx9 code? I mean, we have 13 folders to
choose from.. Perhaps It'd be better if we create a new dll (or at least
directory) called d3dx9 were we implement all d3dx9 stuff and let the other
d3dx9_xx dlls just call these functions? This would improve the clarity
19 matches
Mail list logo
