March 2014 - Wine-Devel - list.winehq.org

Need help getting Win32_PNPEntity WMI class added

by Luke A. Guest

Hi, I thought I understood this thing, but I don't. I'm trying to get this working so that I can work towards getting Rocksmith going. I've added: diff --git a/dlls/wbemprox/builtin.c b/dlls/wbemprox/builtin.c index 4b02ea2..0051837 100644 --- a/dlls/wbemprox/builtin.c +++ b/dlls/wbemprox/builtin.c @@ -75,6 +75,8 @@ static const WCHAR class_paramsW[] = {'_','_','P','A','R','A','M','E','T','E','R','S',0}; static const WCHAR class_physicalmediaW[] = {'W','i','n','3','2','_','P','h','y','s','i','c','a','l','M','e','d','i','a',0}; +static const WCHAR class_pnpentityW[] = + {'W','i','n','3','2','_','P','N','P','E','n','t','i','t','y',0}; static const WCHAR class_qualifiersW[] = {'_','_','Q','U','A','L','I','F','I','E','R','S',0}; static const WCHAR class_process_getowner_outW[] = @@ -394,6 +396,10 @@ static const struct column col_physicalmedia[] = { { prop_serialnumberW, CIM_STRING } }; +static const struct column col_pnpentity[] = +{ + { prop_deviceidW, CIM_STRING|COL_FLAG_KEY } +}; static const struct column col_process[] = { { prop_captionW, CIM_STRING|COL_FLAG_DYNAMIC }, @@ -513,6 +519,8 @@ static const WCHAR diskdrive_manufacturerW[] = {'(','S','t','a','n','d','a','r','d',' ','d','i','s','k',' ','d','r','i','v','e','s',')',0}; static const WCHAR diskdrive_serialW[] = {'W','I','N','E','H','D','I','S','K',0}; +static const WCHAR pnpentity_rscableW[] = + {'U','S','B','\ \','V','I','D','_','1','2','B','A','&','P','I','D','_','0','0','F','F','&','R','E','V','_','0','1','0','0',0}; static const WCHAR networkadapter_pnpdeviceidW[]= {'P','C','I','\ \','V','E','N','_','8','0','8','6','&','D','E','V','_','1','0','0','E','&', 'S','U','B','S','Y','S','_','0','0','1','E','8','0','8','6','&','R','E','V','_','0','2','\\', @@ -796,6 +804,10 @@ static const struct record_physicalmedia data_physicalmedia[] = { { diskdrive_serialW } }; +static const struct record_physicalmedia data_pnpentity[] = +{ + { pnpentity_rscableW } +}; static const struct record_qualifier data_qualifier[] = { { class_process_getowner_outW, param_userW, CIM_SINT32, FLAVOR_ID, prop_idW, 0 }, @@ -2241,6 +2253,7 @@ static struct table builtin_classes[] = { class_osW, SIZEOF(col_os), col_os, 0, 0, NULL, fill_os }, { class_paramsW, SIZEOF(col_param), col_param, SIZEOF(data_param), 0, (BYTE *)data_param }, { class_physicalmediaW, SIZEOF(col_physicalmedia), col_physicalmedia, SIZEOF(data_physicalmedia), 0, (BYTE *)data_physicalmedia }, + { class_pnpentityW, SIZEOF(col_pnpentity), col_pnpentity, SIZEOF(data_pnpentity), 0, (BYTE *)data_pnpentity }, { class_processW, SIZEOF(col_process), col_process, 0, 0, NULL, fill_process }, { class_processorW, SIZEOF(col_processor), col_processor, 0, 0, NULL, fill_processor }, { class_qualifiersW, SIZEOF(col_qualifier), col_qualifier, SIZEOF(data_qualifier), 0, (BYTE *)data_qualifier }, With the *_pnpentity* elements being mine. I've hardcoded the USB device hardware ID in for now. I also added a TRACE to get_propval, but that's not being called. Here's the relevant part of the log: 0009:trace:wbemprox:wbem_services_CreateInstanceEnum 0x3cd6b58, L"Win32_PNPEntity", 000000000, (nil), 0x32f858 0009:trace:wbemprox:parse_query parse_query: L"SELECT * FROM Win32_PNPEntity" 0009:trace:wbemprox:parse_query wql_parse returned 0 0009:trace:wbemprox:EnumWbemClassObject_create 0x32f858 0009:trace:wbemprox:EnumWbemClassObject_create returning iface 0x3cd6ea8 0009:trace:wbemprox:enum_class_object_Next 0x3cd6ea8, 10000, 20, 0x32f888, 0x32f864 0009:fixme:wbemprox:enum_class_object_Next timeout not supported 0009:trace:wbemprox:enum_class_object_Release destroying 0x3cd6ea8 0009:trace:wbemprox:wbem_locator_Release destroying 0x3cd6cc8 0009:trace:wbemprox:wbem_services_Release destroying 0x3cd6b58 0009:trace:wbemprox:DllGetClassObject {4590f811-1d3a-11d0-891f-00aa004b2e24} {00000001-0000-0000-c000-000000000046} 0x32f80c 0009:trace:wbemprox:wbemprox_cf_CreateInstance (nil) {dc12a687-737f-11cf-884d-00aa004b2e24} 0x32f85c 0009:trace:wbemprox:WbemLocator_create (0x32f78c) 0009:trace:wbemprox:WbemLocator_create returning iface 0x3cd6b78 0009:trace:wbemprox:wbem_locator_QueryInterface 0x3cd6b78 {dc12a687-737f-11cf-884d-00aa004b2e24} 0x32f85c 0009:trace:wbemprox:wbem_locator_ConnectServer 0x3cd6b78, L"\\\\.\\root\ \cimv2", (null), (null), (null), 0x00000000, (null), (nil), 0x32f860) 0009:trace:wbemprox:WbemServices_create (0x32f860) 0009:trace:wbemprox:WbemServices_create returning iface 0x3cd6f10 Have I missed something here? Thanks, Luke.

