On Sat, Jul 26, 2008 at 5:34 PM, H. Verbeet <[EMAIL PROTECTED]> wrote:
> 2008/7/26 Allan Tong <[EMAIL PROTECTED]>:
>> You could try the attached hack patch to see if it fixes the problem
>> you're seeing. It completely ignores FBO cleanup, but it should avoid
>> the driver bug.
>>
> It's not *that
John Klehm wrote:
> On Sat, Jul 26, 2008 at 8:25 PM, Chris Ahrendt <[EMAIL PROTECTED]> wrote:
>> Attached to this note is a patch I have been working on for the past few
>> days to finish out the above function.
>> What I did was use MSDN for the definition :
>>
>
> Copyright issues ensue when yo
On Sat, Jul 26, 2008 at 8:25 PM, Chris Ahrendt <[EMAIL PROTECTED]> wrote:
> Attached to this note is a patch I have been working on for the past few
> days to finish out the above function.
> What I did was use MSDN for the definition :
>
Copyright issues ensue when you copy and paste from MSDN.
Attached to this note is a patch I have been working on for the past
few days to finish out the above function.
What I did was use MSDN for the definition :
/*
* Get / Set Render States
* TODO: Verify against dx9 definitions
*
Direct X 9 Definition:
Parameters
State
[in] Device s
2008/7/26 Allan Tong <[EMAIL PROTECTED]>:
> You could try the attached hack patch to see if it fixes the problem
> you're seeing. It completely ignores FBO cleanup, but it should avoid
> the driver bug.
>
It's not *that* easy. You'll need to adjust the code in
apply_fbo_state() as well. fbo_color_
On Sat, Jul 26, 2008 at 3:39 PM, H. Verbeet <[EMAIL PROTECTED]> wrote:
> 2008/7/26 Vitaliy Margolen <[EMAIL PROTECTED]>:
>> So if we need to create an fbo for each thread, does that mean that
>> everything needs to be rebound to it on the context switch?
>>
> It would mostly mean that apply_fbo_sta
2008/7/26 Vitaliy Margolen <[EMAIL PROTECTED]>:
> So if we need to create an fbo for each thread, does that mean that
> everything needs to be rebound to it on the context switch?
>
It would mostly mean that apply_fbo_state() would need to track things
per-context rather than per-device. I guess th
On Friday 25 July 2008 22:13:18 Zac Brown wrote:
> +#include
>
> #include
> #include
> +#include
You shouldn't need these.
-Hans
Allan Tong wrote:
> On Sat, Jul 26, 2008 at 1:48 AM, H. Verbeet <[EMAIL PROTECTED]> wrote:
>> 2008/7/25 Vitaliy Margolen <[EMAIL PROTECTED]>:
>>> So it seems the FBOs are created in one thread used there, then
>>> rebounding in the new thread leads to the crash.
>>>
>>> Any ideas how to fix this? O
On Sat, Jul 26, 2008 at 1:48 AM, H. Verbeet <[EMAIL PROTECTED]> wrote:
> 2008/7/25 Vitaliy Margolen <[EMAIL PROTECTED]>:
>> So it seems the FBOs are created in one thread used there, then
>> rebounding in the new thread leads to the crash.
>>
>> Any ideas how to fix this? Or what to try?
>>
> AFAIK
Vitaliy Margolen ha scritto:
> Max wrote:
>> Vitaliy Margolen ha scritto:
>>> Massimo Del Fedele wrote:
Maybe that's an already asked question, but why does wine reset
path on each wine update ? That's becoming annoying... I mus reedit
registry on each update to make my apps wo
Max wrote:
> Vitaliy Margolen ha scritto:
>> Massimo Del Fedele wrote:
>>> Maybe that's an already asked question, but why does wine reset
>>> path on each wine update ? That's becoming annoying... I mus reedit
>>> registry on each update to make my apps work again.
>>>
>> Which "path" are yo
Max wrote:
> Vitaliy Margolen ha scritto:
>> Massimo Del Fedele wrote:
>>> Maybe that's an already asked question, but why does wine reset
>>> path on each wine update ? That's becoming annoying... I mus reedit
>>> registry on each update to make my apps work again.
>>>
>> Which "path" are yo
THE 'path', the one set in window's environment, the one windows uses to
look for executables.
Upon wine update, when wineprefix gets updated the path is reset to
default one (IIRC c:\\windows;c:\\windows\\system32)
I didn't open a bug because I don't know if it's a bug or a required
behaviour.
Massimo Del Fedele wrote:
> Maybe that's an already asked question, but why does wine reset path
> on each wine update ? That's becoming annoying... I mus reedit registry
> on each update to make my apps work again.
>
Which "path" are you talking about? Please open a bug.
Vitaliy
Austin English wrote:
> On Fri, Jul 25, 2008 at 8:12 PM, Mathias Karwath
> <[EMAIL PROTECTED]> wrote:
>> Hi, im from Germany and i would use iTunes with the iPod Touch. I saw a
>> Post on the Mailing list that its possible to Sync the Touch over iTunes
>> using wine, but its not implemented yet.
>>
On Fri, Jul 25, 2008 at 8:12 PM, Mathias Karwath
<[EMAIL PROTECTED]> wrote:
> Hi, im from Germany and i would use iTunes with the iPod Touch. I saw a
> Post on the Mailing list that its possible to Sync the Touch over iTunes
> using wine, but its not implemented yet.
>
> Is it possible to get the P
Maybe that's an already asked question, but why does wine reset path
on each wine update ? That's becoming annoying... I mus reedit registry
on each update to make my apps work again.
Ciao
Max
Hi, im from Germany and i would use iTunes with the iPod Touch. I saw a
Post on the Mailing list that its possible to Sync the Touch over iTunes
using wine, but its not implemented yet.
Is it possible to get the Patches? Im suck of using iTunes in a VM with
Windows on my System. So i would like to
Hi,
Paul Millar wrote:
> As an aside: this looks to me like a logical fallacy. If I may rephrase your
> argument:
> 1. Most signed software is from a large code-base (probably true)
> 2. Large code-bases are more likely to have vulnerabilities (probably true)
> 3. Therefore, signed softwar
Am Freitag, den 25.07.2008, 22:50 +0800 schrieb Huang, Zhangrong:
> > ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p
> > gdi32_test.exe.so font.c && touch font.ok
> > font.c:850: Test succeeded inside todo block: data index 2: expected font
> > codepage 1252, got 1252
> > font.c:85
2008/7/25 Vitaliy Margolen <[EMAIL PROTECTED]>:
> Ok I think I see the problem:
> 0045:trace:d3d_surface:surface_load_ds_location before bind_fbo
> 0045:trace:d3d:bind_fbo 0x14f474 -> 0
> 0045:trace:d3d:bind_fbo glGenFramebuffersEXT() -> 2 @
> ../../../wine.git/dlls/wined3d/device.c:6084 call ok
>
Hi, and sorry for missing this mail and responding late,
My project to implement PrintDlgEx() has been going well in that I've
implemented everything but the custom property pages feature (and ANSI
support). Therefore, at this point, my main challenge is to implement
this feature and to ensure goo
H. Verbeet wrote:
> 2008/7/25 Vitaliy Margolen <[EMAIL PROTECTED]>:
>> BTW this is a driver crash in libglcore.so with what appears to be a
>> null-pointer dereference. I'm trying to play with your code to see how to
>> "fix" it.
>>
> Thanks.
Ok I think I see the problem:
0045:trace:d3d_surface:su
> Security often involves providing many barriers. There's a tacit assumption
> that none are going to be perfect. A common mantra is "security in depth".
Sure. It's just my professional opinion that a signature on an
application provides no security. Zip, nada. It does give you some
assuranc
Hi Juan,
On Friday 25 July 2008 16:49:34 Juan Lang wrote:
[...]
> > Please, either tell me I'm wrong, or make Wine honest about what it's
> > telling the user.
>
> No, you're not wrong, and this email was my attempt at being honest.
... and your honesty is appreciated!
> I'll point out that ther
26 matches
Mail list logo
