September 2006 - Wine-Devel

Re: [D3D9] Remove const qualifier on state_test data.
by Michael Stefaniuc Sept. 30, 2006

Sept. 30, 2006

Ivan Gyurdiev wrote: > Type: Cleanup > > Why: > The const qualifier is unnecessarily restrictive. > I intend to allocate and free such data on the heap in a future patch. > Instead, const should be primarily used on function parameters. Question: do you realy have to use void pointers? Void pointers are compatible with every pointer type and thus will disable the type checking of the compiler. Also you do not need to to cast a rvalue to void * if the type of the lvalue is void *. bye michael > --- > dlls/d3d9/tests/stateblock.c | 40 ++++++++++++++++++++-------------------- > 1 files changed, 20 insertions(+), 20 deletions(-) > > diff --git a/dlls/d3d9/tests/stateblock.c b/dlls/d3d9/tests/stateblock.c > index 65a11e6..68b431a 100644 > --- a/dlls/d3d9/tests/stateblock.c > +++ b/dlls/d3d9/tests/stateblock.c > @@ -105,20 +105,20 @@ typedef struct state_test { > * as the default data, but a write can have side effects. > * The initial data is tested first, before any writes take place > * The default data can be tested after a write */ > - const void* initial_data; > + void* initial_data; > > /* The default data is the standard state to compare > * against, and restore to */ > - const void* default_data; > + void* default_data; > > /* The test data is the experiment data to try > * in - what we want to write > * out - what windows will actually write (not necessarily the same) */ > - const void* test_data_in; > - const void* test_data_out; > + void* test_data_in; > + void* test_data_out; > > /* The poison data is the data to preinitialize the return buffer to */ > - const void* poison_data; > + void* poison_data; > > /* Return buffer */ > void* return_data; > @@ -562,11 +562,11 @@ static void shader_constants_queue_test( > shader_constant_arg* arg = buffer; > shader_constant_data* return_data = (shader_constant_data*) (arg + 1); > > - test->test_data_in = &shader_constant_test_data; > - test->test_data_out = &shader_constant_test_data; > - test->default_data = &shader_constant_default_data; > - test->initial_data = &shader_constant_default_data; > - test->poison_data = &shader_constant_poison_data; > + test->test_data_in = (void*) &shader_constant_test_data; > + test->test_data_out = (void*) &shader_constant_test_data; > + test->default_data = (void*) &shader_constant_default_data; > + test->initial_data = (void*) &shader_constant_default_data; > + test->poison_data = (void*) &shader_constant_poison_data; > test->return_data = return_data; > test->data_size = sizeof(shader_constant_data); > test->set_handler = shader_constant_set_handler; > @@ -697,11 +697,11 @@ static void lights_queue_test( > light_arg* arg = buffer; > light_data* return_data = (light_data*) (arg + 1); > > - test->test_data_in = &light_test_data_in; > - test->test_data_out = &light_test_data_out; > - test->default_data = &light_default_data; > - test->initial_data = &light_initial_data; > - test->poison_data = &light_poison_data; > + test->test_data_in = (void*) &light_test_data_in; > + test->test_data_out = (void*) &light_test_data_out; > + test->default_data = (void*) &light_default_data; > + test->initial_data = (void*) &light_initial_data; > + test->poison_data = (void*) &light_poison_data; > test->return_data = return_data; > test->data_size = sizeof(light_data); > test->set_handler = light_set_handler; > @@ -856,11 +856,11 @@ static void transform_queue_test( > { > transform_data* return_data = buffer; > > - test->test_data_in = &transform_test_data; > - test->test_data_out = &transform_test_data; > - test->default_data = &transform_default_data; > - test->initial_data = &transform_default_data; > - test->poison_data = &transform_poison_data; > + test->test_data_in = (void*) &transform_test_data; > + test->test_data_out = (void*) &transform_test_data; > + test->default_data = (void*) &transform_default_data; > + test->initial_data = (void*) &transform_default_data; > + test->poison_data = (void*) &transform_poison_data; > test->return_data = return_data; > test->data_size = sizeof(transform_data); > test->set_handler = transform_set_handler; -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Re: [Bug 4995] Check for fontforge >= 20060406 as earlier versions fail to build our fonts with catastrophic results.
by Vitaliy Margolen Sept. 30, 2006

Sept. 30, 2006

Sam Dennis wrote: > aclocal.m4 | 16 ++++++++++++++++ > configure.ac | 6 +++++- > 2 files changed, 21 insertions(+), 1 deletions(-) > You missing change log. Please don't forget to include it in the email body not just subject. Also your patch is not correct. It's been discussed on wine-devel that we should not restrict any one particular version of FontForge. Many distros come with old but good versions and this will add extra noise for no good reason. And it will not catch any new versions that are broken either... Vitaliy.

2 1

Vista applications that work & those that don't
by Nick Law Sept. 30, 2006

Sept. 30, 2006

I thought this may be of interest... applications that work and those that don't in Vista RC1 It would be interesting on how this same list compares with wine 0.9.22 http://www.iexbeta.com/wiki/index.php/Windows_Vista_Software_Compatibility_… and the hardware compatibility list .. http://www.iexbeta.com/wiki/index.php/Windows_Vista_RC_1_Hardware_Compatibi… I don't believe Microsoft's official list has been made public yet, although they said they would sometime! Nick

1 0

Re: shdocvw(2/2): ignore VT_ERROR arguments to WebBrowser_Navigate2
by Michael Stefaniuc Sept. 29, 2006

Sept. 29, 2006

Juan Lang wrote: > Combined with the first patch, I'm able to log in with Skype 2.6 beta. > > ChangeLog: ignore VT_ERROR arguments to WebBrowser_Navigate2 Ignoring VT_ERROR just masks a previous error. bye michael > Index: dlls/shdocvw/webbrowser.c > =================================================================== > RCS file: /home/wine/wine/dlls/shdocvw/webbrowser.c,v > retrieving revision 1.65 > diff -u -r1.65 webbrowser.c > --- dlls/shdocvw/webbrowser.c 25 Sep 2006 19:46:43 -0000 1.65 > +++ dlls/shdocvw/webbrowser.c 29 Sep 2006 00:55:46 -0000 > @@ -675,7 +675,7 @@ > if(V_VT(URL) != VT_BSTR) > return E_INVALIDARG; > > - if(PostData && V_VT(PostData) != VT_EMPTY) { > + if(PostData && V_VT(PostData) != VT_EMPTY && V_VT(PostData) != VT_ERROR) { > if(V_VT(PostData) != (VT_ARRAY | VT_UI1) > || V_ARRAY(PostData)->cDims != 1) { > WARN("Invalid PostData\n"); > @@ -686,7 +686,7 @@ > post_data_len = V_ARRAY(PostData)->rgsabound[0].cElements; > } > > - if(Headers && V_VT(Headers) != VT_EMPTY) { > + if(Headers && V_VT(Headers) != VT_EMPTY && V_VT(Headers) != VT_ERROR) { > if(V_VT(Headers) != VT_BSTR) > return E_INVALIDARG; > > > > ------------------------------------------------------------------------ > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

3 3

Re: [PATCH 0/4] Janitorial: Win64 printf format warning fixes
by Michael Stefaniuc Sept. 29, 2006

Sept. 29, 2006

Michael Stefaniuc wrote: > For all the people wanting to help out with this janitorial task please > wait until Alexandre commits this patch series. After that i'll create a > page for this task on the Wine wiki and link it from > http://wiki.winehq.org/JanitorialProjects Ok, this janitorial task has now a Wiki page: http://wiki.winehq.org/Win64PrintfFormatWarnings This is a good opportunity for anybody that wants to start submitting patches for Wine and get accustomed to this process. > I will put in a download link for my perl script that can automaticly > fix around 20000 out of the remaining 25000 warnings. You realy do not > want to go manualy over 25k warnings. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Can't open DLL's without sudo
by Paul Wilkinson Sept. 29, 2006

Sept. 29, 2006

I'm running wine v 0.9.20 under Fedora Core 5. I'm trying to get the Syncrosoft License Control Center to run under wine. for some reason it can only load MFC42.DLL and MSVCRT.DLL if I put 'sudo' on the command line: [paul(a)localhost LCC]$ wine LCC.exe err:module:import_dll Library MFC42.DLL (which is needed by L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found err:module:import_dll Library MSVCRT.dll (which is needed by L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found err:module:import_dll Library MSVCRT.dll (which is needed by L"C:\\windows\\system32\\MSVCP60.dll") not found err:module:import_dll Library MSVCP60.dll (which is needed by L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe" failed, status c0000135 [paul(a)localhost LCC]$ The NtOpenFile that tries to open the DLL (in loader.c) is returning c00000022 (ACCESS_DENIED). But the permissions for these DLL's are wide open. Any idea what's going on? - Paul

4 4

crypt32/sip: new test failures
by Marcus Meissner Sept. 29, 2006

Sept. 29, 2006

Hi, ../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p crypt32_test.exe.so sip.c && touch sip.ok sip.c:176: Test failed: Expected CryptSIPRetrieveSubjectGuid to succeed sip.c:177: Test failed: Expected ERROR_SUCCESS, got 0x00000002 sip.c:179: Test failed: Expected ({c689aab8-8e78-11d0-8c47-00c04fc295ee}), got ({c689aab8-8e78-11d0-8c47-00c04fc295ee}). sip.c:187: Test failed: Expected CryptSIPRetrieveSubjectGuid to succeed sip.c:188: Test failed: Expected ERROR_SUCCESS, got 0x00000057 sip.c:190: Test failed: Expected ({c689aab8-8e78-11d0-8c47-00c04fc295ee}), got ({c689aab8-8e78-11d0-8c47-00c04fc295ee}). sip.c:199: Test failed: Expected CryptSIPRetrieveSubjectGuid to succeed sip.c:200: Test failed: Expected ERROR_SUCCESS, got 0x00000057 sip.c:202: Test failed: Expected ({c689aab8-8e78-11d0-8c47-00c04fc295ee}), got ({c689aab8-8e78-11d0-8c47-00c04fc295ee}). fixme:crypt:CryptSIPLoad ((null) 0 (nil)) stub! fixme:crypt:CryptSIPLoad ({7b845773-cc00-7ffd-0000-00003b933460} 0 (nil)) stub! fixme:crypt:CryptSIPLoad ({deadbeef-dead-beef-dead-beefdeadbeef} 0 0x33fda0) stub! fixme:crypt:CryptSIPLoad ({deadbeef-dead-beef-dead-beefdeadbeef} 0 0x33fda0) stub! fixme:crypt:CryptSIPLoad ({c689aaba-8e78-11d0-8c47-00c04fc295ee} 0 0x33fda0) stub! fixme:crypt:CryptSIPLoad ({c689aaba-8e78-11d0-8c47-00c04fc295ee} 0 0x33fda0) stub! fixme:crypt:CryptSIPLoad ({c689aaba-8e78-11d0-8c47-00c04fc295ee} 1 0x33fda0) stub! make[2]: *** [sip.ok] Fehler 9 I did run "wineprefixcreate" before (just in case). Ciao, Marcus

1 0

Re: wine-devel Digest, Vol 14, Issue 93
by Anton Litvinov Sept. 29, 2006

Sept. 29, 2006

----- Original Message ----- From: <wine-devel-request(a)winehq.org> To: <wine-devel(a)winehq.org> Sent: Friday, September 29, 2006 8:58 PM Subject: wine-devel Digest, Vol 14, Issue 93 > Send wine-devel mailing list submissions to > wine-devel(a)winehq.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.winehq.org/mailman/listinfo/wine-devel > or, via email, send a message with subject or body 'help' to > wine-devel-request(a)winehq.org > > You can reach the person managing the list at > wine-devel-owner(a)winehq.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wine-devel digest..." > > > Today's Topics: > > 1. Re: Governance Ideas (Mike McCormack) > 2. Re: shdocvw(2/2): ignore VT_ERROR arguments to > WebBrowser_Navigate2 (Michael Stefaniuc) > 3. Re: make test failure (Michael Stefaniuc) > 4. Re: [D3D9] Remove const qualifier on state_test data. > (Michael Stefaniuc) > 5. compiling wine for amd64 on ubuntu dapper 6.06 (Gerald Britton) > 6. Re: make test failure (Vitaliy Margolen) > 7. Re: shdocvw(2/2): ignore VT_ERROR arguments to > WebBrowser_Navigate2 (Juan Lang) > 8. Re: USER32: Stub implementation of BlockInput (Juan Lang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 29 Sep 2006 18:02:08 +0900 > From: Mike McCormack <mike(a)codeweavers.com> > Subject: Re: Governance Ideas > To: bobl(a)optushome.com.au > Cc: wine-devel(a)winehq.com, Alexandre Julliard <julliard(a)winehq.org> > Message-ID: <451CE110.5000708(a)codeweavers.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > > Robert Lunnon wrote: > > > "Community Focused Process" means what it says, develop a process which is > > centred on the community the project serves. This requires the project to > > answer some introspective questions > > > > 1. Who "owns" Wine, does wine belong to A.) Alexandre, or B) the community > > it serves. > > A) Alexandre is a benelovent dictator. He manages Wine with the > interests of "the community" in mind, as he sees them. > > > 1. Answer the questions about the "ownership" of wine and identify the > > community it serves. Determine the right of the community to be involved is > > setting wines direction IE The Bill of rights I mentioned before (for each > > community Developers VS Users etc). > > Your "bill of rights" is the Wine license, the LGPL. > > > 2. Alexandre documents the exact logic he uses to determine patch > > acceptability which becomes the patch acceptance policy in the interim. > > It's very likely impossible to write that down. If you don't agree with > me, please write down your proposal. > > > 3. The project develops a community process for establishing project direction > > and maintaining the patch acceptance policy which includes stakeholders > > elected from the "owners" IE communities with a stakeholding in wine > > NetBSD is a project that is (was?) run by committees: > > http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html > > If you want Wine to be run by a committee, how about creating your own > fork so you can run it as you see fit? > > Mike > > > > ------------------------------ > > Message: 2 > Date: Fri, 29 Sep 2006 10:57:26 +0200 > From: Michael Stefaniuc <mstefani(a)redhat.com> > Subject: Re: shdocvw(2/2): ignore VT_ERROR arguments to > WebBrowser_Navigate2 > To: juan_lang(a)yahoo.com > Cc: wine-devel(a)winehq.org > Message-ID: <451CDFF6.5060904(a)redhat.com> > Content-Type: text/plain; charset=UTF-8 > > Juan Lang wrote: > > Combined with the first patch, I'm able to log in with Skype 2.6 beta. > > > > ChangeLog: ignore VT_ERROR arguments to WebBrowser_Navigate2 > Ignoring VT_ERROR just masks a previous error. > > bye > michael > > > Index: dlls/shdocvw/webbrowser.c > > =================================================================== > > RCS file: /home/wine/wine/dlls/shdocvw/webbrowser.c,v > > retrieving revision 1.65 > > diff -u -r1.65 webbrowser.c > > --- dlls/shdocvw/webbrowser.c 25 Sep 2006 19:46:43 -0000 1.65 > > +++ dlls/shdocvw/webbrowser.c 29 Sep 2006 00:55:46 -0000 > > @@ -675,7 +675,7 @@ > > if(V_VT(URL) != VT_BSTR) > > return E_INVALIDARG; > > > > - if(PostData && V_VT(PostData) != VT_EMPTY) { > > + if(PostData && V_VT(PostData) != VT_EMPTY && V_VT(PostData) != VT_ERROR) { > > if(V_VT(PostData) != (VT_ARRAY | VT_UI1) > > || V_ARRAY(PostData)->cDims != 1) { > > WARN("Invalid PostData\n"); > > @@ -686,7 +686,7 @@ > > post_data_len = V_ARRAY(PostData)->rgsabound[0].cElements; > > } > > > > - if(Headers && V_VT(Headers) != VT_EMPTY) { > > + if(Headers && V_VT(Headers) != VT_EMPTY && V_VT(Headers) != VT_ERROR) { > > if(V_VT(Headers) != VT_BSTR) > > return E_INVALIDARG; > > > > > > > > ------------------------------------------------------------------------ > > > > > > > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani(a)redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart > > > > ------------------------------ > > Message: 3 > Date: Fri, 29 Sep 2006 10:59:02 +0200 > From: Michael Stefaniuc <mstefani(a)redhat.com> > Subject: Re: make test failure > To: wine-devel(a)winehq.org > Message-ID: <451CE056.5000702(a)redhat.com> > Content-Type: text/plain; charset=UTF-8 > > James Hawkins wrote: > > On 9/28/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > > >> James Hawkins wrote: > >> > On 9/28/06, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > >> >> On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: > >> >> > Hi, > >> >> > > >> >> > Running make test fails with: > >> >> > > >> >> > make[2]: Entering directory > >> `/usr/local/src/wine/dlls/comctl32/tests' > >> >> > ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p > >> >> > comctl32_test.exe.so tab.c && touch tab.ok > >> >> > tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >> [56,20] > >> >> > tab.c:208: Test failed: no icon, set size: Expected [42,20] got > >> [54,20] > >> >> > tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >> [56,20] > >> >> > tab.c:208: Test failed: no icon, set size: Expected [42,20] got > >> [54,20] > >> >> > tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >> [56,20] > >> >> > tab.c:184: Test failed: no icon, set size: Expected [54,20] got > >> [56,20] > >> >> > make[2]: *** [tab.ok] Error 6 > >> >> > > >> >> Succeeds over here. > >> >> > >> > > >> > I know, it succeeds on a lot of machines, but the point is that it > >> > shouldn't fail on any machine. > >> > > >> Please remove your ~/.wine dir and try again. It seems your metrics are > >> set different. Or your fonts are wrong. > >> > > > > The tests still fail with a clean .wine. > Yes, i used an empty .wine too. > > bye > michael > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani(a)redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart > > > > ------------------------------ > > Message: 4 > Date: Fri, 29 Sep 2006 12:33:27 +0200 > From: Michael Stefaniuc <mstefani(a)redhat.com> > Subject: Re: [D3D9] Remove const qualifier on state_test data. > To: ivg231(a)gmail.com > Cc: wine-devel(a)winehq.org > Message-ID: <451CF677.1040305(a)redhat.com> > Content-Type: text/plain; charset=UTF-8 > > Ivan Gyurdiev wrote: > > Type: Cleanup > > > > Why: > > The const qualifier is unnecessarily restrictive. > > I intend to allocate and free such data on the heap in a future patch. > > Instead, const should be primarily used on function parameters. > Question: do you realy have to use void pointers? Void pointers are > compatible with every pointer type and thus will disable the type > checking of the compiler. Also you do not need to to cast a rvalue to > void * if the type of the lvalue is void *. > > bye > michael > > > --- > > dlls/d3d9/tests/stateblock.c | 40 ++++++++++++++++++++-------------------- > > 1 files changed, 20 insertions(+), 20 deletions(-) > > > > diff --git a/dlls/d3d9/tests/stateblock.c b/dlls/d3d9/tests/stateblock.c > > index 65a11e6..68b431a 100644 > > --- a/dlls/d3d9/tests/stateblock.c > > +++ b/dlls/d3d9/tests/stateblock.c > > @@ -105,20 +105,20 @@ typedef struct state_test { > > * as the default data, but a write can have side effects. > > * The initial data is tested first, before any writes take place > > * The default data can be tested after a write */ > > - const void* initial_data; > > + void* initial_data; > > > > /* The default data is the standard state to compare > > * against, and restore to */ > > - const void* default_data; > > + void* default_data; > > > > /* The test data is the experiment data to try > > * in - what we want to write > > * out - what windows will actually write (not necessarily the same) */ > > - const void* test_data_in; > > - const void* test_data_out; > > + void* test_data_in; > > + void* test_data_out; > > > > /* The poison data is the data to preinitialize the return buffer to */ > > - const void* poison_data; > > + void* poison_data; > > > > /* Return buffer */ > > void* return_data; > > @@ -562,11 +562,11 @@ static void shader_constants_queue_test( > > shader_constant_arg* arg = buffer; > > shader_constant_data* return_data = (shader_constant_data*) (arg + 1); > > > > - test->test_data_in = &shader_constant_test_data; > > - test->test_data_out = &shader_constant_test_data; > > - test->default_data = &shader_constant_default_data; > > - test->initial_data = &shader_constant_default_data; > > - test->poison_data = &shader_constant_poison_data; > > + test->test_data_in = (void*) &shader_constant_test_data; > > + test->test_data_out = (void*) &shader_constant_test_data; > > + test->default_data = (void*) &shader_constant_default_data; > > + test->initial_data = (void*) &shader_constant_default_data; > > + test->poison_data = (void*) &shader_constant_poison_data; > > test->return_data = return_data; > > test->data_size = sizeof(shader_constant_data); > > test->set_handler = shader_constant_set_handler; > > @@ -697,11 +697,11 @@ static void lights_queue_test( > > light_arg* arg = buffer; > > light_data* return_data = (light_data*) (arg + 1); > > > > - test->test_data_in = &light_test_data_in; > > - test->test_data_out = &light_test_data_out; > > - test->default_data = &light_default_data; > > - test->initial_data = &light_initial_data; > > - test->poison_data = &light_poison_data; > > + test->test_data_in = (void*) &light_test_data_in; > > + test->test_data_out = (void*) &light_test_data_out; > > + test->default_data = (void*) &light_default_data; > > + test->initial_data = (void*) &light_initial_data; > > + test->poison_data = (void*) &light_poison_data; > > test->return_data = return_data; > > test->data_size = sizeof(light_data); > > test->set_handler = light_set_handler; > > @@ -856,11 +856,11 @@ static void transform_queue_test( > > { > > transform_data* return_data = buffer; > > > > - test->test_data_in = &transform_test_data; > > - test->test_data_out = &transform_test_data; > > - test->default_data = &transform_default_data; > > - test->initial_data = &transform_default_data; > > - test->poison_data = &transform_poison_data; > > + test->test_data_in = (void*) &transform_test_data; > > + test->test_data_out = (void*) &transform_test_data; > > + test->default_data = (void*) &transform_default_data; > > + test->initial_data = (void*) &transform_default_data; > > + test->poison_data = (void*) &transform_poison_data; > > test->return_data = return_data; > > test->data_size = sizeof(transform_data); > > test->set_handler = transform_set_handler; > > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Sr. Network Engineer Fax.: +49-711-96437-111 > Red Hat GmbH Email: mstefani(a)redhat.com > Hauptstaetterstr. 58 http://www.redhat.de/ > D-70178 Stuttgart > > > > ------------------------------ > > Message: 5 > Date: Fri, 29 Sep 2006 09:06:48 -0400 > From: "Gerald Britton" <gerald.britton(a)gmail.com> > Subject: compiling wine for amd64 on ubuntu dapper 6.06 > To: wine-devel(a)winehq.org > Message-ID: > <5d1a32000609290606u56007017t6f8ace8de14bb0ab(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi -- I'm trying to get wine going on my ubuntu dapper installation on > an amd 64 box. I have followed the wiki instructions in > http://wiki.winehq.org/WineOn64bit for ubuntu and rechecked my work. > Two things go wrong: > > 1. /configure can't find opengl, and produces these messages: > > configure: WARNING: Wine will be build without OpenGL or Direct3D support > configure: WARNING: because something is wrong with the OpenGL setup: > configure: WARNING: No OpenGL library found on this system. > > 2. make depend works, but make all fails with this: > > LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc > --nostdinc -I. -I. -I../../include -I../../include > -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -foversion.res > version.rc > ../../tools/winegcc/winegcc -B../../tools/winebuild -shared > ./gdi32.spec dispdib.spec.o gdi.exe.spec.o wing.spec.o bidi16.o > dispdib.o env.o gdi16.o metafile16.o wing.o bidi.o bitblt.o bitmap.o > brush.o clipping.o dc.o dib.o driver.o enhmetafile.o enhmfdrv/bitblt.o > enhmfdrv/dc.o enhmfdrv/graphics.o enhmfdrv/init.o enhmfdrv/mapping.o > enhmfdrv/objects.o font.o freetype.o gdi_main.o gdiobj.o icm.o > mapping.o metafile.o mfdrv/bitblt.o mfdrv/dc.o mfdrv/graphics.o > mfdrv/init.o mfdrv/mapping.o mfdrv/objects.o mfdrv/text.o painting.o > palette.o path.o pen.o printdrv.o region.o version.res -o > gdi32.dll.so -ladvapi32 -lkernel32 -lntdll /usr/lib/libsicuuc.a > /usr/lib/libsicudata.a -lstdc++ -lgcc_s ../../libs/port/libwine_port.a > -L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 > ld: Relocatable linking with relocations from format elf64-x86-64 > (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.ArPHdq.o) > is not supported > winebuild: ld -m elf_i386 -r failed with status 256 > winegcc: ../../tools/winebuild/winebuild failed. > make[2]: *** [gdi32.dll.so] Error 2 > make[2]: Leaving directory `/tmp/wine-0.9.22/dlls/gdi' > make[1]: *** [gdi] Error 2 > make[1]: Leaving directory `/tmp/wine-0.9.22/dlls' > make: *** [dlls] Error 2 > > > > I'm not sure what to do now. Any feedback/suggestions would be appreciated. > > > > ------------------------------ > > Message: 6 > Date: Fri, 29 Sep 2006 07:36:58 -0600 > From: Vitaliy Margolen <wine-devel(a)kievinfo.com> > Subject: Re: make test failure > To: wine-devel(a)winehq.org > Message-ID: <451D217A.4060808(a)kievinfo.com> > Content-Type: text/plain; charset=UTF-8 > > Michael Stefaniuc wrote: > > James Hawkins wrote: > >> On 9/28/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > >> > >>> James Hawkins wrote: > >>>> On 9/28/06, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > >>>>> On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote: > >>>>>> Hi, > >>>>>> > >>>>>> Running make test fails with: > >>>>>> > >>>>>> make[2]: Entering directory > >>> `/usr/local/src/wine/dlls/comctl32/tests' > >>>>>> ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p > >>>>>> comctl32_test.exe.so tab.c && touch tab.ok > >>>>>> tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >>> [56,20] > >>>>>> tab.c:208: Test failed: no icon, set size: Expected [42,20] got > >>> [54,20] > >>>>>> tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >>> [56,20] > >>>>>> tab.c:208: Test failed: no icon, set size: Expected [42,20] got > >>> [54,20] > >>>>>> tab.c:184: Test failed: no icon, set size: Expected [44,20] got > >>> [56,20] > >>>>>> tab.c:184: Test failed: no icon, set size: Expected [54,20] got > >>> [56,20] > >>>>>> make[2]: *** [tab.ok] Error 6 > >>>>>> > >>>>> Succeeds over here. > >>>>> > >>>> I know, it succeeds on a lot of machines, but the point is that it > >>>> shouldn't fail on any machine. > >>>> > >>> Please remove your ~/.wine dir and try again. It seems your metrics are > >>> set different. Or your fonts are wrong. > >>> > >> The tests still fail with a clean .wine. > > Yes, i used an empty .wine too. > > > And you guys have windows like "Arial" font? Any test that uses fonts > will not work if you don't have that font or it's not the same metrics > as the native one. > > Vitaliy. > > > > ------------------------------ > > Message: 7 > Date: Fri, 29 Sep 2006 08:36:46 -0700 (PDT) > From: Juan Lang <juan_lang(a)yahoo.com> > Subject: Re: shdocvw(2/2): ignore VT_ERROR arguments to > WebBrowser_Navigate2 > To: Michael Stefaniuc <mstefani(a)redhat.com> > Cc: wine-devel(a)winehq.org > Message-ID: <20060929153646.65850.qmail(a)web30008.mail.mud.yahoo.com> > Content-Type: text/plain; charset=iso-8859-1 > > > Ignoring VT_ERROR just masks a previous error. > > Hm.. are you sure? These are input arguments, not results. This isn't > the only app that gets further with this patch. See also bug 6166. > > I guess a test case is the only answer. > > --Juan > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > ------------------------------ > > Message: 8 > Date: Fri, 29 Sep 2006 09:57:35 -0700 (PDT) > From: Juan Lang <juan_lang(a)yahoo.com> > Subject: Re: USER32: Stub implementation of BlockInput > To: Jason Green <jave27(a)gmail.com> > Cc: wine-devel(a)winehq.org > Message-ID: <20060929165735.77898.qmail(a)web30010.mail.mud.yahoo.com> > Content-Type: text/plain; charset=iso-8859-1 > > You forgot the patch.. > > --Juan > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > ------------------------------ > > _______________________________________________ > wine-devel mailing list - wine-devel(a)winehq.org > http://www.winehq.org/mailman/listinfo/wine-devel > > > End of wine-devel Digest, Vol 14, Issue 93 > ******************************************

1 0

Re: make test failure #6
by Juan Lang Sept. 29, 2006

Sept. 29, 2006

Hi James, > make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' > ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p > user32_test.exe.so sysparams.c && touch sysparams.ok > sysparams.c:1471: Test failed: wrong value in registry -1, expected 154 > sysparams.c:1474: Test failed: wrong value in registry -1, expected 0 > sysparams.c:1477: Test failed: wrong value in registry -1, expected 0 > sysparams.c:1480: Test failed: wrong value in registry -1, expected 8 > make[2]: *** [sysparams.ok] Error 4 This, like many other errors, disappears for me when I rerun make test. (I'm not too happy with the 'rerun make test' option, but I don't see people falling all over themselves up to fix the tests, either.) --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[rsaenh-test]: import&export of a plaintext public key + algID check
by Karsten Elfenbein Sept. 29, 2006

Sept. 29, 2006

* test for importing a PlainPublicKey * test for the correct ALG_ID after the import * test for the correct PlainPublicKey after exporting the key again Karsten

1 0

make test failure (#7?)
by Juan Lang Sept. 29, 2006

Sept. 29, 2006

After I run make test a bunch of times to get other failures to disappear, I get this: make[2]: Entering directory `/home/juan/src/wine-20050725/dlls/user/tests' ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so win.c && touch win.ok fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE win.c:2554: Test failed: message 000f available make[2]: *** [win.ok] Error 1 make[2]: Leaving directory `/home/juan/src/wine-20050725/dlls/user/tests' make[1]: *** [user/tests/__test__] Error 2 make[1]: Leaving directory `/home/juan/src/wine-20050725/dlls' make: *** [dlls/__test__] Error 2 --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: shdocvw: Make sure BSTR is allocated before calling sink
by Jacek Caban Sept. 29, 2006

Sept. 29, 2006

Hi Cihan, Cihan Altinay wrote: > This fixes bug 6054 and let's MSN Messenger 7 start up. > http://bugs.winehq.org/show_bug.cgi?id=6054 > > --- > dlls/shdocvw/dochost.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/shdocvw/dochost.c b/dlls/shdocvw/dochost.c > index 5bb40e0..8d78a49 100644 > --- a/dlls/shdocvw/dochost.c > +++ b/dlls/shdocvw/dochost.c > @@ -49,11 +49,12 @@ static void navigate_complete(DocHost *T > V_DISPATCH(params+1) = disp; > > V_VT(&url) = VT_BSTR; > - V_BSTR(&url) = This->url; > + V_BSTR(&url) = SysAllocString(This->url); > > call_sink(This->cps.wbe2, DISPID_NAVIGATECOMPLETE2, &dispparams); > call_sink(This->cps.wbe2, DISPID_DOCUMENTCOMPLETE, &dispparams); > > + SysFreeString(This->url); You should free V_BSTR(&url) here, not This->url. Jacek

1 0

make test failure
by James Hawkins Sept. 29, 2006

Sept. 29, 2006

Hi, Running make test fails with: make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests' ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so tab.c && touch tab.ok tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:208: Test failed: no icon, set size: Expected [42,20] got [54,20] tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20] tab.c:184: Test failed: no icon, set size: Expected [54,20] got [56,20] make[2]: *** [tab.ok] Error 6 -- James Hawkins

4 8

Re: USER32: Stub implementation of BlockInput
by Juan Lang Sept. 29, 2006

Sept. 29, 2006

You forgot the patch.. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Governance Ideas
by Robert Lunnon Sept. 29, 2006

Sept. 29, 2006

Alexandre said ========================================= To be honest, I have no idea what it is that you are suggesting. All I see is phrases like "community focused process" or "acceptance policy" which frankly are just meaningless buzzwords. If you expect anything to happen, you'll need to make much more concrete suggestions, and provide examples to make us understand how what you are suggesting would work in practice, and how it would be different from what we are doing now. -- Alexandre Julliard julliard(a)winehq.org ========================================== To which I said I would respond soon - well here goes. From the outset I want to say that I am not going to redefine the wine project or make suggestions in the sense of a particular change. I want the communities of developers users and others to define that change. What I will do here is suggest ways in which we could organise to make a change as a collective. Firstly the buzzwords "Community Focused Process" means what it says, develop a process which is centred on the community the project serves. This requires the project to answer some introspective questions 1. Who "owns" Wine, does wine belong to A.) Alexandre, or B) the community it serves. 2 If the answer is B then which community. It may surprise some to realise that a project like this has many communities. We discovered this when setting up the OpenSolaris community process. Some obvious ones are "The Developer Community" and "The User Community" and "Developer + User" Community. There are other less obvious communities, eg the community of distribution maintainers who may be neither developer or user. If we decide that the community "Owns" Wine then it needs to be established whether the community has a right to direct wine's development. As the "Owner" I'd argue the community should have this right. Second Buzzword "Patch Acceptance Policy" means the rules by which a patch is deemed acceptable or not. At the moment this is pretty close to "It's acceptable if Alexandre commits it" This is OK in a community process as long as the community that wine serves supports this approach. I think the recent thread throws significant doubt on this. This particular patch acceptance policy is not Transparent, this is the key reason why dropped patches cause so much argument, why many developers leave the project and possibly why Wine doesn't get the major backing some projects do (EG Gnome, KDE Xorg) dealing with the wine project is risky business. Now what do I propose... 1. Answer the questions about the "ownership" of wine and identify the community it serves. Determine the right of the community to be involved is setting wines direction IE The Bill of rights I mentioned before (for each community Developers VS Users etc). 2. Alexandre documents the exact logic he uses to determine patch acceptability which becomes the patch acceptance policy in the interim. This should be done to the point that someone else could take over from Alexandre and achieve the same result. This opens the way to multiple maintainers as well as allowing Alexandre to take more holidays. 3. The project develops a community process for establishing project direction and maintaining the patch acceptance policy which includes stakeholders elected from the "owners" IE communities with a stakeholding in wine 4. A community process is run to A.) Establish the communities objective for wine - this will actually probably be reasonably argumentative, but that is exactly how it should be. If it's not there is probably something wrong. It was with OpenSolaris and governance was the greatest concern with that project too. B) review the Patch acceptance policy in line with the community objective. For example the policy may be adjusted to favour functionality improvements, or loosen gating on changes leading to solutions that wine critically needs or even establish a "must have" application. 5. A mechanism is created to independently review patches (appeal process) for acceptability IE Whether a patch meets the acceptance policy. Note that if a patch acceptable to the policy is rejected then the policy may need to change (Requiring a new community process to review that change) or an architectural decision needs to be taken. This is done by the architecture review board in the OpenSolaris process. Among other things when a patch is sent to appeal the owner of the patch is guaranteed an explanation of how the patch doesn't meet the acceptance policy. Now if we did all this we would * Have a picture of the needs of the community * Have a way to direct the project toward meeting that need * Have a way to demonstrate we intend to meet that need * Have a consistent review process for patches * Have a way to multistream patches * Have an open transparent, trusting and consistent environment in which to work * Have a way to change and grow * Open ways to allow business to confidently invest in Wine. Even if we ended up with exactly what we have now we will have improved transparency resulting in higher quality of work and less resentment of the process, improving developer retention rates and reducing disputes. Bob

6 5

make test failure #3
by James Hawkins Sept. 29, 2006

Sept. 29, 2006

Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:168: Test failed: The requested file does not exist, ret=3 make[2]: *** [shlfileop.ok] Error 1 -- James Hawkins

2 1

make test failure #5
by James Hawkins Sept. 29, 2006

Sept. 29, 2006

Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' msg.c:3700: Test failed: DrawMenuBar: the msg sequence is not complete: expected 0000 - actual 0021 msg.c:3727: Test failed: MsgWaitForMultipleObjects returned 0 fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet msg.c:6768: Test failed: WmEmpty: the msg sequence is not complete: expected 0000 - actual 0014 make[2]: *** [msg.ok] Error 3 -- James Hawkins

2 2

make test failure #2
by James Hawkins Sept. 28, 2006

Sept. 28, 2006

Hi, This test passes on my machine, should it not? make[2]: Entering directory `/usr/local/src/wine/dlls/d3d9/tests' ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so surface.c && touch surface.ok fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x18cd10) : stub, simulating 64MB for now, returning 64MB left surface.c:131: Test succeeded inside todo block: Got pitch 12, expected 12 make[2]: *** [surface.ok] Error 1 -- James Hawkins

3 3

make test failure #6
by James Hawkins Sept. 28, 2006

Sept. 28, 2006

Hi, This is with a clean .wine. make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so sysparams.c && touch sysparams.ok sysparams.c:1471: Test failed: wrong value in registry -1, expected 154 sysparams.c:1474: Test failed: wrong value in registry -1, expected 0 sysparams.c:1477: Test failed: wrong value in registry -1, expected 0 sysparams.c:1480: Test failed: wrong value in registry -1, expected 8 make[2]: *** [sysparams.ok] Error 4 -- James Hawkins

1 0

make test failure #4
by James Hawkins Sept. 28, 2006

Sept. 28, 2006

Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[0]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[1]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[2]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[3]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) make[2]: *** [monitor.ok] Error 4 -- James Hawkins

1 0

Re: Route WGL font code through gdi32.dll
by Huw Davies Sept. 28, 2006

Sept. 28, 2006

On Thu, Sep 28, 2006 at 08:20:51PM +0200, Roderick Colenbrander wrote: > Again as mentioned by Huw, the gdi32.spec file wasn't correct. > It should be correct this time. No. Your gdi32.spec was fine. It was the opengl32.spec that was wrong (hint: that's why I quoted that bit of the patch ;-). Your patch is for the wglUseFont*Bitmaps* functions and not the wglUseFont*Outlines* functions, so the only thing that should be changing is the former and not the latter. So in opengl32.spec you need to forward the wglUseFont*Bitmaps* functions to functions of the same name in gdi32. Huw.

2 1

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype (2nd attempt)
by Vitaliy Margolen Sept. 28, 2006

Sept. 28, 2006

Thomas Weidenmueller wrote: > The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, > not unsigned int. > > - Thomas > It's been discussed numerous times, you should avoid use of 'long' in Wine. On win64 sizeof(long) == 4. On Linux64 sizeof(long) == 8. Vitaliy.

1 1

Re: Patchwork (was Re: Governance revisited)
by Ge van Geldorp Sept. 28, 2006

Sept. 28, 2006

> From: Vitaliy Margolen <wine-devel(a)kievinfo.com> > > So in a sense you will require some one to respond for any > incoming e-mail to wine-patches. And if no one does, > Alexandre don't get to see the status? Not sure I understand what you mean. If no-one responds to the patch on wine-devel the patch would remain queued and it would show up in Alexandres list. > What if he already > applied the patch? Now you slowing down what would have > worked just fine before. If the patch is already applied it would be marked as such in the database. When a message is sent to wine-devel after the fact, it won't get magically un-applied. > Ok now you making it dependant on an e-mail client. Yet > that's exactly what we are trying avoid with GIT. Actually, my preference would be to do patch management via a web-based interface. But that's just my preference, I assume a lot of other people prefer the mailinglist method. So let's try to support both. > Not really. You can't make some one to review something that > don't understand. Or if they are busy/on vacation/away from > PC/etc. I'm not trying to change the review process, it would remain as-is. The only addition would be a bot which could do some checks (e.g. does the patch apply cleanly?). But that bot could be introduced anyway, even if Patchwork isn't introduced, so I guess it's not an integral part of the proposed system. > So in the end you'll end up with either huge queue > that no one wants to touch. Or a "clean up" jobs that will > once in a while go and mark all patches as old and will > require authors to resubmit. How's that better then what we use now? If no-one touches a patch, it would end up on Alexandres plate. He could review the patch himself or ask a subsystem maintainer to review it. Again, that's not different from the current system. If the queue of patches waiting for commit grows without bounds, that's a clear indication that Alexandre is overloaded and the project should find ways to remove some of his workload. The same would happen without a patch management system, but perhaps it wouldn't be as visible, so I'm chalking this one up as an added benefit of a patch management system. The system would also be self-cleaning. If a patch has been in RFC status too long it would be deleted from the queue (with appropriate warning email to the author) http://www.winehq.org/pipermail/wine-devel/2006-September/051114.html > When people well send out right hacks and expect some one to > tell then what they really should do. Current system allows > to no waste any time on such craft. We seem to have fundamentally different views of the "peripheral" (non-core) Wine developers. You seem to view them as potentially bad guys, going out of their way to submit hacks and decrease the quality of Wine code as much as possible, people you'd rather see leave. I see people willing to donate their time to improve Wine. Sure, they make mistakes but at least they make an effort. > No, by requiring some one to respond you making them > responsible (at least until they respond). Of course > responses like "sucks" wouldn't be nice, so some one who does > understand the subject will have to spend their time to > understand the patch, write a review of the patch and send > it. I don't get your point here. Isn't the purpose of reviewing to actually review the patch? > And you want that ASAP! Which means whenever patch > arrives in wine-patches some one (most likely more then one > person) will stop everything they are doing, and start > writing a review? No, I don't want to change the review process. It can remain just as it is now. My objective is to improve Wine by maximizing the number of patches of acceptable quality. In my opinion, this can be done by: 1) assuring no patches get lost 2) assuring an author gets informed about why his patch is not acceptable in its current form so he can improve it. Ge van Geldorp.

4 6

Award for solving bug 6183
by Mirek Sept. 28, 2006

Sept. 28, 2006

There is bug in wine, which prevents me to play NFS MW with sound (and even Call of Duty). I would like to offer some money for solving this bug. I dont know how much will be good and i can give you all info from my system to solve this (debug, system info). If you are interested in just reply on my email address. Thanks, Mirek

1 0

Re: Setupapi: add stubs [resend]
by Alexandre Julliard Sept. 28, 2006

Sept. 28, 2006

Julien <julienc(a)psychologie-fr.org> writes: > +/*********************************************************************** > + * SetupDiDestroyClassImageList(SETUPAPI.@) > + */ > +BOOL WINAPI SetupDiDestroyClassImageList(PSP_CLASSIMAGELIST_DATA ClassImageListData) > +{ > + FIXME ("Stub %p\n", ClassImageListData); > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return TRUE; > +} > + > +/*********************************************************************** > + * SetupDiGetClassImageList(SETUPAPI.@) > + */ > +BOOL WINAPI SetupDiGetClassImageList(PSP_CLASSIMAGELIST_DATA ClassImageListData) > +{ > + FIXME ("Stub %p\n", ClassImageListData); > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return TRUE; > +} It makes no sense to set last error if you return success. And you really shouldn't return success unless you also store the right things in that data structure. -- Alexandre Julliard julliard(a)winehq.org

1 0