March 2, 2014

Re: fonts: Add Liberation Sans (SIL Open Font License) as an Arialreplacement.

by Mariusz Wawrzyński

thank you very much for message. I do not know NET platform. Dnia 27 lutego 2014 23:14 "Erich E. Hoover" <erich.e.hoover(a)gmail.com> napisał(a): The attached patch adds the Arial font (arial.ttf) using version 2.00.1 of the Liberation Sans font. The Liberation Sans font is licensed under the SIL Open Font License, which is, to the best of my knowledge, compatible with our other license restrictions. This patch fixes an issue where several Silveright and .NET applications expect either Arial or Verdana to be installed on the system (Bug #32323).

March 2, 2014

Re: dpnet: Check if DirectDplay is installed

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5312 Your paranoid android. === build (build) === Patch failed to apply

March 2, 2014

Re: patch:add HANDLE

by Nikolay Sivov

On 3/2/2014 14:13, 中川祥 wrote: > Handle for eventlog. > It is different from event. > It's almost same as hfile,but more info needed. > Is it implemented? What event log API are you talking about? Why does this handle have to be maintained by a server? > > > 2014-03-02 16:19 GMT+09:00 Nikolay Sivov <bunglehead(a)gmail.com > <mailto:bunglehead(a)gmail.com>>: > > On 3/2/2014 10:44, Akira Nakagawa wrote: > > What's that about? > >

March 2, 2014

Re: patch:add HANDLE

by Nikolay Sivov

On 3/2/2014 10:44, Akira Nakagawa wrote: What's that about?

March 2, 2014

Re: [PATCH 2/3] gdiplus: Set outer pointer to NULL when image loading functions fail.

by Dmitry Timoshkov

Qian Hong <qhong(a)codeweavers.com> wrote: > >> + *bitmap = NULL; > > > > Is there an application that depends on this behaviour? > > No, I don't know yet. I hope maybe some app will be benefited from > this change. Any advice? Probably this change is OK since it matches what GdipLoadImageFromFile does. > >> stat = GdipCreateStreamOnFile(filename, GENERIC_READ, &stream); > >> > >> if(stat != Ok) > >> - return stat; > >> + return InvalidParameter; > > > > Probably GdipCreateStreamOnFile should be fixed instead (with tests > > of course). > > 1. I have some tests in [Patch 3/3] which show that the error code > from GdipCreateStreamOnFile doesn't match the error code from > GdipCreateBitmapFromFile. > 2. I haven't found any real world app rely on return code from > GdipCreateStreamOnFile, so I leave those todo_wine there. > 3. I haven't found any real world app rely on return code from > GdipCreateBitmapFromFile as well, I don't have strong opinion here. > > What's your advice regarding the return code here? A common rule is to propagate errors from lower level APIs. > >> stat = GdipCreateStreamOnFile(filename, GENERIC_READ, &stream); > >> > >> if (stat != Ok) > >> - return stat; > >> + return OutOfMemory; > > > > Same note about GdipCreateStreamOnFile. And I don't think that's a good > > idea to replicate weird return error codes without actually getting any > > memory allocation errors. > > The same situation here: > 1. return code from GdipCreateStreamOnFile doesn't match return code > from GdipLoadImageFromFile > 2. haven't found real world app reply on the return code yet. > > Any advice? There is no need to change something just to replicate behaviour that you don't really understand. -- Dmitry.

March 2, 2014

Re: [PATCH 2/3] gdiplus: Set outer pointer to NULL when image loading functions fail.

by Qian Hong

Hi Dmitry, Thanks for comment :) On Sun, Mar 2, 2014 at 10:50 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: >> + *bitmap = NULL; > > Is there an application that depends on this behaviour? No, I don't know yet. I hope maybe some app will be benefited from this change. Any advice? >> stat = GdipCreateStreamOnFile(filename, GENERIC_READ, &stream); >> >> if(stat != Ok) >> - return stat; >> + return InvalidParameter; > > Probably GdipCreateStreamOnFile should be fixed instead (with tests > of course). 1. I have some tests in [Patch 3/3] which show that the error code from GdipCreateStreamOnFile doesn't match the error code from GdipCreateBitmapFromFile. 2. I haven't found any real world app rely on return code from GdipCreateStreamOnFile, so I leave those todo_wine there. 3. I haven't found any real world app rely on return code from GdipCreateBitmapFromFile as well, I don't have strong opinion here. What's your advice regarding the return code here? >> + *image = NULL; > > Same question as above. Yes for this one. As the email said, 'Essence Securities.' depends on this behavior. http://www.essence.com.cn/essence/softInfoAction.do?method=addSoftLog&urlId… ~/.wine/drive_c/AX/2003$ WINEDEBUG=+tid,+gdiplus,+seh wine client_rzrq.exe 0009:trace:gdiplus:GdipLoadImageFromFile (L"") 0x329c44 0009:trace:gdiplus:GdipCreateStreamOnFile (L"", 2147483648, 0x329bdc) ... 0009:trace:gdiplus:GdipDrawImageRect (0x1d3ed8, 0x320000, 4.00, -3.00, 30.00, 30.00) 0009:trace:gdiplus:GdipGetImageBounds 0x320000 0x329bc0 0x329bd0 wine: Unhandled page fault on read access to 0x00000000 at address 0x7d33495d (thread 0009), starting debugger... Backtrace: =>0 0x7d33495d ipicture_pixel_width+0x15(pic=(nil)) [/home/fracting/wine-git/dlls/gdiplus/../../include/ocidl.h:1221] in gdiplus (0x00329af8) 1 0x7d3440fc GdipGetImageBounds+0x141(image=0x320000, srcRect=0x329bc0, srcUnit=0x329bd0) [/home/fracting/wine-git/dlls/gdiplus/image.c:2158] in gdiplus (0x00329b68) 2 0x7d3239ba GdipDrawImageRect+0xc4(graphics=<couldn't compute location>, image=<couldn't compute location>, x=<couldn't compute location>, y=<couldn't compute location>, width=<couldn't compute location>, height=<couldn't compute location>) [/home/fracting/wine-git/dlls/gdiplus/graphics.c:3146] in gdiplus (0x00329bf8) 3 0x0040f799 in client_rzrq (+0xf798) (0x0032e9a8) ... 0x7d33495d ipicture_pixel_width+0x15 [/home/fracting/wine-git/dlls/gdiplus/../../include/ocidl.h:1221] in gdiplus: movl 0x0(%eax),%eax 1221 return This->lpVtbl->get_Width(This,pWidth); 1. The program pass &image to GdipLoadImageFromFile, while image->picture is NULL; 2. GdipLoadImageFromFile of cause didn't load any image because file name is empty; 3. Unfortunately the program didn't check the return code from GdipLoadImageFromFile, and pass image to GdipDrawImageRect 4. Finally crashing happen in gdiplus because image->picture is NULL. (I have a test for empty file name which has the same result with non-existent file, so I didn't add it to the patch) >> stat = GdipCreateStreamOnFile(filename, GENERIC_READ, &stream); >> >> if (stat != Ok) >> - return stat; >> + return OutOfMemory; > > Same note about GdipCreateStreamOnFile. And I don't think that's a good > idea to replicate weird return error codes without actually getting any > memory allocation errors. The same situation here: 1. return code from GdipCreateStreamOnFile doesn't match return code from GdipLoadImageFromFile 2. haven't found real world app reply on the return code yet. Any advice? Thanks for every lines of comment :) -- Regards, Qian Hong - http://www.codeweavers.com

