André Hentschel wrote:
> - Design similar to ntdll/tests/error.c
> - Passes all Machines on WTB
> - with check for existance of function
> - just the known 2 instead of 4510
> - intendation for todo_wine choosen so that it can be easy removed without
> touching the tests
You need to test Compar
I noticed a problem with the icons in Wine when alt+tabbing today. After
doing a regression test it appears that commit
c29cf0591976f96c3adb30c3c3b6db59f4983251 results in pixmaps that do not
always display properly when alt+tabbing (see attached screenshot).
Erich Hoover
ehoo...@mines.edu
<>
Nikolay Sivov schrieb:
> On 4/14/2010 22:51, André Hentschel wrote:
>> case 0x3: /* TTT TTTDD TTTDDD */
>> - if (iDate&& dp.dwCount == 3)
>> + if (dp.dwCount == 3&& !strncmp(ShortDate,"dd.MM.yy",8))
>>
>>
>
>> case 0x1B: /* localized DDDTTT */
>> - if (!iDate)
>> +
On 04/14/2010 09:24 PM, Maarten Lankhorst wrote:
---
I cannot query the version string unless a device context is created.
Since OpenAL-1.12 added support for thread local contexts I use that to
determine whether pulseaudio should be ignored or not. OpenAL 1.10 and
older will crash on pulseaudio.
On 4/14/2010 22:51, André Hentschel wrote:
case 0x3: /* TTT TTTDD TTTDDD */
- if (iDate&& dp.dwCount == 3)
+ if (dp.dwCount == 3&& !strncmp(ShortDate,"dd.MM.yy",8))
case 0x1B: /* localized DDDTTT */
- if (!iDate)
+ if (strncmp(ShortDate,"dd.MM.yy",8))
On Wed, Apr 14, 2010 at 8:35 PM, frechdachs69
wrote:
> Am Mittwoch, 24. März 2010 19:49:46 schrieb Damjan Jovanovic:
>> On Wed, Mar 24, 2010 at 8:30 PM, Alexandre Julliard
> wrote:
>> > Damjan Jovanovic writes:
>> >> Changelog:
>> >> * usbhub.sys: add stubbed usbhub.sys
>> >
>> > What is this go
On Apr 14, 2010, at 1:48 PM, Matijn Woudt wrote:
>> I think you want to test if the compiled shader works instead of the
>> exact bytecode. Generating the same bytecode is probably way too hard,
>> fragile to test, and most likely not worth the effort.
>
> I think I should go for exact bytecode a
Am Mittwoch, 24. März 2010 19:49:46 schrieb Damjan Jovanovic:
> On Wed, Mar 24, 2010 at 8:30 PM, Alexandre Julliard
wrote:
> > Damjan Jovanovic writes:
> >> Changelog:
> >> * usbhub.sys: add stubbed usbhub.sys
> >
> > What is this going to be useful for?
> >
> > --
> > Alexandre Julliard
> > jul
Am 14.04.2010 um 19:29 schrieb Henri Verbeet:
> I think you want to test if the compiled shader works instead of the
> exact bytecode. Generating the same bytecode is probably way too hard,
> fragile to test, and most likely not worth the effort.
Yep, comparing generated bytecode is not going to w
On Wed, Apr 14, 2010 at 7:30 PM, Roderick Colenbrander
wrote:
> On Wed, Apr 14, 2010 at 7:22 PM, Matijn Woudt wrote:
>> On Wed, Apr 14, 2010 at 6:47 PM, Matteo Bruni
>> wrote:
dlls/wineshader doesn't exist in that tree?
>>>
>>> Check if you are in the correct branch (should be the "co
On Wed, Apr 14, 2010 at 7:29 PM, Henri Verbeet wrote:
> On 14 April 2010 17:19, Matijn Woudt wrote:
>> I have thought about using LLVM, but I don't like it because of:
>> 1) Having another wine dependency (~40MB for me on ubuntu)
>> 2) Code generated by LLVM will most likely not generated exactly
On Wed, Apr 14, 2010 at 7:22 PM, Matijn Woudt wrote:
> On Wed, Apr 14, 2010 at 6:47 PM, Matteo Bruni
> wrote:
>>> dlls/wineshader doesn't exist in that tree?
>>>
>>
>> Check if you are in the correct branch (should be the "compiler"
>> branch in his tree).
>>
>
> Right, my mistake.
>
Lastly
On 14 April 2010 17:19, Matijn Woudt wrote:
> I have thought about using LLVM, but I don't like it because of:
> 1) Having another wine dependency (~40MB for me on ubuntu)
> 2) Code generated by LLVM will most likely not generated exactly the
> same bytecode as native compiler does, even though th
On Wed, Apr 14, 2010 at 6:47 PM, Matteo Bruni wrote:
>> dlls/wineshader doesn't exist in that tree?
>>
>
> Check if you are in the correct branch (should be the "compiler"
> branch in his tree).
>
Right, my mistake.
>>> Lastly, a bit on testing the compiler. I'm not sure trying to get
>>> exactl
Luis Busquets wrote:
Could someone please confirm the following points?:
2. Integration of DosBOX or other emulator. How this will be done? Is
the plan to use them when wine detects that the programme is compiled
for real mode? Does that mean that the sake of wine is to provide
compatibility
On 4/14/10 10:36 AM, Reece Dunn wrote:
> On 14 April 2010 16:19, Matijn Woudt wrote:
>> I have thought about using LLVM, but I don't like it because of:
>> 1) Having another wine dependency (~40MB for me on ubuntu)
>> 2) Code generated by LLVM will most likely not generated exactly the
>> same byt
> dlls/wineshader doesn't exist in that tree?
>
Check if you are in the correct branch (should be the "compiler"
branch in his tree).
>> Lastly, a bit on testing the compiler. I'm not sure trying to get
>> exactly the same bytecode as native is a feasible objective: while for
>> an assembler prog
On Wed, Apr 14, 2010 at 10:19 AM, Alexandre Julliard
wrote:
> Austin English writes:
>
>> Clang defaults to compiling in C99 mode, which breaks the compile.
>
> Of course the compile should be fixed instead.
Not entirely trivial, since the compile is broken for gcc in c99 mode as well:
http://bu
On 14 April 2010 16:19, Matijn Woudt wrote:
> I have thought about using LLVM, but I don't like it because of:
> 1) Having another wine dependency (~40MB for me on ubuntu)
> 2) Code generated by LLVM will most likely not generated exactly the
> same bytecode as native compiler does, even though th
On Wed, Apr 14, 2010 at 5:59 PM, Matteo Bruni wrote:
> 2010/4/14 Matijn Woudt :
>> On Wed, Apr 14, 2010 at 4:27 PM, Stefan Dösinger
>> wrote:
>>>
>>> Am 14.04.2010 um 15:44 schrieb Henri Verbeet:
>>>
On 14 April 2010 15:07, Stefan Dösinger wrote:
>> 3) Implement the compiler in d3dcomp
2010/4/14 Matijn Woudt :
> On Wed, Apr 14, 2010 at 4:27 PM, Stefan Dösinger
> wrote:
>>
>> Am 14.04.2010 um 15:44 schrieb Henri Verbeet:
>>
>>> On 14 April 2010 15:07, Stefan Dösinger wrote:
> 3) Implement the compiler in d3dcompiler_xx.
I wrote a basic HLSL compiler as university proje
On 4/13/10 11:49 PM, Detlef Riekenberg wrote:
---
dlls/urlmon/tests/sec_mgr.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/dlls/urlmon/tests/sec_mgr.c b/dlls/urlmon/tests/sec_mgr.c
index e758115..8e39301 100644
--- a/dlls/urlmon/tests/sec_mgr.c
+++
On Wed, Apr 14, 2010 at 5:19 PM, Matijn Woudt wrote:
> On Wed, Apr 14, 2010 at 4:51 PM, Roderick Colenbrander
> wrote:
>> On Wed, Apr 14, 2010 at 4:38 PM, Matijn Woudt wrote:
>>> On Wed, Apr 14, 2010 at 4:27 PM, Stefan Dösinger
>>> wrote:
Am 14.04.2010 um 15:44 schrieb Henri Verbeet:
Austin English writes:
> Clang defaults to compiling in C99 mode, which breaks the compile.
Of course the compile should be fixed instead.
--
Alexandre Julliard
julli...@winehq.org
On Wed, Apr 14, 2010 at 4:51 PM, Roderick Colenbrander
wrote:
> On Wed, Apr 14, 2010 at 4:38 PM, Matijn Woudt wrote:
>> On Wed, Apr 14, 2010 at 4:27 PM, Stefan Dösinger
>> wrote:
>>>
>>> Am 14.04.2010 um 15:44 schrieb Henri Verbeet:
>>>
On 14 April 2010 15:07, Stefan Dösinger wrote:
>
On Wed, Apr 14, 2010 at 4:38 PM, Matijn Woudt wrote:
> On Wed, Apr 14, 2010 at 4:27 PM, Stefan Dösinger
> wrote:
>>
>> Am 14.04.2010 um 15:44 schrieb Henri Verbeet:
>>
>>> On 14 April 2010 15:07, Stefan Dösinger wrote:
> 3) Implement the compiler in d3dcompiler_xx.
I wrote a basic HLSL
On Wed, Apr 14, 2010 at 4:27 PM, Stefan Dösinger wrote:
>
> Am 14.04.2010 um 15:44 schrieb Henri Verbeet:
>
>> On 14 April 2010 15:07, Stefan Dösinger wrote:
3) Implement the compiler in d3dcompiler_xx.
>>> I wrote a basic HLSL compiler as university project in 2008, this is where
>>> part
Am 14.04.2010 um 15:44 schrieb Henri Verbeet:
> On 14 April 2010 15:07, Stefan Dösinger wrote:
>>> 3) Implement the compiler in d3dcompiler_xx.
>> I wrote a basic HLSL compiler as university project in 2008, this is where
>> part of the assembler code came from. Do you have the sources, do you
On 14 April 2010 15:07, Stefan Dösinger wrote:
>> 3) Implement the compiler in d3dcompiler_xx.
> I wrote a basic HLSL compiler as university project in 2008, this is where
> part of the assembler code came from. Do you have the sources, do you need
> them?
>
Quite frankly, I also believe that's
On Wed, Apr 14, 2010 at 3:07 PM, Stefan Dösinger wrote:
>
> Am 14.04.2010 um 13:08 schrieb Matijn Woudt:
>> 2) Move the assembler to d3dcompiler_xx.dll and forward calls from
>> d3dx9. This is needed because the assembler and compiler can share the
>> same bytecode writer this way.
> When Mattheo
Am 14.04.2010 um 13:08 schrieb Matijn Woudt:
> 2) Move the assembler to d3dcompiler_xx.dll and forward calls from
> d3dx9. This is needed because the assembler and compiler can share the
> same bytecode writer this way.
When Mattheo implemented the assembler in the gsoc project we decided to put
Joel Holdsworth wrote:
> Hi Joel,
>
> I think this has been mentioned before, but the monitor icons (32-bit
> and 8-bit for size 32) show a wider lower half of the monitor compared
> to the upper half (I think the 32-bit size 22 as well).
>
I've heard feedback about the screen colour befor
On 04/14/2010 02:04 PM, Joel Holdsworth wrote:
> Hi Joel,
>
> I think this has been mentioned before, but the monitor icons (32-bit
> and 8-bit for size 32) show a wider lower half of the monitor compared
> to the upper half (I think the 32-bit size 22 as well).
>
I've heard feedback ab
> Hi Joel,
>
> I think this has been mentioned before, but the monitor icons (32-bit
> and 8-bit for size 32) show a wider lower half of the monitor compared
> to the upper half (I think the 32-bit size 22 as well).
>
I've heard feedback about the screen colour before, which I've resolved. Nev
On 04/14/2010 01:41 PM, Paul Vriens wrote:
On 04/13/2010 10:59 PM, Joel Holdsworth wrote:
Signed-off-by: Joel Holdsworth
---
dlls/shell32/mycomputer.ico | Bin 15086 -> 25214 bytes
dlls/shell32/mycomputer.svg | 2400
++-
2 files changed, 1477 insertions(+),
On 04/13/2010 10:59 PM, Joel Holdsworth wrote:
Signed-off-by: Joel Holdsworth
---
dlls/shell32/mycomputer.ico | Bin 15086 -> 25214 bytes
dlls/shell32/mycomputer.svg | 2400 ++-
2 files changed, 1477 insertions(+), 923 deletions(-)
Hi Joel,
I
On 14 April 2010 13:08, Matijn Woudt wrote:
> Hi,
>
> I'm about to implement the HLSL compiler, but I want to make sure I'm
> taking the right direction.
> For the compiler:
> preprocessor(wpp)->hlslparser/compiler(lex/bison)->bytecode
> writer(same as for the shader assembler).
> Now the question
Hi,
I'm about to implement the HLSL compiler, but I want to make sure I'm
taking the right direction.
For the compiler:
preprocessor(wpp)->hlslparser/compiler(lex/bison)->bytecode
writer(same as for the shader assembler).
Now the question is where to implement the compiler. It can be called
from a
On 14 April 2010 11:08, Florian Köberle wrote:
> You have worked on quite a few bugs I have voted for. Would be buying
> Crossover Games (again) the correct way to support your work?
>
In principle, yes. Though in all fairness it should also be noted that
Wine is the work of many people, not all o
On 14 April 2010 11:52, Stefan Dösinger wrote:
> Am 13.04.2010 um 23:51 schrieb Henri Verbeet:
>> I'm not sure I see how that's going to make things better.
> Well, mostly to have the sync conditions and the way we sync in a single
> place. That'll make it easier to use more suited GL methods to
Am 13.04.2010 um 23:51 schrieb Henri Verbeet:
> On 13 April 2010 23:13, Stefan Dösinger wrote:
>> Am 13.04.2010 um 20:46 schrieb Henri Verbeet:
>>> +if (wined3d_settings.strict_draw_ordering) wglFlush(); /* Flush to
>>> ensure ordering across contexts. */
>> I'd prefer to have this in an (i
Hello Henri,
your patch fixes bug 12611:
http://bugs.winehq.org/show_bug.cgi?id=12611
Thanks for your great work!
You have worked on quite a few bugs I have voted for. Would be buying
Crossover Games (again) the correct way to support your work?
Best regards,
Florian
Damjan Jovanovic wrote:
> On Wed, Apr 14, 2010 at 6:35 AM, Luis Busquets
> wrote:
>> Could someone please confirm the following points?:
>>
>
>> 2. Integration of DosBOX or other emulator. How this will be done? Is the
>> plan to use them when wine detects that the programme is compiled for real
On Wed, Apr 14, 2010 at 6:35 AM, Luis Busquets
wrote:
> Could someone please confirm the following points?:
>
> 2. Integration of DosBOX or other emulator. How this will be done? Is the
> plan to use them when wine detects that the programme is compiled for real
> mode? Does that mean that the sa
On Wed, Apr 14, 2010 at 1:52 AM, John Klehm wrote:
> On Wed, Apr 14, 2010 at 1:46 AM, Tom Wickline wrote:
>>
>> Wine also runs on BSD and OpenSolaris, so if OSS was removed it would kill
>> sound support on these platforms.
>>
>
> Doesn't openal support bsd and solaris too?
> http://connect.creat
45 matches
Mail list logo
