Re: ole32: add a test for OleInitialize
Austin English wrote: On Tue, Jan 13, 2009 at 1:28 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: Austin English wrote: Pointed out by Anastasius in bug 13011. Tested on XP SP2 2K SP4 (and Wine, of course). Hi Austin, The test case that is pointed out in bug 13011 is different though: hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr); hr = OleInitialize(NULL); ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr); The above succeeds on W2K3 but fails on Wine. -- Cheers, Paul. I was referring to this comment: Calling OleInitialize() for the first time should yield S_OK - even with apartment already initialized by previous CoInitialize(Ex) calls. Calling OleInitialize() more than once yields S_FALSE for the second and following calls. Though that testcase should probably be added as well, in a todo_wine of course. So maybe we should do hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr); hr = OleInitialize(NULL); todo_wine ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr); hr = OleInitialize(NULL); ok(hr == S_FALSE, Expected S_FALSE, hr = 0x%08x\n, hr); and move that to a separate test function? (Maybe in compobj.c?) I mean it's a ole32 basic thing that's wrong, not something that should be in a specific test I guess? -- Cheers, Paul.
Fwd: Draft XI 2 protocol specification
Hi Vitaliy,
Peter Hutterer has submitted a draft specification of Xinput2 to the xorg
mailinglist. As you know it will offer relative mouse movements. He is asking
for feedback. Since I have no experience with Xinput you might want to review
it and see if it works out for Wine.
Roderick
Original-Message
From: Peter Hutterer peter.hutte...@who-t.net
To: X.Org List x...@lists.freedesktop.org
CC: Daniel Stone dan...@fooishbar.org
Subject: Draft XI 2 protocol specification
I know we're all thinking about getting 1.6 out, but here's the next lot of
big changes that I really need some feedback on. LCA is coming up and napkins
want to be written on, so the more feedback before that happens, the better.
As a friendly reminder, the X Protocol has a tendency to be set in stone, so
if you don't speak up now you will have to explain yourself to your
grandchildren why GUI's still suck.
Short story long, X Input 2.0 is in the making and should come out with server
1.7 somewhen later this decade. Server 1.6 has all the internal changes but
doesn't expose anything to the clients. So far, I have bits and pieces of XI2
that compile and henceforth are bug-free. But I need your review is needed,
before I go further down a dead end.
Some clarification:
XI2 X Input Extension version 2.0 Protocol
XI 1.x . X Input Extension version 1.x Protocol
server 1.6 . X server version 1.6 (supports XI 1.5)
server 1.7 . X server version 1.7 (will support XI 2.0)
If you want to skip the background, scroll down to Protocol Specification
== Background ==
The biggest change between XI 1.5 and XI 2.0 will be the master/slave device
hierarchy being visible to the client and the ability to create additional
master devices (i.e. cursors/keyboard foci).
The current state of XI2 in master is that we're using the XI 1.x events plus
a few new ones (some of which are GenericEvents) and we have a few new
requests.
This has some shortcomings:
- XI 1.x events are full, there is no more space in the 32 bytes that allow
for more data.
- XI 1.x events suck for event registration. It is not possible to just
register for motion events, you have to open all devices, get the class,
etc.
- The pointer/keyboard distinction is not really a good idea these days, many
devices are both.
- XI 1.x does not allow for both rel+abs axes on a device.
- Subpixel precision only for absolute valuators.
- Static input devices. Devices cannot change capabilities (e.g. add an axis)
at runtime.
- Keycode range 255. This is also a limitation with XKB.
== Protocol Specification ==
Basically the idea is to provide GenericEvents for *all* XI2 events, even
those covered through XI 1.x. Which means that we have another API to support
for those clients that keep using XI 1. This however can be achieved in a
similar fashion to the core emulation we already do anyway.
Why? GenericEvent have a length-field, so we can keep extending in future
versions without having to modify the client. Clients are expected to read the
full event off the wire, but only access the fields that they know of,
allowing us to tack on data to the end of the event.
Below is the preliminary specification for those XI2 events I was planning to
add/implement for XI 2.0. If anything doesn't make sense, is missing, etc.
please state so.
I am not yet covering requests, this is events only for now.
In the remainder of this email, the following notation is used
┌───
Name of event
name of field: type of field
name of field: type of field
───
name of field: type of field
└───
Where ─── denotes the 32 byte boundary of the event, padded accordingly if
necessary. Fields after ─── require the event to have a length greater than 0.
If ─── is missing, the event is exactly 32 bytes long.
┌───
XIGenericDeviceEvent
type: BYTE
extension: BYTE
sequenceNumber: CARD16
length: CARD32
evtype: CARD16
deviceid: CARD16
time: CARD32
└───
XGenericDeviceEvent is the generic header for all XI 2 events.
type is always GenericEvent.
extension is always the X Input extension offset.
evtype is the XI-specific event type.
For brevity, this information is specified as GENERICEVENTDATA in the
following events.
┌───
XIDeviceHierarchyEvent:
GENERICEVENTDATA
flags: SETofHIERARCHYMASK
ndevices: CARD16
───
devices:LISTofINT16
└───
HIERARCHYMASK { MasterAdded, MasterRemoved, SlaveAttached, SlaveDetached,
SlaveAdded, SlaveRemoved }
type is XI_HierarchyChangedNotify.
flags
Re: ole32: add a test for OleInitialize
On Tue, Jan 13, 2009 at 2:20 AM, Paul Vriens paul.vriens.w...@gmail.com wrote:
Austin English wrote:
On Tue, Jan 13, 2009 at 1:28 AM, Paul Vriens paul.vriens.w...@gmail.com
wrote:
Austin English wrote:
Pointed out by Anastasius in bug 13011. Tested on XP SP2 2K SP4 (and
Wine, of course).
Hi Austin,
The test case that is pointed out in bug 13011 is different though:
hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr);
hr = OleInitialize(NULL);
ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr);
The above succeeds on W2K3 but fails on Wine.
--
Cheers,
Paul.
I was referring to this comment:
Calling OleInitialize() for the first time should yield S_OK - even with
apartment already initialized by previous CoInitialize(Ex) calls.
Calling OleInitialize() more than once yields S_FALSE for the second and
following calls.
Though that testcase should probably be added as well, in a todo_wine of
course.
So maybe we should do
hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr);
hr = OleInitialize(NULL);
todo_wine
ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr);
hr = OleInitialize(NULL);
ok(hr == S_FALSE, Expected S_FALSE, hr = 0x%08x\n, hr);
and move that to a separate test function? (Maybe in compobj.c?) I mean it's
a ole32 basic thing that's wrong, not something that should be in a specific
test I guess?
--
Cheers,
Paul.
How's this?
--
-Austin
diff --git a/dlls/ole32/tests/compobj.c b/dlls/ole32/tests/compobj.c
index 02dc080..4793bd6 100644
--- a/dlls/ole32/tests/compobj.c
+++ b/dlls/ole32/tests/compobj.c
@@ -1017,6 +1017,23 @@ static void test_CoGetObjectContext(void)
CoUninitialize();
}
+static void test_CoInitializeEx(void)
+{
+HRESULT hr;
+
+hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
+ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr);
+
+/* Calling OleInitialize for the first time should yield S_OK even with
+ * apartment already initialized by previous CoInitialize(Ex) calls. */
+hr = OleInitialize(NULL);
+todo_wine ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr);
+
+/* Subsequent calls to OleInitialize should return S_FALSE */
+hr = OleInitialize(NULL);
+ok(hr == S_FALSE, Expected S_FALSE, hr = 0x%08x\n, hr);
+}
+
START_TEST(compobj)
{
HMODULE hOle32 = GetModuleHandle(ole32);
@@ -1045,4 +1062,5 @@ START_TEST(compobj)
test_registered_object_thread_affinity();
test_CoFreeUnusedLibraries();
test_CoGetObjectContext();
+test_CoInitializeEx();
}
Re: [3/5] WineD3D: Put vertex shader duplication infrastructure in place
2009/1/13 Stefan Dösinger ste...@codeweavers.com:
-This-baseShader.is_compiled = TRUE;
-
This changes code in pixelshader.c, looks unrelated.
+void find_vs_compile_args(IWineD3DVertexShaderImpl *shader,
IWineD3DStateBlockImpl *stateblock, struct vs_compile_args *args) {
+args-fog_src = stateblock-renderState[WINED3DRS_FOGTABLEMODE] ==
WINED3DFOG_NONE ? VS_FOG_COORD : VS_FOG_Z;
+args-swizzle_map = ((IWineD3DDeviceImpl
*)shader-baseShader.device)-strided_streams.swizzle_map;
+}
You need to mask swizzle_map with use_map like in the original code,
or you'll end up creating new shaders if an attribute that was
previously swizzled is undefined now.
+shader-gl_shaders = HeapReAlloc(GetProcessHeap(), 0, old_array,
+ (shader-num_gl_shaders + 1) *
sizeof(*shader-gl_shaders));
Please don't grow arrays by a single element like that.
I noticed find_gl_pshader() does that as well, please fix.
- *
+ *
You're adding a trailing space here.
Re: ole32: add a test for OleInitialize
Paul Vriens wrote:
Austin English wrote:
On Tue, Jan 13, 2009 at 2:20 AM, Paul Vriens
paul.vriens.w...@gmail.com wrote:
Austin English wrote:
On Tue, Jan 13, 2009 at 1:28 AM, Paul Vriens
paul.vriens.w...@gmail.com
wrote:
Austin English wrote:
Pointed out by Anastasius in bug 13011. Tested on XP SP2 2K SP4
(and
Wine, of course).
Hi Austin,
The test case that is pointed out in bug 13011 is different though:
hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr);
hr = OleInitialize(NULL);
ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr);
The above succeeds on W2K3 but fails on Wine.
--
Cheers,
Paul.
I was referring to this comment:
Calling OleInitialize() for the first time should yield S_OK - even
with
apartment already initialized by previous CoInitialize(Ex) calls.
Calling OleInitialize() more than once yields S_FALSE for the second
and
following calls.
Though that testcase should probably be added as well, in a
todo_wine of
course.
So maybe we should do
hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr);
hr = OleInitialize(NULL);
todo_wine
ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr);
hr = OleInitialize(NULL);
ok(hr == S_FALSE, Expected S_FALSE, hr = 0x%08x\n, hr);
and move that to a separate test function? (Maybe in compobj.c?) I
mean it's
a ole32 basic thing that's wrong, not something that should be in a
specific
test I guess?
--
Cheers,
Paul.
How's this?
Looks great :). Two (minor) things though:
- you should maybe use pCoInitializeEx? (there is some remark in that
file about it not being present on all platforms, current
test.winehq.org doesn't show this though)
- do some uninitialize to clean things up?
I see that moniker.c also uses CoInitializeEx directly and no errors on
test.winehq.org for that ('not run' would be shown if that was the case).
So maybe we should get rid of the GetProcAddress for CoInitializeEx in all
files, but that would be another patch(set).
--
Cheers,
Paul.
Re: ole32: add a test for OleInitialize
Austin English wrote: On Tue, Jan 13, 2009 at 2:20 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: Austin English wrote: On Tue, Jan 13, 2009 at 1:28 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: Austin English wrote: Pointed out by Anastasius in bug 13011. Tested on XP SP2 2K SP4 (and Wine, of course). Hi Austin, The test case that is pointed out in bug 13011 is different though: hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr); hr = OleInitialize(NULL); ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr); The above succeeds on W2K3 but fails on Wine. -- Cheers, Paul. I was referring to this comment: Calling OleInitialize() for the first time should yield S_OK - even with apartment already initialized by previous CoInitialize(Ex) calls. Calling OleInitialize() more than once yields S_FALSE for the second and following calls. Though that testcase should probably be added as well, in a todo_wine of course. So maybe we should do hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr); hr = OleInitialize(NULL); todo_wine ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr); hr = OleInitialize(NULL); ok(hr == S_FALSE, Expected S_FALSE, hr = 0x%08x\n, hr); and move that to a separate test function? (Maybe in compobj.c?) I mean it's a ole32 basic thing that's wrong, not something that should be in a specific test I guess? -- Cheers, Paul. How's this? Looks great :). Two (minor) things though: - you should maybe use pCoInitializeEx? (there is some remark in that file about it not being present on all platforms, current test.winehq.org doesn't show this though) - do some uninitialize to clean things up? -- Cheers, Paul.
Re: ole32: add a test for OleInitialize
On Tue, Jan 13, 2009 at 3:09 AM, Paul Vriens paul.vriens.w...@gmail.com wrote:
Austin English wrote:
On Tue, Jan 13, 2009 at 2:20 AM, Paul Vriens paul.vriens.w...@gmail.com
wrote:
Austin English wrote:
On Tue, Jan 13, 2009 at 1:28 AM, Paul Vriens
paul.vriens.w...@gmail.com
wrote:
Austin English wrote:
Pointed out by Anastasius in bug 13011. Tested on XP SP2 2K SP4 (and
Wine, of course).
Hi Austin,
The test case that is pointed out in bug 13011 is different though:
hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr);
hr = OleInitialize(NULL);
ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr);
The above succeeds on W2K3 but fails on Wine.
--
Cheers,
Paul.
I was referring to this comment:
Calling OleInitialize() for the first time should yield S_OK - even
with
apartment already initialized by previous CoInitialize(Ex) calls.
Calling OleInitialize() more than once yields S_FALSE for the second and
following calls.
Though that testcase should probably be added as well, in a todo_wine of
course.
So maybe we should do
hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr);
hr = OleInitialize(NULL);
todo_wine
ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr);
hr = OleInitialize(NULL);
ok(hr == S_FALSE, Expected S_FALSE, hr = 0x%08x\n, hr);
and move that to a separate test function? (Maybe in compobj.c?) I mean
it's
a ole32 basic thing that's wrong, not something that should be in a
specific
test I guess?
--
Cheers,
Paul.
How's this?
Looks great :). Two (minor) things though:
- you should maybe use pCoInitializeEx? (there is some remark in that file
about it not being present on all platforms, current test.winehq.org doesn't
show this though)
- do some uninitialize to clean things up?
--
Cheers,
Paul.
I haven't tested on windows though. I can test it later today before
submitting to wine-patches [though I'm sure you'll beat me to it ;-)].
--
-Austin
diff --git a/dlls/ole32/tests/compobj.c b/dlls/ole32/tests/compobj.c
index 02dc080..450db78 100644
--- a/dlls/ole32/tests/compobj.c
+++ b/dlls/ole32/tests/compobj.c
@@ -1017,6 +1017,27 @@ static void test_CoGetObjectContext(void)
CoUninitialize();
}
+static void test_CoInitializeEx(void)
+{
+HRESULT hr;
+
+hr = pCoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
+ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr);
+
+/* Calling OleInitialize for the first time should yield S_OK even with
+ * apartment already initialized by previous CoInitialize(Ex) calls. */
+hr = OleInitialize(NULL);
+todo_wine ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr);
+
+/* Subsequent calls to OleInitialize should return S_FALSE */
+hr = OleInitialize(NULL);
+ok(hr == S_FALSE, Expected S_FALSE, hr = 0x%08x\n, hr);
+
+/* Cleanup */
+CoUninitialize();
+OleUninitialize();
+}
+
START_TEST(compobj)
{
HMODULE hOle32 = GetModuleHandle(ole32);
@@ -1045,4 +1066,5 @@ START_TEST(compobj)
test_registered_object_thread_affinity();
test_CoFreeUnusedLibraries();
test_CoGetObjectContext();
+test_CoInitializeEx();
}
Re: [5/5] d3d9: Use D3DFOG_* constants instead of plain integers
I think this change is ok, but note that the ok() line for this test will still just print the numeric value.
Re: ole32: add a test for OleInitialize
Austin English wrote: On Tue, Jan 13, 2009 at 3:09 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: Austin English wrote: On Tue, Jan 13, 2009 at 2:20 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: Austin English wrote: On Tue, Jan 13, 2009 at 1:28 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: Austin English wrote: Pointed out by Anastasius in bug 13011. Tested on XP SP2 2K SP4 (and Wine, of course). Hi Austin, The test case that is pointed out in bug 13011 is different though: hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr); hr = OleInitialize(NULL); ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr); The above succeeds on W2K3 but fails on Wine. -- Cheers, Paul. I was referring to this comment: Calling OleInitialize() for the first time should yield S_OK - even with apartment already initialized by previous CoInitialize(Ex) calls. Calling OleInitialize() more than once yields S_FALSE for the second and following calls. Though that testcase should probably be added as well, in a todo_wine of course. So maybe we should do hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr); hr = OleInitialize(NULL); todo_wine ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr); hr = OleInitialize(NULL); ok(hr == S_FALSE, Expected S_FALSE, hr = 0x%08x\n, hr); and move that to a separate test function? (Maybe in compobj.c?) I mean it's a ole32 basic thing that's wrong, not something that should be in a specific test I guess? -- Cheers, Paul. How's this? Looks great :). Two (minor) things though: - you should maybe use pCoInitializeEx? (there is some remark in that file about it not being present on all platforms, current test.winehq.org doesn't show this though) - do some uninitialize to clean things up? -- Cheers, Paul. I haven't tested on windows though. I can test it later today before submitting to wine-patches [though I'm sure you'll beat me to it ;-)]. Succeeds on Win95, W2K3 and Vista (haven't tested others). -- Cheers, Paul.
Re: ole32: add a test for OleInitialize
Austin English wrote: On Tue, Jan 13, 2009 at 3:09 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: Austin English wrote: On Tue, Jan 13, 2009 at 2:20 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: Austin English wrote: On Tue, Jan 13, 2009 at 1:28 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: Austin English wrote: Pointed out by Anastasius in bug 13011. Tested on XP SP2 2K SP4 (and Wine, of course). Hi Austin, The test case that is pointed out in bug 13011 is different though: hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr); hr = OleInitialize(NULL); ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr); The above succeeds on W2K3 but fails on Wine. -- Cheers, Paul. I was referring to this comment: Calling OleInitialize() for the first time should yield S_OK - even with apartment already initialized by previous CoInitialize(Ex) calls. Calling OleInitialize() more than once yields S_FALSE for the second and following calls. Though that testcase should probably be added as well, in a todo_wine of course. So maybe we should do hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); ok(hr == S_OK, CoInitializeEx failed with error 0x%08x\n, hr); hr = OleInitialize(NULL); todo_wine ok(hr == S_OK, OleInitialize failed with error 0x%08x\n, hr); hr = OleInitialize(NULL); ok(hr == S_FALSE, Expected S_FALSE, hr = 0x%08x\n, hr); and move that to a separate test function? (Maybe in compobj.c?) I mean it's a ole32 basic thing that's wrong, not something that should be in a specific test I guess? -- Cheers, Paul. How's this? Looks great :). Two (minor) things though: - you should maybe use pCoInitializeEx? (there is some remark in that file about it not being present on all platforms, current test.winehq.org doesn't show this though) - do some uninitialize to clean things up? -- Cheers, Paul. I haven't tested on windows though. I can test it later today before submitting to wine-patches [though I'm sure you'll beat me to it ;-)]. Succeeded on WinXP too.
Re: urlmon: Skip more tests on old IE and ignore BINDSTATUS_PROXYDETECTING notification.
Jacek Caban wrote: --- dlls/urlmon/tests/url.c | 157 +-- 1 files changed, 84 insertions(+), 73 deletions(-) Hi Jacek, As of this patch we skip running most of the tests on Wine (and Windows). I only see a few W2K boxes that run the full tests for url.c (+/- 3800 tests). The rest only run 137 tests -- Cheers, Paul.
Re: urlmon: Skip more tests on old IE and ignore BINDSTATUS_PROXYDETECTING notification.
Paul Vriens wrote:
Jacek Caban wrote:
---
dlls/urlmon/tests/url.c | 157
+--
1 files changed, 84 insertions(+), 73 deletions(-)
Hi Jacek,
As of this patch we skip running most of the tests on Wine (and
Windows). I only see a few W2K boxes that run the full tests for url.c
(+/- 3800 tests). The rest only run 137 tests
Shouldn't that
if(!test_RegisterBindStatusCallback()) {
actually be
if(test_RegisterBindStatusCallback()) {
--
Cheers,
Paul.
Re: [2/5] wined3d: Fix texture creation error handling.
Hi Henri, Just a suggestion for a future patch. The current autogenmipmap code isn't correct. Even when this capability isn't supported the function might not return D3DERR_INVALIDCALL IF CheckDeviceFormat returns D3DOK_NOAUTOGEN for this usage flag. I stumbled on this when I started improving our caps code but didn't have time to fix it yet. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
Re: urlmon: Skip more tests on old IE and ignore BINDSTATUS_PROXYDETECTING notification.
Paul Vriens wrote:
Paul Vriens wrote:
Jacek Caban wrote:
---
dlls/urlmon/tests/url.c | 157
+--
1 files changed, 84 insertions(+), 73 deletions(-)
Hi Jacek,
As of this patch we skip running most of the tests on Wine (and
Windows). I only see a few W2K boxes that run the full tests for
url.c (+/- 3800 tests). The rest only run 137 tests
Shouldn't that
if(!test_RegisterBindStatusCallback()) {
actually be
if(test_RegisterBindStatusCallback()) {
Yes, it should. It's fixed by my yesterday (not yet applied) patch.
Thanks,
Jacek
Re: urlmon: Skip more tests on old IE and ignore BINDSTATUS_PROXYDETECTING notification.
Jacek Caban wrote:
Paul Vriens wrote:
Paul Vriens wrote:
Jacek Caban wrote:
---
dlls/urlmon/tests/url.c | 157
+--
1 files changed, 84 insertions(+), 73 deletions(-)
Hi Jacek,
As of this patch we skip running most of the tests on Wine (and
Windows). I only see a few W2K boxes that run the full tests for
url.c (+/- 3800 tests). The rest only run 137 tests
Shouldn't that
if(!test_RegisterBindStatusCallback()) {
actually be
if(test_RegisterBindStatusCallback()) {
Yes, it should. It's fixed by my yesterday (not yet applied) patch.
Thanks,
Jacek
Great !!
I just noticed it because I got an err:ole:CoUninitialize Mismatched
CoUninitialize error ans started investigating.
The CoUninitialize should be moved inside the if(). I'll sent a patch once your
stuff is in.
--
Cheers,
Paul.
Re: [2/2] setupapi: Fix resolving target path when given a section. Default to the system directory.
Hans Leidekker h...@codeweavers.com writes: @@ -68,6 +68,20 @@ static const char inf_data2[] = sp1qfe\\winhttp.dll=3EC6F518114606CA59D4160322077437,000500010A280615,331776,SP1QFE\n sp1qfe\\xpob2res.dll=DB83156B9F496F20D1EA70E4ABEC0166,000500010A280622,158720,SP1QFE\n; +static const char inf_data3[] = +[Version]\n +Signature = \$Windows NT$\\n +[DestinationDirs]\n +CopyAlways.System32.files = 11\n +[CopyAlways.System32.Files]\n +WindowsCodecs.dll\n; + +static const char inf_data4[] = +[Version]\n +Signature = \$Windows NT$\\n +[CopyAlways.System32.Files]\n +WindowsCodecs.dll\n; It would be better to use a different directory in the first test so that you can make sure there's a difference. Also you should try setting DefaultDestDir to see how this changes the behavior. -- Alexandre Julliard julli...@winehq.org
Fwd: wine-bugs Digest, Vol 42, Issue 330
-- Forwarded message -- From: wine-bugs-requ...@winehq.org Date: Tue, Jan 13, 2009 at 9:20 AM Subject: wine-bugs Digest, Vol 42, Issue 330 To: wine-b...@winehq.org -- Message: 1 Date: Tue, 13 Jan 2009 08:40:35 -0600 From: wine-b...@winehq.org Subject: [Bug 14413] Freedom: First Resistance problems To: wine-b...@winehq.org Message-ID: e1lmkrx-0004cj...@wine.codeweavers.com Content-Type: text/plain; charset=UTF-8 http://bugs.winehq.org/show_bug.cgi?id=14413 Dmitry Timoshkov dmi...@codeweavers.com changed: What|Removed |Added Resolution|REMIND |ABANDONED --- Comment #5 from Dmitry Timoshkov dmi...@codeweavers.com 2009-01-13 08:40:35 --- REMIND is not an appropriate resolution in Wine bugzilla. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. --- You are receiving this mail because: --- You are watching all bug changes. -- Message: 3 Date: Tue, 13 Jan 2009 08:45:37 -0600 From: wine-b...@winehq.org Subject: [Bug 14413] Freedom: First Resistance problems To: wine-b...@winehq.org Message-ID: e1lmkwp-0004za...@wine.codeweavers.com Content-Type: text/plain; charset=UTF-8 http://bugs.winehq.org/show_bug.cgi?id=14413 Maki mak...@gmail.com changed: What|Removed |Added Resolution|ABANDONED |LATER --- Comment #6 from Maki mak...@gmail.com 2009-01-13 08:45:36 --- (In reply to comment #5) REMIND is not an appropriate resolution in Wine bugzilla. Fun, fun. It shouldn't BE IN bugzilla's dropdown menu then. -- Message: 6 Date: Tue, 13 Jan 2009 08:53:34 -0600 From: wine-b...@winehq.org Subject: [Bug 14413] Freedom: First Resistance problems To: wine-b...@winehq.org Message-ID: e1lmke6-0005wl...@wine.codeweavers.com Content-Type: text/plain; charset=UTF-8 http://bugs.winehq.org/show_bug.cgi?id=14413 Dmitry Timoshkov dmi...@codeweavers.com changed: What|Removed |Added Resolution|LATER |ABANDONED --- Comment #7 from Dmitry Timoshkov dmi...@codeweavers.com 2009-01-13 08:53:34 --- Fun, fun. It shouldn't BE IN bugzilla's dropdown menu then. It doesn't matter what in the bugzilla's dropdown menu. LATER and REMIND are considered as not appropriate resolutions in WineHQ bugzilla, they are meaningless. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. --- You are receiving this mail because: --- You are watching all bug changes. How do we expect users to know not to use these resolutions? It's not listed anywhere, and those are appropriate resolutions in other bugzillas. We've already went through and removed all of them from bug entries in bugzilla, so can an admin please remove these resolutions? -- -Austin
Re: [2/5] WineD3D: Get rid of last_was_foggy_shader friends
Stefan Dösinger ste...@codeweavers.com writes: This patch breaks a set of fog tests, so they're marked as todo. The tests aren't really working correctly right now anyway, they depend on undefined default values in opengl. A later patch will make the vertex shader select the result.fogcoord(and glsl equivalent) depending on the fog settings, thus really fixing this test. The added todo doesn't fail here: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c touch visual.ok visual.c:8746: Tests skipped: D3DFMT_G16R16F textures not supported visual.c:8746: Tests skipped: D3DFMT_G32R32F textures not supported visual.c:7536: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests visual.c:1540: Test succeeded inside todo block: fog vs1 ps0 fvm0 ftm0 0: got color ff00, expected ff00 +-5%(todo) visual.c:8607: Tests skipped: Only 1 simultaneous render target supported, skipping MRT test make[2]: *** [visual.ok] Error 1 -- Alexandre Julliard julli...@winehq.org
Re: wcmd: Fix redirecting a pipe to another pipe
On Sun, Jan 11, 2009 at 01:01:02PM -0700, Erich Hoover wrote: Done, I don't know who maintains http://www.winehq.org/sending_patches but that might be worth mentioning there - I always pull out that guide since I do not submit very often. It's in another git repo (see http://source.winehq.org/git/ with a web browser). You can send in patches for it as usual with the repo [name] in those brackets before the patch subject. Jan
RE: [2/5] WineD3D: Get rid of last_was_foggy_shader friends
visual.c:1540: Test succeeded inside todo block: fog vs1 ps0 fvm0 ftm0 0: got color ff00, expected ff00 +-5%(todo) I thought I added an exception for this case, where the wrong calculation gets lucky and produces the right result. Well, I'll double-check
Re: Wineaudioio driver
On Fri, 9 Jan 2009, Roderick Colenbrander wrote: [...] Those two guys said that Sun is working together with 4Front (from the commercial OSS) on some new audio system called 'Boomer' and which is also OSS compatible. I believe that our wineoss driver works fine. This page contains some more info and more links http://opensolaris.org/os/project/opensound/. Yay! Yet another audio system. Just what we needed. Well, at least it seems to support OSS so maybe we don't have to develop yet another sound backend. So to summarize, on Solaris we have the following situation: * Libaudioio - Abandoned by Solaris - No package provided on the Solaris 10u5 DVD - No package provided on the Solaris 2008/07 Companion CD - Obsolete Wine driver, many '#if 0', commented out code = Sounds like we could remove the Wine backend * OSS - Supported by Boomer which is said to be the future of the day - No package is provided with the Solaris 10u5 DVD - No package provided on the Solaris 2008/07 Companion CD - Our OSS backend seems to work with Boomer. Are we missing out on a lot of features? * ESound - Installed by default in Solaris 10u5 - But not started by default? - wineesd may need some fixing to work right with it? * NAS - Not used for local sound anyway - No package provided on the Solaris 10u5 DVD - No package provided on the Solaris 2008/07 Companion CD * Jack - Not available on Solaris at all? * Coreaudio - Mac-specific so not relevant Did I miss something? -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.
RE: [5/5] d3d9: Use D3DFOG_* constants instead of plain integers
I think this change is ok, but note that the ok() line for this test will still just print the numeric value. Yes, I'm aware of that. I mainly wrote the change after I incorrectly assumed that D3DFOG_LINEAR == 1 and got pretty confused. Writing a debug function for better ok() lines might be a good idea too
meaning of Hardware field in bugzilla?
Does mac mean powerpc mac only? I rather thought it meant apple macintosh, regardless of cpu. I ask because Austin has just gone through and changed lots of mac bugs to pc even though the bugs were on Intel macs, which just seems wrong.
Re: meaning of Hardware field in bugzilla?
Does mac mean powerpc mac only? I rather thought it meant apple macintosh, regardless of cpu. I ask because Austin has just gone through and changed lots of mac bugs to pc even though the bugs were on Intel macs, which just seems wrong. I agree with you, this change seems suspect. Austin, are you trying to distinguish PPC bugs from x86 ones with this, or what? --Juan
Re: meaning of Hardware field in bugzilla?
On Tue, Jan 13, 2009 at 1:12 PM, Juan Lang juan.l...@gmail.com wrote: Does mac mean powerpc mac only? I rather thought it meant apple macintosh, regardless of cpu. I ask because Austin has just gone through and changed lots of mac bugs to pc even though the bugs were on Intel macs, which just seems wrong. I agree with you, this change seems suspect. Austin, are you trying to distinguish PPC bugs from x86 ones with this, or what? --Juan I've seen the same change made a few times in the past (I'd have to search for it). Looking at other bugzilla's, Mozilla puts Intel Mac bugs under PC...after all, since they've moved to x86, for all intents and purposes, Intel Macs are PC's (especially if running Linux rather than OS X). Those running OS X still can be identified as such by the OS field. Yes, my goal was to separate x86/ppc bugs. -- -Austin
Wine being targeted for adware
http://philosecurity.org/2009/01/12/interview-with-an-adware-author In an interesting interview, former adware author Matt Knox mentions that he was able to run his adware client on Wine: S: In your professional opinion, how can people avoid adware? M: Um, run UNIX. S: [ laughs] M: We did actually get the ad client working under Wine on Linux. S: That seems like a bit of a stretch! M: That was a pretty limited market, I'd say.
RE: ole32: add a test for OleInitialize
Paul Vriens wrote: Austin English wrote: Paul Vriens wrote: - you should maybe use pCoInitializeEx? (there is some remark in that file about it not being present on all platforms, current test.winehq.org doesn't show this though) - do some uninitialize to clean things up? I haven't tested on windows though. I can test it later today before submitting to wine-patches [though I'm sure you'll beat me to it ;-)]. Succeeds on Win95, W2K3 and Vista (haven't tested others). The Ex variant might be something added in one of the Win95 releases. Posts like this http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/Win95 _3x/95/Win95_Setup/Q_10055969.html seem to indicate so. Of course an IE6 installer or such might have updated the OLE subsystem too in your case. Most probably there are not many systems around using an original Win95 installation anymore but still technically CoInitializeEx() may not be available on all Win95 systems. Rolf Kalbermatter
Re: setupapi: Add the Romanian translation.
Michael Stefaniuc wrote: +/* + * English resources for SETUPAPI + * I guess that should be Romanian resources. -- Cheers, Paul.
Re: oleaut32/tests: add tests for OleLoadPictureFile(Ex) and OleLoadPicturePath (resend) [2/2]
On Mon, 5 Jan 2009, Jeremy Drake wrote: --- dlls/oleaut32/tests/olepicture.c | 321 ++ 1 files changed, 321 insertions(+), 0 deletions(-) Is there anything wrong with these two patches? I'd really like to see these tests go in, so hopefully someone will decide to tackle this olepicture stuff. At the very least, putting the stubs in for OleLoadPictureFile (patch 1/2) keeps my app from crashing...
Re: [PATCH] quartz: Add a filtergraph test for mpeg files.
Lei Zhang wrote: Hi, I cleaned up dlls/quartz/tests/filtergraph.c a bit so we can drop in a 'test.mpg' file and test the rendering of MPEG files. Please stick to the CreateFileA (instead of W) to have these tests run on win9x. -- Cheers, Paul.