March 1, 2014

Re: [PATCH 3/3] gdiplus/tests: Added tests for GdipCreateStreamOnFile.

by Dmitry Timoshkov

Qian Hong <qhong(a)codeweavers.com> wrote: > +static void test_gdipstream(void) > +{ > + IStream *stream; > + WCHAR nonexistentW[] = {'n','o','n','e','x','i','s','t','.','b','m','p','\0'}; > + WCHAR nonshareW[] = {'n','o','n','s','h','a','r','e','.','b','m','p','\0'}; > + GpStatus stat; > + HANDLE hfile; > + > + hfile = CreateFileW(nonshareW, GENERIC_READ, 0, NULL, CREATE_NEW, FILE_FLAG_DELETE_ON_CLOSE, 0); > + ok(hfile != INVALID_HANDLE_VALUE, "failed to create file\n"); Same problem with temp files in current directory. > + stream = (IStream *)0xdeadcafe; > + stat = GdipCreateStreamOnFile(nonexistentW, GENERIC_READ, &stream); > + todo_wine ok(stat == NotImplemented, "returned %d, expected NotImplemented\n", stat); > + todo_wine ok(stream == (IStream *)0xdeadcafe, "returned %p\n", stream); > + > + stream = (IStream *)0xdeadcafe; > + stat = GdipCreateStreamOnFile(nonshareW, GENERIC_READ, &stream); > + todo_wine ok(stat == NotImplemented, "returned %d, expected NotImplemented\n", stat); > + todo_wine ok(stream == (IStream *)0xdeadcafe, "returned %p\n", stream); > + > + CloseHandle(hfile); > +} Please use common 0xdeadbeef instead of new inventions. -- Dmitry.

