On Wed, Jan 28, 2009 at 04:44:44PM +0100, Henri Verbeet wrote:
> 2009/1/28 Claudio Ciccani :
>> I mean, you could implement a hardware based vertex blending routine
>> using a vertex shader and keep the software vertex blending routine in
>> case vertex programs are not supported by underlying hard
Reece Dunn wrote:
> Hi,
>
> The Wine tests are now passing on a Windows XP machine
> (http://test.winehq.org/data/4b27dfec939d131c9d7e09f97f14dfc7dabe8843/#group_XP).
> Two of the other four only have 2 or 3 failures.
>
> The 2003 group has 3 machines with 1 failure each (urlmon:protocol on
> one
On Thu, Jan 29, 2009 at 9:40 PM, Dmitry Timoshkov
wrote:
> The exception tests in ntdll is a nice example how to do that
> without hurting readability and maintainability.
Sure, it's doable, but after a while one's fingers begin
to bleed. It all depends on how much code we're talking
about, and
"Dan Kegel" wrote:
>>> Compiling DOS code to a .com file will produce a very small
>>> executable, then embedding it into the test, put it in %TEMP%,
>>> and exec should be trivial. No need for external tools IMO.
>>
>> I thought of that, it's tempting.
>>
>> But nasm is pretty common; I don't kn
On Thu, Jan 29, 2009 at 9:34 PM, Dan Kegel wrote:
>> Compiling DOS code to a .com file will produce a very small
>> executable, then embedding it into the test, put it in %TEMP%,
>> and exec should be trivial. No need for external tools IMO.
>
> I thought of that, it's tempting.
>
> But nasm is pr
On Thu, Jan 29, 2009 at 9:20 PM, Dmitry Timoshkov
wrote:
> Compiling DOS code to a .com file will produce a very small
> executable, then embedding it into the test, put it in %TEMP%,
> and exec should be trivial. No need for external tools IMO.
I thought of that, it's tempting.
But nasm is pret
On Fri, Jan 30, 2009 at 5:41 AM, Vitaliy Margolen
wrote:
> Luke Kenneth Casson Leighton wrote:
>> also note it's file descriptors not file handles
> There are no such thing as "handle" in *NIX world. The only thing matter is
> a file descriptor. But it's for files, directories, devices, etc.
>
> W
"Dan Kegel" wrote:
> Looking at http://bugs.winehq.org/show_bug.cgi?id=17181
> I get a feeling that we really need some
> testcases to verify we conform to the 16 bit MS-DOS
> API. Yeah, even though 16 bit is on the way out,
> there's still some use for a few win16 programs, and
> they use MS-D
2009/1/29 Dan Kegel :
> Wow, that's awesome! A day seven years in the making...
> 2009: the test suite passes for somebody besides Alexandre on Wine:
> http://www.winehq.org/wwn/355#Test%20Suite%20Passes!
We'll have a new link to WWN 356 for Test Suite Passes v2 : Windows Style :)
Congrats to t
Luke Kenneth Casson Leighton wrote:
> also note it's file descriptors not file handles
There are no such thing as "handle" in *NIX world. The only thing matter is
a file descriptor. But it's for files, directories, devices, etc.
Wine takes care of all the handles internally (one of the main tasks
This bug is related to that http://bugs.winehq.org/show_bug.cgi?id=17190
2009/1/29 Zachary Goldberg
> All,
>
> An interesting piece from Phoronix about new VirtualBox Direct3D
> support; which apparently uses WineD3D in the backend. I haven't
> noticed anything in particular but has Sun been fi
All,
An interesting piece from Phoronix about new VirtualBox Direct3D
support; which apparently uses WineD3D in the backend. I haven't
noticed anything in particular but has Sun been filing bugs / sending
patches?
http://www.phoronix.com/scan.php?page=news_item&px=NzAyNA
--Zach
Vincent Pelletier wrote:
> Hi.
>
> Windows supports setting force feedback effect gain at 2 levels:
> - device
> - effect
> There is support for the former on Linux, but not for the latter.
>
>
> + DWORD ff_gain;
> };
...
> + This->ff_gain = max(0, (int) pd->d
Wow, that's awesome! A day seven years in the making...
2002: the C test suite is started:
http://source.winehq.org/git/wine.git/?a=commit;h=caa03388b64f444f9b4ef664ec5039d5bf72
2003: winetest committed:
http://www.winehq.org/wwn/199#Winetest%20Integrated%20&%20Future%20Steps
2004: server
2009/1/29 Alex Villacís Lasso :
> Guillaume SH escribió:
>> Hi wine community,
>>
>> I took some time for reflexion following the thread "A step in the wrong
>> direction, in an ocean of steps in the right direction" and to the
>> explanations some of you kindly exposed to me.
>>
>> As a follow-up
Looking at http://bugs.winehq.org/show_bug.cgi?id=17181
I get a feeling that we really need some
testcases to verify we conform to the 16 bit MS-DOS
API. Yeah, even though 16 bit is on the way out,
there's still some use for a few win16 programs, and
they use MS-DOS for file I/O.
We could merge
Hi,
The Wine tests are now passing on a Windows XP machine
(http://test.winehq.org/data/4b27dfec939d131c9d7e09f97f14dfc7dabe8843/#group_XP).
Two of the other four only have 2 or 3 failures.
The 2003 group has 3 machines with 1 failure each (urlmon:protocol on
one, user32:menu on the others).
Con
Hi Paul,
I'm just sending a patch to fix that. Thanks for spotting.
Bye,
Christian
Paul Vriens a écrit :
>
> Christian Costa wrote:
>>
>>
>>
>>
>>
> Hi Christian,
>
> + if ((token != TOKEN_SEMICOLON) && (token != TOKEN
2009/1/29 :
> Hi, I've been lurking on this list for awhile, thinking about how I could
> contribute to Wine.
>
> I wanted to weigh in because I think this overall proposal is on the right
> track. Graceful handling of errors and crashes would provide a better user
> experience and potentially he
On Thu, Jan 29, 2009 at 11:31 AM, wrote:
>
> Hi, I've been lurking on this list for awhile, thinking about how I could
> contribute to Wine.
>
> I wanted to weigh in because I think this overall proposal is on the right
> track. Graceful handling of errors and crashes would provide a better user
On Thu, 29 Jan 2009 14:07:13 -0500, Alex Villacís Lasso
wrote:
> Guillaume SH escribió:
>> Hi wine community,
>>
>> I took some time for reflexion following the thread "A step in the wrong
>> direction, in an ocean of steps in the right direction" and to the
>> explanations some of you kindly ex
Guillaume SH escribió:
> Hi wine community,
>
> I took some time for reflexion following the thread "A step in the wrong
> direction, in an ocean of steps in the right direction" and to the
> explanations some of you kindly exposed to me.
>
> As a follow-up I am making a proposal.
>
> A - The propo
On Thu, Jan 29, 2009 at 12:55 PM, Susan Cragin
wrote:
> When I installed DNS10 today, the included Visual C++ 8.0 runtime does not
> load, with the following message.
>
> fixme:advapi:LookupAccountNameW (null) L"susan" (nil) 0x33f80c (nil) 0x33f810
> 0x33f804 - stub
> fixme:advapi:LookupAccountN
When I installed DNS10 today, the included Visual C++ 8.0 runtime does not
load, with the following message.
fixme:advapi:LookupAccountNameW (null) L"susan" (nil) 0x33f80c (nil) 0x33f810
0x33f804 - stub
fixme:advapi:LookupAccountNameW (null) L"susan" 0x131958 0x33f80c 0x132430
0x33f810 0x33f80
Hi wine community,
I took some time for reflexion following the thread "A step in the wrong
direction, in an ocean of steps in the right direction" and to the
explanations some of you kindly exposed to me.
As a follow-up I am making a proposal.
A - The proposal
A1 - The core proposal
Al
On Thursday 29 January 2009 17:51:26 Juan Lang wrote:
> > No, we should have a warning because the algorithm is unknown and the
> > tests are not exhaustive.
>
> Fair enough. This is an implementation of the same origin policy,
> yes? Wikipedia provides some interesting examples, for instance,
> No, we should have a warning because the algorithm is unknown and the
> tests are not exhaustive.
Fair enough. This is an implementation of the same origin policy,
yes? Wikipedia provides some interesting examples, for instance,
having different port numbers in the same domain can cause a mism
On Thursday 29 January 2009 17:18:35 Juan Lang wrote:
> +FIXME("(%s, %s)\n", debugstr_w(s1), debugstr_w(s2));
>
> Shouldn't that be TRACE?
No, we should have a warning because the algorithm is unknown and the
tests are not exhaustive.
-Hans
Hi Hans, minor point:
+FIXME("(%s, %s)\n", debugstr_w(s1), debugstr_w(s2));
Shouldn't that be TRACE?
--Juan
On Thu, Jan 29, 2009 at 2:02 PM, Michael Stefaniuc wrote:
> Hi!
>
> Luke Kenneth Casson Leighton wrote:
>> well the saga continues with using python under wine - i thought i'd
>> let you know the analysis and clues so far, in case it rings any bells
>> with anyone, now or in the future. as you're
Hi!
Luke Kenneth Casson Leighton wrote:
> well the saga continues with using python under wine - i thought i'd
> let you know the analysis and clues so far, in case it rings any bells
> with anyone, now or in the future. as you're probably aware, there's
> a limit in nt of 2048 file descriptors w
hiya folks,
well the saga continues with using python under wine - i thought i'd
let you know the analysis and clues so far, in case it rings any bells
with anyone, now or in the future. as you're probably aware, there's
a limit in nt of 2048 file descriptors which has caused a large number
of fre
> From: Rob Shearman [mailto:robertshear...@gmail.com]
> > -error = RegCreateKeyEx(HKEY_CLASSES_ROOT, buffer, 0, NULL, 0,
> > KEY_SET_VALUE, NULL, &hkey,
> > +error = RegCreateKeyEx(HKEY_CURRENT_USER, buffer, 0, NULL, 0,
> > KEY_SET_VALUE, NULL, &hkey,
>
> This appears to have cau
2009/1/26 Alexandre Julliard :
> hr = StringFromCLSID(&CLSID_WineTest, &pszClsid);
> ok_ole_success(hr, "StringFromCLSID");
> -strcpy(buffer, "CLSID\\");
> +strcpy(buffer, "Software\\Classes\\CLSID\\");
> WideCharToMultiByte(CP_ACP, 0, pszClsid, -1, buffer + strlen(buffer),
> s
2009/1/29 Konstantin Kondratyuk :
> Hi!
>
> Javascript which is defined in the frame doesn't work.
> There is a test in attachement.
>
> Run index.html in 'wine iexplore'
>
> Correct events for this test (checked up in IE and Firefox):
> 1. "call f_right script" message
> 2. "call onLoad" message d
Aurimas Fišeras writes:
> But what about this and similar situations?
There's no single answer, each situation is different, you have to study
the code flow to understand what can and cannot happen.
> What should I do?
> 1. change get_process_exe_module() to
> return LIST_ENTRY( ptr, stru
Hi!
Javascript which is defined in the frame doesn't work.
There is a test in attachement.
Run index.html in 'wine iexplore'
Correct events for this test (checked up in IE and Firefox):
1. "call f_right script" message
2. "call onLoad" message during loading
3. "call myOnClick" message after cli
http://bugs.winehq.org/show_bug.cgi?id=17181 seems to be
a bug in our implementation of DOS FindNext.
It's one of the bugs blocking Winbench 96 from running.
I'm interested in Winbench 96 simply because it's the
only mainstream magazine system benchmark for Windows
I've ever even remotely gotten t
38 matches
Mail list logo