On Jan 28, 2010, at 5:21 PM, Michael Stefaniuc wrote:
> On 01/28/2010 10:59 PM, Henri Verbeet wrote:
>> On 28 January 2010 22:39, Stefan Leichter
>> wrote:
>>> Is this a know problem? Is a work around available?
>>>
>> Yeah, that's a known problem. As a workaround you can use ">>"
>> (append) i
On 29 January 2010 00:21, Michael Stefaniuc wrote:
> On 01/28/2010 10:59 PM, Henri Verbeet wrote:
>>
>> On 28 January 2010 22:39, Stefan Leichter
>> wrote:
>>>
>>> Is this a know problem? Is a work around available?
>>>
>> Yeah, that's a known problem. As a workaround you can use ">>"
>> (append)
On 29 January 2010 00:28, Juan Lang wrote:
>> When submitting multiple patches that apply to the same component but
>> each patch is unrelated (ie. each one fixes a different issue), is it
>> still appropriate to label the patches with the [PATCH X/Y] notation?
>> In the case I have at hand the pa
On 29 January 2010 00:27, Stefan Dösinger wrote:
> Please use the number of texture blend stages reported from the fragment
> pipeline rather than gl_limits.texture_stages. texture_stages only works with
> the nvrc and ffp pipelines, but not arbfp or atifs(it works out ok by chance
> on most GL ca
srrose wrote:
> What does this mean? Iim using a USB 2.0 Flash Drive and a LAUNCHU3.EXE
> file says it is linked to a missing export. It then says
> KERNEL32.DLL:GetVolumeMountPointW.
> Can you help me? Thank you!!
Yes... but you're on the wrong list. User questions need to go to
wine-users.
On 01/29/2010 12:23 AM, Nikolay Sivov wrote:
On 1/29/2010 02:21, Michael Stefaniuc wrote:
For the winefixme collector i have the luxury to be able to ignore the
mangled output lines; not so much for the wineoops crash collector.
Btw, are they ready and hosted somewhere already?
winefixme is "
On 01/29/2010 12:26 AM, Erich Hoover wrote:
When submitting multiple patches that apply to the same component but
each patch is unrelated (ie. each one fixes a different issue), is it
still appropriate to label the patches with the [PATCH X/Y] notation?
In the case I have at hand the patches are
> When submitting multiple patches that apply to the same component but
> each patch is unrelated (ie. each one fixes a different issue), is it
> still appropriate to label the patches with the [PATCH X/Y] notation?
> In the case I have at hand the patches are even for different files of
> the same
On Thursday 28 January 2010 23:40:25 Henri Verbeet wrote:
> +static void prune_invalid_states(struct StateEntry *state_table, const
> struct wined3d_gl_info *gl_info) +{
> +unsigned int start, last, i;
> +
> +start = STATE_TEXTURESTAGE(gl_info->limits.texture_stages, 0);
> +last = STAT
When submitting multiple patches that apply to the same component but
each patch is unrelated (ie. each one fixes a different issue), is it
still appropriate to label the patches with the [PATCH X/Y] notation?
In the case I have at hand the patches are even for different files of
the same component
On 1/29/2010 02:21, Michael Stefaniuc wrote:
For the winefixme collector i have the luxury to be able to ignore the
mangled output lines; not so much for the wineoops crash collector.
Btw, are they ready and hosted somewhere already?
bye
michael
On 01/28/2010 10:59 PM, Henri Verbeet wrote:
On 28 January 2010 22:39, Stefan Leichter wrote:
Is this a know problem? Is a work around available?
Yeah, that's a known problem. As a workaround you can use ">>"
(append) instead of ">" to redirect to the file. You'll still need the
"2>&1" to red
On 29 January 2010 00:14, Ben Klein wrote:
> 2010/1/29 Henri Verbeet :
>> On 28 January 2010 22:39, Stefan Leichter
>> wrote:
>>> Is this a know problem? Is a work around available?
>>>
>> Yeah, that's a known problem. As a workaround you can use ">>"
>> (append) instead of ">" to redirect to th
2010/1/29 Henri Verbeet :
> On 28 January 2010 22:39, Stefan Leichter wrote:
>> Is this a know problem? Is a work around available?
>>
> Yeah, that's a known problem. As a workaround you can use ">>"
> (append) instead of ">" to redirect to the file. You'll still need the
> "2>&1" to redirect stde
What does this mean? Iim using a USB 2.0 Flash Drive and a LAUNCHU3.EXE file
says it is linked to a missing export. It then says
KERNEL32.DLL:GetVolumeMountPointW.
Can you help me? Thank you!!
srr...@commspeed.net
On 28 January 2010 22:39, Stefan Leichter wrote:
> Is this a know problem? Is a work around available?
>
Yeah, that's a known problem. As a workaround you can use ">>"
(append) instead of ">" to redirect to the file. You'll still need the
"2>&1" to redirect stderr to stdout, of course.
Hello,
does anyone notice a problem that the lines of the logging are written over
each other as in the attached log?
My system has an AMD Phenom(tm) II X2 550 Processor on a NVIDIA GeForce 8300
Chipset running running Debian Lenny 32 bit
Is this a know problem? Is a work around available?
--
Does anyone have any comments on this please?
-- Forwarded message --
From: Jason Edmeades
Date: Wed, Jan 27, 2010 at 1:09 AM
Subject: Loader, mapping and sharing issues with main exe
To: wine-devel@winehq.org
Hello,
I've been debugging a problem with an application which check
On 01/28/2010 09:25 PM, Henri Verbeet wrote:
> On 28 January 2010 20:15, Arjun Comar wrote:
>> Ah, I wasn't going to do it as a SoC project, but rather as a way to get a
>> feel for wine, directx, etc. over the next couple months (leading up to
>> SoC). Henri is suggesting that I not do so?
>>
> I
On 28 January 2010 20:15, Arjun Comar wrote:
> Ah, I wasn't going to do it as a SoC project, but rather as a way to get a
> feel for wine, directx, etc. over the next couple months (leading up to
> SoC). Henri is suggesting that I not do so?
>
I think anyone would have a hard time getting those co
On 01/28/2010 08:15 PM, Arjun Comar wrote:
> Ah, I wasn't going to do it as a SoC project, but rather as a way to get
> a feel for wine, directx, etc. over the next couple months (leading up
> to SoC). Henri is suggesting that I not do so?
>
> Anyway, if there are no objections, I'm willing to do
Paul Vriens a écrit :
On 01/27/2010 04:41 PM, joerg-cyril.hoe...@t-systems.com wrote:
Hi,
my (unreleased) MIDI tests have spotted that not all versions of
MS-Windows
seem to send out the MM_MOM_POSITIONCB callback/notification
resulting from
a MEVT_F_CALLBACK event in midiStreamOut(). w9X/M
Am 28.01.2010 20:38, schrieb Reece Dunn:
> There is already support for WIC codecs by Vincent Povirk that has
> been committed into wine, supporting bmp, jpeg, gif, png and other
> formats.
>
> I don't know how complete this is, though, for what D3DX needs.
>
> - Reece
>
>
yeah, the plan was to
On 28 January 2010 19:25, Tony Wasserka wrote:
> Just btw, those depend on D3DXGetImageInfoFromMemory, D3DXFilterTexture,
> D3DXCreateTexture and possibly others I can't think of right now.
> D3DXFilterTexture is quite trivial, but the other two also add a notable
> effort. On the other hand, I ha
Am 28.01.2010 19:46, schrieb Loïc Hoguin:
> If a student wishes to do the integration work as a SoC project, then
> I'll step down. It'll certainly be more helpful for a student than for
> me. I can find another project to work on in that case.
>
>
Not sure whether integration of my work is stil
Ah, I wasn't going to do it as a SoC project, but rather as a way to get a
feel for wine, directx, etc. over the next couple months (leading up to
SoC). Henri is suggesting that I not do so?
Anyway, if there are no objections, I'm willing to do it. Loic, you probably
have more experience, I'll ced
On 01/28/2010 06:33 PM, Tony Wasserka wrote:
> About my own work, it's not been integrated that much, yet: Loïc Hoguin
> has expressed interest to integrate them, but I'm not sure whether he
> was sure about that, yet.
> I might work again on integrating my texture stuff in case you'd really
> par
2010/1/28 Tony Wasserka :
> Henri: I'm not sure whether the D3DX9 interface _depends_ on the HLSL
> compiler; maybe the bytecode effect compiler does, but there's plenty of
The effect compiler does, you can use embedded HLSL or assembly in
effects. You can skip implementing the compiler of course,
About my own work, it's not been integrated that much, yet: Loïc Hoguin
has expressed interest to integrate them, but I'm not sure whether he
was sure about that, yet.
I might work again on integrating my texture stuff in case you'd really
participate in gsoc with some d3dx stuff, can't promise an
Paul Vriens wrote:
> Doesn't the DXGI_ERROR_NOT_FOUND return value tell us there is no D3D10
> capable adapter (instead of any adapter)?
>
Possibly, but my understanding was that on Vista and higher DXGI is
shared across pretty much the entire graphics subsystem.
Henri
On 01/28/2010 05:14 PM, Henri Verbeet wrote:
Paul Vriens wrote:
Hi,
On VMware with the "Standard VGA" adapter and on VirtualBox there are no
adapters returned when enumerating.
I didn't use broken() as 'no adapters' seems somehow a valid return
(added Henri to the cc: to prove me wrong). There
2010/1/28 Stefan Dösinger :
> On Wednesday 27 January 2010 23:41:27 Henri Verbeet wrote:
>> The problem with the effect interface is that there are several fairly
>> large parts/dependencies to implement. For example, it has important
>> dependencies on both the (non-existent) HLSL compiler and the
On Thursday 28 January 2010 16:05:58 Mihai Donțu wrote:
> Hi,
>
> I use wine to run cl.exe and build some dll-s. However, each time make
> invokes wine, my mouse short-jumps from one position to another or stops
> responding for a brief period of time. Is there any way to tell wine to
> skip an
Hi,
I use wine to run cl.exe and build some dll-s. However, each time make invokes
wine, my mouse short-jumps from one position to another or stops responding
for a brief period of time. Is there any way to tell wine to skip any GUI
initialization or to not touch the mouse?
Thanks,
--
Mihai
On Wednesday 27 January 2010 23:41:27 Henri Verbeet wrote:
> The problem with the effect interface is that there are several fairly
> large parts/dependencies to implement. For example, it has important
> dependencies on both the (non-existent) HLSL compiler and the only
> partially merged shader a
--- On Wed, 27/1/10, Alexandre Julliard wrote:
> The first step would probably be to explain why you need to
> have an app
> with the same name as an existing builtin.
ddiwrapper provides its own gdi32.dll.so winspool.drv.so , so that bitmap
generated by the host's ghostscript is fed into the p
On 28 January 2010 09:40, Stefan Dösinger wrote:
> Why do we have to do this even when there is only one context? In the event
> another context is created after the draw?
>
Yes.
> -if (SUCCEEDED(IWineD3DSurface_GetContainer((IWineD3DSurface *)target,
> &IID_IWineD3DSwapChain, (void **)&swapchain))) {
> -if (target == (IWineD3DSurfaceImpl*) swapchain->frontBuffer) {
> -wglFlush();
> -}
> -IWineD3DSwapChain_Release((IWineD3DSwapChain
38 matches
Mail list logo