March 1, 2014

Re: [PATCH 2/3] gdiplus: Set outer pointer to NULL when image loading functions fail.

by Dmitry Timoshkov

Qian Hong <qhong(a)codeweavers.com> wrote: > @@ -1365,10 +1365,12 @@ GpStatus WINGDIPAPI GdipCreateBitmapFromFile(GDIPCONST WCHAR* filename, > if(!filename || !bitmap) > return InvalidParameter; > > + *bitmap = NULL; Is there an application that depends on this behaviour? > stat = GdipCreateStreamOnFile(filename, GENERIC_READ, &stream); > > if(stat != Ok) > - return stat; > + return InvalidParameter; Probably GdipCreateStreamOnFile should be fixed instead (with tests of course). > > stat = GdipCreateBitmapFromStream(stream, bitmap); > > @@ -2923,10 +2925,12 @@ GpStatus WINGDIPAPI GdipLoadImageFromFile(GDIPCONST WCHAR* filename, > if (!filename || !image) > return InvalidParameter; > > + *image = NULL; Same question as above. > stat = GdipCreateStreamOnFile(filename, GENERIC_READ, &stream); > > if (stat != Ok) > - return stat; > + return OutOfMemory; Same note about GdipCreateStreamOnFile. And I don't think that's a good idea to replicate weird return error codes without actually getting any memory allocation errors. -- Dmitry.

March 1, 2014

Re: [PATCH 1/3] gdiplus/tests: Added more tests for image loading functions.

by Dmitry Timoshkov

Qian Hong <qhong(a)codeweavers.com> wrote: > + WCHAR nonexistentW[] = {'n','o','n','e','x','i','s','t','.','b','m','p','\0'}; > + WCHAR nonshareW[] = {'n','o','n','s','h','a','r','e','.','b','m','p','\0'}; > + HANDLE hfile; > + > + hfile = CreateFileW(nonshareW, GENERIC_READ, 0, NULL, CREATE_NEW, FILE_FLAG_DELETE_ON_CLOSE, 0); > + ok(hfile != INVALID_HANDLE_VALUE, "failed to create file\n"); Please use official temporary storage instead of creating files in current directory. -- Dmitry.

March 1, 2014