July 2015 - Wine-Devel - list.winehq.org

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer Nov. 22, 2020

Nov. 22, 2020

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong Sept. 28, 2018

Sept. 28, 2018

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

5 6

ODBC Databases: Jet/Access success
by Barry Bird June 14, 2018

June 14, 2018

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

IMM / IME work
by Aric Stewart June 16, 2016

June 16, 2016

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

Speed of gdi vs opengl DirectDrawRenderer
by Jonas Maebe Oct. 11, 2015

Oct. 11, 2015

Hi, I had a problem with Majesty Gold HD running at glacial speed on my machine (quad Core i5 2.9GHz, NVidia GeForce GT 750M 1GB, OS X 10.9.5). I'm using wine 1.7.35, but I've had similar problems with older wine versions. It's a DirectDraw7 game that has been partially remastered to run on modern systems, but still uses DirectDraw7. This is a common problem on Windows too, but generally can be resolved by telling the game to use the DirectDraw blitter (instead of blitting itself). That didn't help on Wine though. I profiled wine (Instruments time profile) and noticed that most time was spent in wined3d's convert_r5g6b5_x8r8g8b8. Replacing that routine with an optimized sse2 version from pixman did not make much of a difference. Then I discovered that if I told the game to render to a 16 bit instead of to a 32 bit surface, wine would let OpenGL handle the colour conversion. Unfortunately, while this significantly reduced wine's cpu usage, it by no means made the game any faster. Looking at the OpenGL Driver Monitor stats, it seems the cpu was simply waiting all the time on the GPU, probably while it was blitting all of those 1920x1080 images to the screen. Reducing the resolution to the lowest supported by the game (800x600) made it slightly faster, but not much. Next, I added the DirectDrawRenderer registry key and set it to gdi. Now, while it's still slow at 1920x1080, the game runs much faster at 800x600 and even still at 1024x768. Profiling the gdi renderer shows that it has way higher cpu usage than the OpenGL renderer (virtually all in convert_to_8888), but it seems that for some reason it has causes much less traffic to the GPU. The wiki's wording suggests the gdi renderer is deprecated though. Does that mean this qualifies as a bug in the OpenGL renderer (maybe it tries to update the screen more often than necessary, saturating the bus that way?), and are there any things I can try to narrow down why the gdi renderer is so much faster? I didn't immediately see where it blits things actually to the screen. Thanks, Jonas

4 10

Migrating away from Sourceforge
by Austin English Sept. 29, 2015

Sept. 29, 2015

Howdy all, I noticed there was some discussion of this on #winehackers a week or two ago, but I haven't seen any formal discussion about it. Given SourceForge's recent activities [1] [2] with taking over open source projects for their own gain, I propose that we migrate away from SourceForge. The main uses for SourceForge is for mirroring tarballs, wine-gecko/wine-mono installers, and the wine-gecko git repository. @Jeremy, would it be feasible for winehq's (existing) servers to handle the additional load? [1] http://www.extremetech.com/computing/206687-sourceforge-accused-of-hijackin… [2] http://www.extremetech.com/computing/206687-sourceforge-accused-of-hijackin… -- -Austin

14 22

Prep for Wineconf - testing
by Jeremy White Sept. 17, 2015

Sept. 17, 2015

Hi folks, Now that I have my room booked, my thoughts turn to what we'll actually do at Wineconf. And, of course, a Wineconf tradition is for me to lock everyone in the room, away from the bar, until the test situation improves. Sadly, despite the best efforts of some people (yay, Huw!), we are still staring at a range of test failures on Windows. It looks like we've got XP and 2003 starting to show green, and 2000 and 2008 look tantalizingly close. Looks like msi timeouts remain a problem. We had some discussion of throwing some hardware at the problem; I'm happy to do that, but, afair, it wasn't clear that it would help. Weren't we going to run an experiment by setting the run queue size to 1 to see if that prevented the msi timeout failures? If changing the run queue size from n to 1 and buying n machines will 'fix' this, maybe it's time to do that. I seem to recall that Francois needed cooperation from Alexandre to run that experiment - is that right? Once we think we've got robust Windows tests, then we move on to pursuit of the the holy grail - having at least two Linux machines capable of running make test cleanly. (I recall a glorious day when we achieved that; sadly, that moment didn't last :-/). So does it make sense to ask people to start daily winetest runs so we can populate a bit more data? Looks like we've got the CodeWeavers test boxes, and one from Austin. And I don't see any for Mac :-(. Cheers, Jeremy

7 16

Re: [website] Update Debian downloads info
by Jeremy Newman Sept. 12, 2015

Sept. 12, 2015

Patch looks good. We will also need to update all the other languages and put in a redirect for the /downloads/debian page to the regular downloads page. -N On 07/22/2015 01:43 PM, Rosanne DiMesio wrote: > Updates the Debian links on the Downloads page to point to packages.debian.org and deletes the obsolete WineHQ Debian downloads page. > > > >

8 18

D3DRM Implementation patches upto CreateDeviceFromSurface
by Aaryaman Vasishta Aug. 5, 2015

Aug. 5, 2015

CreateDeviceFromD3D will be pushed as soon as patch 9 is finalised. The main concern right now is the thunking of the Release methods of the device. This concern comes up from the fact that the CreateDeviceFromSurface methods from all 3 versions behave the same way except for one difference in version 3, which I mention below. When you create a device from IDirect3DRM3::CreateDeviceFromSurface and release it, native will also destroy the depth surface attached to it (if it created it internally), otherwise it'll let the application keep the reference to the depth surface it created. Other than the above peculiarity, the behaviour is identical. I've attached all the commits which lead to the point of implementing CreateDeviceFromSurface. Please, review the patches as much as you'd like and if possible, provide feedback and suggestions on any improvements that can be made, possible comments required, any stupid mistakes I made etc. :) Thank you! Aaryaman

2 20

Re: [PATCH 1/4] reg: Add path/key conversion functions
by Stefan Dösinger Aug. 3, 2015

Aug. 3, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks for picking up this work! Please submit patches with your real name. We need this for proper copyright attribution. Since this is derived from Jonathan work please mention this as well. The patch doesn't apply for me, I suspect that this is because of the no-break spaces instead of normal spaces. I highly recommend to use git send-email to send the mail. I haven't looked at the code itself. I hope I get around to look at it later today or on Sunday and compare it to the last suggestions I gave Jonathan. If you don't hear from me by Monday please ping me again. Cheers, Stefan Am 2015-07-31 um 11:46 schrieb xantares 09: > --- programs/reg/reg.c | 166 > +++++++++++++++++++++++++++------------------------- 1 file > changed, 86 insertions(+), 80 deletions(-) > > diff --git a/programs/reg/reg.c b/programs/reg/reg.c index > 4ec25bc..cf6425e 100644 --- a/programs/reg/reg.c +++ > b/programs/reg/reg.c @@ -22,6 +22,32 @@ > > #define ARRAY_SIZE(A) (sizeof(A)/sizeof(*A)) > > +static const WCHAR short_hklm[] = {'H','K','L','M',0}; +static > const WCHAR short_hkcu[] = {'H','K','C','U',0}; +static const WCHAR > short_hkcr[] = {'H','K','C','R',0}; +static const WCHAR short_hku[] > = {'H','K','U',0}; +static const WCHAR short_hkcc[] = > {'H','K','C','C',0}; +static const WCHAR long_hklm[] = > {'H','K','E','Y','_','L','O','C','A','L','_','M','A','C','H','I','N',' E',0}; > > +static const WCHAR long_hkcu[] = {'H','K','E','Y','_','C','U','R','R','E','N','T','_','U','S','E','R',0}; > +static const WCHAR long_hkcr[] = > {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0 }; > > +static const WCHAR long_hku[] = {'H','K','E','Y','_','U','S','E','R','S',0}; > +static const WCHAR long_hkcc[] = > {'H','K','E','Y','_','C','U','R','R','E','N','T','_','C','O','N','F',' I','G',0}; > > + > +static const struct +{ + HKEY key; + const WCHAR > *short_name; + const WCHAR *long_name; +} +root_rels[] = +{ + > {HKEY_LOCAL_MACHINE, short_hklm, long_hklm}, + > {HKEY_CURRENT_USER, short_hkcu, long_hkcu}, + > {HKEY_CLASSES_ROOT, short_hkcr, long_hkcr}, + {HKEY_USERS, > short_hku, long_hku}, + {HKEY_CURRENT_CONFIG, short_hkcc, > long_hkcc}, +}; + static const WCHAR type_none[] = > {'R','E','G','_','N','O','N','E',0}; static const WCHAR type_sz[] = > {'R','E','G','_','S','Z',0}; static const WCHAR type_expand_sz[] = > {'R','E','G','_','E','X','P','A','N','D','_','S','Z',0}; @@ -95,51 > +121,56 @@ static int reg_message(int msg) return > reg_printfW(formatW, msg_buffer); } > > -static int reg_StrCmpNIW(LPCWSTR str, LPCWSTR comp, int len) > +static inline BOOL path_rootname_cmp(const WCHAR *input_path, > const WCHAR *rootkey_name) { - int i; + DWORD length = > strlenW(rootkey_name); > > - for (i = 0; i < len; i++) + return (!strncmpiW(input_path, > rootkey_name, length) && + (input_path[length] == 0 || > input_path[length] == '\\')); +} + +static HKEY > path_get_rootkey(const WCHAR *path) +{ + DWORD i; + + for (i > = 0; i < ARRAY_SIZE(root_rels); i++) { - if (!str[i]) - > { - len = i + 1; - break; - } + > if (path_rootname_cmp(path, root_rels[i].short_name) || + > path_rootname_cmp(path, root_rels[i].long_name)) + > return root_rels[i].key; } > > - return CompareStringW(CP_ACP, NORM_IGNORECASE, str, len, comp, > len) - CSTR_EQUAL; + return NULL; } > > -static HKEY get_rootkey(LPWSTR key) +static HKEY path_open(const > WCHAR *path, BOOL create) { - static const WCHAR szHKLM[] = > {'H','K','L','M',0}; - static const WCHAR szHKEY_LOCAL_MACHINE[] > = > {'H','K','E','Y','_','L','O','C','A','L','_','M','A','C','H','I','N',' E',0}; > > - - static const WCHAR szHKCU[] = {'H','K','C','U',0}; > - static const WCHAR szHKEY_CURRENT_USER[] = > {'H','K','E','Y','_','C','U','R','R','E','N','T','_','U','S','E','R',0 }; > > - - static const WCHAR szHKCR[] = {'H','K','C','R',0}; > - static const WCHAR szHKEY_CLASSES_ROOT[] = > {'H','K','E','Y','_','C','L','A','S','S','E','S','_','R','O','O','T',0 }; > > - - static const WCHAR szHKU[] = {'H','K','U',0}; > - static const WCHAR szHKEY_USERS[] = > {'H','K','E','Y','_','U','S','E','R','S',0}; - static const > WCHAR szHKCC[] = {'H','K','C','C',0}; - static const WCHAR > szHKEY_CURRENT_CONFIG[] = > {'H','K','E','Y','_','C','U','R','R','E','N','T','_','C','O','N','F',' I','G',0}; > > - - > - if (!reg_StrCmpNIW(key, szHKLM, 4) || - > !reg_StrCmpNIW(key, szHKEY_LOCAL_MACHINE, 18)) - return > HKEY_LOCAL_MACHINE; - else if (!reg_StrCmpNIW(key, szHKCU, 4) > || - !reg_StrCmpNIW(key, szHKEY_CURRENT_USER, 17)) - > return HKEY_CURRENT_USER; - else if (!reg_StrCmpNIW(key, szHKCR, > 4) || - !reg_StrCmpNIW(key, szHKEY_CLASSES_ROOT, 17)) - > return HKEY_CLASSES_ROOT; - else if (!reg_StrCmpNIW(key, szHKU, > 3) || - !reg_StrCmpNIW(key, szHKEY_USERS, 10)) - > return HKEY_USERS; - else if (!reg_StrCmpNIW(key, szHKCC, 4) || > - !reg_StrCmpNIW(key, szHKEY_CURRENT_CONFIG, 19)) - > return HKEY_CURRENT_CONFIG; - else return NULL; + LONG err; + > HKEY k; + + k = path_get_rootkey(path); + if (!k) + { + > reg_message(STRING_INVALID_KEY); + return NULL; + } + + > path = strchrW(path, '\\'); + if (path) + path++; + + > if (create) + err = RegCreateKeyW(k, path, &k); + else + > err = RegOpenKeyW(k, path, &k); + + if (err != ERROR_SUCCESS) + > { + reg_message(STRING_CANNOT_FIND); + return NULL; + > } + + return k; } > > static DWORD wchar_get_type(const WCHAR *type_name) @@ -221,34 > +252,16 @@ static int reg_add(WCHAR *key_name, WCHAR *value_name, > BOOL value_empty, { static const WCHAR stubW[] = {'A','D','D',' > ','-',' ','%','s', ' ','%','s',' ','%','d',' ','%','s',' > ','%','s',' ','%','d','\n',0}; - LPWSTR p; - HKEY > root,subkey; + HKEY subkey; > > reg_printfW(stubW, key_name, value_name, value_empty, type, data, > force); > > if (!sane_path(key_name)) return 1; > > - p = strchrW(key_name,'\\'); - if (!p) - { - > reg_message(STRING_INVALID_KEY); - return 1; - } - > p++; - - root = get_rootkey(key_name); - if (!root) - { - > reg_message(STRING_INVALID_KEY); + subkey = path_open(key_name, > TRUE); + if (!subkey) return 1; - } - - > if(RegCreateKeyW(root,p,&subkey)!=ERROR_SUCCESS) - { - > reg_message(STRING_INVALID_KEY); - return 1; - } > > if (value_name || data) { @@ -288,8 +301,8 @@ static int > reg_add(WCHAR *key_name, WCHAR *value_name, BOOL value_empty, > static int reg_delete(WCHAR *key_name, WCHAR *value_name, BOOL > value_empty, BOOL value_all, BOOL force) { - LPWSTR p; - HKEY > root,subkey; + HKEY subkey; + LONG err; > > static const WCHAR stubW[] = {'D','E','L','E','T','E', ' ','-',' > ','%','s',' ','%','s',' ','%','d',' ','%','d',' ','%','d','\n' @@ > -299,20 +312,9 @@ static int reg_delete(WCHAR *key_name, WCHAR > *value_name, BOOL value_empty, if (!sane_path(key_name)) return 1; > > - p = strchrW(key_name,'\\'); - if (!p) - { - > reg_message(STRING_INVALID_KEY); - return 1; - } - > p++; - - root = get_rootkey(key_name); - if (!root) - { - > reg_message(STRING_INVALID_KEY); + subkey = path_open(key_name, > FALSE); + if (!subkey) return 1; - } > > if (value_name && value_empty) { @@ -334,7 +336,17 @@ static int > reg_delete(WCHAR *key_name, WCHAR *value_name, BOOL value_empty, /* > Delete subtree only if no /v* option is given */ if (!value_name && > !value_empty && !value_all) { - if > (RegDeleteTreeW(root,p)!=ERROR_SUCCESS) + static const WCHAR > empty_wstr[] = {0}; + + err = RegDeleteTreeW(subkey, NULL); > + if (err != ERROR_SUCCESS) + { + > reg_message(STRING_CANNOT_FIND); + return 1; + } > + + err = RegDeleteKeyW(subkey, empty_wstr); + if > (err != ERROR_SUCCESS) { reg_message(STRING_CANNOT_FIND); return > 1; @@ -343,12 +355,6 @@ static int reg_delete(WCHAR *key_name, > WCHAR *value_name, BOOL value_empty, return 0; } > > - if(RegOpenKeyW(root,p,&subkey)!=ERROR_SUCCESS) - { - > reg_message(STRING_CANNOT_FIND); - return 1; - } - if > (value_all) { LPWSTR szValue; > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVu33xAAoJEN0/YqbEcdMw1MEP/RZYiu5ZzcuAxcOvzmu2LrqR siZmDtSFzd+KN40tHl8IgrFB2kX2RePc0i4cNZJ1EUeMReS84HXoXSzUtDil5oy8 g0J9jFaZVv3xtznxKtQZDur2v3t+IYicjquhfbj7szheLpRbnfULwk3cs825QN1k C/Nhpj9aeDST49fe/YSi84XC15n2OyVHcZtTRgd4IZFVgd76L5kQYKYzLmv4ttes Mm5LGn5No72nehefRkW9YaFv2JAddgM/2jgz48+nd/pFhCB1NyXL2K6c5WPxT1OT Ahyx3oatrP5vSgNDc1Q3g0qGgYlk+aJAfulbSYZ4aSxS/YFcVqMbjEqb8mpPGUzX 1viNVuxg4dcfxozINJYPLkyU/ef9DwlSLdG3HlN9HDy/WFK/0lW4L4TEV9DrPwA+ /OPB8I7Vkb3r6qjsBEH4c1yG9PVQ0TiP3vjpEZM20J/gsvlTnJ6g3PSm9hFjwBWH bv5eBKJMUJKYiEJSoamfnermKEcxBcdOKsGbMApvRyVifcuUpY45+zv4bH0iVnKM 6pxb0EhWfizzbsDItSLDYNJZj1/XgMisgoKwnfUyxdmzRuzW9SipFmFqU6v8Sxpd QQOFSVG0IzL1QED51V2rlS5H1kZxCjRp+mKAn0j6a6KGNuZHcSAqCanhkyVW8FY7 OiDRd7mrwc32lMRcxqS+ =Sn4W -----END PGP SIGNATURE-----

2 2

Re: [PATCH 4/4] reg: Clean up reg_delete
by Marvin July 31, 2015

July 31, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15677 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/4] reg: Clean up reg_add
by Marvin July 31, 2015

July 31, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15676 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/4] reg: Add wchar/raw data conversion functions
by Marvin July 31, 2015

July 31, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15675 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 4/4] reg: Clean up reg_delete
by Marvin July 31, 2015

July 31, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15671 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/4] reg: Clean up reg_add
by Marvin July 31, 2015

July 31, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15670 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/4] reg: Add wchar/raw data conversion functions
by Marvin July 31, 2015

July 31, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15669 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: ole32/tests: Fix new failures in CoWaitForMultipleHandles tests
by Marvin July 30, 2015

July 30, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15660 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/2] d3d9/tests: Add a depth bias test (v2).
by Marvin July 30, 2015

July 30, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15655 Your paranoid android. === w8 (32 bit visual) === visual.c:19757: Test failed: Got unexpected color 00ffffff at x=64, format 77. visual.c:19759: Test failed: Got unexpected color 00ffffff at x=190, format 77. visual.c:19762: Test failed: Got unexpected color 00ffffff at x=194, format 77. visual.c:19764: Test failed: Got unexpected color 00ffffff at x=318, format 77. visual.c:19767: Test failed: Got unexpected color 00000000 at x=322, format 77. visual.c:19769: Test failed: Got unexpected color 00000000 at x=446, format 77. visual.c:19757: Test failed: Got unexpected color 00ffffff at x=64, format 75. visual.c:19759: Test failed: Got unexpected color 00ffffff at x=190, format 75. visual.c:19762: Test failed: Got unexpected color 00ffffff at x=194, format 75. visual.c:19764: Test failed: Got unexpected color 00ffffff at x=318, format 75. visual.c:19767: Test failed: Got unexpected color 00000000 at x=322, format 75. visual.c:19769: Test failed: Got unexpected color 00000000 at x=446, format 75.

1 0

Re: ole32: Don't pump all messages in CoWaitForMultipleHandles in threads without apartment window
by Marvin July 30, 2015

July 30, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15654 Your paranoid android. === w8 (32 bit compobj) === compobj.c:2149: Test failed: expected index 0, got 3735928559 compobj.c:2157: Test failed: expected index 0, got 3735928559

1 0

Re: [PATCH 4/4] reg: Clean up reg_delete
by Marvin July 30, 2015

July 30, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15658 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 3/4] reg: Clean up reg_add
by Marvin July 30, 2015

July 30, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15657 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/4] reg: Add wchar/raw data conversion functions
by Marvin July 30, 2015

July 30, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15656 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/2] d3d9/tests: Add a depth bias test.
by Marvin July 30, 2015

July 30, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15652 Your paranoid android. === w8 (32 bit visual) === visual.c:19757: Test failed: Got unexpected color 00ffffff at x=64, format 77. visual.c:19759: Test failed: Got unexpected color 00ffffff at x=190, format 77. visual.c:19762: Test failed: Got unexpected color 00ffffff at x=194, format 77. visual.c:19764: Test failed: Got unexpected color 00ffffff at x=318, format 77. visual.c:19767: Test failed: Got unexpected color 00000000 at x=322, format 77. visual.c:19769: Test failed: Got unexpected color 00000000 at x=446, format 77.

1 0

Re: [4 PATCHES] reg.exe: implement query (bug #24017)
by Alex Henrie July 30, 2015

July 30, 2015

Xan, You will have to send these patches to the mailing list in separate emails. I strongly recommend using the `git send-email` command for this purpose. It would also be a good idea to ask for feedback on the #wine-staging IRC channel. -Alex

5 5

Re: [PATCH] ws2_32: Implement setting the keep-alive idle timeout and interval on Mac OS.
by Ken Thomases July 30, 2015

July 30, 2015

On Jul 30, 2015, at 1:38 AM, Charles Davis <cdavis5x(a)gmail.com> wrote: > @@ -4459,14 +4464,20 @@ INT WINAPI WSAIoctl(SOCKET s, DWORD code, LPVOID in_buff, DWORD in_size, LPVOID > fd = get_sock_fd(s, 0, NULL); > if (setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepalive, sizeof(int)) == -1) > status = WSAEINVAL; > -#if defined(TCP_KEEPIDLE) && defined(TCP_KEEPINTVL) > +#if defined(TCP_KEEPIDLE) This could be an #ifdef, but see below. > /* these values need to be set only if SO_KEEPALIVE is enabled */ > else if(keepalive) > { > if (setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, (void *)&keepidle, sizeof(int)) == -1) > status = WSAEINVAL; > + /* TCP_KEEPINTVL was only introduced on Mac in 10.9 */ > +#ifdef TCP_KEEPINTVL > else if (setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL, (void *)&keepintvl, sizeof(int)) == -1) > status = WSAEINVAL; > +#else > + else > + FIXME("ignoring keepalive interval\n"); > +#endif > } > #else > else The #ifdef's in the above don't seem quite right. If TCP_KEEPINTVL is a legitimate alternative to TCP_KEEPIDLE/TCP_KEEPALIVE, then why is the latter a precondition for trying the former? That is, if TCP_KEEPINTVL is defined but TCP_KEEPIDLE is not, we still don't try it. That's not something that you introduced, but might as well fix it. -Ken

1 0

HID work?
by Aric Stewart July 30, 2015

July 30, 2015

Hi, Just a poke around the HID patches I have submitted. After my last refactor they did not appear to get any review. I know that Alexandre has been off on a vacation so that is part of it. But I wanted to know what is next that I need to fix or if they can start getting in. thanks! -aric

1 0

Re: [PATCH 1/2] wined3d: Try to detect the polygon offset scale value.
by Henri Verbeet July 30, 2015

July 30, 2015

On 30 July 2015 at 12:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (depth->format_flags & WINED3DFMT_FLAG_FLOAT) > + scale = gl_info->float_polyoffset_scale; > + else > + scale = gl_info->fixed_polyoffset_scale; Ideally this would be a format property. In practice it probably works because we only use 24 and 32 bit depth formats, and the hardware probably either only distinguishes between 16 and 24/32, or just doesn't support 32. > + while(1) I would have preferred that as "for (;;)" > + return powf(2, cur); It seems the compiler is smart enough to work it out, but strictly speaking powf() takes floating point arguments.

2 1

Re: [PATCH 2/2] d3d9/tests: Add a depth bias test.
by Henri Verbeet July 30, 2015

July 30, 2015

On 30 July 2015 at 12:00, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + static const D3DFORMAT formats[] = > + { > + D3DFMT_D16, D3DFMT_D24X8, D3DFMT_D32, > + > + /* The scaling factor detection function detects the wrong factor for > + * float formats on Nvidia, therefore the following tests are disabled. > + * The wined3d function detects 2^23 like for fixed point formats but > + * the test needs 2^22 to pass. > + * > + * AMD GPUs need a different scaling factor for float depth buffers > + * (2^24) than fixed point (2^23), but the wined3d detection function > + * works there, producing the right result in the test. > + * > + * D3DFMT_D32F_LOCKABLE, D3DFMT_D24FS8, > + */ > + }; > + No D24S8? I think that's one of the most common formats. (No INTZ either, but I suppose it's likely to behave like everything else.)

1 0

Re: ws2_32: socket keepalive for OSX
by Charles Davis July 30, 2015

July 30, 2015

> On Jul 29, 2015, at 7:30 PM, Matt Durgavich <mattdurgavich(a)gmail.com> wrote: > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -4468,6 +4468,15 @@ INT WINAPI WSAIoctl(SOCKET s, DWORD code, LPVOID in_buff, DWORD in_size, LPVOID […] > + else if (setsockopt(fd, IPPROTO_TCP, TCP_KEEPALIVE, (void*)&keepintvl, sizeof(int)) == -1) > + status = WSAEINVAL; This isn’t correct. Not for Darwin, anyway. TCP_KEEPALIVE on Darwin corresponds to Linux TCP_KEEPIDLE, not TCP_KEEPINTVL. (I checked. I read the kernel source to make sure of this.) The easiest way to implement this is to define TCP_KEEPIDLE to TCP_KEEPALIVE if TCP_KEEPIDLE isn’t defined but TCP_KEEPALIVE is. As for the other BSD systems, I’m pretty sure they implement the Linux interface (if at all). I know FreeBSD does. Also, Darwin only grew support for TCP_KEEPINTVL in Darwin 13 (i.e. Mac OS 10.9), so even with my suggested change, the existing #ifdef block won’t get compiled in on lower than 10.9. If you want to support 10.6 (when TCP_KEEPALIVE was introduced) through 10.8, you might consider pulling the TCP_KEEPINTVL check into its own #ifdef block, and printing a FIXME if it isn’t defined. You know what? I already have a patch that does all these things. I think I’ll just send that. (I’ve really got to start sending more of my patches upstream…) Chip

1 0

Re: ws2_32: socket keepalive for OSX
by Bruno Jesus July 30, 2015

July 30, 2015

Hi, Matt, thanks for the patch, here is some feedback. Please use a 4 space identation like the code style in this function. > +#elif defined(SO_KEEPALIVE) && defined(TCP_KEEPALIVE) SO_KEEPALIVE is defined for sure (already used outside #ifdef) so there is no need to test. > + /* BSDish platforms like Darwin */ > + else if (keepalive) > + { > + if (setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, (void*)&keepalive, sizeof(int)) == 1) > + status = WSAEINVAL; SO_KEEPALIVE value was already set by a previous call before the #ifdef. Is there a reason to repeat it? Also you are testing the return value for 1 instead of -1. > + else if (setsockopt(fd, IPPROTO_TCP, TCP_KEEPALIVE, (void*)&keepintvl, sizeof(int)) == -1) > + status = WSAEINVAL; > + } Please note that in the rest of the code it is used (void *), not (void*). Best wishes, Bruno On Wed, Jul 29, 2015 at 10:30 PM, Matt Durgavich <mattdurgavich(a)gmail.com> wrote: > Set socket options for keepalive on OSX tcp connections. > No tests at this time. > > dlls/ws2_32/socket.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > > >

1 0

Re: [PATCH 5/5] d3dx9/tests: Add tests for normals computation.
by Matteo Bruni July 29, 2015

July 29, 2015

2015-07-25 11:23 GMT+02:00 Józef Kucia <joseph.kucia(a)gmail.com>: > --- > dlls/d3dx9_36/tests/mesh.c | 573 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 573 insertions(+) > > diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c > index 2da077a..a5b3c46 100644 > --- a/dlls/d3dx9_36/tests/mesh.c > +++ b/dlls/d3dx9_36/tests/mesh.c > @@ -65,6 +65,11 @@ static BOOL compare_vec3(D3DXVECTOR3 u, D3DXVECTOR3 v) > return ( compare(u.x, v.x) && compare(u.y, v.y) && compare(u.z, v.z) ); > } > > +static BOOL compare_vec4(D3DXVECTOR4 u, D3DXVECTOR4 v) > +{ > + return compare(u.x, v.x) && compare(u.y, v.y) && compare(u.z, v.z) && compare(u.w, v.w); > +} > + > #define check_floats(got, exp, dim) check_floats_(__LINE__, "", got, exp, dim) > static void check_floats_(int line, const char *prefix, const float *got, const float *exp, int dim) > { > @@ -10373,6 +10378,573 @@ static void test_optimize_faces(void) > "faces when using 16-bit indices. Got %x\n, expected D3DERR_INVALIDCALL\n", hr); > } > > +static HRESULT clear_normals(ID3DXMesh *mesh) > +{ > + HRESULT hr; > + BYTE *vertices; > + size_t normal_size; > + DWORD i, num_vertices, vertex_stride; > + const D3DXVECTOR4 normal = {NAN, NAN, NAN, NAN}; > + D3DVERTEXELEMENT9 *normal_declaration = NULL; > + D3DVERTEXELEMENT9 declaration[MAX_FVF_DECL_SIZE] = {D3DDECL_END()}; > + > + if (FAILED(hr = mesh->lpVtbl->GetDeclaration(mesh, declaration))) > + return hr; > + > + for (i = 0; declaration[i].Stream != 0xFF; i++) > + { > + if (declaration[i].Usage == D3DDECLUSAGE_NORMAL && declaration[i].UsageIndex == 0) Style, lowercase hex literal and !var instead of var == 0 are usually preferred in d3d. > + { > + normal_declaration = &declaration[i]; > + break; > + } > + } > + > + if (!normal_declaration) > + return D3DERR_INVALIDCALL; > + > + if (normal_declaration->Type == D3DDECLTYPE_FLOAT3) > + { > + normal_size = sizeof(D3DXVECTOR3); > + } > + else if (normal_declaration->Type == D3DDECLTYPE_FLOAT4) > + { > + normal_size = sizeof(D3DXVECTOR4); > + } > + else > + { > + trace("Cannot clear normals\n"); > + return E_NOTIMPL; > + } > + > + num_vertices = mesh->lpVtbl->GetNumVertices(mesh); > + vertex_stride = mesh->lpVtbl->GetNumBytesPerVertex(mesh); > + > + if (FAILED(hr = mesh->lpVtbl->LockVertexBuffer(mesh, 0, (void **)&vertices))) > + return hr; > + > + vertices += normal_declaration->Offset; > + > + for (i = 0; i < num_vertices; i++, vertices += vertex_stride) > + memcpy(vertices, &normal, normal_size); > + > + return mesh->lpVtbl->UnlockVertexBuffer(mesh); > +} > + > +static void compare_normals(unsigned int line, const char *test_name, > + ID3DXMesh *mesh, const D3DXVECTOR3 *normals, unsigned int num_normals) > +{ > + unsigned int i; > + BYTE *vertices; > + DWORD num_vertices, vertex_stride; > + D3DVERTEXELEMENT9 *normal_declaration = NULL; > + D3DVERTEXELEMENT9 declaration[MAX_FVF_DECL_SIZE] = {D3DDECL_END()}; > + > + if (FAILED(mesh->lpVtbl->GetDeclaration(mesh, declaration))) > + { > + ok_(__FILE__, line)(0, "%s: Failed to get declaration\n", test_name); > + return; > + } > + > + for (i = 0; declaration[i].Stream != 0xFF; i++) > + { > + if (declaration[i].Usage == D3DDECLUSAGE_NORMAL && declaration[i].UsageIndex == 0) > + { > + normal_declaration = &declaration[i]; > + break; > + } > + } > + > + if (!normal_declaration) > + { > + ok_(__FILE__, line)(0, "%s: Mesh has no normals\n", test_name); > + return; > + } > + > + if (normal_declaration->Type != D3DDECLTYPE_FLOAT3 && normal_declaration->Type != D3DDECLTYPE_FLOAT4) > + { > + ok_(__FILE__, line)(0, "%s: Mesh has invalid normals type\n", test_name); > + return; > + } > + > + num_vertices = mesh->lpVtbl->GetNumVertices(mesh); > + vertex_stride = mesh->lpVtbl->GetNumBytesPerVertex(mesh); > + > + ok_(__FILE__, line)(num_vertices == num_normals, "%s: Expected %u vertices, got %u\n", test_name, > + num_normals, num_vertices); > + > + if (FAILED(mesh->lpVtbl->LockVertexBuffer(mesh, 0, (void **)&vertices))) > + { > + ok_(__FILE__, line)(0, "%s: Failed to compare normals\n", test_name); > + return; > + } > + > + vertices += normal_declaration->Offset; > + > + for (i = 0; i < min(num_vertices, num_normals); i++, vertices += vertex_stride) > + { > + if (normal_declaration->Type == D3DDECLTYPE_FLOAT3) > + { > + const D3DXVECTOR3 *n = (D3DXVECTOR3 *)vertices; > + ok_(__FILE__, line)(compare_vec3(*n, normals[i]), > + "%s: normal %2u, expected (%f, %f, %f), got (%f, %f, %f)\n", > + test_name, i, normals[i].x, normals[i].y, normals[i].z, n->x, n->y, n->z); > + } > + else > + { > + const D3DXVECTOR4 *n = (D3DXVECTOR4 *)vertices; > + const D3DXVECTOR4 normal = {normals[i].x, normals[i].y, normals[i].z, 1.0f}; > + ok_(__FILE__, line)(compare_vec4(*n, normal), > + "%s: normal %2u, expected (%f, %f, %f, %f), got (%f, %f, %f, %f)\n", > + test_name, i, normals[i].x, normals[i].y, normals[i].z, 1.0f, > + n->x, n->y, n->z, n->w); > + } > + } > + > + mesh->lpVtbl->UnlockVertexBuffer(mesh); > +} > + > +static HRESULT compute_normals_D3DXComputeNormals(ID3DXMesh *mesh, const DWORD *adjacency) > +{ > + return D3DXComputeNormals((ID3DXBaseMesh *)mesh, adjacency); > +} > + > +static HRESULT compute_normals_D3DXComputeTangentFrameEx(ID3DXMesh *mesh, const DWORD *adjacency) > +{ > + return D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS, > + adjacency, -1.01f, -0.01f, -1.01f, NULL, NULL); > +} > + > +static void test_compute_normals(void) > +{ > + HRESULT hr; > + ULONG refcount; > + ID3DXMesh *mesh, *cloned_mesh; > + ID3DXBuffer *adjacency; > + IDirect3DDevice9 *device; > + struct test_context *test_context; > + unsigned int i; > + > + static const struct compute_normals_func > + { > + const char *name; > + HRESULT (*apply)(ID3DXMesh *mesh, const DWORD *adjacency); > + } > + compute_normals_funcs[] = > + { > + {"D3DXComputeNormals", compute_normals_D3DXComputeNormals }, > + {"D3DXComputeTangentFramEx", compute_normals_D3DXComputeTangentFrameEx} Typo. BTW, I feel like you could push this kind of table-based test organization further. E.g. also add a couple more variants for D3DXTANGENT_WEIGHT_BY_AREA and D3DXTANGENT_WEIGHT_EQUAL. You might have to store the expected results for box and sphere normals in the table. Doing that might be more messy than it looks like though, so I'm okay if you think that's not worth it. > + }; > + > + static const D3DXVECTOR3 box_normals[24] = > + { > + {-1.0f, 0.0f, 0.0f}, {-1.0f, 0.0f, 0.0f}, {-1.0f, 0.0f, 0.0f}, {-1.0f, 0.0f, 0.0f}, > + { 0.0f, 1.0f, 0.0f}, { 0.0f, 1.0f, 0.0f}, { 0.0f, 1.0f, 0.0f}, { 0.0f, 1.0f, 0.0f}, > + { 1.0f, 0.0f, 0.0f}, { 1.0f, 0.0f, 0.0f}, { 1.0f, 0.0f, 0.0f}, { 1.0f, 0.0f, 0.0f}, > + { 0.0f,-1.0f, 0.0f}, { 0.0f,-1.0f, 0.0f}, { 0.0f,-1.0f, 0.0f}, { 0.0f,-1.0f, 0.0f}, > + { 0.0f, 0.0f, 1.0f}, { 0.0f, 0.0f, 1.0f}, { 0.0f, 0.0f, 1.0f}, { 0.0f, 0.0f, 1.0f}, > + { 0.0f, 0.0f,-1.0f}, { 0.0f, 0.0f,-1.0f}, { 0.0f, 0.0f,-1.0f}, { 0.0f, 0.0f,-1.0f} > + }; > + float box_normal_component = 1.0f / sqrtf(3.0f); > + D3DXVECTOR3 box_normals_adjacency[24] = I think you can still make this const. > + { > + {-box_normal_component, -box_normal_component, -box_normal_component}, > + {-box_normal_component, -box_normal_component, box_normal_component}, > + {-box_normal_component, box_normal_component, box_normal_component}, > + {-box_normal_component, box_normal_component, -box_normal_component}, > + {-box_normal_component, box_normal_component, -box_normal_component}, > + {-box_normal_component, box_normal_component, box_normal_component}, > + { box_normal_component, box_normal_component, box_normal_component}, > + { box_normal_component, box_normal_component, -box_normal_component}, > + { box_normal_component, box_normal_component, -box_normal_component}, > + { box_normal_component, box_normal_component, box_normal_component}, > + { box_normal_component, -box_normal_component, box_normal_component}, > + { box_normal_component, -box_normal_component, -box_normal_component}, > + {-box_normal_component, -box_normal_component, box_normal_component}, > + {-box_normal_component, -box_normal_component, -box_normal_component}, > + { box_normal_component, -box_normal_component, -box_normal_component}, > + { box_normal_component, -box_normal_component, box_normal_component}, > + {-box_normal_component, -box_normal_component, box_normal_component}, > + { box_normal_component, -box_normal_component, box_normal_component}, > + { box_normal_component, box_normal_component, box_normal_component}, > + {-box_normal_component, box_normal_component, box_normal_component}, > + {-box_normal_component, -box_normal_component, -box_normal_component}, > + {-box_normal_component, box_normal_component, -box_normal_component}, > + { box_normal_component, box_normal_component, -box_normal_component}, > + { box_normal_component, -box_normal_component, -box_normal_component} > + }; > + static const D3DXVECTOR3 box_normals_adjacency_area[24] = > + { > + {-0.666667f, -0.333333f, -0.666667f}, {-0.333333f, -0.666667f, 0.666667f}, > + {-0.816496f, 0.408248f, 0.408248f}, {-0.408248f, 0.816496f, -0.408248f}, > + {-0.408248f, 0.816496f, -0.408248f}, {-0.816496f, 0.408248f, 0.408248f}, > + { 0.333333f, 0.666667f, 0.666667f}, { 0.666667f, 0.333333f, -0.666667f}, > + { 0.666667f, 0.333333f, -0.666667f}, { 0.333333f, 0.666667f, 0.666667f}, > + { 0.816496f, -0.408248f, 0.408248f}, { 0.408248f, -0.816496f, -0.408248f}, > + {-0.333333f, -0.666667f, 0.666667f}, {-0.666667f, -0.333333f, -0.666667f}, > + { 0.408248f, -0.816496f, -0.408248f}, { 0.816496f, -0.408248f, 0.408248f}, > + {-0.333333f, -0.666667f, 0.666667f}, { 0.816497f, -0.408248f, 0.408248f}, > + { 0.333333f, 0.666667f, 0.666667f}, {-0.816497f, 0.408248f, 0.408248f}, > + {-0.666667f, -0.333333f, -0.666667f}, {-0.408248f, 0.816497f, -0.408248f}, > + { 0.666667f, 0.333333f, -0.666667f}, { 0.408248f, -0.816496f, -0.408248f} > + }; > + static const D3DXVECTOR3 box_normals_position1f[24] = {{0}}; > + static const D3DXVECTOR3 box_normals_position2f[24] = > + { > + {0.0f, 0.0f, -1.0f}, {0.0f, 0.0f, 1.0f}, {0.0f, 0.0f, 1.0f}, > + {0.0f, 0.0f, -1.0f}, {0.0f, 0.0f, -1.0f}, {0.0f, 0.0f, 1.0f}, > + {0.0f, 0.0f, 1.0f}, {0.0f, 0.0f, -1.0f}, {0.0f, 0.0f, -1.0f}, > + {0.0f, 0.0f, 1.0f}, {0.0f, 0.0f, 1.0f}, {0.0f, 0.0f, -1.0f}, > + {0.0f, 0.0f, 1.0f}, {0.0f, 0.0f, -1.0f}, {0.0f, 0.0f, -1.0f}, > + {0.0f, 0.0f, 1.0f}, {0.0f, 0.0f, 1.0f}, {0.0f, 0.0f, 1.0f}, > + {0.0f, 0.0f, 1.0f}, {0.0f, 0.0f, 1.0f}, {0.0f, 0.0f, -1.0f}, > + {0.0f, 0.0f, -1.0f}, {0.0f, 0.0f, -1.0f}, {0.0f, 0.0f, -1.0f} > + }; > + > + static const D3DXVECTOR3 sphere_normals[22] = > + { > + { 0.000000f, -0.000000f, 1.000000f}, { 0.000000f, 0.582244f, 0.813014f}, > + { 0.582244f, -0.000000f, 0.813014f}, {-0.000000f, -0.582244f, 0.813014f}, > + {-0.582244f, 0.000000f, 0.813014f}, {-0.000000f, 0.890608f, 0.454772f}, > + { 0.890608f, 0.000000f, 0.454772f}, { 0.000000f, -0.890608f, 0.454772f}, > + {-0.890608f, -0.000000f, 0.454772f}, { 0.000000f, 1.000000f, -0.000000f}, > + { 1.000000f, -0.000000f, -0.000000f}, {-0.000000f, -1.000000f, -0.000000f}, > + {-1.000000f, 0.000000f, -0.000000f}, { 0.000000f, 0.890608f, -0.454773f}, > + { 0.890608f, -0.000000f, -0.454772f}, {-0.000000f, -0.890608f, -0.454773f}, > + {-0.890608f, 0.000000f, -0.454773f}, { 0.000000f, 0.582244f, -0.813015f}, > + { 0.582244f, -0.000000f, -0.813015f}, { 0.000000f, -0.582244f, -0.813015f}, > + {-0.582243f, 0.000000f, -0.813015f}, { 0.000000f, 0.000000f, -1.000000f} > + }; > + static const D3DXVECTOR3 sphere_normals_area[22] = > + { > + { 0.000000f, -0.000000f, 1.000000f}, {-0.215311f, 0.554931f, 0.803550f}, > + { 0.554931f, 0.215311f, 0.803550f}, { 0.215311f, -0.554931f, 0.803550f}, > + {-0.554931f, -0.215311f, 0.803550f}, {-0.126638f, 0.872121f, 0.472618f}, > + { 0.872121f, 0.126638f, 0.472618f}, { 0.126638f, -0.872121f, 0.472618f}, > + {-0.872121f, -0.126637f, 0.472618f}, { 0.000000f, 1.000000f, -0.000000f}, > + { 1.000000f, -0.000000f, -0.000000f}, {-0.000000f, -1.000000f, -0.000000f}, > + {-1.000000f, 0.000000f, -0.000000f}, { 0.126638f, 0.872121f, -0.472618f}, > + { 0.872121f, -0.126638f, -0.472618f}, {-0.126638f, -0.872121f, -0.472618f}, > + {-0.872121f, 0.126638f, -0.472618f}, { 0.215311f, 0.554931f, -0.803550f}, > + { 0.554931f, -0.215311f, -0.803550f}, {-0.215311f, -0.554931f, -0.803550f}, > + {-0.554931f, 0.215311f, -0.803550f}, { 0.000000f, 0.000000f, -1.000000f} > + }; > + static const D3DXVECTOR3 sphere_normals_equal[22] = > + { > + { 0.000000f, -0.000000f, 1.000000f}, {-0.134974f, 0.522078f, 0.842150f}, > + { 0.522078f, 0.134974f, 0.842150f}, { 0.134974f, -0.522078f, 0.842150f}, > + {-0.522078f, -0.134974f, 0.842150f}, {-0.026367f, 0.857121f, 0.514440f}, > + { 0.857121f, 0.026367f, 0.514440f}, { 0.026367f, -0.857121f, 0.514440f}, > + {-0.857121f, -0.026367f, 0.514440f}, { 0.000000f, 1.000000f, -0.000000f}, > + { 1.000000f, -0.000000f, -0.000000f}, {-0.000000f, -1.000000f, -0.000000f}, > + {-1.000000f, 0.000000f, -0.000000f}, { 0.026367f, 0.857121f, -0.514440f}, > + { 0.857121f, -0.026367f, -0.514440f}, {-0.026367f, -0.857121f, -0.514440f}, > + {-0.857121f, 0.026367f, -0.514440f}, { 0.134975f, 0.522078f, -0.842150f}, > + { 0.522078f, -0.134975f, -0.842150f}, {-0.134974f, -0.522078f, -0.842150f}, > + {-0.522078f, 0.134974f, -0.842150f}, { 0.000000f, 0.000000f, -1.000000f} > + }; > + > + static const D3DVERTEXELEMENT9 position3f_normal1f_declaration[] = > + { > + {0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0}, > + {0, sizeof(D3DXVECTOR3), D3DDECLTYPE_FLOAT1, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0}, > + D3DDECL_END() > + }; > + static const D3DVERTEXELEMENT9 position3f_normal2f_declaration[] = > + { > + {0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0}, > + {0, sizeof(D3DXVECTOR3), D3DDECLTYPE_FLOAT2, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0}, > + D3DDECL_END() > + }; > + static const D3DVERTEXELEMENT9 normal4f_position3f_declaration[] = > + { > + {0, 0, D3DDECLTYPE_FLOAT4, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0}, > + {0, sizeof(D3DXVECTOR4), D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0}, > + D3DDECL_END() > + }; Can you check that a 4-component normal placed after the position gives the same results? It doesn't need to be in the patch if there are no surprises (and there shouldn't be, this is me being paranoid). > + static const D3DVERTEXELEMENT9 position1f_normal3f_declaration[] = > + { > + {0, 0, D3DDECLTYPE_FLOAT1, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0}, > + {0, sizeof(float), D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0}, > + D3DDECL_END() > + }; > + static const D3DVERTEXELEMENT9 position2f_normal3f_declaration[] = > + { > + {0, 0, D3DDECLTYPE_FLOAT2, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0}, > + {0, sizeof(D3DXVECTOR2), D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0}, > + D3DDECL_END() > + }; > + static const D3DVERTEXELEMENT9 position4f_normal3f_declaration[] = > + { > + {0, 0, D3DDECLTYPE_FLOAT4, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0}, > + {0, sizeof(D3DXVECTOR4), D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0}, > + D3DDECL_END() > + }; > + > + for (i = 0; i < ARRAY_SIZE(compute_normals_funcs); i++) > + { > + hr = compute_normals_funcs[i].apply(NULL, NULL); > + ok(hr == D3DERR_INVALIDCALL, "%s returned %#x, expected D3DERR_INVALIDCALL\n", compute_normals_funcs[i].name, hr); > + } > + > + if (!(test_context = new_test_context())) > + { > + skip("Couldn't create test context\n"); > + return; > + } > + device = test_context->device; > + > + hr = D3DXCreateBox(device, 1.0f, 1.0f, 1.0f, &mesh, &adjacency); > + ok(SUCCEEDED(hr), "D3DXCreateBox failed %#x\n", hr); > + > + /* Check wrong input */ > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_GENERATE_IN_PLACE, NULL, -1.01f, -0.01f, -1.01f, NULL, NULL); > + todo_wine ok(hr == D3DERR_INVALIDCALL, "D3DXComputeTangentFrameEx returned %#x, expected D3DERR_INVALIDCALL\n", hr); > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DDECLUSAGE_NORMAL, 0, > + D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS | D3DXTANGENT_WEIGHT_BY_AREA | D3DXTANGENT_WEIGHT_EQUAL, > + NULL, -1.01f, -0.01f, -1.01f, NULL, NULL); > + ok(hr == D3DERR_INVALIDCALL, "D3DXComputeTangentFrameEx returned %#x, expected D3DERR_INVALIDCALL\n", hr); > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 0, 0, NULL, -1.01f, -0.01f, -1.01f, NULL, NULL); > + todo_wine ok(hr == D3DERR_INVALIDCALL, "D3DXComputeTangentFrameEx returned %#x, expected D3DERR_INVALIDCALL\n", hr); > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 1, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS, > + NULL, -1.01f, -0.01f, -1.01f, NULL, NULL); > + ok(hr == D3DERR_INVALIDCALL, "D3DXComputeTangentFrameEx returned %#x, expected D3DERR_INVALIDCALL\n", hr); > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DX_DEFAULT, 0, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS, > + NULL, -1.01f, -0.01f, -1.01f, NULL, NULL); > + ok(hr == D3DERR_INVALIDCALL, "D3DXComputeTangentFrameEx returned %#x, expected D3DERR_INVALIDCALL\n", hr); > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_CALCULATE_NORMALS, > + NULL, -1.01f, -0.01f, -1.01f, NULL, NULL); > + todo_wine ok(hr == D3DERR_INVALIDCALL, "D3DXComputeTangentFrameEx returned %#x, expected D3DERR_INVALIDCALL\n", hr); > + > + for (i = 0; i < ARRAY_SIZE(compute_normals_funcs); i++) > + { > + const struct compute_normals_func *func = &compute_normals_funcs[i]; > + > + /* Mesh without normals */ > + hr = mesh->lpVtbl->CloneMeshFVF(mesh, 0, D3DFVF_XYZ, device, &cloned_mesh); > + ok(SUCCEEDED(hr), "CloneMeshFVF failed %#x\n", hr); > + > + hr = func->apply(cloned_mesh, NULL); > + ok(hr == D3DERR_INVALIDCALL, "%s returned %#x, expected D3DERR_INVALIDCALL\n", func->name, hr); > + > + refcount = cloned_mesh->lpVtbl->Release(cloned_mesh); > + ok(!refcount, "Mesh has %u references left\n", refcount); > + > + /* Mesh without positions */ > + hr = mesh->lpVtbl->CloneMeshFVF(mesh, 0, D3DFVF_NORMAL, device, &cloned_mesh); > + ok(SUCCEEDED(hr), "CloneMeshFVF failed %#x\n", hr); > + > + hr = func->apply(cloned_mesh, NULL); > + ok(hr == D3DERR_INVALIDCALL, "%s returned %#x, expected D3DERR_INVALIDCALL\n", func->name, hr); > + > + refcount = cloned_mesh->lpVtbl->Release(cloned_mesh); > + ok(!refcount, "Mesh has %u references left\n", refcount); > + > + /* Mesh with D3DDECLTYPE_FLOAT1 normals */ > + hr = mesh->lpVtbl->CloneMesh(mesh, 0, position3f_normal1f_declaration, device, &cloned_mesh); > + ok(SUCCEEDED(hr), "CloneMesh failed %#x\n", hr); > + > + hr = func->apply(cloned_mesh, NULL); > + ok(hr == D3DERR_INVALIDCALL, "%s returned %#x, expected D3DERR_INVALIDCALL\n", func->name, hr); > + > + refcount = cloned_mesh->lpVtbl->Release(cloned_mesh); > + ok(!refcount, "Mesh has %u references left\n", refcount); > + > + /* Mesh with D3DDECLTYPE_FLOAT2 normals */ > + hr = mesh->lpVtbl->CloneMesh(mesh, 0, position3f_normal2f_declaration, device, &cloned_mesh); > + ok(SUCCEEDED(hr), "CloneMesh failed %#x\n", hr); > + > + hr = func->apply(cloned_mesh, NULL); > + ok(hr == D3DERR_INVALIDCALL, "%s returned %#x, expected D3DERR_INVALIDCALL\n", func->name, hr); > + > + refcount = cloned_mesh->lpVtbl->Release(cloned_mesh); > + ok(!refcount, "Mesh has %u references left\n", refcount); > + > + /* Mesh without adjacency data */ > + hr = clear_normals(mesh); > + ok(SUCCEEDED(hr), "Failed to clear normals, returned %#x\n", hr); > + > + hr = func->apply(mesh, NULL); > + ok(hr == D3D_OK, "%s returned %#x, expected D3D_OK\n", func->name, hr); > + > + compare_normals(__LINE__, func->name, mesh, box_normals, ARRAY_SIZE(box_normals)); > + > + /* Mesh with adjacency data */ > + hr = clear_normals(mesh); > + ok(SUCCEEDED(hr), "Failed to clear normals, returned %#x\n", hr); > + > + hr = func->apply(mesh, ID3DXBuffer_GetBufferPointer(adjacency)); > + ok(hr == D3D_OK, "%s returned %#x, expected D3D_OK\n", func->name, hr); > + > + compare_normals(__LINE__, func->name, mesh, box_normals_adjacency, ARRAY_SIZE(box_normals_adjacency)); > + > + /* Mesh with custom vertex format, D3DDECLTYPE_FLOAT4 normals and adjacency */ > + hr = mesh->lpVtbl->CloneMesh(mesh, 0, normal4f_position3f_declaration, device, &cloned_mesh); > + ok(SUCCEEDED(hr), "CloneMesh failed %#x\n", hr); > + > + hr = clear_normals(cloned_mesh); > + ok(SUCCEEDED(hr), "Failed to clear normals, returned %#x\n", hr); > + > + hr = func->apply(cloned_mesh, ID3DXBuffer_GetBufferPointer(adjacency)); > + ok(hr == D3D_OK, "%s returned %#x, expected D3D_OK\n", func->name, hr); > + > + compare_normals(__LINE__, func->name, cloned_mesh, box_normals_adjacency, ARRAY_SIZE(box_normals_adjacency)); > + > + refcount = cloned_mesh->lpVtbl->Release(cloned_mesh); > + ok(!refcount, "Mesh has %u references left\n", refcount); > + > + /* Mesh with D3DDECLTYPE_FLOAT1 positions and D3DDECLTYPE_FLOAT3 normals */ > + hr = mesh->lpVtbl->CloneMesh(mesh, 0, position1f_normal3f_declaration, device, &cloned_mesh); > + ok(SUCCEEDED(hr), "CloneMesh failed %#x\n", hr); > + > + hr = clear_normals(cloned_mesh); > + ok(SUCCEEDED(hr), "Failed to clear normals, returned %#x\n", hr); > + > + hr = func->apply(cloned_mesh, ID3DXBuffer_GetBufferPointer(adjacency)); > + ok(hr == D3D_OK, "%s returned %#x, expected D3D_OK\n", func->name, hr); > + > + compare_normals(__LINE__, func->name, cloned_mesh, box_normals_position1f, ARRAY_SIZE(box_normals_position1f)); > + > + refcount = cloned_mesh->lpVtbl->Release(cloned_mesh); > + ok(!refcount, "Mesh has %u references left\n", refcount); > + > + /* Mesh with D3DDECLTYPE_FLOAT2 positions and D3DDECLTYPE_FLOAT3 normals */ > + hr = mesh->lpVtbl->CloneMesh(mesh, 0, position2f_normal3f_declaration, device, &cloned_mesh); > + ok(SUCCEEDED(hr), "CloneMesh failed %#x\n", hr); > + > + hr = clear_normals(cloned_mesh); > + ok(SUCCEEDED(hr), "Failed to clear normals, returned %#x\n", hr); > + > + hr = func->apply(cloned_mesh, ID3DXBuffer_GetBufferPointer(adjacency)); > + ok(hr == D3D_OK, "%s returned %#x, expected D3D_OK\n", func->name, hr); > + > + compare_normals(__LINE__, func->name, cloned_mesh, box_normals_position2f, ARRAY_SIZE(box_normals_position2f)); > + > + refcount = cloned_mesh->lpVtbl->Release(cloned_mesh); > + ok(!refcount, "Mesh has %u references left\n", refcount); > + > + /* Mesh with D3DDECLTYPE_FLOAT4 positions and D3DDECLTYPE_FLOAT3 normals */ > + hr = mesh->lpVtbl->CloneMesh(mesh, 0, position4f_normal3f_declaration, device, &cloned_mesh); > + ok(SUCCEEDED(hr), "CloneMesh failed %#x\n", hr); > + > + hr = clear_normals(cloned_mesh); > + ok(SUCCEEDED(hr), "Failed to clear normals, returned %#x\n", hr); > + > + hr = func->apply(cloned_mesh, ID3DXBuffer_GetBufferPointer(adjacency)); > + ok(hr == D3D_OK, "%s returned %#x, expected D3D_OK\n", func->name, hr); > + > + compare_normals(__LINE__, func->name, cloned_mesh, box_normals_adjacency, ARRAY_SIZE(box_normals_adjacency)); > + > + refcount = cloned_mesh->lpVtbl->Release(cloned_mesh); > + ok(!refcount, "Mesh has %u references left\n", refcount); > + } > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS | D3DXTANGENT_WEIGHT_BY_AREA, > + NULL, -1.01f, -0.01f, -1.01f, NULL, NULL); > + ok(hr == D3D_OK, "D3DXComputeTangentFrameEx returned %#x, expected D3D_OK\n", hr); > + > + compare_normals(__LINE__, "D3DXComputeTangentFrameEx", mesh, box_normals, ARRAY_SIZE(box_normals)); > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS | D3DXTANGENT_WEIGHT_BY_AREA, > + ID3DXBuffer_GetBufferPointer(adjacency), -1.01f, -0.01f, -1.01f, NULL, NULL); > + ok(hr == D3D_OK, "D3DXComputeTangentFrameEx returned %#x, expected D3D_OK\n", hr); > + > + compare_normals(__LINE__, "D3DXComputeTangentFrameEx", mesh, box_normals_adjacency_area, ARRAY_SIZE(box_normals_adjacency_area)); > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS | D3DXTANGENT_WEIGHT_EQUAL, > + NULL, -1.01f, -0.01f, -1.01f, NULL, NULL); > + ok(hr == D3D_OK, "D3DXComputeTangentFrameEx returned %#x, expected D3D_OK\n", hr); > + > + compare_normals(__LINE__, "D3DXComputeTangentFrameEx", mesh, box_normals, ARRAY_SIZE(box_normals)); > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS | D3DXTANGENT_WEIGHT_EQUAL, > + ID3DXBuffer_GetBufferPointer(adjacency), -1.01f, -0.01f, -1.01f, NULL, NULL); > + ok(hr == D3D_OK, "D3DXComputeTangentFrameEx returned %#x, expected D3D_OK\n", hr); > + > + compare_normals(__LINE__, "D3DXComputeTangentFrameEx", mesh, box_normals_adjacency_area, ARRAY_SIZE(box_normals_adjacency_area)); > + > + refcount = mesh->lpVtbl->Release(mesh); > + ok(!refcount, "Mesh has %u references left\n", refcount); > + refcount = ID3DXBuffer_Release(adjacency); > + ok(!refcount, "Buffer has %u references left\n", refcount); > + > + hr = D3DXCreateSphere(device, 1.0f, 4, 6, &mesh, &adjacency); > + ok(SUCCEEDED(hr), "D3DXCreateSphere failed %#x\n", hr); > + > + for (i = 0; i < ARRAY_SIZE(compute_normals_funcs); i++) > + { > + const struct compute_normals_func *func = &compute_normals_funcs[i]; > + > + /* Sphere without adjacency data */ > + hr = clear_normals(mesh); > + ok(SUCCEEDED(hr), "Failed to clear normals, returned %#x\n", hr); > + > + hr = func->apply(mesh, NULL); > + ok(hr == D3D_OK, "%s returned %#x, expected D3D_OK\n", func->name, hr); > + > + compare_normals(__LINE__, func->name, mesh, sphere_normals, ARRAY_SIZE(sphere_normals)); > + > + /* Sphere with adjacency data */ > + hr = clear_normals(mesh); > + ok(SUCCEEDED(hr), "Failed to clear normals, returned %#x\n", hr); > + > + hr = func->apply(mesh, ID3DXBuffer_GetBufferPointer(adjacency)); > + ok(hr == D3D_OK, "%s returned %#x, expected D3D_OK\n", func->name, hr); > + > + compare_normals(__LINE__, func->name, mesh, sphere_normals, ARRAY_SIZE(sphere_normals)); > + } > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS | D3DXTANGENT_WEIGHT_BY_AREA, > + NULL, -1.01f, -0.01f, -1.01f, NULL, NULL); > + ok(hr == D3D_OK, "D3DXComputeTangentFrameEx returned %#x, expected D3D_OK\n", hr); > + > + compare_normals(__LINE__, "D3DXComputeTangentFrameEx", mesh, sphere_normals_area, ARRAY_SIZE(sphere_normals_area)); > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS | D3DXTANGENT_WEIGHT_BY_AREA, > + ID3DXBuffer_GetBufferPointer(adjacency), -1.01f, -0.01f, -1.01f, NULL, NULL); > + ok(hr == D3D_OK, "D3DXComputeTangentFrameEx returned %#x, expected D3D_OK\n", hr); > + > + compare_normals(__LINE__, "D3DXComputeTangentFrameEx", mesh, sphere_normals_area, ARRAY_SIZE(sphere_normals_area)); > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS | D3DXTANGENT_WEIGHT_EQUAL, > + NULL, -1.01f, -0.01f, -1.01f, NULL, NULL); > + ok(hr == D3D_OK, "D3DXComputeTangentFrameEx returned %#x, expected D3D_OK\n", hr); > + > + compare_normals(__LINE__, "D3DXComputeTangentFrameEx", mesh, sphere_normals_equal, ARRAY_SIZE(sphere_normals_equal)); > + > + hr = D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, > + D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS | D3DXTANGENT_WEIGHT_EQUAL, > + ID3DXBuffer_GetBufferPointer(adjacency), -1.01f, -0.01f, -1.01f, NULL, NULL); > + ok(hr == D3D_OK, "D3DXComputeTangentFrameEx returned %#x, expected D3D_OK\n", hr); > + > + compare_normals(__LINE__, "D3DXComputeTangentFrameEx", mesh, sphere_normals_equal, ARRAY_SIZE(sphere_normals_equal)); > + > + refcount = mesh->lpVtbl->Release(mesh); > + ok(!refcount, "Mesh has %u references left\n", refcount); > + refcount = ID3DXBuffer_Release(adjacency); > + ok(!refcount, "Buffer has %u references left\n", refcount); > + > + free_test_context(test_context); > +} > + > START_TEST(mesh) > { > D3DXBoundProbeTest(); > @@ -10401,4 +10973,5 @@ START_TEST(mesh) > test_clone_mesh(); > test_valid_mesh(); > test_optimize_faces(); > + test_compute_normals(); > } > -- > 2.3.6 Looking good otherwise, thanks!

2 1

Re: gdi32: Simplify bitwise and and xor with 0 (PVS-Studio)
by Huw Davies July 29, 2015

July 29, 2015

On 29 Jul 2015, at 12:32, Michael Stefaniuc wrote: > --- > Same sha1 for primitives.o with and without patch. > > > > dlls/gdi32/dibdrv/primitives.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/gdi32/dibdrv/primitives.c b/dlls/gdi32/dibdrv/primitives.c > index c7b48ed..9da08ad 100644 > --- a/dlls/gdi32/dibdrv/primitives.c > +++ b/dlls/gdi32/dibdrv/primitives.c > @@ -5655,8 +5655,8 @@ static void create_dither_masks_1(const dib_info *dib, int rop2, COLORREF color, > } > else > { > - rop_mask.and = (0x00 & codes.a1) ^ codes.a2; > - rop_mask.xor = (0x00 & codes.x1) ^ codes.x2; > + rop_mask.and = codes.a2; > + rop_mask.xor = codes.x2; > } > *and_bits |= (rop_mask.and & pixel_masks_1[x]); > *xor_bits |= (rop_mask.xor & pixel_masks_1[x]); It's clearer as it was, especially given the lines just above this hunk. Huw.

2 2

Re: [PATCH 4/5] amstream: Zero-initialize DirectDraw surface desc. (Valgrind)
by Henri Verbeet July 29, 2015

July 29, 2015

On 28 July 2015 at 23:14, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > diff --git a/dlls/amstream/mediastream.c b/dlls/amstream/mediastream.c > index 947be1e..3725c68 100644 > --- a/dlls/amstream/mediastream.c > +++ b/dlls/amstream/mediastream.c > @@ -991,6 +991,7 @@ static HRESULT ddrawstreamsample_create(IDirectDrawMediaStream *parent, IDirectD > return hr; > } > > + memset(&desc, 0, sizeof(desc)); > desc.dwSize = sizeof(desc); > desc.dwFlags = DDSD_CAPS|DDSD_HEIGHT|DDSD_WIDTH|DDSD_PIXELFORMAT; > desc.dwHeight = 100; This should not be needed. If this is for bug 38911, that's a duplicate of bug 36383, and sort of a false positive. ddraw_surface_create() clears DDSD_LPSURFACE if desc->lpSurface is NULL. The issue is that desc->lpSurface may be uninitialized if DDSD_LPSURFACE is not set, but in that case clearing the flag also wouldn't make a difference. If we want to do something about the false positive that should happen in ddraw_surface_create(). I don't personally feel strongly about it one way or the other.

1 0

Re: [2/2] shell32/tests: Check if error status is reset after successful file copy
by Marvin July 28, 2015

July 28, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15616 Your paranoid android. === w2000pro (32 bit shlfileop) === shlfileop.c:1833: Test failed: Expected ERROR_SUCCESS, got 6 === wvistau64 (32 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

1 0

Re: [1/2] ntdll/tests: Add basic tests for RtlQueueWorkItem.
by Marvin July 28, 2015

July 28, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15580 Your paranoid android. === w7u (32 bit threadpool) === threadpool.c:763: Test failed: WaitForSingleObject returned 258 threadpool.c:777: Test failed: WaitForSingleObject returned 0 threadpool.c:779: Test failed: threadpool.c:715: Running timer callback

3 3

Re: odbccp32: Implement SQLGetPrivateProfileString/W (try 9)
by Nikolay Sivov July 28, 2015

July 28, 2015

On 28.07.2015 12:55, Alistair Leslie-Hughes wrote: > + if(!defvalue) > + buff[0] = 0; > + > + if (!section || !defvalue || !buff) > + return 0; > + > + if (buff) > + buff[0] = 0; This makes no sense.

1 0

Re: [PATCH] gdi32: check for NULL pointer in GetOutlineTextMetrics (try 2)
by Marvin July 27, 2015

July 27, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15598 Your paranoid android. === wvistau64 (32 bit font) === The test timed out === wvistau64 (64 bit font) === The test timed out

2 1

Re: [PATCH 3/5] d3dx9: Partially implement D3DXComputeTangentFrameEx().
by Matteo Bruni July 27, 2015

July 27, 2015

Hi, I've got a number of nitpicks but these patches are essentially okay with me. 2015-07-25 11:23 GMT+02:00 Józef Kucia <joseph.kucia(a)gmail.com>: > --- > dlls/d3dx9_36/mesh.c | 235 ++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 232 insertions(+), 3 deletions(-) > > diff --git a/dlls/d3dx9_36/mesh.c b/dlls/d3dx9_36/mesh.c > index 4aeac26..1558b17 100644 > --- a/dlls/d3dx9_36/mesh.c > +++ b/dlls/d3dx9_36/mesh.c > @@ -7235,6 +7235,41 @@ error: > return hr; > } > > +static inline D3DXVECTOR3 *vertex_element_vec3(BYTE *vertices, > + const D3DVERTEXELEMENT9 *declaration, DWORD vertex_stride, DWORD index) Better not to include the "inline" specifier, the compiler will inline the function anyway if it thinks it's a good idea. > +{ > + return (D3DXVECTOR3 *)(vertices + declaration->Offset + index * vertex_stride); > +} > + > +static inline D3DXVECTOR3 read_vec3(BYTE *vertices, const D3DVERTEXELEMENT9 *declaration, > + DWORD vertex_stride, DWORD index) > +{ > + D3DXVECTOR3 vec3 = {0}; > + const float *src = (float *)(vertices + declaration->Offset + index * vertex_stride); You can just use vertex_element_vec3() here, like e.g. const D3DXVECTOR3 *src = vertex_element_vec3(vertices, declaration, vertex_stride, index); although the source data isn't necessarily a full vec3. Your call. > + > + switch (declaration->Type) > + { > + case D3DDECLTYPE_FLOAT1: > + vec3.x = src[0]; > + break; > + case D3DDECLTYPE_FLOAT2: > + vec3.x = src[0]; > + vec3.y = src[1]; > + break; > + case D3DDECLTYPE_FLOAT3: > + case D3DDECLTYPE_FLOAT4: > + vec3.x = src[0]; > + vec3.y = src[1]; > + vec3.z = src[2]; > + break; > + default: > + ERR("Cannot read vec3\n"); > + break; > + } You could sort the cases the other way around and fallthrough to make this part shorter. Again, this is also fine and it's up to you. > + > + return vec3; > +} > + > /************************************************************************* > * D3DXComputeTangentFrameEx (D3DX9_36.@) > */ > @@ -7244,15 +7279,209 @@ HRESULT WINAPI D3DXComputeTangentFrameEx(ID3DXMesh *mesh, DWORD texture_in_seman > const DWORD *adjacency, float partial_edge_threshold, float singular_point_threshold, > float normal_edge_threshold, ID3DXMesh **mesh_out, ID3DXBuffer **vertex_mapping) > { > - FIXME("mesh %p, texture_in_semantic %u, texture_in_index %u, u_partial_out_semantic %u, u_partial_out_index %u, " > + HRESULT hr; > + void *indices = NULL; > + BYTE *vertices = NULL; > + DWORD *point_reps = NULL; > + size_t normal_size; > + BOOL indices_are_32bit; > + DWORD i, j, num_faces, num_vertices, vertex_stride; > + D3DVERTEXELEMENT9 declaration[MAX_FVF_DECL_SIZE] = {D3DDECL_END()}; > + D3DVERTEXELEMENT9 *position_declaration = NULL, *normal_declaration = NULL; > + > + TRACE("mesh %p, texture_in_semantic %u, texture_in_index %u, u_partial_out_semantic %u, u_partial_out_index %u, " > "v_partial_out_semantic %u, v_partial_out_index %u, normal_out_semantic %u, normal_out_index %u, " > "options %#x, adjacency %p, partial_edge_threshold %f, singular_point_threshold %f, " > - "normal_edge_threshold %f, mesh_out %p, vertex_mapping %p stub!\n", > + "normal_edge_threshold %f, mesh_out %p, vertex_mapping %p\n", > mesh, texture_in_semantic, texture_in_index, u_partial_out_semantic, u_partial_out_index, > v_partial_out_semantic, v_partial_out_index, normal_out_semantic, normal_out_index, options, adjacency, > partial_edge_threshold, singular_point_threshold, normal_edge_threshold, mesh_out, vertex_mapping); > > - return E_NOTIMPL; > + if (!mesh) > + { > + WARN("mesh is NULL\n"); > + return D3DERR_INVALIDCALL; > + } > + > + if ((options & (D3DXTANGENT_WEIGHT_EQUAL | D3DXTANGENT_WEIGHT_BY_AREA)) == (D3DXTANGENT_WEIGHT_EQUAL | D3DXTANGENT_WEIGHT_BY_AREA)) I would store the result of "options & (D3DXTANGENT_WEIGHT_EQUAL | D3DXTANGENT_WEIGHT_BY_AREA)" in a variable and use it here and below. > + { > + WARN("D3DXTANGENT_WEIGHT_BY_AREA and D3DXTANGENT_WEIGHT_EQUAL are mutally exclusive\n"); > + return D3DERR_INVALIDCALL; > + } > + > + if (u_partial_out_semantic != D3DX_DEFAULT) > + { > + FIXME("tangent vectors computation is not supported\n"); > + return E_NOTIMPL; > + } > + > + if (v_partial_out_semantic != D3DX_DEFAULT) > + { > + FIXME("binormal vectors computation is not supported\n"); > + return E_NOTIMPL; > + } > + > + if (options & ~(D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS | D3DXTANGENT_WEIGHT_EQUAL | D3DXTANGENT_WEIGHT_BY_AREA)) > + { > + FIXME("unsupported options %#x\n", options); > + return E_NOTIMPL; > + } > + > + if (!(options & D3DXTANGENT_CALCULATE_NORMALS)) > + { > + FIXME("only normals computation is supported\n"); > + return E_NOTIMPL; > + } > + > + if (!(options & D3DXTANGENT_GENERATE_IN_PLACE) || mesh_out || vertex_mapping) > + { > + FIXME("only D3DXTANGENT_GENERATE_IN_PLACE is supported\n"); > + return E_NOTIMPL; > + } > + > + if (FAILED(hr = mesh->lpVtbl->GetDeclaration(mesh, declaration))) > + return hr; > + > + for (i = 0; declaration[i].Stream != 0xFF; i++) Lowercase is preferred for hex literals. > + { > + if (declaration[i].Usage == D3DDECLUSAGE_POSITION && declaration[i].UsageIndex == 0) > + position_declaration = &declaration[i]; > + if (declaration[i].Usage == normal_out_semantic && declaration[i].UsageIndex == normal_out_index) > + normal_declaration = &declaration[i]; > + } > + > + if (!position_declaration || !normal_declaration) > + return D3DERR_INVALIDCALL; > + > + if (normal_declaration->Type == D3DDECLTYPE_FLOAT3) > + { > + normal_size = sizeof(D3DXVECTOR3); > + } > + else if (normal_declaration->Type == D3DDECLTYPE_FLOAT4) > + { > + normal_size = sizeof(D3DXVECTOR4); > + } > + else > + { > + WARN("unsupported normals type %u\n", normal_declaration->Type); > + return D3DERR_INVALIDCALL; > + } > + > + num_faces = mesh->lpVtbl->GetNumFaces(mesh); > + num_vertices = mesh->lpVtbl->GetNumVertices(mesh); > + vertex_stride = mesh->lpVtbl->GetNumBytesPerVertex(mesh); > + indices_are_32bit = mesh->lpVtbl->GetOptions(mesh) & D3DXMESH_32BIT; > + > + point_reps = HeapAlloc(GetProcessHeap(), 0, num_vertices * sizeof(*point_reps)); > + if (!point_reps) > + { > + hr = E_OUTOFMEMORY; > + goto done; > + } > + > + if (adjacency) > + { > + if (FAILED(hr = mesh->lpVtbl->ConvertAdjacencyToPointReps(mesh, adjacency, point_reps))) > + goto done; > + } > + else > + { > + for (i = 0; i < num_vertices; i++) > + point_reps[i] = i; > + } > + > + if (FAILED(hr = mesh->lpVtbl->LockIndexBuffer(mesh, 0, &indices))) > + goto done; > + > + if (FAILED(hr = mesh->lpVtbl->LockVertexBuffer(mesh, 0, (void **)&vertices))) > + goto done; > + > + for (i = 0; i < num_vertices; i++) > + { > + const D3DXVECTOR4 zero = {0.0f, 0.0f, 0.0f, 1.0f}; That's a weird zero :) Not sure about a better name though, maybe "default_vector"? Also, please make it static. > + void *normal = vertices + normal_declaration->Offset + i * vertex_stride; > + > + memcpy(normal, &zero, normal_size); > + } > + > + for (i = 0; i < num_faces; i++) > + { > + float weights[3]; > + D3DXVECTOR3 a, b, cross, face_normal; > + const DWORD face_indices[3] = > + { > + read_ib(indices, indices_are_32bit, 3 * i + 0), > + read_ib(indices, indices_are_32bit, 3 * i + 1), > + read_ib(indices, indices_are_32bit, 3 * i + 2) > + }; > + const D3DXVECTOR3 v0 = read_vec3(vertices, position_declaration, vertex_stride, face_indices[0]); > + const D3DXVECTOR3 v1 = read_vec3(vertices, position_declaration, vertex_stride, face_indices[1]); > + const D3DXVECTOR3 v2 = read_vec3(vertices, position_declaration, vertex_stride, face_indices[2]); > + > + D3DXVec3Cross(&cross, D3DXVec3Subtract(&a, &v0, &v1), D3DXVec3Subtract(&b, &v0, &v2)); > + > + switch (options & (D3DXTANGENT_WEIGHT_BY_AREA | D3DXTANGENT_WEIGHT_EQUAL)) > + { > + case D3DXTANGENT_WEIGHT_EQUAL: > + weights[0] = weights[1] = weights[2] = 1.0f; > + break; > + case D3DXTANGENT_WEIGHT_BY_AREA: > + weights[0] = weights[1] = weights[2] = D3DXVec3Length(&cross); > + break; > + default: > + weights[0] = acosf(D3DXVec3Dot(&a, &b) / (D3DXVec3Length(&a) * D3DXVec3Length(&b))); > + > + D3DXVec3Subtract(&a, &v1, &v0); > + D3DXVec3Subtract(&b, &v1, &v2); > + weights[1] = acosf(D3DXVec3Dot(&a, &b) / (D3DXVec3Length(&a) * D3DXVec3Length(&b))); > + > + D3DXVec3Subtract(&a, &v2, &v0); > + D3DXVec3Subtract(&b, &v2, &v1); > + weights[2] = acosf(D3DXVec3Dot(&a, &b) / (D3DXVec3Length(&a) * D3DXVec3Length(&b))); > + > + if (isnan(weights[0])) weights[0] = 1.0f; > + if (isnan(weights[1])) weights[1] = 1.0f; > + if (isnan(weights[2])) weights[2] = 1.0f; > + break; This might cause problems in the (unlikely) case float exceptions are enabled. Ideally this case would need to be tested with native and, if it doesn't throw exceptions, your code would need to take care of that. I don't think this is super critical though, it should be easy to figure it out later on if some application crashes here. > + } > + > + D3DXVec3Normalize(&face_normal, &cross); > + > + for (j = 0; j < 3; j++) > + { > + D3DXVECTOR3 normal; > + DWORD rep_index = point_reps[face_indices[j]]; > + D3DXVECTOR3 *rep_normal = vertex_element_vec3(vertices, normal_declaration, vertex_stride, rep_index); > + > + D3DXVec3Scale(&normal, &face_normal, weights[j]); > + D3DXVec3Add(rep_normal, rep_normal, &normal); > + } > + } > + > + for (i = 0; i < num_vertices; i++) > + { > + DWORD rep_index = point_reps[i]; > + D3DXVECTOR3 *normal = vertex_element_vec3(vertices, normal_declaration, vertex_stride, i); > + D3DXVECTOR3 *rep_normal = vertex_element_vec3(vertices, normal_declaration, vertex_stride, rep_index); > + > + if (i == rep_index) > + D3DXVec3Normalize(rep_normal, rep_normal); > + else > + *normal = *rep_normal; > + } > + > + hr = D3D_OK; > + > +done: > + if (vertices) > + mesh->lpVtbl->UnlockVertexBuffer(mesh); > + > + if (indices) > + mesh->lpVtbl->UnlockIndexBuffer(mesh); > + > + HeapFree(GetProcessHeap(), 0, point_reps); > + > + return hr; > } > > /************************************************************************* > -- > 2.3.6 > > >

2 1

Re: [PATCH] gdi32: check for NULL pointer in GetOutlineTextMetrics
by Nikolay Sivov July 27, 2015

July 27, 2015

On 27.07.2015 21:19, Daniel Lehman wrote: > > Yes, looks like it will access NULL out pointer if cbData != 0. Please add a test for that, if it returns required buffer size your fix looks correct to me, if it returns 0 we don't need to call driver at all and API call itself should be fixed, not a driver.

1 0

Re: include/d3dcommon.idl: Add missing typedefs
by Matteo Bruni July 27, 2015

July 27, 2015

2015-07-26 3:24 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > + D3D_SIF_TEXTURE_COMPONENT_0 = 4, > + D3D_SIF_TEXTURE_COMPONENT_1 = 8, > + D3D_SIF_TEXTURE_COMPONENTS = 12, Please use hexadecimal here. FWIW in the Win 8.1 SDK headers there is also a D3D_SIF_UNUSED enum value.

1 0

Re: [PATCH 3/9] d2d1: Validate bitmap formats.
by Marvin July 27, 2015

July 27, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15530 Your paranoid android. === wvistau64 (32 bit d2d1) === d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x1. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0x2. === w2008s64 (32 bit d2d1) === d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x1. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0x2. === w7u (32 bit d2d1) === d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x1. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0x2. === w8 (32 bit d2d1) === d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x1. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0x2.

2 1

mountmgr.sys: Write usable device paths into HKLM\SYSTEM\MountedDevices.
by Bernhard Übelacker July 27, 2015

July 27, 2015

Hello, I got asked if I could get a discussion started for the attached patch and bug #38235 [1]. This bug is about Blindwrite 7 not showing any usable source DVD drive. It seems Blindwrite relies on the values stored in HKLM\SYSTEM\MountedDevices to enumerate drives. Wine currently stores in e.g. "\DosDevices\D:" the linux mount point of the drive as ansi string. A native Windows XP stores there (as wide string): \??\IDE#CdRomVBOX_CD-ROM_____________________________1.0_____#42562d3231303037333036372020202020202020#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b} This patch stores now as content just the device (also as wide string): \\.\d: This is sufficient to make Blindwrite 7 happy. - Is there currently any use of the stored linux mount point anywhere? - Is there a test needed and where should that be placed as mountmgr.sys has currently no tests subdirectory? - Is there a reason known why this short device name should not be used in this situation? Kind regards, Bernhard [1] https://bugs.winehq.org/show_bug.cgi?id=38235

1 0

Re: d3dx9_36: Add D3DXTessellateNPatches stub
by Matteo Bruni July 27, 2015

July 27, 2015

2015-07-24 11:06 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > > > Changelog: > d3dx9_36: Add D3DXTessellateNPatches stub > > > Best Regards > Alistair Leslie-Hughes Please avoid caps in the parameter names. Also don't forget the period at the end of the FIXME message.

1 0

Re: [2/2] d3dx9_36: Add D3DXCreateFragmentLinker, D3DXCreateFragmentLinkerEx stubs
by Matteo Bruni July 27, 2015

July 27, 2015

2015-07-23 11:11 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > > Hi, > > Fixes crash of https://bugs.winehq.org/show_bug.cgi?id=38086 > > Changelog: > d3dx9_36: Add D3DXCreateFragmentLinker, D3DXCreateFragmentLinkerEx stubs > > > Best Regards > Alistair Leslie-Hughes > + FIXME("(device %p, size %u, linker %p)\n", device, size, linker); Please drop the parentheses in the message. > + > + if(linker) Space between if and '('. While you're at it, please drop the D3DXCreateFragmentLinker and D3DXCreateFragmentLinkerEx entries from d3dx9_42.spec, it looks like those functions were removed in d3dx9_42.dll. You should probably also add the function prototypes to d3dx9shader.h.

1 0

Re: [1/2] include: Add ID3DXFragmentLinker interface
by Matteo Bruni July 27, 2015

July 27, 2015

2015-07-23 11:11 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > > > Changelog: > include: Add ID3DXFragmentLinker interface > > > Best Regards > Alistair Leslie-Hughes > +typedef interface ID3DXFragmentLinker ID3DXFragmentLinker; You don't need that. > + STDMETHOD(GetDevice)(THIS_ IDirect3DDevice9 *device) PURE; This is wrong. > + STDMETHOD(LinkPixelShader)(THIS_ const char *profile, DWORD flags, const D3DXHANDLE *fragmenthandles, UINT fragments, IDirect3DVertexShader9 **shader, ID3DXBuffer **errors) PURE; This too. For reference, I checked the definitions with those from the March 2009 DirectX SDK.

1 0

Re: d3dcompiler: Add D3DCompileFromFile, D3DCompile2 stubs (try 3 - resend)
by Matteo Bruni July 27, 2015

July 27, 2015

2015-07-23 11:09 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > + FIXME(" srcdata %p, srcdatasize %lu, sourcename %s, defines %p, includes %p, entrypoint %s, target %s, " Extra space at the start. But it's okay, not worth a resend IMHO. As followups you could make D3DCompile() forward to D3DCompile2() and you could try to implement D3DCompileFromFile(), probably via the new D3DReadFileToBlob() function.

1 0

Re: [PATCH 5/5] qcap/tests: Add COM tests for VfwCapture.
by Marvin July 27, 2015

July 27, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15590 Your paranoid android. === build (build) === Make failed

2 1

Re: user32: Hide horizontal Listbox scroll bar if no horizontal extent is set. (try 2)
by Marvin July 26, 2015

July 26, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15569 Your paranoid android. === wvistau64 (32 bit listbox) === listbox.c:709: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 listbox.c:944: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18 === wvistau64 (64 bit listbox) === listbox.c:709: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 listbox.c:944: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18

1 0

Re: widl: Don't output C++ default value if the argument is followed by another without default value.
by Michael Stefaniuc July 26, 2015

July 26, 2015

Jacek, On 07/26/2015 05:07 PM, Jacek Caban wrote: > + /* Output default value only is all following arguments also have default value. */ should that be an "if"? ^^^ bye michael

2 1

Re: [PATCH 1/5] d3dx9/tests: Remove todo that succeeds now.
by Nikolay Sivov July 26, 2015

July 26, 2015

On 25.07.2015 12:23, Józef Kucia wrote: > --- > dlls/d3dx9_36/tests/effect.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/d3dx9_36/tests/effect.c b/dlls/d3dx9_36/tests/effect.c > index 482f064..dd88b29 100644 > --- a/dlls/d3dx9_36/tests/effect.c > +++ b/dlls/d3dx9_36/tests/effect.c > @@ -156,7 +156,7 @@ static void test_create_effect_and_pool(IDirect3DDevice9 *device) > ok(hr == D3D_OK, "Got result %x, expected 0 (D3D_OK)\n", hr); > > hr = D3DXCreateEffect(device, effect_desc, sizeof(effect_desc), NULL, NULL, 0, NULL, &effect, NULL); > - todo_wine ok(hr == D3D_OK, "Got result %x, expected 0 (D3D_OK)\n", hr); > + ok(hr == D3D_OK, "Got result %x, expected 0 (D3D_OK)\n", hr); > if (FAILED(hr)) > { > skip("Failed to compile effect, skipping test.\n"); > Hi, Jozef. There's no failures currently http://test.winehq.org/data/tests/d3dx9_36:mesh.html, so I'm not sure why it succeeds for you.

2 1

[PATCH] Use asserts for mmap failure modes
by Michael Gilbert July 26, 2015

July 26, 2015

Hi, Using exit in shared libraries is a discouraged practice, and wine's mmap implementation currently does that. I attach a proposed change using asserts instead. Let me know if you have any feedback. Best wishes, Mike (btw I'm the debian wine maintainer)

2 2

re: Wine Stable
by Michael Gilbert July 26, 2015

July 26, 2015

Michael Stefaniuc wrote: > We already have a topic "Wine Stable Considered Harmful" for the > WineConf in September, see http://wiki.winehq.org/WineConf2015 "Considered Harmful" is also Considered Harmful ;) http://meyerweb.com/eric/comment/chech.html > On a high level view this are IMHO the good and bad things about the > current stable process in Wine: > > Good Bad > ---- --- > Code freeze/stabilization Way too old > Marketing Release slips with features slippage > Some distributions want it Distributions insist on using it > Bug reports for stable are ignored The other good is that we can plan on shipping a stabilized (bug fixed, well tested) version of the package, rather than whichever version happened to be released at the time of the Debian freeze. The whole point of having both stable and development versions of the package in Debian is so the user can have a choice. Either go with the stable, well tested version, or go with a snapshot from the date of the freeze. Best wishes, Mike

1 0

Re: psapi/tests: Don't check for exact value (try 2)
by Sebastian Lackner July 26, 2015

July 26, 2015

On 23.07.2015 22:50, André Hentschel wrote: > --- > dlls/psapi/tests/psapi_main.c | 59 +++++++++++++------------------------------ > 1 file changed, 17 insertions(+), 42 deletions(-) > > diff --git a/dlls/psapi/tests/psapi_main.c b/dlls/psapi/tests/psapi_main.c > index cebfc5f..1ee30d2 100644 > --- a/dlls/psapi/tests/psapi_main.c > +++ b/dlls/psapi/tests/psapi_main.c > @@ -194,6 +194,11 @@ static void test_GetModuleInformation(void) > ok(info.lpBaseOfDll == hMod, "lpBaseOfDll=%p hMod=%p\n", info.lpBaseOfDll, hMod); > } > > +#define ADMITTED_ERROR (64) > +#define CHECK_MARGIN(perf, sys) \ > + ok(perf >= max(sys, ADMITTED_ERROR) - ADMITTED_ERROR && perf <= sys + ADMITTED_ERROR, \ > + "expected approximately " #perf "=%u but got %u\n", sys, (ULONG)perf) > + > static void test_GetPerformanceInfo(void) > { > PERFORMANCE_INFORMATION info; > @@ -227,36 +232,16 @@ static void test_GetPerformanceInfo(void) > ok(status == STATUS_SUCCESS, "expected STATUS_SUCCESS, got %08x\n", status); > ok(size >= sizeof(SYSTEM_PERFORMANCE_INFORMATION), "incorrect length %d\n", size); > > - ok(info.CommitTotal == sys_performance_info->TotalCommittedPages, > - "expected info.CommitTotal=%u but got %u\n", > - sys_performance_info->TotalCommittedPages, (ULONG)info.CommitTotal); > - > - ok(info.CommitLimit == sys_performance_info->TotalCommitLimit, > - "expected info.CommitLimit=%u but got %u\n", > - sys_performance_info->TotalCommitLimit, (ULONG)info.CommitLimit); > - > - ok(info.CommitPeak == sys_performance_info->PeakCommitment, > - "expected info.CommitPeak=%u but got %u\n", > - sys_performance_info->PeakCommitment, (ULONG)info.CommitPeak); > - > - ok(info.PhysicalAvailable >= max(sys_performance_info->AvailablePages, 25) - 25 && > - info.PhysicalAvailable <= sys_performance_info->AvailablePages + 25, > - "expected approximately info.PhysicalAvailable=%u but got %u\n", > - sys_performance_info->AvailablePages, (ULONG)info.PhysicalAvailable); > + CHECK_MARGIN(info.CommitTotal, sys_performance_info->TotalCommittedPages); > + CHECK_MARGIN(info.CommitLimit, sys_performance_info->TotalCommitLimit); > + CHECK_MARGIN(info.CommitPeak, sys_performance_info->PeakCommitment); > + CHECK_MARGIN(info.PhysicalAvailable, sys_performance_info->AvailablePages); > > /* TODO: info.SystemCache not checked yet - to which field(s) does this value correspond to? */ > > - ok(info.KernelTotal == sys_performance_info->PagedPoolUsage + sys_performance_info->NonPagedPoolUsage, > - "expected info.KernelTotal=%u but got %u\n", > - sys_performance_info->PagedPoolUsage + sys_performance_info->NonPagedPoolUsage, (ULONG)info.KernelTotal); > - > - ok(info.KernelPaged == sys_performance_info->PagedPoolUsage, > - "expected info.KernelPaged=%u but got %u\n", > - sys_performance_info->PagedPoolUsage, (ULONG)info.KernelPaged); > - > - ok(info.KernelNonpaged == sys_performance_info->NonPagedPoolUsage, > - "expected info.KernelNonpaged=%u but got %u\n", > - sys_performance_info->NonPagedPoolUsage, (ULONG)info.KernelNonpaged); > + CHECK_MARGIN(info.KernelTotal, sys_performance_info->PagedPoolUsage + sys_performance_info->NonPagedPoolUsage); > + CHECK_MARGIN(info.KernelPaged, sys_performance_info->PagedPoolUsage); > + CHECK_MARGIN(info.KernelNonpaged, sys_performance_info->NonPagedPoolUsage); > > /* compare with values from SYSTEM_BASIC_INFORMATION */ > size = 0; > @@ -264,13 +249,8 @@ static void test_GetPerformanceInfo(void) > ok(status == STATUS_SUCCESS, "expected STATUS_SUCCESS, got %08x\n", status); > ok(size >= sizeof(SYSTEM_BASIC_INFORMATION), "incorrect length %d\n", size); > > - ok(info.PhysicalTotal == sys_basic_info.MmNumberOfPhysicalPages, > - "expected info.PhysicalTotal=%u but got %u\n", > - sys_basic_info.MmNumberOfPhysicalPages, (ULONG)info.PhysicalTotal); > - > - ok(info.PageSize == sys_basic_info.PageSize, > - "expected info.PageSize=%u but got %u\n", > - sys_basic_info.PageSize, (ULONG)info.PageSize); > + CHECK_MARGIN(info.PhysicalTotal, sys_basic_info.MmNumberOfPhysicalPages); I think we can safely assume that the total physical memory does not change between two calls. > + CHECK_MARGIN(info.PageSize, sys_basic_info.PageSize); The pagesize should usually also match exactly. > > /* compare with values from SYSTEM_PROCESS_INFORMATION */ > size = 0; > @@ -297,14 +277,9 @@ static void test_GetPerformanceInfo(void) > } > HeapFree(GetProcessHeap(), 0, sys_process_info); > > - ok(info.HandleCount == handle_count, > - "expected info.HandleCount=%u but got %u\n", handle_count, info.HandleCount); > - > - ok(info.ProcessCount == process_count, > - "expected info.ProcessCount=%u but got %u\n", process_count, info.ProcessCount); > - > - ok(info.ThreadCount == thread_count, > - "expected info.ThreadCount=%u but got %u\n", thread_count, info.ThreadCount); > + CHECK_MARGIN(info.HandleCount, handle_count); > + CHECK_MARGIN(info.ProcessCount, process_count); > + CHECK_MARGIN(info.ThreadCount, thread_count); A tolerance of 64 (especially for process/threads) basically disables these tests. A smaller tolerance would already be sufficient to avoid random test failures. > } > } > >

1 0

Re: user32/tests: Also check against the low word of hSubMenu (try 2)
by Marvin July 25, 2015

July 25, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15565 Your paranoid android. === w2003std (32 bit menu) === menu.c:2545: Test failed: id 202: expected fState 0, got 0003 menu.c:2545: Test failed: id 202: expected fState 0, got 1000

1 0

Re: [PATCH 14/21] api-ms-win-crt-multibyte-l1-1-0: Add stub dll.
by Sebastian Lackner July 25, 2015

July 25, 2015

On 23.07.2015 21:47, Martin Storsjo wrote: > +@ stdcall __p__mbcasemap() ucrtbase.__p__mbcasemap This (and a couple of other redirects) should probably be declared as cdecl, similar to how its done in all other msvcr* dlls. You have to update the hack in tools/make_specfiles for this to work properly, for example like that: --- snip --- @@ -376,7 +376,7 @@ sub update_spec_file($) if ($parent{callconv} ne "stub" || $parent{args}) { my $callconv = $parent{callconv} ne "stub" ? $parent{callconv} : - $parent{spec} =~ /msvc/ ? "cdecl" : "stdcall"; # hack + $parent{spec} =~ /(msvc|ucrtbase)/ ? "cdecl" : "stdcall"; # hack $_ = sprintf "$descr{ordinal} %s %s%s", $callconv, $flags, $func; if ($parent{target} =~ /$group_head\./) # use the same forward as parent if possible --- snip --- Please note that this is the first patch affected by this problem.

2 1

Re: user32: Hide horizontal Listbox scroll bar if no horizontal extent is set.
by Marvin July 24, 2015

July 24, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15534 Your paranoid android. === wvistau64 (32 bit listbox) === listbox.c:709: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 listbox.c:944: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18 === wvistau64 (64 bit listbox) === listbox.c:709: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 listbox.c:944: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18

2 1

Re: [PATCH 1/2] user32: Initialize buffer before sending WM_GETTEXT
by Marvin July 24, 2015

July 24, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15535 Your paranoid android. === wvistau64 (32 bit win) === win.c:7546: Test failed: transparent window didn't get WM_NCHITTEST message win.c:7547: Test failed: button under static window didn't get WM_LBUTTONUP

2 1

Re: [PATCH 8/9] d2d1: Bitmap values are always premultiplied in practice.
by Marvin July 23, 2015

July 23, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15531 Your paranoid android. === wvistau64 (32 bit d2d1) === d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x1. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0x2. === w2008s64 (32 bit d2d1) === d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x1. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0x2. === w7u (32 bit d2d1) === d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x1. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0x2. === w8 (32 bit d2d1) === d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x1. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0x2. === wvistau64 (64 bit d2d1) === d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x1. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0x2. === w2008s64 (64 bit d2d1) === d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x2/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xa/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0xb/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1b/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x1c/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1d/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1e/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x1f/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x20/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x1. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x41/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x2. d2d1.c:1613: Test failed: Got unexpected hr 0x80070057, for format 0x57/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x58/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x1. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x2. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5a/0x3. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0. d2d1.c:1616: Test failed: Got unexpected hr 0x80070057, for format 0x5b/0x2.

1 0

Re: msxml3: Handle NULL parameter in IXMLDOMElement::get_ownerDocument().
by Nikolay Sivov July 23, 2015

July 23, 2015

On 14.07.2015 16:31, Zhenbo Li wrote: > Hi Nikolay, > > 2015-07-14 20:17 GMT+08:00 Nikolay Sivov <bunglehead(a)gmail.com>: >> In principle this is most likely fine, but I'd really prefer to have similar >> test for all node types that support this method, so we can move a check >> directly to node_get_owner_doc(). For those additional tests it would be >> better to add a new test function called test_get_ownerDocument(). Next step >> would be to make this test run on all document versions (3, 4 and 6), but >> that should be a separate patch, and I'm not asking you to work on it. > > Thanks for your reply. > I agree with you that move the check into node_get_owner_doc might be > more general > > Do you mean I should write a helper function like: > > #define test_get_ownerDocument_call(el,doc) > _test_get_ownerDocument_call(__LINE__,el,doc) > static void _test_get_ownerDocument_call(unsigned line, IXMLDOMElement > *element, IXMLDOMDocument *doc) > { > IXMLDOMDocument *owner; > HRESULT r; > r = IXMLDOMElement_get_ownerDocument( element, NULL ); > ok( r == E_INVALIDARG, "got %08x, expected E_INVALIDARG\n", r); > > owner = NULL; > r = IXMLDOMElement_get_ownerDocument( element, &owner ); > ok( r == S_OK, "get_ownerDocument return code\n"); > ok( owner != doc, "get_ownerDocument return\n"); > IXMLDOMDocument_Release(owner); > } > > No, helper like that won't work, because the point is to check how all node types work, not just elements. What I meant is to have a separate test_* function in START_TEST() that will load a document with all node types you need and iterating through them call get_ownderDocument.

2 3

Scan-build report uploaded
by André Hentschel July 22, 2015

July 22, 2015

Hi, in case someone is interested, i've uploaded a scan-build here: http://dawncrow.de/scan-build-2015-07-20-200148-28114-1/ Wine source is from last Friday

2 2

Re: [PATCH 4/4] mshtml: Add IHTMLXMLHttpRequest::statusText property implementation.
by Jacek Caban July 22, 2015

July 22, 2015

Hi Zhenbo, On 22/07/15 17:34, Zhenbo Li wrote: > + len = MultiByteToWideChar(CP_ACP, 0, str, -1, NULL, 0); > + *p = SysAllocStringLen(NULL, len); > + if(!*p) { > + nsACString_Finish(nscstr); > + return E_OUTOFMEMORY; > + } > + MultiByteToWideChar(CP_ACP, 0, str, -1, *p, len); I didn't catch it earlier, but this should use CP_UTF8. Cheers, Jacek

1 0

1.7.48 release delayed
by Alexandre Julliard July 22, 2015

July 22, 2015

Folks, I'm out to my brother's wedding for a few days, so there won't be a release this Friday. I'm planning to release 1.7.48 early next week, probably on Tuesday. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/3] setupapi: SetupDiGetClassDevsEx returns INVALID_HANDLE_VALUE on error.
by Nikolay Sivov July 22, 2015

July 22, 2015

On 22.07.2015 12:57, Dmitry Timoshkov wrote: > --- > dlls/setupapi/devinst.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/setupapi/devinst.c b/dlls/setupapi/devinst.c > index b084a5e..5a18937 100644 > --- a/dlls/setupapi/devinst.c > +++ b/dlls/setupapi/devinst.c > @@ -2340,7 +2340,7 @@ HDEVINFO WINAPI SetupDiGetClassDevsExW(const GUID *class, PCWSTR enumstr, HWND p > if (!(flags & DIGCF_ALLCLASSES) && !class) > { > SetLastError(ERROR_INVALID_PARAMETER); > - return NULL; > + return INVALID_HANDLE_VALUE; > } > if (flags & unsupportedFlags) > WARN("unsupported flags %08x\n", flags & unsupportedFlags); > How about a test for this and next one?

2 1

Re: winhttp: Implement WINHTTP_OPTION_UNLOAD_NOTIFY_EVENT.
by Dmitry Timoshkov July 22, 2015

July 22, 2015

Huw Davies <huw(a)codeweavers.com> wrote: > + case WINHTTP_OPTION_UNLOAD_NOTIFY_EVENT: > + TRACE("WINHTTP_OPTION_UNLOAD_NOTIFY_EVENT: %p\n", *(HANDLE *)buffer); > + session->unload_event = *(HANDLE *)buffer; > + return TRUE; I admit, that adding another case that doesn't check input buffer size doesn't change much, but it has to stop at some point, rather sooner than later. -- Dmitry.

1 0

Skyrim hang on exit: Any news?
by Theodore Dubois July 22, 2015

July 22, 2015

When you quit to desktop from Skyrim, it hangs. This is bug 34041. It's still a bug, but it has not been touched by anyone from Codewaevers since 2013 (as far as I can tell.) Clearly, it's low priority. Any news? ~Theodore

2 1

Re: user32/tests: Test for caption width of 13 on japanese W7
by Marvin July 21, 2015

July 21, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15482 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2489: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2502: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

1 0

Re: ntdll: Don't touch SecurityCookie when the pointer is outside of the image
by Michael Müller July 21, 2015

July 21, 2015

Am 21.07.2015 um 20:33 schrieb André Hentschel: > + if (loadcfg && loadcfg_size >= sizeof(*loadcfg) && > + (ULONG_PTR)ptr > loadcfg->SecurityCookie &&loadcfg->SecurityCookie < (ULONG_PTR)ptr + total_size) > set_security_cookie((ULONG_PTR *)loadcfg->SecurityCookie); Your check doesn't take the size of the security cookie into account. If the cookie would only be partially inside of the image area, the check would still succeed although not all memory is writable. The check for the lower limit should be (<= instead of >): (ULONG_PTR)ptr <= loadcfg->SecurityCookie Is it possible to have an unmapped space between mapped sections? According to the NT section header it should be possible, but I am not sure if Wine fills this area.

2 1

Re: dwrite: Remove unused initializer (Clang)
by Nikolay Sivov July 21, 2015

July 21, 2015

Looks good, thanks.

1 0

Re: user32/tests: Test for caption width of 13 on japanese W7
by Huw Davies July 21, 2015

July 21, 2015

On 21 Jul 2015, at 19:32, André Hentschel wrote: > --- a/dlls/user32/tests/sysparams.c > +++ b/dlls/user32/tests/sysparams.c > @@ -1554,8 +1554,9 @@ static void test_SPI_SETNONCLIENTMETRICS( void ) /* 44 */ > > ok( Ncmcur.iCaptionWidth == 8 || > Ncmcur.iCaptionWidth == 12 || /* Vista, W7b */ > + Ncmcur.iCaptionWidth == 13 || /* Win7 japanese */ > Ncmcur.iCaptionWidth == Ncmstart.iCaptionWidth, /* with windows XP theme, the value never changes */ > - "CaptionWidth: %d expected 8, 12 or %d\n", Ncmcur.iCaptionWidth, Ncmstart.iCaptionWidth); > + "CaptionWidth: %d expected 8, 12, 13 or %d\n", Ncmcur.iCaptionWidth, Ncmstart.iCaptionWidth); > ok( Ncmcur.iScrollWidth == 8, > "ScrollWidth: %d expected 8\n", Ncmcur.iScrollWidth); > ok( Ncmcur.iScrollHeight == 8, I deliberately haven't fixed it like this because it has already become untenable. I suspect it should be compared to the height of the default gui font, or something like that. Huw.

1 0

[PATCH v2 00/15] AppUserModelID support
by Jonas Kümmerlin July 21, 2015

July 21, 2015

Changes since the last version: - Feedback by Vincent Porvik, Nikolay Sivov and GOUJON Alexandre has been incorporated. - Where appropriate, bigger patches have been split into smaller chunks. - All required features are now implemented: You can try it out by installing LibreOffice using the MSI package, set the windows version to Win7 in winecfg and observe the new fancy desktop file matching performed by your desktop shell. (assuming your shell does this; Gnome3 and Unity do, XFCE and LXDE don't) - While Gnome3 works great, KDE hasn't been exactly cooperative so far. It now gets the grouping right, but ignores the StartupWMClass key in the desktop files, so pinning and fancy high-res icons won't work. This is most likely not fixable on our side, at least not without further research. I am still not happy with the PROPVARIANT (de)serialization code (patches 4 and 5, hope the mailing list won't eat it this time). The ole32 <-> propsys interfacing has been implemented as Nikolay Sivov suggested, but I'm not really happy with it. The new (de)serialization code also caused a weird regression in MSI.dll which I haven't been able to track down yet. I'm currently leaning towards moving the new code to propsys.dll and leaving ole32.dll untouched, even though that would result in two different implementations of basically the same thing. Does anyone have strong opinions on this matter? Rationale: AppUserModelIDs can be used to match open windows to shortcuts in order to make the Win7 Taskbar happen. The idea is similar to WM_CLASS in X11/freedesktop.org environments: Add the AppUserModelID to every window and every shortcut and let the shell figure out the matching. The shell can then do fancy things like pinning the app or showing a high quality icon. While most windows apps rely on the fallback algorithm of doing the shortcut<->window mapping via the full path to the executable, some applications, like LibreOffice, are making use of the AppUserModelID feature to appear as a set of different applications (Writer, Calc, ...) while sharing the same exe file (soffice.bin). Modern freedesktop.org shells work very similar to the Win7 Taskbar in this regard (using the X11 WM_CLASS attribute and the StartupWMClass= deskop entry key), and the goal is to have wine apps appear like any native app: With a high-res icon and pinnable. Jonas Kümmerlin (15): shell32: Implement process-wide explicit AppUserModelID propsys: Implement several PropVariantInit*() functions propsys: Extend PropVariantCompareEx() ole32: Rework property (de)serialization propsys: Implement Stg(De)SerializePropVariant propsys: Implement named properties on the in-memory property store propsys: Implement serialization of the in-memory property store propsys: Implement IPersistStream on the in-memory property store propsys: Partially implement property stringification shell32: Properly implement IPropertyStore for shell links shell32: Implement window property store (SHGetPropertyStoreForWindow) winex11.drv,user32,shell32 Use AppUserModelID to populate WM_CLASS propsys: Partially implement/stub IPropertyDescription msi: Write shortcut properties winemenubuilder: Save AppUserModelID as StartupWMClass dlls/msi/Makefile.in | 2 +- dlls/msi/action.c | 120 ++ dlls/msi/tests/Makefile.in | 2 +- dlls/msi/tests/action.c | 75 +- dlls/msi/tests/automation.c | 1 - dlls/msi/tests/suminfo.c | 4 +- dlls/ole32/stg_prop.c | 1717 +++++++++++++++++++++++----- dlls/ole32/tests/propvariant.c | 86 +- dlls/propsys/Makefile.in | 4 +- dlls/propsys/propdesc.c | 537 +++++++++ dlls/propsys/propdesc_builtin_data.c | 85 ++ dlls/propsys/propstore.c | 1062 ++++++++++++++++- dlls/propsys/propsys.spec | 36 +- dlls/propsys/propsys_classes.idl | 7 +- dlls/propsys/propsys_main.c | 6 - dlls/propsys/propsys_private.h | 23 + dlls/propsys/propvar.c | 889 +++++++++++++- dlls/propsys/tests/Makefile.in | 2 +- dlls/propsys/tests/propstore.c | 403 ++++++- dlls/propsys/tests/propsys.c | 709 +++++++++++- dlls/shell32/Makefile.in | 1 + dlls/shell32/shell32.spec | 2 + dlls/shell32/shell32_main.c | 109 +- dlls/shell32/shelllink.c | 218 +++- dlls/shell32/tests/Makefile.in | 1 + dlls/shell32/tests/appusermodel.c | 272 +++++ dlls/shell32/tests/shell32_test.h | 9 + dlls/shell32/tests/shelllink.c | 123 ++ dlls/shell32/winpropstore.c | 303 +++++ dlls/user32/message.c | 2 +- dlls/user32/user_private.h | 5 +- dlls/winex11.drv/window.c | 160 ++- include/propidl.idl | 6 + include/propsys.idl | 1 + include/propvarutil.h | 105 +- include/shellapi.h | 1 + include/shobjidl.idl | 6 + include/strsafe.h | 17 + include/winbase.h | 2 + include/wine/server_protocol.h | 59 +- programs/winemenubuilder/winemenubuilder.c | 123 +- server/protocol.def | 38 + server/request.h | 35 + server/trace.c | 47 + server/window.c | 148 +++ 45 files changed, 7098 insertions(+), 465 deletions(-) create mode 100644 dlls/propsys/propdesc.c create mode 100644 dlls/propsys/propdesc_builtin_data.c create mode 100644 dlls/shell32/tests/appusermodel.c create mode 100644 dlls/shell32/winpropstore.c -- 2.4.3

4 22

Re: include: Add stuff related to WSAPoll() (try 4)
by Alexandre Julliard July 21, 2015

July 21, 2015

Bruno Jesus <00cpxxx(a)gmail.com> writes: > Use Sebastian's idea of not naming the struct since only WSAPOLLFD is > used anyway. This is still causing a lot of warnings on mingw: In file included from ../../../wine/include/ws2tcpip.h:22:0, from ../../../wine/dlls/jsproxy/main.c:34: ../../../wine/include/winsock2.h:117:0: warning: "POLLERR" redefined In file included from ../../../wine/dlls/jsproxy/main.c:20:0: ../../../wine/include/wine/port.h:293:0: note: this is the location of the previous definition In file included from ../../../wine/include/ws2tcpip.h:22:0, from ../../../wine/dlls/jsproxy/main.c:34: ../../../wine/include/winsock2.h:118:0: warning: "POLLHUP" redefined In file included from ../../../wine/dlls/jsproxy/main.c:20:0: ../../../wine/include/wine/port.h:294:0: note: this is the location of the previous definition In file included from ../../../wine/include/ws2tcpip.h:22:0, from ../../../wine/dlls/jsproxy/main.c:34: ../../../wine/include/winsock2.h:119:0: warning: "POLLNVAL" redefined In file included from ../../../wine/dlls/jsproxy/main.c:20:0: ../../../wine/include/wine/port.h:295:0: note: this is the location of the previous definition In file included from ../../../wine/include/ws2tcpip.h:22:0, from ../../../wine/dlls/jsproxy/main.c:34: ../../../wine/include/winsock2.h:124:0: warning: "POLLPRI" redefined In file included from ../../../wine/dlls/jsproxy/main.c:20:0: ../../../wine/include/wine/port.h:291:0: note: this is the location of the previous definition In file included from ../../../wine/include/ws2tcpip.h:22:0, from ../../../wine/dlls/jsproxy/main.c:34: ../../../wine/include/winsock2.h:125:0: warning: "POLLIN" redefined In file included from ../../../wine/dlls/jsproxy/main.c:20:0: ../../../wine/include/wine/port.h:290:0: note: this is the location of the previous definition In file included from ../../../wine/include/ws2tcpip.h:22:0, from ../../../wine/dlls/jsproxy/main.c:34: ../../../wine/include/winsock2.h:126:0: warning: "POLLOUT" redefined -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] regsvr32: change regsvr32 to a GUI program.
by Nikolay Sivov July 21, 2015

July 21, 2015

On 21.07.2015 12:26, Hao Peng wrote: > --- > programs/regsvr32/Makefile.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > -APPMODE = -mconsole -municode > +APPMODE = -mwindows -municode Why do you need this?

2 1

Re: [PATCH] advapi32: test and fix ChangeServiceConfig2 when given a zero length or a null description (try2, resend)
by Marvin July 20, 2015

July 20, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15399 Your paranoid android. === w7u (32 bit service) === service.c:1421: Test failed: Active services mismatch 1 service.c:1422: Test failed: Inactive services mismatch 4294967295

3 3

Re: odbccp32: Implement SQLGetPrivateProfileStringW/SQLGetPrivateProfileString
by Alistair Leslie-Hughes July 20, 2015

July 20, 2015

On 19/07/15 21:10, Nikolay Sivov wrote: > Based on patch by Alistair Leslie-Hughes > Here is a modified version of the patch you sent. This patch includes test cases for SQLGetPrivateProfileStringW. There was an error in my logic with the entry parameter which I have also corrected. When the entry parameter is NULL, it returns the list of keys, in the format keyname\0keyname\0. I've tested two application which now work correctly with the attached patch. Happy to hear any feedback. Best Regards Alistair.

2 1

Re: kernel32/editline: Enabling/disabling Insert Mode via the user dialog should take effect immediately
by Sebastian Lackner July 20, 2015

July 20, 2015

On 20.07.2015 04:02, Hugh McMaster wrote: > Currently, if Insert Mode is enabled/disabled via the user dialog, > the new console mode does not take effect until after > CONSOLE_Readline is called again. > > On Windows, this change takes effect immediately. > --- > dlls/kernel32/editline.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/dlls/kernel32/editline.c b/dlls/kernel32/editline.c > index 7664b55..581ea7c 100644 > --- a/dlls/kernel32/editline.c > +++ b/dlls/kernel32/editline.c > @@ -987,6 +987,10 @@ WCHAR* CONSOLE_Readline(HANDLE hConsoleIn, BOOL can_pos_cursor) > } > } > > + GetConsoleMode(hConsoleIn, &mode); > + ctx.insert = (mode & (ENABLE_INSERT_MODE|ENABLE_EXTENDED_FLAGS)) == > + (ENABLE_INSERT_MODE|ENABLE_EXTENDED_FLAGS) ? 1 : 0; You can remove the " ? 1 : 0" here, the value is already BOOL. > + > if (func) > (func)(&ctx); > else if (!(ir.Event.KeyEvent.dwControlKeyState & LEFT_ALT_PRESSED)) >

2 1

Re: [PATCH 3/4] msvcp110: Add tr2_sys__Last_write_time implementation and test.(resend)
by Piotr Caban July 20, 2015

July 20, 2015

On 07/18/15 05:15, YongHao Hu wrote: > + /* test the formula */ > + file = CreateFileA("tr2_test_dir/f1", 0, FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE, > + NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, 0); > + ok(file != INVALID_HANDLE_VALUE, "create file failed: INVALID_HANDLE_VALUE\n"); > + ok(GetFileTime(file, 0, 0, &lwt), "GetFileTime failed\n"); > + CloseHandle(file); > + last_write_time = (((__int64)lwt.dwHighDateTime)<< 32) + lwt.dwLowDateTime; > + last_write_time -= TICKS_1601_TO_1970; > + last_write_time /= TICKSPERSEC; > + ok(last_write_time == newtime, "last_write_time after converting from FILETIME to UNIX Timestamp should equal to newtime\n"); There's no guarantee that the filesystem will store the time accurately. As far as I know the test will not work on fat file system. > + /* test negative time */ > + newtime = 1111111; > + p_tr2_sys__Last_write_time_set("tr2_test_dir/f1", -newtime); > + last_write_time = p_tr2_sys__Last_write_time("tr2_test_dir/f1"); > + todo_wine ok(1844674407369-newtime+1 == last_write_time, "last_write_time expect %s, got %s\n", > + debugstr_longlong(1844674407369-newtime+1), debugstr_longlong(last_write_time)); You can't use debugstr_longlong 2 times inside one ok call. You can't use 64-bit constants this way. Also please avoid using "magic" constants. Is this test still failing on wine if unsigned __int64 is used in computations? > + /* maximum time */ > + newtime = 9223372036854775807; > + p_tr2_sys__Last_write_time_set("tr2_test_dir/f1", newtime); > + todo_wine ok(1844674407369 == p_tr2_sys__Last_write_time("tr2_test_dir/f1"), "last_write_time expect 1844674407369, got %s\n", > + debugstr_longlong(p_tr2_sys__Last_write_time("tr2_test_dir/f1"))); I'm expecting it to fail on some filesystems. It would be nice to run this tests on fat32 filesystem. Cheers, Piotr

1 0

Re: [PATCH] user32/tests: Correct spelling of "Invisible".
by Marvin July 20, 2015

July 20, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15450 Your paranoid android. === wvistau64 (64 bit msg) === msg.c:10609: Test failed: expected PeekMessage to return FALSE, got 1

1 0

Re: [PATCH 2/4] msvcp110: Add tr2_sys__Stat and tr2_sys__Lstat implementation and test.(try 2)
by Piotr Caban July 20, 2015

July 20, 2015

On 07/17/15 20:20, YongHao Hu wrote: > --- > dlls/msvcp110/msvcp110.spec | 8 +- > dlls/msvcp120/msvcp120.spec | 8 +- > dlls/msvcp120/tests/msvcp120.c | 142 > ++++++++++++++++++++++++++++++++++++ > dlls/msvcp120_app/msvcp120_app.spec | 8 +- > dlls/msvcp90/ios.c | 47 ++++++++++++ > 5 files changed, 201 insertions(+), 12 deletions(-) There's a compilation warning: msvcp120.c: In function 'test_tr2_sys__Stat': msvcp120.c:777:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] BYTE buf[sizeof(struct REPARSE_MOUNTPOINT_DATA_BUFFER) + MAX_PATH * sizeof(WCHAR)]; The tests are also not working for me on Windows 7: msvcp120.c:770: Test failed: CreateSymbolicLinkA failed msvcp120.c:771: Test failed: CreateSymbolicLinkA failed msvcp120.c:823: Test failed: tr2_sys__Stat(): test 6 expect: 2, got 1 msvcp120.c:834: Test failed: tr2_sys__Lstat(): test 6 expect: 2, got 1 msvcp120.c:823: Test failed: tr2_sys__Stat(): test 7 expect: 3, got 1 msvcp120.c:834: Test failed: tr2_sys__Lstat(): test 7 expect: 3, got 1 msvcp120.c:845: Test failed: expect tr2_test_dir/f1_link to exist msvcp120.c:846: Test failed: expect tr2_test_dir/dir_link to exist msvcp120: 380 tests executed (0 marked as todo, 8 failures), 0 skipped. There are some more test failures when tests are run from filesystem that doesn't support reparse points: msvcp120.c:621: Test failed: test_tr2_sys__Copy_file(): test 5 expect: 5, got 80 msvcp120.c:623: Test failed: test_tr2_sys__Copy_file(): test 11 expect: 3, got 2 msvcp120.c:770: Test failed: CreateSymbolicLinkA failed msvcp120.c:771: Test failed: CreateSymbolicLinkA failed msvcp120.c:785: Test failed: DeviceIoControl failed msvcp120.c:792: Test failed: DeviceIoControl failed msvcp120.c:823: Test failed: tr2_sys__Stat(): test 6 expect: 2, got 1 msvcp120.c:834: Test failed: tr2_sys__Lstat(): test 6 expect: 2, got 1 msvcp120.c:823: Test failed: tr2_sys__Stat(): test 7 expect: 3, got 1 msvcp120.c:834: Test failed: tr2_sys__Lstat(): test 7 expect: 3, got 1 msvcp120.c:845: Test failed: expect tr2_test_dir/f1_link to exist msvcp120.c:846: Test failed: expect tr2_test_dir/dir_link to exist msvcp120: 380 tests executed (0 marked as todo, 12 failures), 0 skipped.

2 2

Re: include: Add stuff related to WSAPoll() (try 3)
by Sebastian Lackner July 20, 2015

July 20, 2015

On 17.07.2015 18:29, Bruno Jesus wrote: > Try to apply Matteo's idea to not redefine the struct when port.h was > already included. I can't test in mingw myself unfortunately. I don't think this will work properly. The Linux pollfd struct contains "fd" with type "int", but on Windows its defined as "SOCKET" (which has size of a pointer). My personal preference would be to just leave out the "struct pollfd" definition here, and only declare WSAPOLLFD. Basically: +typedef struct +{ + SOCKET fd; + SHORT events; + SHORT revents; +} WSAPOLLFD; Not sure if this would be an acceptable solution for the other devs though.

2 1

Re: [PATCH 3/4] msvcp110: Add tr2_sys__Last_write_time implementation and test.
by Piotr Caban July 20, 2015

July 20, 2015

2 1

Re: msi/tests: Mark a test result on win2k3 as broken.
by Marvin July 17, 2015

July 17, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15404 Your paranoid android. === w7u (32 bit package) === The test timed out

1 0

Re: [4/4] user32: SystemParametersInfo(SPI_GETNONCLIENTMETRICS) should return real font names.
by Marvin July 17, 2015

July 17, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15397 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2488: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2501: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

1 0

Re: winemac.drv: Release mouse capture when destroying window specified in SetCapture call
by Ken Thomases July 17, 2015

July 17, 2015

On Jul 17, 2015, at 5:54 AM, Piotr Caban <piotr(a)codeweavers.com> wrote: > --- > dlls/winemac.drv/window.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/winemac.drv/window.c b/dlls/winemac.drv/window.c > index c67ccd0..9d996ec 100644 > --- a/dlls/winemac.drv/window.c > +++ b/dlls/winemac.drv/window.c > @@ -1274,6 +1274,8 @@ void CDECL macdrv_DestroyWindow(HWND hwnd) > > if (!(data = get_win_data(hwnd))) return; > > + if (hwnd == GetCapture()) macdrv_SetCapture(0, 0); > + > if (data->gl_view) macdrv_dispose_view(data->gl_view); > destroy_cocoa_window(data); > > Looks good to me. Thanks! -Ken

1 0

Re: [1/4] user32: Add a test to show that fonts returned by SystemParametersInfo(SPI_GETNONCLIENTMETRICS) should be listed b
by Marvin July 17, 2015

July 17, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15394 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2488: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2501: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

1 0

Re: [PATCH 2/2] d3drm/tests: Add version specific tests for CreateDeviceFrom* methods. (try 3)
by Stefan Dösinger July 17, 2015

July 17, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Sorry, there are always more issues to find :-( . Am 2015-07-16 um 18:08 schrieb Aaryaman Vasishta: > + hr = IDirectDrawSurface_GetClipper(d3drm_primary, &d3drm_clipper); > ... > + if (d3drm_primary) > + IDirectDrawSurface_Release(d3drm_primary); The if check here is redundant. I expect Coverity to complain about this sooner or later... (version 2 and 3 are affected too) > + hr = IDirect3DRM3_CreateDeviceFromClipper(d3drm3, clipper, &driver, 0, 0, &device3); > + todo_wine ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got %x.\n", hr); > ... > + /* If NULL is passed for clipper, CreateDeviceFromClipper returns D3DRMERR_BADVALUE */ > + hr = IDirect3DRM3_CreateDeviceFromClipper(d3drm3, NULL, &driver, 0, 0, &device3); > + todo_wine ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got %x.\n", hr); Does it return D3DRMERR_BADVALUE because clipper is NULL or because width / height are 0? Don't test two error conditions at once, unless both return a different error and you want to test the priority of the error handling. (version 2 and 3 are affected too) > + /* What happens if we don't pass D3DRMDEVICE_NOZBUFFER and still not attach our own depth surface? */ > + hr = IDirect3DRM3_CreateDeviceFromSurface(d3drm3, &driver, ddraw, surface, D3DRMDEVICE_NOZBUFFER, &device3); > + ok(SUCCEEDED(hr), "Cannot create IDirect3DRMDevice3 interface (hr = %x).\n", hr); Please also test what happens when you have an already attached depth surface and do *not* pass D3DRMDEVICE_NOZBUFFER. I suspect that it either works like version 2 (your surface is kept, no error), or that it returns an error (because AddAttachedSurface fails). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVqLmUAAoJEN0/YqbEcdMw3L8P/iqw4zcu9MbgJsfvM7MBLqZa OEbQ5SyYot/QTPqGL1TPujjLIkm4q557Ban2ZBcN3lPSWscJ5KQoo2sKedWfu/yi Y47Cvwqggrx7FUOpdNEdp4311eDQ3xo6wYklhzVAUXqQ4cZRmjm6clhMlIW1PPfX v2iJSNg4xTBqABH6xz+bapO29QpDqq5KuWTRtUuzGFZt9N1cvCzgNHRPmMtlpiCp ray9/trglSQzsqbyamRD5Tr9Cd8bpSgxrtF7juIVc1MEBISuJquN+Hv/I3qqKgUb SZkf3yDmEoKeRrCHgfESR9j9gkzH6Iy0R01GWIVdQCshyW36rNI6NwP8zBu9kaeq psHeFv0Rp0Ed4OKqc+WT+OwagEaH9TwBXmd/JruOiNMQK4/q4HOVvM/10jPG+/gP /PioGPETbISnMZqZBqSJkdw/NgKoiP8AnJKxYI8GNoAPnPbkktTZ+G0T4rRJkKX/ uYEoUma38cSs6Mv0t1Qb5mxMOl6ioeBnZlGF2WxnZkAOct4Xaww2EM7fPN0dqUP3 nDGd4dU4Sj66hrb5p3nb12K/iJ+skjT0beHWQfxPDhlL9NyLDLl/96XCB/sV5S8Y qJR3irxiFgSbcm+kGsSa24GV2B1gDDGeXFDEm6rZo37jlG3ASzoOnek9HqcSgBA1 scHWj2bMxjyM39oePaek =ve5C -----END PGP SIGNATURE-----

1 0

[PATCH 0/6] [WIP] AppUserModelID implementation
by Jonas Kümmerlin July 16, 2015

July 16, 2015

Hi, I'm currently working on implementing AppUserModelID[1] support in Wine. It's far from finished, but it's slowly getting there, so I want to show it off and get some feedback. Rationale: AppUserModelIDs can be used to match open windows to shortcuts in order to make the Win7 Taskbar happen. The idea is similar to WM_CLASS in X11/freedesktop.org environments: Add the AppUserModelID to every window and every shortcut and let the shell figure out the matching. The shell can then do fancy things like pinning the app or showing a high quality icon. While most windows apps rely on the fallback algorithm of doing the shortcut<->window mapping via the full path to the executable, some applications, like LibreOffice, are making use of the AppUserModelID feature to appear as a set of different applications (Writer, Calc, ...) while sharing the same exe file (soffice.bin). Modern freedesktop.org shells work very similar to the Win7 Taskbar in this regard (using the X11 WM_CLASS attribute and the StartupWMClass= deskop entry key), and the goal is to have wine apps appear like any native app: With a high-res icon and pinnable. At the moment, the following features are implemented and working: - SetCurrentProcessExplicitAppUserModelID - IPropertyStore implementation on IShellLink - Exporting the AppUserModelID as WM_CLASS in the X11 driver The following things are not yet implemented, but I expect to complete them in the following weeks: - The window-specific property store (SHGetPropertyStoreForWindow) - MSI support for shortcut properties - Extracting the AppUserModelID in winemenubuilder.exe The whole thing required me to implement a fair bit of infrastructure (mostly in propsys.dll), and I am afraid that more might follow. Since I am kinda new to wine development, I appreciate any early feedback and comments. Regards Jonas Kümmerlin [1] Application User Model IDs: https://msdn.microsoft.com/en-us/library/windows/desktop/dd378459(v=vs.85).… Jonas Kümmerlin (6): shell32: Implement process-wide explicit AppUserModelID winex11.drv: Use process-wide AppUserModelID to populate WM_CLASS ole32, propsys: Rework PROPVARIANT (de)serialization propsys: Implement named properties, serialization on the in-memory store propsys: Partially implement property stringification shell32: Properly implement IPropertyStore for shell links dlls/ole32/ole32.spec | 3 + dlls/ole32/stg_prop.c | 1711 ++++++++++++++++++++++++++++++++----- dlls/ole32/tests/propvariant.c | 55 +- dlls/propsys/propstore.c | 1088 ++++++++++++++++++++++- dlls/propsys/propsys.spec | 34 +- dlls/propsys/propsys_classes.idl | 7 +- dlls/propsys/propvar.c | 821 +++++++++++++++++- dlls/propsys/tests/Makefile.in | 2 +- dlls/propsys/tests/propstore.c | 400 ++++++++- dlls/propsys/tests/propsys.c | 460 +++++++++- dlls/shell32/shell32.spec | 1 + dlls/shell32/shell32_main.c | 109 ++- dlls/shell32/shelllink.c | 218 +++-- dlls/shell32/tests/Makefile.in | 1 + dlls/shell32/tests/appusermodel.c | 108 +++ dlls/shell32/tests/shell32_test.h | 9 + dlls/shell32/tests/shelllink.c | 123 +++ dlls/winex11.drv/window.c | 72 +- include/propidl.idl | 10 + include/propvarutil.h | 106 ++- include/shobjidl.idl | 6 + include/winbase.h | 2 + 22 files changed, 4971 insertions(+), 375 deletions(-) create mode 100644 dlls/shell32/tests/appusermodel.c -- 2.4.3

4 22

Re: [PATCH 1/4] d3d9/tests: Add a windowed GetFrontBufferData test.
by Henri Verbeet July 16, 2015

July 16, 2015

On 6 July 2015 at 23:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > --- > dlls/d3d9/tests/visual.c | 92 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 92 insertions(+) > Testbot failures aside, GetFrontBufferData() is pretty unreliable. This will (potentially) fail if e.g. a different window is covering the test window. (And the ChildWindowFromPoint() in v2 doesn't help, because it only takes other Wine windows into account.)

2 11

Re: [PATCH 2/7] winex11.drv: implement DoDragDrop on top of XDND (try 2)
by Ken Thomases July 16, 2015

July 16, 2015

Hi, On Jul 16, 2015, at 12:38 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Implements DoDragDrop on top of XDND. > --- > dlls/winex11.drv/clipboard.c | 50 +++ > dlls/winex11.drv/event.c | 2 + > dlls/winex11.drv/x11drv.h | 7 + > dlls/winex11.drv/xdnd.c | 837 +++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 896 insertions(+) Since you removed the parts touching the user drivers from patch 1 (at my request; thanks), doesn't this patch need to add the entry point to the .spec file? -Ken

2 1

Re: [PATCH (try 2)] user32: Scroll listbox item completely into view on LB_SETCURSEL.
by Marvin July 16, 2015

July 16, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15351 Your paranoid android. === wvistau64 (32 bit listbox) === listbox.c:709: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 listbox.c:944: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18 === wvistau64 (64 bit listbox) === listbox.c:709: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 listbox.c:944: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18

1 0

Re: [1/4] msvcirt: Implement ios static locking (try 3)
by Piotr Caban July 16, 2015

July 16, 2015

Hi Iván, On 07/15/15 21:29, Iván Matellanes wrote: > +CRITICAL_SECTION ios_static_lock; ... > +CRITICAL_SECTION ios_static_lock = { &ios_static_lock_debug, -1, 0, 0, 0, 0 }; This will not compile when Microsoft Visual Studio is used (variable redefinition). Please use "extern". Thanks, Piotr

1 0

Re: [4/8] vcomp: Implement stub for _vcomp_fork.
by Alexandre Julliard July 16, 2015

July 16, 2015

Sebastian Lackner <sebastian(a)fds-team.de> writes: > +void WINAPIV _vcomp_fork(BOOL ifval, int nargs, void *wrapper, ...) > +{ > + __ms_va_list valist; > + > + TRACE("(%d, %d, %p, ...)\n", ifval, nargs, wrapper); > + > + __ms_va_start(valist, wrapper); > + _vcomp_fork_call_wrapper(wrapper, nargs, valist); > + __ms_va_end(valist); > +} Using a valist for this is questionable, even more so in the next patch where you copy it around, and doesn't buy anything over doing it in assembly from the start. -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: [PATCH] user32: Scroll listbox item completely into view on LB_SETCURSEL.
by Marvin July 16, 2015

July 16, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15347 Your paranoid android. === wvistau64 (32 bit listbox) === listbox.c:711: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 listbox.c:946: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18 === w7u (32 bit listbox) === listbox.c:452: Test failed: expected vscroll 0, got 1 listbox.c:457: Test failed: expected vscroll 1, got 2 === wvistau64 (64 bit listbox) === listbox.c:711: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY, *) filled with 7 entries, expected > 7 listbox.c:946: Test failed: SendMessage(LB_DIR, DDL_DIRECTORY|DDL_EXCLUSIVE, *) failed err 18

1 0

Re: [PATCH 3/8] winex11.drv: implement DoDragDrop on top of XDND
by Sebastian Lackner July 16, 2015

July 16, 2015

On 04.07.2015 15:36, Damjan Jovanovic wrote: > Implements DoDragDrop on top of XDND. While some of DoDragDrop() and > supporting functions are copied from ole32, they were modified to be > non-blocking and event-driven. > > The clipboard is patched to allow searching its clipboard formats for > X11 atoms, export data in X11 format, and forward selection requests > for the XdndSelection selection to XDND. > > We support XDND version 3 to 5 (although we still need XdndProxy > support for version 4). XdndPosition messages are rate-limited to at > most 1 unreplied message and at least every 50 milliseconds apart, so > that we don't flood slow X11 clients like the spec warns. > > Damjan Jovanovic > --- > dlls/winex11.drv/clipboard.c | 50 +++ > dlls/winex11.drv/event.c | 2 + > dlls/winex11.drv/x11drv.h | 7 + > dlls/winex11.drv/xdnd.c | 829 ++++++++++++++++++++++++++++++++++++++++++- > 4 files changed, 887 insertions(+), 1 deletion(-) Thanks for working on this. Sorry for the delayed reply, I've been a bit busy during the last days. Not sure if you have already started improving the patches, but I'll just comment on this version. First of all, regarding patch 2, applying such a patch separately doesn't make much sense. Either the design is accepted (then it can be part of patch 3), or it needs additional work, but then its questionable if the function can be used without further modifications. At first I was planning to give line by line feedback on the patch, but I think you are more interested in general feedback about the design. One of the main disadvantages I see in the current approach is that there is a lot of code duplication in winex11 and ole32. It will get even worse as soon as someone starts implementing the same for winemac or other future backends. I am aware that Ken Thomases basically asked for such a solution, but I don't think its the right approach. There are basically two ways to solve it: * Either the code in winex11 has to be stripped down a lot. A more minimalistic solution has better chances to be accepted, and as soon as winemac contains a similar implementation, the code in ole32 could be removed. When we need a huge statemachine though, its better to avoid duplication. * Alternatively, instead of duplicating code, the winex11/winemac backend could provide a function pointer table or separate exports, with callbacks for things which can be done natively. Ole32 could use these callbacks to register the format, query if it dragging was finished, and so on. To avoid polling, the driver could also post window messages to the "TrackerWindow". If you need any help, feel free to ask. Also feel free to show proof-of-concept patches even when they are not finished yet, for example via IRC or wine-devel. As a side note, it looks like various parts of your patch lack proper locking, but thats not your fault, its already missing in the existing winex11 code. I'll see if I can clean up the existing code a bit to simplify the integration of such a new feature. Best regards, Sebastian

2 1

Re: [PATCH 2/2] d3drm: Add version specific tests for CreateDeviceFrom* methods. (try 2)
by Marvin July 15, 2015

July 15, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15326 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm: unhandled exception c0000005 at 00409C73 === wxppro (32 bit d3drm) === d3drm: unhandled exception c0000005 at 00409C73 === w2003std (32 bit d3drm) === d3drm: unhandled exception c0000005 at 00409C73

1 0

Re: [PATCH 1/2] d3drm/tests: Fix leaks while creating device in tests (Valgrind) (try 2)
by Marvin July 15, 2015

July 15, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15325 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm: unhandled exception c0000005 at 00409DAB === wxppro (32 bit d3drm) === d3drm: unhandled exception c0000005 at 00409DAB === w2003std (32 bit d3drm) === d3drm: unhandled exception c0000005 at 00409DAB

1 0

WineConf 2015 RSVP
by Stefan Dösinger July 15, 2015

July 15, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Jeremy Newman has set up a simple form to register for WineConf: https://www.winehq.org/wineconf/rsvp . If you're planning to attend the conference please fill out this form. This allows us to give the hotel a better guest estimate to prepare the conference room. The link can of course be found at the WineConf 2015 wiki page: http://wiki.winehq.org/WineConf2015 . Thanks, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVppXBAAoJEN0/YqbEcdMwlwIP/jmLTAGgjm++2oE4NtznKisw TKdclyHGxsi//iVSPJ3TGH+GZdjd1ymcnoNthIWxHJfnDBxm/eqeNDsyRcOEEtAg g/qgiTa1dToWdb9lkyJKqU7MJioYOnDXDruhn1C9+3LUVkQE1hdSvMlIq2+4iRoX s2A+pkT1Gz8qfn/QXjrReZ5ZswvqaqNTWvfBtXRKxzHw/IhtEA5KnNDyQAfB1GiM B5gbWr5GWe200LDnxAu4L0wduznnFA4GKPtdOYByFHGT3eXUShCB8q6vCTBIVvq3 grZSAdE08p7XLj9f41YIN/P5LpjB40zdvns/KxtkYOmLsCF49npLptQrbxgCqWqz +1W2mdcRKu8Y7EusLB+Oa9shwfgIMO2wiRIGiRvxRB2w3h4Yg3IvYMaha+YczYa3 4+iaDgSLwwfTi5OKhK0zV+8JYyWzWaSSRlBm0MFS407i+DHkFtTWtmktQrG20LGG tcdTWRlD02GvjxWbuF3iMDwk2DRJl9wAY4PH9Z2VyR15i3w2Bs00FmY+Td4L38GS otw4EozknMNd/MBv7ijWrDaiEw1GMrkhh1b+wbxKmw/Ac2x+tBNtcLM8R00PuxK3 corVb1WzkRbIjCNPpQ0YS2C/8OVFh/k0ScO5R5+au0L0FepUxKg91A94hOH0KJk/ waKBRJ23gYN55NlsIh8J =KVcj -----END PGP SIGNATURE-----

1 0

Re: [PATCH 3/5] d3drm: Add version specific tests for CreateDeviceFrom* methods.
by Marvin July 15, 2015

July 15, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15324 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm: unhandled exception c0000005 at 00409C73 === wxppro (32 bit d3drm) === d3drm: unhandled exception c0000005 at 00409C73 === w2003std (32 bit d3drm) === d3drm: unhandled exception c0000005 at 00409C73

1 0

Need a new subscriber password
by Aaryaman Vasishta July 15, 2015

July 15, 2015

Hello, Please provide me with a new password as I've forgotten the old one for this list. Thanks! Jam

2 1

Re: [PATCH 1/5] d3drm/tests: Fix leaks while creating device in tests (Valgrind)
by Marvin July 15, 2015

July 15, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15323 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm: unhandled exception c0000005 at 00409DAB === wxppro (32 bit d3drm) === d3drm: unhandled exception c0000005 at 00409DAB === w2003std (32 bit d3drm) === d3drm: unhandled exception c0000005 at 00409DAB

1 0

Re: [PATCH 1/5] d3drm/tests: Fix leaks while creating device in tests (Valgrind)
by Aaryaman Vasishta July 15, 2015

July 15, 2015

This fixes bug #38913. https://bugs.winehq.org/show_bug.cgi?id=38913 On Wed, Jul 15, 2015 at 5:23 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > --- > dlls/d3drm/tests/d3drm.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index 1816214..8c1c9d6 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -1999,10 +1999,14 @@ static void test_create_device_from_clipper(void) > > hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, > 0, 0, &device2); > todo_wine ok(hr == D3DRMERR_BADVALUE, "Expected hr == > D3DRMERR_BADVALUE, got %x.\n", hr); > + if (FAILED(hr)) > + IDirect3DRMDevice2_Release(device2); > > /* If NULL is passed for clipper, CreateDeviceFromClipper returns > D3DRMERR_BADVALUE */ > hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, NULL, &driver, 0, > 0, &device2); > todo_wine ok(hr == D3DRMERR_BADVALUE, "Expected hr == > D3DRMERR_BADVALUE, got %x.\n", hr); > + if (FAILED(hr)) > + IDirect3DRMDevice2_Release(device2); > > hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, > 300, 200, &device2); > ok(hr == D3DRM_OK, "Cannot create IDirect3DRMDevice2 interface (hr = > %x).\n", hr); > -- > 2.3.2 (Apple Git-55) > >

1 1

Processing flags before files in regsvr32
by Hugh McMaster July 15, 2015

July 15, 2015

After investigating bug 38870 [1], I came up with some possible solutions to this problem. 1. Duplicate argv. 2. Copy the filename argument into a dynamically allocated array. 3. Copy the filename's iteration number (the 'n' of argv[n]) into a dynamically allocated array. 4. Use NULL pointers after processing to determine whether an argument is a flag or a filename. Of these answers, option four is the lightest and easiest to implement. It is also efficient. The idea is to assign argv[i] = NULL after we have processed an argument that is a flag. So, I'm proposing something like this pseudo-code (there is an actual diff below): for (i = 1; i < argc; i++) { if (is a flag) { do something; argv[i] = NULL; } } for (i = 1; i < argc; i++) { if (argv[i]) /* only filenames are valid */ do something; } diff --git a/programs/regsvr32/regsvr32.c b/programs/regsvr32/regsvr32.c index 449124f..ef895e0 100644 --- a/programs/regsvr32/regsvr32.c +++ b/programs/regsvr32/regsvr32.c @@ -270,8 +270,13 @@ int wmain(int argc, WCHAR* argv[]) output_write(STRING_USAGE); return 1; } + argv[i] = NULL; } - else + } + + for (i = 1; i < argc; i++) + { + if (argv[i]) { WCHAR *DllName = argv[i]; int res = 0; The proposed changes work correctly, both with a test DLL and also MediaInfo program from the bug. Any comments and suggestions are welcome. [1] https://bugs.winehq.org/show_bug.cgi?id=38870

2 2

Re: [4/7] msvcirt: Implement ios static locking (resend)
by Piotr Caban July 15, 2015

July 15, 2015

On 07/13/15 21:39, Iván Matellanes wrote: > > +/* ?x_lockc(a)ios@@0U_CRT_CRITICAL_SECTION@@A */ > +CRITICAL_SECTION ios_static_lock; > /* ?unsetf(a)ios@@QAEJJ(a)Z */ > @@ -1322,6 +1327,12 @@ static void init_io(void *base) > init_streambuf_rtti(base); > init_ios_rtti(base); > #endif > + InitializeCriticalSection(&ios_static_lock); > +} > + > +static void free_io(void) > +{ > + DeleteCriticalSection(&ios_static_lock); > } Please initialize the critical section statically (e.g. MSVCRT_file_cs is initialized that way in dlls/msvcrt/file.c). Thanks, Piotr

1 0

Re: [1/2] gdi32: EnumFontFamilies should enumerate substituted fonts when directly asked for.
by Alexandre Julliard July 15, 2015

July 15, 2015

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > I.e. EnumFontFamilies(NULL) won't enumerate substituted fonts, but > EnumFontFamilies("MS Shell Dlg") will do. > > Part1 of the fix for bug 19289. It breaks the tests here: ../../../tools/runtest -q -P wine -T ../../.. -M gdiplus.dll -p gdiplus_test.exe.so font && touch font.ok font.c:756: Test failed: wrong face name MS Shell Dlg font.c:767: Test failed: wrong face name MS Shell Dlg -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: dwrite: Fix transform matrix usage for pixel snapping
by Marvin July 14, 2015

July 14, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15314 Your paranoid android. === wvistau64 (64 bit layout) === layout.c:3395: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 === w2008s64 (64 bit layout) === layout.c:3395: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859 layout.c:3408: Test failed: 27: got 12.001999, expected 12.002001, baseline 12.005859

1 0

Re: msxml3: Handle NULL parameter in IXMLDOMElement::get_ownerDocument().
by Nikolay Sivov July 14, 2015

July 14, 2015

On 14.07.2015 15:09, Zhenbo Li wrote: > --- > dlls/msxml3/element.c | 2 ++ > dlls/msxml3/tests/domdoc.c | 3 +++ > 2 files changed, 5 insertions(+) > In principle this is most likely fine, but I'd really prefer to have similar test for all node types that support this method, so we can move a check directly to node_get_owner_doc(). For those additional tests it would be better to add a new test function called test_get_ownerDocument(). Next step would be to make this test run on all document versions (3, 4 and 6), but that should be a separate patch, and I'm not asking you to work on it.

1 0

Re: [1/2] windowscodecs/tests: Add some tests for loading truncated GIF images.
by Vincent Povirk July 13, 2015

July 13, 2015

Series looks good to me, but I'm not sure what you're trying to pull by putting an obviously correct fix in a patch labeled "tests".

2 1

Re: gdiplus: Move the burden of supporting GIF encoding to the WIC backend.
by Vincent Povirk July 13, 2015

July 13, 2015

I don't have a strong opinion on this, but committing this before we have support in WIC seems a bit sideways? What we were doing before was broken, but this just makes it broken in a different way. Before, we weren't reporting all formats native does, but now we're reporting formats we can't encode. So, this is just going to break or fix applications at random?

2 1

Re: windowscodecs: Add support for 8bpp grayscale TIFF with 8bpp alpha.
by Vincent Povirk July 13, 2015

July 13, 2015

Looks good to me, thanks.

1 0

Re: [PATCH 4/5] wined3d: Don't run check_filter() on core contexts.
by Henri Verbeet July 13, 2015

July 13, 2015

On 10 July 2015 at 00:06, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > The code uses glBegin() / glEnd() and other APIs removed from core > profile. > --- > In theory we could fix check_filter() to work on core profile but it > doesn't seem to be useful there. I probably agree about the limited usefulness of check_filter() on core profiles, but at the same time it seems that most of the functionality needed to make it work there would be needed for other capability tests anyway.

3 3

Re: (resend 2)[2/5]hidclass.sys: Implement a report ring buffer
by Henri Verbeet July 13, 2015

July 13, 2015

On 10 July 2015 at 21:39, Aric Stewart <aric(a)codeweavers.com> wrote: > +typedef struct __ReportRingBuffer Did you borrow this from somewhere? Identifiers starting with double underscore are reserved. (And using a single underscore instead isn't much better.) The naming is also inconsistent with the existing code. And I have to say that goes for much of the rest of the series as well. There seems to be no consistent style from one patch to the next, and sometimes within the same structure. (E.g. __WINE_ELEMENT, __WINE_HID_REPORT, etc.) And of course most of this patch is unused code until patch 5/5 when RingBuffer_Create() is actually called. > +struct __ReportRingBuffer* RingBuffer_Create(UINT buffer_size) > +{ > + ReportRingBuffer *ring; > + ring = HeapAlloc(GetProcessHeap(), 0, sizeof(*ring)); > + if (!ring) > + return NULL; > + ring->start = ring->end = 0; > + ring->size = 32; > + ring->buffer_size = buffer_size; > + ring->pointer_alloc = 5; > + ring->pointers = HeapAlloc(GetProcessHeap(), 0, sizeof(int) * 5); > + memset(ring->pointers, 0xff, sizeof(int) * 5); > + ring->buffer = HeapAlloc(GetProcessHeap(), 0, buffer_size * ring->size); > + InitializeCriticalSection(&ring->lock); > + ring->lock.DebugInfo->Spare[0] = (DWORD_PTR)(__FILE__ ": RingBuffer.lock"); > + return ring; > +} Why handle allocation failure for "ring", but not for "ring->pointers" and "ring->buffer"? Why did you pick "5" for the initial size of "ring->pointers"? Seems like an odd choice. > +VOID RingBuffer_Destroy(struct __ReportRingBuffer *ring) Why use "VOID"? Are you concerned "void" may not be available? > + if (size < 2 || size > 256 || size == ring->size) > + return; What's special about 2 and 256? And if this does nothing, why would you ever call the function like that? > + new_buffer = HeapAlloc(GetProcessHeap(), 0, ring->buffer_size * size); > + HeapFree(GetProcessHeap(), 0, ring->buffer); > + ring->buffer = new_buffer; Why bother with "new_buffer" if you're not going to handle failures?

2 2

Re: [PATCH 2/5] rpcrt4: Set CorrDespIncrement to the size of the (non-range) /robust payload.
by Dmitry Timoshkov July 13, 2015

July 13, 2015

Huw Davies <huw(a)codeweavers.com> wrote: > +static void test_NdrCorrelationInitialize(void) > +{ > + MIDL_STUB_MESSAGE stub_msg; > + BYTE buf[256]; > + > + memset( &stub_msg, 0, sizeof(stub_msg) ); > + memset( buf, 0, sizeof(buf) ); > + > + NdrCorrelationInitialize( &stub_msg, buf, sizeof(buf), 0 ); > + ok( stub_msg.CorrDespIncrement == 2 || > + broken(stub_msg.CorrDespIncrement == 0), /* <= Win 2003 */ > + "got %d\n", stub_msg.CorrDespIncrement ); > + > + stub_msg.CorrDespIncrement = 1; > + NdrCorrelationInitialize( &stub_msg, buf, sizeof(buf), 0 ); > + ok( stub_msg.CorrDespIncrement == 1, "got %d\n", stub_msg.CorrDespIncrement ); > +} Probably having memset() calls before both tests would make it more convincing. -- Dmitry.

2 1

Re: (resend 2)[1/5]hidclass.sys: Implement helper IoCallMinidriver
by Henri Verbeet July 13, 2015

July 13, 2015

On 10 July 2015 at 21:39, Aric Stewart <aric(a)codeweavers.com> wrote: > +NTSTATUS IoCallMinidriver(ULONG code, DEVICE_OBJECT *device, VOID *in_buff, ULONG in_size, VOID *out_buff, ULONG out_size) DECLSPEC_HIDDEN; This is unused until patch 3/5. It also seems like a really bad idea to name internal helper functions like Windows functions. > + if (out_size) > + { > + buffer = HeapAlloc(GetProcessHeap(), 0, out_size); > + memcpy(buffer, out_buff, out_size); > + } Either out_buff and out_size are really badly named, or this is really suspicious.

2 1

Re: [1/2] gdi32: EnumFontFamilies should enumerate substituted fonts when directly asked for.
by Marvin July 13, 2015

July 13, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15259 Your paranoid android. === w2000pro (32 bit font) === font.c:4054: Test failed: Times New Roman Baltic should be enumerated font.c:4056: Test failed: Times New Roman Baltic should be enumerated === wvistau64 (32 bit font) === The test timed out === wvistau64 (64 bit font) === The test timed out

1 0

Re: d3drm: Add stubs for IDirect3DRMDevice methods.
by Stefan Dösinger July 13, 2015

July 13, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, You aren't returning the version 1 interface from QueryInterface. Am 2015-07-11 um 14:40 schrieb Aaryaman Vasishta: > if (IsEqualGUID(riid, &IID_IDirect3DRMDevice3)) > *out = (IUnknown*)&object->IDirect3DRMDevice3_iface; > - else > + else if (IsEqualGUID(riid, &IID_IDirect3DRMDevice2)) > *out = (IUnknown*)&object->IDirect3DRMDevice2_iface; > + else > + *out = (IUnknown*)&object->IDirect3DRMDevice_iface; You can call QueryInterface instead of doing GUID checks like this. Just initialize ref = 0, then call QI and you'll return a ref = 1 device. Another option, if you like this better, is to always return e.g. a IDirect3DRMDevice3 from Direct3DRMDevice_create, remove the riid parameter and do the QueryInterface in the caller. In this case init the refcount to 1 and call device3_Release in the caller after calling QI to obtain the right interface. The first 3 patches look good to me. I'll ack them tomorrow. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVok1NAAoJEN0/YqbEcdMwlFcQAJUgHXSjnseG9zIMJuKwiOoU K0IeSIAODnpT/+Mqc307owC7WBnKhTu4XLmZA1F7NxTxqdIcH85BsYx/LdLSeipq Y9KnTOg6dD00bNrujqyoZ5RmFI/pA+BXwhNXrwfbFg+RLr21ecQTpfRuDn3ENmPM VjWPHsfd4QIRqd+0Qo4LHAAS4UDmMm/avLdN+Gh5AOsDvOQYWW6reaerxYz6k61h rlkZwu1gLsSFTsA/PGz4W3nacVZkfcH8JourB80CJ/+bdPj1DfVImCpa2sx/WQ3g KMzwmR4MnS0n8/F2wGsqx/VMIKQ3zBblWVy4ZkZaMao6wA5IOoISSFXWrQlfUZrS GU5sRGwyVlaYK8qCzBOn3TdHhrrNLpg5hHkCqpN2JM1IgNYVaMevjZ+ISJhvaKXO GlQKwxOdB0M/SRWIPQ2261eQG/31lGEYm9ocu7i4USmNkaVZZCKlBt6wqsbmj6hF 7J2eU2KtfUoJwRozZRPaEdcKa0Xdp9AfrOrq4wilvEpIuUBI2leVVpOBQrbDD1c6 Z7/z8I1hmIw8ZPNl9NIIx7IyRrtnV3GBFG8rmWfRkHMMmIlZKqnC7+Yzgj5UF7Ai vr89VCzoAGj1Du/Xr8x5vmciLAdoRVNNTqV6QTPYqOgOQkodyls8RxH/IwM1sH/6 ZHUuK1kI7/vyX2WkYPi1 =1vdj -----END PGP SIGNATURE-----

3 3

Looking at Bugzilla Bug 38665 - Toontown Rewritten Launcher under Wine/FreeBSD gives "ValueError: Empty certificate data"
by Neel Chauhan July 12, 2015

July 12, 2015

Hi, Can you please look at the Wine Bugzilla Bug 38665. The URL is: https://bugs.winehq.org/show_bug.cgi?id=38665 Thanks, Neel Chauhan

1 0

Re: (resend)[1/5]hidclass.sys: Implement helper IoCallMinidriver
by Dmitry Timoshkov July 10, 2015

July 10, 2015

Aric Stewart <aric(a)codeweavers.com> wrote: > +HRESULT IoCallMinidriver(ULONG code, PDEVICE_OBJECT device, PVOID in_buff, ULONG in_size, PVOID out_buff, ULONG out_size) What 'HRESULT' is supposed to represent in the kernel space? (Especially when actually an NTSTATUS is being returned). That applies to all patches in the series. Also it would be nice to get rid of all LPJUNK style types used all over the place. -- Dmitry.

3 2

Re: [PATCH 5/5] wined3d: Don't install fog compatibility wrappers in core profile contexts.
by Stefan Dösinger July 10, 2015

July 10, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-07-10 um 00:06 schrieb Matteo Bruni: > - if (!gl_info->supported[EXT_FOG_COORD]) > + if (!gl_info->supported[EXT_FOG_COORD] && gl_info->supported[WINED3D_GL_LEGACY_CONTEXT]) Shouldn't that depend on the chosen vertex pipeline implementation rather than the context type? I don't think we need those wrappers in legacy contexts if we're using GLSL for vertex processing. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVn66UAAoJEN0/YqbEcdMwwaMP/1NL3D/IB/tP6Ch1CH/SkwLc LVHe5/NZNTJNXCAj3EH+8yKvDZig3aC3yNemO+KZhu+UKdK4iOeoJeHGAxyu1Fa+ d4Vh8aMyG8QFfKDIiaRG8/qxL18HwBBVnp0KtAq2eOB8847XdL0sXGPW0SHiDaWZ 57oE3W85Ym1hfdn6RhRx0QGMFsLlil5d9vd6IF8yAXluItNNH+SDxdVmBwg2IfrA hpH6f5GcEtqG4VZd8ete6DwgEqEQDtvqdlRlcf/HTUSu8RF0Kr+y0SC00Q1NUfEb /QHboR9Vc1Uwca8MZqm9PgsT9aeZgHv5f7K79AewFUnHqj7ZckGM9ptHuPS2pWzM ChHNghvP22LCnhndKl71WJqFTCobGfjNwmD3+ffedBmu7UNLfl2hKSbQCpr3cCCa NDxKlUATuZWKpqJfGrcMbt10grgGolZfbGM99/ngQdeILZc7uwHXveGQJYlerrCz s89ey8dQydozL/sh9QCllcUI58DVE0DOx7rYlvI4/mZMD1+E131JAdIiqDWQYnS5 EVViK+uBXYWTGlTOg1btU9TK0gpzcBSCu3WEfV+BnjhZdR18jQfOzYD1hvy8c36A wBalWpvI6Iqbe/5f32MniyBFaJA2CCaqqZgd5sVx3Y0Y7mhfMk/kgC0vdc9h4tgh N77kUu44pDmGazZwxmjM =6Cds -----END PGP SIGNATURE-----

2 1

Re: msi/tests: Avoid test failures on win2k3.
by Marvin July 10, 2015

July 10, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15219 Your paranoid android. === wvistau64 (32 bit install) === The test timed out === w7u (32 bit install) === Failure running script in VM: timed out waiting for the child process

1 0

Re: crossover programs missing from source code
by Theodore Dubois July 10, 2015

July 10, 2015

I'm not really interested in the source code, I just want to know what the programs do. And yes, I forgot about ntoskrnl, the only dll with an exe extension. I generated that list using ls, grep, and diff, and didn't look over it that carefully. ~Theodore On Jul 05, 2015, at 10:09 AM, Ben Klein <shacklein(a)gmail.com> wrote: In particular, all the cx* programs are Crossover-specific and should not appear in upstream wine at any point. On 6 July 2015 at 02:07, Vincent Povirk <madewokherd(a)gmail.com> wrote: The LGPL doesn't require us to publish the source code of individual .exe.so or .dll.so binaries if we're not basing them on LGPL code. I haven't checked the whole list, but most of these are programs CodeWeavers developed internally and thus controls the copyright on, and they mostly exist for integration with other components of CrossOver. That doesn't mean we can't or shouldn't publish the code, just that we probably haven't considered it. At the very least, I think we want to publish the source code of anything that exists for Windows compatibility. Note that ntoskrnl.exe is actually in the dlls/ directory of the Wine source tree, and it should be there in the CrossOver/Wine source code as well.

3 3

Re: Adding RID_TYPEHID RawInput support to user32
by Aric Stewart July 10, 2015

July 10, 2015

On 7/6/15 10:53 AM, Nathan Schulte wrote: > On 07/06/2015 07:40 AM, Aric Stewart wrote: >> Hello there, Sorry for the delay I was away on vacation until today. >> >> Yes, RawInput support should go through hid.dll. That is actually part of the reason I am doing the hid work the ways I am doing it. I want to be able to fully and correctly support RawInput as well as dinput, xinput and winmm joysticks. >> >> For wine work, you can have all the user32 stuff using the hid.dll HidD_ and HidP_ functions as they can be considered user land work. If you find there are HidD_ or HidP_ function you need that are not implemented, then that can be done. >> >> Right now the hid.dll work has gotten in but I am just starting to get the underlying hid minidriver work in place. Without the minidriver work hid.dll will not do much. > > I found your recent discussion from April ("Wine Joysticks, seeking a plan"), as well as reviewed your current work to hid.dll. I've been learning about the stack as I go along, but it seems documented enough to get a grasp of. These are the minidrivers you're talking about? > > https://msdn.microsoft.com/en-us/library/windows/hardware/jj131707(v=vs.85)… > > You're thinking of creating one per platform/API (on the hosting side: Linux/evdev, (Unix/Linux?) X11, Unix/Mac *), or mirroring MS's setup? I'm not sure how the loading of those libraries works (I did see the HidRegisterMinidriver routine though), so maybe the question is inaccurate. So the next round of patches have been submitted so you can see my hidclass and minidriver work. The goal is to have all the system native minidriver be in the winehidminidriver.sys so that it can be independent from the graphics driver. Wine's hidclass.sys can handle multiple minidrivers in one service, so we should not need independent minidrivers for every platform. Which should be handy. > > On 07/06/2015 07:40 AM, Aric Stewart wrote: >> Yes all the user32 work will need to be done. >> >> Xinput is on my goal list also. Xinput should also be a client of hid.dll > > Sounds good. I'll try to help where I can. It sounds like I need to become more familiar with the system before I'm really useful. There are 3 places I can really use help. 1) Review patches: I always love good reviews on my patches. Leads to stronger code. 2) Above hid.dll: This is doing the development work on RawInput, Xinput, Dinput and such to become clients of the user level hid.dll functions to access joysticks and gamepads. This should mostly be learning the respective APIs and hooking them into HID. RawInput is probably the easiest as it does not do much with the HID reports other than just pass them on. 3) Linux minidrivers: I have implemented the OS/X minidriver because that is what I am most familiar with. There is work to implement the linux and linuxinput minidrivers. This is for someone familiar with or wants to become familiar with the lower level linux interfaces. -aric

3 7

wine CPU usage and CreateWaitableTimer
by andrea July 9, 2015

July 9, 2015

Hi, I'm trying to understand why AppleWin uses 100% CPU when running in wine vs ~1% in Windows. my case is wine 1.7.43 vs Windows 7 https://appdb.winehq.org/objectManager.php?sClass=version&iId=29403 https://bugs.winehq.org/show_bug.cgi?id=34945 basically 97% time is spent in a WaitForSingleObject on a semaphore signalled by a DirectSound IReferenceClock via AdvisePeriodic. The timer period is set to 1 millisecond. I have tried an other Windows call to create the timer: CreateWaitableTimer The latter uses about 50% CPU, so it is much better, but still not very good. This is true even on a simple app that does nothing other than waiting for this timer all the time. Does anybody know 1) is this normal? should these waits be almost free like they are in Windows? 2) what is the best implemented timer in wine that can be used for a periodic event (~1ms)? Thanks

3 10

Re: [5/7] ntdll: Implement RtlDecompressFragment.
by Matteo Bruni July 9, 2015

July 9, 2015

Hi, a bunch of nitpicks which you can take or ignore: 2015-07-09 3:07 GMT+02:00 Sebastian Lackner <sebastian(a)fds-team.de>: > Based on a patch by Michael Müller. > > For https://bugs.winehq.org/show_bug.cgi?id=37449 > > --- > dlls/ntdll/ntdll.spec | 2 > dlls/ntdll/rtl.c | 214 ++++++++++++++++++++++++++++++++++-- > dlls/ntdll/tests/rtl.c | 3 > dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 > 4 files changed, 210 insertions(+), 11 deletions(-) > > diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec > index 75dc647..ca3561d 100644 > --- a/dlls/ntdll/ntdll.spec > +++ b/dlls/ntdll/ntdll.spec > @@ -513,7 +513,7 @@ > @ stdcall RtlDecodePointer(ptr) > # @ stub RtlDecodeSystemPointer > @ stdcall RtlDecompressBuffer(long ptr long ptr long ptr) > -@ stub RtlDecompressFragment > +@ stdcall RtlDecompressFragment(long ptr long ptr long long ptr ptr) > @ stub RtlDefaultNpAcl > @ stub RtlDelete > @ stdcall RtlDeleteAce(ptr long) > diff --git a/dlls/ntdll/rtl.c b/dlls/ntdll/rtl.c > index d9e448a..9a196d2 100644 > --- a/dlls/ntdll/rtl.c > +++ b/dlls/ntdll/rtl.c > @@ -1309,17 +1309,219 @@ NTSTATUS WINAPI RtlCompressBuffer(USHORT format, PUCHAR uncompressed, ULONG unco > } > } > > +/* decompress a single LZNT1 chunk */ > +static PUCHAR lznt1_decompress_chunk(UCHAR *dst, ULONG dst_size, UCHAR *src, ULONG src_size) PUCHAR -> UCHAR * > +{ > + UCHAR *src_cur = src, *src_end = src + src_size; > + UCHAR *dst_cur = dst, *dst_end = dst + dst_size; > + ULONG displacement_bits, length_bits; > + ULONG code_displacement, code_length; > + WORD flags, code; > + > + while (src_cur < src_end && dst_cur < dst_end) > + { > + flags = 0x8000 | *src_cur++; > + while ((flags & 0xFF00) && src_cur < src_end) It looks like we're mostly using lowercase in hex literals. > + { > + if (flags & 1) > + { > + /* backwards reference */ > + if (src_cur + sizeof(WORD) > src_end) > + return NULL; > + > + code = *(WORD *)src_cur; > + src_cur += sizeof(WORD); > + > + /* find length / displacement bits */ > + for (displacement_bits = 12; displacement_bits > 4; displacement_bits--) > + if ((1 << (displacement_bits - 1)) < dst_cur - dst) break; > + > + length_bits = 16 - displacement_bits; > + code_length = (code & ((1 << length_bits) - 1)) + 3; > + code_displacement = (code >> length_bits) + 1; > + > + if (dst_cur < dst + code_displacement) > + return NULL; > + > + /* copy bytes of chunk - we can't use memcpy() > + * since source and dest can be overlapping */ I would also mention that you can't use memmove() either because you actually want to copy any overlapping byte over and over again, as necessary. > + while (code_length--) > + { > + if (dst_cur >= dst_end) return dst_cur; > + *dst_cur = *(dst_cur - code_displacement); > + dst_cur++; > + } > + } > + else > + { > + /* uncompressed data */ > + if (dst_cur >= dst_end) return dst_cur; > + *dst_cur++ = *src_cur++; > + } > + flags >>= 1; > + } > + } > + > + return dst_cur; > +} > + > +/* decompress data encoded with LZNT1 */ > +static NTSTATUS lznt1_decompress(UCHAR *dst, ULONG dst_size, UCHAR *src, ULONG src_size, > + ULONG offset, ULONG *final_size, UCHAR *workspace) > +{ > + UCHAR *src_cur = src, *src_end = src + src_size; > + UCHAR *dst_cur = dst, *dst_end = dst + dst_size; > + ULONG chunk_size, block_size; > + WORD chunk_header; > + UCHAR *ptr; > + > + if (src_cur + sizeof(WCHAR) > src_end) > + return STATUS_BAD_COMPRESSION_BUFFER; > + > + /* skip over chunks which have a distance >= 0x1000 to the destination offset */ > + while (offset >= 0x1000 && src_cur + sizeof(WCHAR) <= src_end) > + { > + chunk_header = *(WORD *)src_cur; > + src_cur += sizeof(WCHAR); Why this mixing of WORD and WCHAR? They do match in practice but still... > + if (!chunk_header) goto out; > + chunk_size = (chunk_header & 0xFFF) + 1; > + > + if (src_cur + chunk_size > src_end) > + return STATUS_BAD_COMPRESSION_BUFFER; > + > + src_cur += chunk_size; > + offset -= 0x1000; > + } > + > + /* check if a chunk is included partially */ > + if (offset && src_cur + sizeof(WCHAR) <= src_end) > + { > + chunk_header = *(WORD *)src_cur; > + src_cur += sizeof(WCHAR); > + if (!chunk_header) goto out; > + chunk_size = (chunk_header & 0xFFF) + 1; > + > + if (src_cur + chunk_size > src_end) > + return STATUS_BAD_COMPRESSION_BUFFER; > + > + if (dst_cur >= dst_end) > + goto out; > + > + if (chunk_header & 0x8000) > + { > + /* compressed chunk */ > + if (!workspace) return STATUS_ACCESS_VIOLATION; > + ptr = lznt1_decompress_chunk(workspace, 0x1000, src_cur, chunk_size); I guess in theory you could avoid decompressing the whole chunk if you need less than the whole chunk to be decompressed. It's not strictly required though so if doing that makes the code too convoluted then ignore it. > + if (!ptr) return STATUS_BAD_COMPRESSION_BUFFER; > + if (ptr - workspace > offset) > + { > + block_size = min((ptr - workspace) - offset, dst_end - dst_cur); > + memcpy(dst_cur, workspace + offset, block_size); > + dst_cur += block_size; > + } > + } > + else > + { > + /* uncompressed chunk */ > + if (chunk_size > offset) > + { > + block_size = min(chunk_size - offset, dst_end - dst_cur); > + memcpy(dst_cur, src_cur + offset, block_size); > + dst_cur += block_size; > + } > + } > + > + src_cur += chunk_size; > + } > + > + /* remaining blocks */ > + while (src_cur + sizeof(WCHAR) <= src_end) > + { > + chunk_header = *(WORD *)src_cur; > + src_cur += sizeof(WCHAR); > + if (!chunk_header) goto out; > + chunk_size = (chunk_header & 0xFFF) + 1; > + > + if (src_cur + chunk_size > src_end) > + return STATUS_BAD_COMPRESSION_BUFFER; > + > + /* fill space with padding */ > + block_size = ((dst_cur - dst) + offset) & 0xFFF; > + if (block_size) > + { > + block_size = 0x1000 - block_size; > + if (dst_cur + block_size >= dst_end) > + goto out; > + memset(dst_cur, 0, block_size); > + dst_cur += block_size; > + } I'm probably dense but I don't follow this padding part. Don't you still need to memset to 0 the "remaining part" even if dst_end <= dst_cur + block_size (obviously stopping at dst_end) and then proceed to decompress the chunk? Unless you're not supposed to decompress the last chunk in that case? > + > + if (dst_cur >= dst_end) > + goto out; > + > + if (chunk_header & 0x8000) > + { > + /* compressed chunk */ > + dst_cur = lznt1_decompress_chunk(dst_cur, dst_end - dst_cur, src_cur, chunk_size); > + if (!dst_cur) return STATUS_BAD_COMPRESSION_BUFFER; > + } > + else > + { > + /* uncompressed chunk */ > + block_size = min(chunk_size, dst_end - dst_cur); > + memcpy(dst_cur, src_cur, block_size); > + dst_cur += block_size; > + } > + > + src_cur += chunk_size; > + } > + > +out: > + if (final_size) > + *final_size = dst_cur - dst; > + > + return STATUS_SUCCESS; > + > +} > + > +/****************************************************************************** > + * RtlDecompressFragment [NTDLL.@] > + */ > +NTSTATUS RtlDecompressFragment(USHORT format, PUCHAR uncompressed, ULONG uncompressed_size, > + PUCHAR compressed, ULONG compressed_size, ULONG offset, > + PULONG final_size, PVOID workspace) > +{ > + TRACE("0x%04x, %p, %u, %p, %u, %u, %p, %p\n", format, uncompressed, > + uncompressed_size, compressed, compressed_size, offset, final_size, workspace); > + > + switch (format & ~COMPRESSION_ENGINE_MAXIMUM) > + { > + case COMPRESSION_FORMAT_LZNT1: > + return lznt1_decompress(uncompressed, uncompressed_size, compressed, > + compressed_size, offset, final_size, workspace); > + > + case COMPRESSION_FORMAT_NONE: > + case COMPRESSION_FORMAT_DEFAULT: > + return STATUS_INVALID_PARAMETER; > + > + default: > + FIXME("format %u not implemented\n", format); > + return STATUS_UNSUPPORTED_COMPRESSION; > + } > +} > + > + > /****************************************************************************** > * RtlDecompressBuffer [NTDLL.@] > */ > -NTSTATUS WINAPI RtlDecompressBuffer(USHORT CompressionFormat, PUCHAR UncompressedBuffer, > - ULONG UncompressedBufferSize, PUCHAR CompressedBuffer, > - ULONG CompressedBufferSize, PULONG FinalUncompressedSize) > +NTSTATUS WINAPI RtlDecompressBuffer(USHORT format, PUCHAR uncompressed, ULONG uncompressed_size, > + PUCHAR compressed, ULONG compressed_size, PULONG final_size) > { > - FIXME("0x%04x, %p, %u, %p, %u, %p :stub\n", CompressionFormat, UncompressedBuffer, UncompressedBufferSize, > - CompressedBuffer, CompressedBufferSize, FinalUncompressedSize); > + TRACE("0x%04x, %p, %u, %p, %u, %p\n", format, uncompressed, > + uncompressed_size, compressed, compressed_size, final_size); > > - return STATUS_NOT_IMPLEMENTED; > + return RtlDecompressFragment(format, uncompressed, uncompressed_size, > + compressed, compressed_size, 0, final_size, NULL); > } > > /*********************************************************************** > diff --git a/dlls/ntdll/tests/rtl.c b/dlls/ntdll/tests/rtl.c > index c6a7023..99fd413 100644 > --- a/dlls/ntdll/tests/rtl.c > +++ b/dlls/ntdll/tests/rtl.c > @@ -1663,11 +1663,8 @@ static void test_RtlCompressBuffer(void) > memset(buf2, 0x11, sizeof(buf2)); > status = pRtlDecompressBuffer(COMPRESSION_FORMAT_LZNT1, buf2, sizeof(buf2), > buf1, buf_size, &final_size); > - todo_wine > ok(status == STATUS_SUCCESS, "got wrong status 0x%08x\n", status); > - todo_wine > ok(final_size == sizeof(test_buffer), "got wrong final_size %u\n", final_size); > - todo_wine > ok(!memcmp(buf2, test_buffer, sizeof(test_buffer)), "got wrong decoded data\n"); > ok(buf2[sizeof(test_buffer)] == 0x11, "too many bytes written\n"); > > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > index 11d1c62..0bb7d04 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > +++ b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > @@ -977,7 +977,7 @@ > @ stub RtlCustomCPToUnicodeN > @ stdcall RtlDecompressBuffer(long ptr long ptr long ptr) ntdll.RtlDecompressBuffer > @ stub RtlDecompressChunks > -@ stub RtlDecompressFragment > +@ stdcall RtlDecompressFragment(long ptr long ptr long long ptr ptr) ntdll.RtlDecompressFragment > @ stub RtlDelete > @ stdcall RtlDeleteAce(ptr long) ntdll.RtlDeleteAce > @ stdcall RtlDeleteAtomFromAtomTable(ptr long) ntdll.RtlDeleteAtomFromAtomTable > -- > 2.4.5 > >

2 1

Re: gdiplus: GdipConvertToEmfPlus parameter succ is optional
by Nikolay Sivov July 9, 2015

July 9, 2015

Please add a test for this.

1 0

Re: libwine: Add support for tcc
by Alexandre Julliard July 8, 2015

July 8, 2015

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -67,7 +67,7 @@ void DECLSPEC_NORETURN wine_switch_to_stack( void (*func)(void *), void *arg, vo > * Switch to the specified stack to call the function and return. > */ > > -#if defined(__i386__) && defined(__GNUC__) > +#if defined(__i386__) && (defined(__GNUC__) || defined(__TINYC__)) Are you planning to do this everywhere __GNUC__ is used? If so, this needs a better approach. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [7/7] msvcirt: Implement ios::unsetf
by Marvin July 8, 2015

July 8, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15160 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [6/7] msvcirt: Implement ios::setf
by Marvin July 8, 2015

July 8, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15159 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [5/7] msvcirt: Implement ios::flags
by Marvin July 8, 2015

July 8, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15158 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [4/7] msvcirt: Implement ios static locking (try 2)
by Marvin July 8, 2015

July 8, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15157 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [3/7] msvcirt: Implement ios stream locking (try 2)
by Marvin July 8, 2015

July 8, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15156 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [2/7] msvcirt: Implement ios object locking (try 2)
by Marvin July 8, 2015

July 8, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15155 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [1/7] msvcirt: Implement ios locking control (try 2)
by Marvin July 8, 2015

July 8, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15154 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [1/4] msvcirt: Implement ios locking control
by Piotr Caban July 8, 2015

July 8, 2015

Hi Iván, On 07/07/15 21:00, Iván Matellanes wrote: > + /* locking */ > + ios_obj.do_lock = 1; > + p_ios_clrlock(&ios_obj); > + ok(ios_obj.do_lock == 1, "expected 1 got %d\n", ios_obj.do_lock); > + ios_obj.do_lock = 0; > + p_ios_clrlock(&ios_obj); > + ok(ios_obj.do_lock == 1, "expected 1 got %d\n", ios_obj.do_lock); > + p_ios_setlock(&ios_obj); > + ok(ios_obj.do_lock == 0, "expected 0 got %d\n", ios_obj.do_lock); > + ios_obj.do_lock = -1; > + p_ios_setlock(&ios_obj); > + ok(ios_obj.do_lock == -2, "expected -2 got %d\n", ios_obj.do_lock); Please add a test that shows what happens with this->sb->do_lock value when ios_setlock and ios_clrlock are called (it should also be updated). Thanks, Piotr

2 1

Re: [2/2] server: Add fallback to desktop keystate in get_key_state wineserver call.
by Marvin July 8, 2015

July 8, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15142 Your paranoid android. === wvistau64 (64 bit input) === input.c:731: Test failed: 0 (a4/0): 10 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): 11 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a0 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a2 from 01 -> 00 unexpected

1 0

Re: [PATCH 4/5] wined3d: Add a setting for the maximum OpenGL version to use.
by Henri Verbeet July 8, 2015

July 8, 2015

On 6 July 2015 at 22:20, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > if (context_debug_output_enabled(gl_info)) > + ctx_flags = WGL_CONTEXT_DEBUG_BIT_ARB; > + ctx_attribs[ctx_attrib_idx++] = WGL_CONTEXT_MAJOR_VERSION_ARB; > + ctx_attribs[ctx_attrib_idx++] = gl_info->selected_gl_version >> 16; > + ctx_attribs[ctx_attrib_idx++] = WGL_CONTEXT_MINOR_VERSION_ARB; > + ctx_attribs[ctx_attrib_idx++] = gl_info->selected_gl_version & 0xffff; > + if (gl_info->selected_gl_version >= MAKEDWORD_VERSION(3, 2)) > + ctx_flags |= WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB; > + if (ctx_flags) > { > ctx_attribs[ctx_attrib_idx++] = WGL_CONTEXT_FLAGS_ARB; > - ctx_attribs[ctx_attrib_idx++] = WGL_CONTEXT_DEBUG_BIT_ARB; > + ctx_attribs[ctx_attrib_idx++] = ctx_flags; > } > ctx_attribs[ctx_attrib_idx] = 0; > > if (!(ctx = gl_info->p_wglCreateContextAttribsARB(hdc, share_ctx, ctx_attribs))) > { > - ERR("Failed to create a WGL context.\n"); > - context_release(ret); > - goto out; > + if (ctx_flags & WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB) > + { > + ctx_attribs[ctx_attrib_idx - 1] &= ~WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB; > + if (!(ctx = gl_info->p_wglCreateContextAttribsARB(hdc, share_ctx, ctx_attribs))) > + { > + ERR("Failed to create a WGL context.\n"); > + context_release(ret); > + goto out; > + } > + } > } > } I think this is starting to become complex enough that we'd probably benefit from a helper function to be able to share some of this with wined3d_adapter_init(). > + glGetIntegerv(GL_CONTEXT_PROFILE_MASK, &context_profile); > + if (glGetError() != GL_NO_ERROR) > + context_profile = 0; Should this perhaps just check for gl_info->p_wglCreateContextAttribsARB instead of eating errors? > + for (i = 0; i < ARRAY_SIZE(supported_gl_versions); ++i) > + { > + if (supported_gl_versions[i] <= wined3d_settings.max_gl_version) > + { > + if (supported_gl_versions[i] != wined3d_settings.max_gl_version) > + ERR_(winediag)("Requested GL version %u.%u which is unsupported, trying version %u.%u instead.\n", > + wined3d_settings.max_gl_version >> 16, wined3d_settings.max_gl_version & 0xffff, > + supported_gl_versions[i] >> 16, supported_gl_versions[i] & 0xffff); > + break; > + } > + } > + if (i == ARRAY_SIZE(supported_gl_versions)) > + { > + ERR_(winediag)("Requested invalid GL version %u.%u.\n", > + wined3d_settings.max_gl_version >> 16, wined3d_settings.max_gl_version & 0xffff); > + i = ARRAY_SIZE(supported_gl_versions) - 1; > + } This is a bit different than what I had in mind. I think max_gl_version should just be a maximum, and e.g. specifying 4.4 should just result in 3.2 at the moment. I think the winediag message should just happen if the registry setting is set, regardless of its actual value. (Except possibly if it's equal to the default value.) I.e. we also want to know if someone sets e.g. 3.2 while the default is currently 1.0 when reporting a bug. > + if (!get_config_key(hkey, appkey, "MaxGLVersion", buffer, size)) > + { > + unsigned int major, minor; > + > + if (sscanf(buffer, "%u.%u", &major, &minor) == 2) > + wined3d_settings.max_gl_version = MAKEDWORD_VERSION(major, minor); > + else > + ERR_(winediag)("Couldn't parse the requested maximum OpenGL version.\n"); > + } I'd make this a DWORD, if nothing else for consistency with MaxShaderModelVS etc. Perhaps "MaxVersionGL" would also more consistent for the naming, I'm not sure.

2 6

Re: [1/2] user32/tests: Add tests for calling GetKeyState from thread without message queue.
by Sebastian Lackner July 8, 2015

July 8, 2015

On 08.07.2015 13:31, Sebastian Lackner wrote: > For https://bugs.winehq.org/show_bug.cgi?id=27238 > > The test is marked as broken on VMs > Win2003, but manually testing confirms > that it still works the same way on Windows 7. There must be a difference > between simulated keyboard input and real keyboard input. > > NOTE: SendInput doesn't make a difference. > > --- > dlls/user32/tests/input.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 65 insertions(+) > The test failures on wvistau64 are not caused by my patch. Seems to be "just another random issue". ;) All tests passed on a second attempt: https://newtestbot.winehq.org/JobDetails.pl?Key=15143

1 0

Re: [1/2] user32/tests: Add tests for calling GetKeyState from thread without message queue.
by Marvin July 8, 2015

July 8, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15141 Your paranoid android. === wvistau64 (32 bit input) === input.c:731: Test failed: 0 (a4/0): 10 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): 11 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a0 from 01 -> 00 unexpected input.c:731: Test failed: 0 (a4/0): a2 from 01 -> 00 unexpected

1 0

Re: [PATCH 3/4] wined3d: Clip blits from / to the front buffer to the GL drawable.
by Henri Verbeet July 8, 2015

July 8, 2015

On 6 July 2015 at 23:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > -void surface_translate_drawable_coords(const struct wined3d_surface *surface, HWND window, RECT *rect) > +BOOL surface_clip_drawable_coords(const struct wined3d_surface *surface, HWND window, > + RECT *screen_rect, RECT *other) Can we please call these "src_rect" and "dst_rect" instead of "screen_rect" and "other"? It probably wouldn't hurt to mention "blt" somewhere in the function name either. > + ClientToScreen(window, &offset); ... > - ScreenToClient(window, &offset); > - OffsetRect(rect, offset.x, offset.y); > + /* Finally, translate the screen coordinate rectangle to client coordinates. */ > + OffsetRect(screen_rect, -offset.x, -offset.y); That change seems pretty pointless. > +BOOL wined3d_clip_blit(const RECT *clip_rect, RECT *clipped, RECT *other) "src_rect", "dst_rect".

2 2

Re: kernel32/tests: Attempt to avoid timeouts by increasing the baud rate.
by Marvin July 8, 2015

July 8, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15126 Your paranoid android. === w2000pro (32 bit comm) === comm.c:1552: test_AbortWaitCts timeout 500 handle 00000368 comm.c:1519: Changing CommMask on the fly for handle 00000368 after timeout 500 === w2008s64 (32 bit comm) === comm.c:861: Test failed: WaitCommEvent failed with a timeout comm.c:872: recovering after WAIT_TIMEOUT... comm.c:882: Test failed: WaitCommEvent error 0 comm.c:883: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:887: WaitCommEvent for EV_TXEMPTY took 1500 ms (timeout 1500) comm.c:888: Test failed: WaitCommEvent used 1500 ms for waiting comm.c:1552: test_AbortWaitCts timeout 500 handle 000000BC comm.c:1519: Changing CommMask on the fly for handle 000000BC after timeout 500

2 1

#include <hidclass.h>
by Aric Stewart July 8, 2015

July 8, 2015

Hi, So when my patch for include/ddk/hidport.h got included Alexandre add this line to the top: #include <hidclass.h> The problem is that my hidclass.sys work stopped building for me. In file included from ../../../wine-git/dlls/hidclass.sys/hid.h:27: ../../../wine-git/include/ddk/hidport.h:22:10: error: 'hidclass.h' file not found with <angled> include; use "quotes" instead #include <hidclass.h> ^~~~~~~~~~~~ "hidclass.h" 1 error generated. Is this a problem with my build setup or something else? hidclass.h is located in include/ddk/hidclass.h thanks, -aric

2 1

Re: [PATCH 1/5] wined3d: Use the correct texture coordinates in swapchain_blit() in the non-glBlitFramebuffer, NP2 case.
by Henri Verbeet July 7, 2015

July 7, 2015

On 6 July 2015 at 22:20, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/swapchain.c b/dlls/wined3d/swapchain.c > index 146f5d6..141abc2 100644 > --- a/dlls/wined3d/swapchain.c > +++ b/dlls/wined3d/swapchain.c > @@ -280,21 +280,21 @@ HRESULT CDECL wined3d_swapchain_get_gamma_ramp(const struct wined3d_swapchain *s > > /* A GL context is provided by the caller */ > static void swapchain_blit(const struct wined3d_swapchain *swapchain, > - struct wined3d_context *context, const RECT *src_rect, const RECT *dst_rect) > + struct wined3d_context *context, unsigned int src_w, unsigned int src_h, > + const RECT *src_rect, const RECT *dst_rect) > { > struct wined3d_surface *backbuffer = surface_from_resource( > wined3d_texture_get_sub_resource(swapchain->back_buffers[0], 0)); > - UINT src_w = src_rect->right - src_rect->left; > - UINT src_h = src_rect->bottom - src_rect->top; > GLenum gl_filter; > const struct wined3d_gl_info *gl_info = context->gl_info; > RECT win_rect; > UINT win_h; > > - TRACE("swapchain %p, context %p, src_rect %s, dst_rect %s.\n", > - swapchain, context, wine_dbgstr_rect(src_rect), wine_dbgstr_rect(dst_rect)); > + TRACE("swapchain %p, context %p, src_w %u, src_h %u, src_rect %s, dst_rect %s.\n", > + swapchain, context, src_w, src_h, wine_dbgstr_rect(src_rect), wine_dbgstr_rect(dst_rect)); > > - if (src_w == dst_rect->right - dst_rect->left && src_h == dst_rect->bottom - dst_rect->top) > + if (src_rect->right - src_rect->left == dst_rect->right - dst_rect->left > + && src_rect->bottom - src_rect->top == dst_rect->bottom - dst_rect->top) > gl_filter = GL_NEAREST; > else > gl_filter = GL_LINEAR; > @@ -528,7 +528,7 @@ static void swapchain_gl_present(struct wined3d_swapchain *swapchain, const RECT > if (swapchain->desc.swap_effect == WINED3D_SWAP_EFFECT_FLIP && !once++) > FIXME("WINED3D_SWAP_EFFECT_FLIP not implemented.\n"); > > - swapchain_blit(swapchain, context, &src_rect, &dst_rect); > + swapchain_blit(swapchain, context, back_buffer->pow2Width, back_buffer->pow2Height, &src_rect, &dst_rect); > } > > if (swapchain->num_contexts > 1) I may be missing something subtle here, but wouldn't it be better to just replace src_w/wrc_h with backbuffer->pow2Width/backbuffer->powe2Height in the "if (backbuffer->container->flags & WINED3D_TEXTURE_NORMALIZED_COORDS)" block that scales the texture coordinates?

3 3

Re: [PATCH 4/4] wined3d: Always use screen-sized frontbuffers.
by Henri Verbeet July 7, 2015

July 7, 2015

On 6 July 2015 at 23:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > --- > dlls/wined3d/device.c | 6 +++--- > dlls/wined3d/surface.c | 22 +++++++++++++++++----- > dlls/wined3d/swapchain.c | 27 +++++++++++++-------------- > 3 files changed, 33 insertions(+), 22 deletions(-) > Why would we want that?

2 1

Re: [PATCH 5/5] wined3d: Use GLSL 1.50 on core contexts.
by Henri Verbeet July 7, 2015

July 7, 2015

On 6 July 2015 at 22:20, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > static const char *shader_glsl_get_version(const struct wined3d_gl_info *gl_info, > const struct wined3d_shader_version *version) > { > - if (gl_info->glsl_version >= MAKEDWORD_VERSION(1, 30) && version->major >= 4) > + if (!gl_info->supported[WINED3D_GL_LEGACY_CONTEXT]) > + return "#version 150"; > + else if (gl_info->glsl_version >= MAKEDWORD_VERSION(1, 30) && version && version->major >= 4) > return "#version 130"; > else > return "#version 120"; Is GLSL 1.20 unavailable in core contexts? I only glanced over the spec, but didn't immediately see anything that explicitly makes earlier versions unavailable. What's a bit unfortunate about this is that drivers may decide to use different floating point rules (in particular wrt. multiplications by zero) depending on the GLSL version. IIRC at least r600g considered doing that at some point, although I'd have to check if that's currently the case.

2 1

Re: [PATCH 2/2] mshtml: Add IHTMLXMLHttpRequest::send() method implementation. (try 2)
by Marvin July 7, 2015

July 7, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15123 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/4] d3d8/tests: Add a windowed GetFrontBufferData test.
by Henri Verbeet July 7, 2015

July 7, 2015

On 6 July 2015 at 23:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +/* Locks a given surface and returns the color at (x,y). It's the caller's > + * responsibility to only pass in lockable surfaces and valid x,y coordinates */ > +static DWORD get_pixel_color_from_surface(IDirect3DSurface8 *surface, UINT x, UINT y) In ddraw this is called get_surface_color(), the equivalent d3d10core function is called get_texture_color().

1 0

odbccp32: Implement SQLGetPrivateProfileString (try 7)
by Hugh McMaster July 7, 2015

July 7, 2015

On Tuesday, 7 July 2015, 10:31 pm UTC+10, Nikolay Sivov wrote: >On 07.07.2015 11:15, Alistair Leslie-Hughes wrote: > >> + retval = heap_alloc(cbRetBuffer*sizeof(WCHAR)); >> + >> + ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); > >cbRetBuffer is A-buffer length, you're still using it as W-buffer length. Unless I'm reading MSDN [1] incorrectly, this should work. cbRetBuffer is the size, in characters, of RetBuffer (i.e. the A-buffer). retval is the W-buffer. Its allocated byte size is double that of RetBuffer, but its size, in characters, is still the same.

2 2

Re: odbccp32: Implement SQLGetPrivateProfileString (try 7)
by Nikolay Sivov July 7, 2015

July 7, 2015

On 07.07.2015 11:15, Alistair Leslie-Hughes wrote: > + retval = heap_alloc(cbRetBuffer*sizeof(WCHAR)); > + > + ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); cbRetBuffer is A-buffer length, you're still using it as W-buffer length.

1 0

Re: msscript.ocx: Added IDispatch functions implementation.
by Dmitry Timoshkov July 7, 2015

July 7, 2015

Hi Jacek, Jacek Caban <jacek(a)codeweavers.com> wrote: > + case DLL_PROCESS_DETACH: > + release_typelib(); > + break; There should be a check to avoid freeing resources on process termination to avoid possible deadlocks. -- Dmitry.

1 0

Re: shell32/tests: Try harder to close Open With window
by Marvin July 7, 2015

July 7, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15086 Your paranoid android. === w2000pro (32 bit shlexec) === shlexec.c:2449: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2449: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2449: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2449: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2449: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2449: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 === wxppro (32 bit shlexec) === shlexec.c:1224: Test failed: expected 1 args, got 4 === w2003std (32 bit shlexec) === shlexec.c:1224: Test failed: expected 1 args, got 4

2 1

Re: [PATCH 2/4] d3d8/tests: Add a windowed GetFrontBufferData test.
by Marvin July 7, 2015

July 7, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15097 Your paranoid android. === w8 (32 bit visual) === visual.c:7637: Test failed: Got color 0xfffff913. visual.c:7639: Test failed: Got color 0xfffff913. visual.c:7641: Test failed: Got color 0xfffff913. visual.c:7643: Test failed: Got color 0xfffff913. visual.c:7646: Test failed: Got color 0xfffffa13. visual.c:7648: Test failed: Got color 0xfffffa13. visual.c:7650: Test failed: Got color 0xfffffa13. visual.c:7652: Test failed: Got color 0xfffefa13. visual.c:7655: Test failed: Got color 0xfffff913. visual.c:7657: Test failed: Got color 0xfffff913. visual.c:7659: Test failed: Got color 0xfffff913. visual.c:7661: Test failed: Got color 0xfffff913. visual.c:7664: Test failed: Got color 0xfffffa13. visual.c:7666: Test failed: Got color 0xfffef913. visual.c:7668: Test failed: Got color 0xfffffa13. visual.c:7670: Test failed: Got color 0xfffef913.

1 0

Re: [PATCH 1/4] d3d9/tests: Add a windowed GetFrontBufferData test.
by Marvin July 7, 2015

July 7, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15096 Your paranoid android. === w8 (32 bit visual) === visual.c:19339: Test failed: Got color 0xff7170fb. visual.c:19341: Test failed: Got color 0xff7170fb. visual.c:19343: Test failed: Got color 0xff7170fb. visual.c:19345: Test failed: Got color 0xff7170fb. visual.c:19348: Test failed: Got color 0xff71fefb. visual.c:19350: Test failed: Got color 0xff71fefb. visual.c:19352: Test failed: Got color 0xff71fefb. visual.c:19354: Test failed: Got color 0xff71fefb. visual.c:19357: Test failed: Got color 0xff7f70fb. visual.c:19359: Test failed: Got color 0xff7f70fb. visual.c:19361: Test failed: Got color 0xffff70fb. visual.c:19363: Test failed: Got color 0xffff70fb. visual.c:19366: Test failed: Got color 0xff86fefb. visual.c:19368: Test failed: Got color 0xff85fefb. visual.c:19370: Test failed: Got color 0xfffffe90. visual.c:19372: Test failed: Got color 0xfffffe90.

1 0

Re: [1/2] ole32: Add a storage test using a custom ILockBytes.
by Marvin July 7, 2015

July 7, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15093 Your paranoid android. === w7u (32 bit storage32) === Failure running script in VM: timed out waiting for the child process

1 0

Re: [PATCH 3/8] winex11.drv: implement DoDragDrop on top of XDND
by Ken Thomases July 6, 2015

July 6, 2015

On Jul 4, 2015, at 8:36 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > Implements DoDragDrop on top of XDND. While some of DoDragDrop() and > supporting functions are copied from ole32, they were modified to be > non-blocking and event-driven. > > The clipboard is patched to allow searching its clipboard formats for > X11 atoms, export data in X11 format, and forward selection requests > for the XdndSelection selection to XDND. > > We support XDND version 3 to 5 (although we still need XdndProxy > support for version 4). XdndPosition messages are rate-limited to at > most 1 unreplied message and at least every 50 milliseconds apart, so > that we don't flood slow X11 clients like the spec warns. In set_XdndTypeList() and X11DRV_XDND_SelectionRequest(), you use FIXMEs for most unsupported format properties, but just a TRACE for dwAspect != DVASPECT_CONTENT. Is there a reason for that? > + * When we ask for feedback from the drop source, sometimes it will > + * do all the necessary work and sometimes it will not handle it > + * when that's the case, we must display the standard drag and drop > + * cursors. Copy-pasted typo. There should be a period after "handle it" and we should capitalize "when that's the case". (Or change to "When it doesn't handle it" to be clearer.) > + /* > + * All the return valued will stop the operation except the S_OK > + * return value. > + */ Copy-pasted typo: "return valued" should be "return values". > + /* > + * When keyboard messages are sent to windows on this thread, we > + * want to ignore notify the drop source that the state changed. > + * in the case of the Escape key, we also notify the drop source > + * we give it a special meaning. > + */ Copy-pasted typo: "ignore notify". I'm not sure if the fix is to just drop "ignore" or to expand the sentence to explain that we swallow key events except to notify the drop source about the Escape key. -Ken

1 0

Re: [PATCH 2/8] ole32/user32/winemac.drv/winex11.drv: try using native drag and drop if possible
by Ken Thomases July 6, 2015

July 6, 2015

Hi, > On Jul 4, 2015, at 8:36 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > If possible, try using the drag and drop implemented by the native > windowing system instead of the one implemented by our ole32. This > patch just provides the framework, the next patch actually implements > all drag and drop over XDND. Thanks for doing this redesign. For this patch, is it necessary to add the driver entry point to the user drivers (winemac, winex11)? Since the null driver already returns E_NOTIMPL, it would seem the user drivers don't need to provide an entry point that just does the same thing. Is there a reason there's no loaderdrv_DoDragDrop()? Is it not possible for DoDragDrop() to be called before the driver has been loaded? -Ken

1 0

Re: [PATCH 1/2] shell32/tests: Win XP splits the args if there are spaces in the path.
by Marvin July 6, 2015

July 6, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15076 Your paranoid android. === w2000pro (32 bit shlexec) === shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1545: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1577: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1545: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1577: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\wtD96A.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\wtD96A.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2115: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\wtD96A.tmp" Exec") succeeded: rc=42

2 1

Re: [2/10]hidclass.sys: add hidclass.sys
by Henri Verbeet July 6, 2015

July 6, 2015

I didn't really look at the rest of the series, but here are a few things that caught my eye. On 6 July 2015 at 17:46, Aric Stewart <aric(a)codeweavers.com> wrote: > +struct list minidriver_list = LIST_INIT(minidriver_list); You don't seem to access this outside of main.c anywhere in this series, and it seems somewhat unlikely that you'll ever have to. Shouldn't this just be static? > +static VOID WINAPI UnloadDriver(DRIVER_OBJECT *driver) "void" > + TRACE("Driver Unload\n"); > + LIST_FOR_EACH_ENTRY_SAFE(md, next, &minidriver_list, minidriver, entry) > + { > + if (md->minidriver.DriverObject == driver) > + { > + if (md->DriverUnload) > + md->DriverUnload(md->minidriver.DriverObject); > + list_remove(&md->entry); > + break; > + } > + } > +} Did you intend to use find_minidriver() here? > +minidriver* find_minidriver(DRIVER_OBJECT* driver) > +{ > + minidriver *md; > + LIST_FOR_EACH_ENTRY(md, &minidriver_list, minidriver, entry) > + { > + if (md->minidriver.DriverObject == driver) > + return md; > + } > + return NULL; > +} As the code currently is this isn't actually used until patch 10/10. You could potentially use it from UnloadDriver() as mentioned above, but it should still initially be static in that case. Your '*' placement is inconsistent. > +NTSTATUS WINAPI HidRegisterMinidriver(PHID_MINIDRIVER_REGISTRATION registration) "HID_MINIDRIVER_REGISTRATION *registration" > +BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpv) > +{ > + switch(fdwReason) > + { > + case DLL_PROCESS_ATTACH: > + DisableThreadLibraryCalls(hInstDLL); > + break; > + } > + return TRUE; > +} As long as you don't do anything special in here, you don't need an explicit DllMain(). (But if you did, "void *" instead of LPVOID, and parameter naming.) > +/* These are from hidport.h but are only used here anyway */ > +typedef struct _HID_MINIDRIVER_REGISTRATION { The brace placement is inconsistent with the rest of the code. > + ULONG Revision; > + PDRIVER_OBJECT DriverObject; > + PUNICODE_STRING RegistryPath; "UNICODE_STRING *RegistryPath;" > + ULONG DeviceExtensionSize; > + BOOLEAN DevicesArePolled; > + UCHAR Reserved[3]; > +} HID_MINIDRIVER_REGISTRATION, *PHID_MINIDRIVER_REGISTRATION; If this is really only used inside hidclass.sys, you shouldn't need the PHID_MINIDRIVER_REGISTRATION typedef. > +NTSTATUS WINAPI HidRegisterMinidriver(PHID_MINIDRIVER_REGISTRATION MinidriverRegistration); The whitespace is odd here. Also, "HID_MINIDRIVER_REGISTRATION *registration". > +typedef struct _minidriver > +{ > + struct list entry; > + > + HID_MINIDRIVER_REGISTRATION minidriver; > + > + PDRIVER_UNLOAD DriverUnload; > +} minidriver; I suppose it's somewhat up to personal style, but you don't need a typedef for this. Aside from saving you from typing "struct" a few times it only obfuscates the code. I suspect some of the imports and includes aren't actually used until later in the series, but I didn't explicitly check that.

1 0

Re: [PATCH 2/2] shell32/tests: Win 2k doesn't cope with spaces in the path.
by Marvin July 6, 2015

July 6, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15077 Your paranoid android. === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1545: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1577: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1545: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1577: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\wtDFB4.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\wtDFB4.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2115: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\wtDFB4.tmp" Exec") succeeded: rc=42

1 0

Wine Gecko 2.40-beta1
by Jacek Caban July 6, 2015

July 6, 2015

Hi all, It's time for another Wine Gecko update. I uploaded new builds to SourceForge. The new version is updated to use upcoming Firefox 40 engine and brings a few Wine-specific fixes. It also adds support for building with MSVC, contributed by Austin. If you want to test it, just build Wine with the attached patch. Wine will download Gecko for you. All feedback is appreciated. Thanks, Jacek

1 0

Re: [PATCH 2/3]: msvcp110: Add tr2_sys__Rename implementation and test.(try 3)
by Piotr Caban July 6, 2015

July 6, 2015

On 07/05/15 20:49, YongHao Hu wrote: > + if(!strcmp(old_path, new_path) || MoveFileExA(old_path, new_path, MOVEFILE_COPY_ALLOWED)) The comparison of paths doesn't look right. Why have you added it? Cheers, Piotr

2 1

Adding RID_TYPEHID RawInput support to user32
by Nathan Schulte July 6, 2015

July 6, 2015

(Apologies if double posting; I wasn't sub'd the first time and it wasn't in the archives.) I'm working to extend Wine's RawInput implementation to support gamepads/controllers (and possibly joysticks, or any non-keyboard/mouse HID device). I found this on the wine-patches list: Vincas Miliūnas wrote: > A comment about going beyond mouse/keyboard for raw input:Other > devices then mouse&keyboard produce undocumented blobs of bytes;to > interpret them, functions from the hid.dll are used. Currently > theyare unimplemented stubs in WINE as well as not the problem I am > solving.There is a recent article about this subject - Using the Raw > Input APIto Process Joystick Input > -http://www.codeproject.com/KB/game/RawInputJoystick.aspx Does this imply then, that if one was to add support for "raw" rawinput (RIM_TYPEHID device type) it could be used in conjunction with a native hid.dll and software that required RIM_TYPEHID input (for e.g. game controllers in games) would start working? Nathan Schulte (me; original post) wrote: > Also, could one create an adaptation from some joystick input libraries > (evdev/x11,rawhid) and make it conform to the API in the CodeProject > example, making modifications similar to Henri Verbeet's for mouse and > keyboard and have built-in support for this? > > (Henri Verbeet's rawinput contributions: > http://source.winehq.org/git/wine.git/?a=search&st=commit&s=rawinput) > > I see that Wine already has support for joysticks in some other > fashion (the gamepad I'm working with shows up in the `wine control` > Game Controller testing interface), and I bet it's a good idea to > leverage that adaptation (those adaptations...) than to start adding > my own. > > Any direction here would be appreciated. I think I understand the > separation between the wineserver (mainly server/queue.c) and the > dlls (dlls/user32/*), but I see that there are other "dlls" that > don't use (or don't appear to use, given my probably incorrect > understanding) wineserver for their adaptation, and instead talk > directly with the Linux libs to do their work (I'm assuming). It looks like what I was was seeing was "Wine drivers," (winejoystick.drv, for winmm's joystick bits, and DirectInput's joystick bits). Should I follow that route, or should I plumb this through wineserver, like the rawinput keyboard and mouse? Why are those plumbed through wineserver? Are they shared resources, and if so, why doesn't that matter for winmm and DirectInput? I'm thinking this should be fairly easy to get working, by enumerating the rawhid devices and just piping the data through. I'm not sure how well the native hid.dll will work though; can anyone comment? Any help is welcome, as it means my patches are more likely to make it upstream and benefit others. I'm wondering if there's an architecture diagram/doc somewhere to help me understand how the system works. Thanks, -- Nate

3 3

crossover programs missing from source code
by Theodore Dubois July 5, 2015

July 5, 2015

The following programs in Crossover are absent from the source code download: assocscan autorun ctfmon cxcplinfo cxdummy cxinstallfonts cxmanip cxmklnk cxnative cxwget ddhelp extract findfast icwconn1 imjpmig maildoff mdm mosearch netscape ntoskrnl pstores qttask reboot sendwndcmd winewrapper Can I get an explanation for each of these? ~Theodore

4 3

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger July 5, 2015

July 5, 2015

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

Re: [4/7] ntdll/tests: Add basic tests for threadpool wait objects.
by Marvin July 5, 2015

July 5, 2015

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://testbot.winehq.org/JobDetails.pl?Key=15039 Your paranoid android. === w7u (32 bit threadpool) === threadpool.c:734: Test failed: WaitForSingleObject returned 258

2 1

Re: ole32: Accept STG_E_UNIMPLEMENTEDFUNCTION when ILockBytes implementation doesn't support locking.
by Nikolay Sivov July 4, 2015

July 4, 2015

On 03.07.2015 10:27, Dmitry Timoshkov wrote: > Some custom implementations return it instead of STG_E_INVALIDFUNCTION. > --- > dlls/ole32/storage32.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ole32/storage32.c b/dlls/ole32/storage32.c > index 220e17e..aa53758 100644 > --- a/dlls/ole32/storage32.c > +++ b/dlls/ole32/storage32.c > @@ -5015,7 +5015,7 @@ static HRESULT StorageImpl_GrabLocks(StorageImpl *This, DWORD openFlags) > hr = StorageImpl_LockRegionSync(This, offset, cb, LOCK_ONLYONCE); > > /* If the ILockBytes doesn't support locking that's ok. */ > - if (hr == STG_E_INVALIDFUNCTION) return S_OK; > + if (hr == STG_E_INVALIDFUNCTION || hr == STG_E_UNIMPLEMENTEDFUNCTION) return S_OK; > else if (FAILED(hr)) return hr; > > hr = S_OK; > It looks like StorageImpl_LockRegionSync should be fixed instead to filter some error codes. Could you add a test with external ILockBytes implementation that does that?

3 7

Re: [PATCH 5/6]: msvcp110: Add tr2_sys__Lstat implementation and test.(resend)
by Piotr Caban July 4, 2015

July 4, 2015

On 07/03/15 06:00, YongHaoHu wrote: > +/* ?_Lstat(a)sys@tr2(a)std@@YA?AW4file_type(a)123@PBDAAH(a)Z */ > +/* ?_Lstat(a)sys@tr2(a)std@@YA?AW4file_type(a)123@PEBDAEAH(a)Z */ > +file_type tr2_sys__Lstat(char const* path, int *err_code) > +{ > + DWORD attr; > + TRACE("(%s %p)\n", debugstr_a(path), err_code); > + if(!path) { > + *err_code = ERROR_INVALID_PARAMETER; > + return status_unknown; > + } > + > + attr = GetFileAttributesA(path); > + if(attr == INVALID_FILE_ATTRIBUTES) > + return stat_set_error(err_code); > + if(attr & FILE_ATTRIBUTE_REPARSE_POINT) > + FIXME("reparse point is not supported yet\n"); > + > + *err_code = ERROR_SUCCESS; > + return (attr & FILE_ATTRIBUTE_DIRECTORY)?directory_file:regular_file; > +} What's the reason for not calling tr2_sys__Stat function here? Thanks, Piotr

2 3

Adding RID_TYPEHID RawInput support to user32
by Nathan Schulte July 3, 2015

July 3, 2015

I'm working to extend Wine's RawInput implementation to support gamepads/controllers (and possibly joysticks, or any non-keyboard/mouse HID device). I found this on the wine-patches list: Vincas Miliūnas wrote: > A comment about going beyond mouse/keyboard for raw input:> Other devices then mouse&keyboard produce undocumented blobs of bytes;> to interpret them, functions from the hid.dll are used. Currently they> are unimplemented stubs in WINE as well as not the problem I am solving.> There is a recent article about this subject - Using the Raw Input API> to Process Joystick Input -> http://www.codeproject.com/KB/game/RawInputJoystick.aspx Does this imply then, that if one was to add support for "raw" rawinput (RIM_TYPEHID device type) it could be used in conjunction with a native hid.dll and software that required RIM_TYPEHID input (for e.g. game controllers in games) would start working? Also, could one create an adaptation from some joystick input libraries (evdev/x11) and make it conform to the API in the CodeProject example, making modifications similar to Henri Verbeet's and have built-in support for this? (Henri Verbeet's rawinput contributions: http://source.winehq.org/git/wine.git/?a=search&st=commit&s=rawinput) I see that Wine already has support for joysticks in some other fashion (the gamepad I'm working with shows up in the `wine control` Game Controller testing interface), and I bet it's a good idea to leverage that adaptation (those adaptations...) than to start adding my own. Any direction here would be appreciated. I think I understand the separation between the wineserver (mainly server/queue.c) and the dlls (dlls/user32/*), but I see that there are other "dlls" that don't use (or don't appear to use, given my probably incorrect understanding) wineserver for their adaptation, and instead talk directly with the Linux libs to do their work (I'm assuming). Any help is welcome, as it means my patches are more likely to make it upstream and benefit others. I'm wondering if there's an architecture diagram/doc somewhere to help me understand how the system works. Thanks, -- Nate

1 0

Re: [PATCH 1/2] d3drm: Add stubs for IDirect3DRMDevice methods.
by Stefan Dösinger July 3, 2015

July 3, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-07-01 um 01:03 schrieb Aaryaman Vasishta: > +static ULONG WINAPI d3drm_device1_AddRef(IDirect3DRMDevice *iface) > +{ > + struct d3drm_device *device = impl_from_IDirect3DRMDevice(iface); > + ULONG refcount = InterlockedIncrement(&device->ref); > + > + TRACE("%p increasing refcount to %u.\n", iface, refcount); > + > + return refcount; > +} > + > +static ULONG WINAPI d3drm_device1_Release(IDirect3DRMDevice *iface) > +{ > + struct d3drm_device *device = impl_from_IDirect3DRMDevice(iface); > + > + return IDirect3DRMDevice2_Release(&device->IDirect3DRMDevice2_iface); > +} Why are you forwarding Release to d3drmdevice2 but not Addref? I think we should look again at moving the IUnknown methods to Device3, so we don't thunk to the middle child and stay consistent with the other methods. Please send an extra patch before this one that migrates the code to device3. I remember we already looked at this. If this failed in some spectacular way please remind me :-) . Is there a logic behind which method forwards to device3 and which just returns E_NOTIMPL? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVk+jzAAoJEN0/YqbEcdMwL/MP/jmYjvhWcVOosMP2FyKVaezA c4SqCONBE+xPvhmC97IfPXZ8wJQUjH0tt5CjZN2JZTY0yw50bEM4JHDfC1pPjF3O IX4qKllp0UeAeNCNKu64a8rxYT2kLRwLp7zs+GO7YygwimKy9DAMxUCW5+IP4DiB bsO1wTcSWlCHQ8c4ikUou6aIY/npJ+UqVS8DNGl5m1cLw6oUdzZMvcurSooH2LUv 1oq4XC1DQe/wx3Ob826xY8w/2v6CM0JDAgAT1dGqxIWDS5DNzsKj9P8oKEso/C8c thpZdsIvgQLEkfmKgN6wRh9h03aAMVHbXoSmGVihaapSspF7299DYrDyoiQvYxEq k+SgAMqHAtAzfXkQto9n0f8FjiLEJzbFu9WMoKLJmjdk7hpH8CXPsoioA/o8xNDA 8dB9LxITlJuK5oEUczGhdrnN144Ml8AkZbs+DBcvTdHvaOaY7urL2sZ6/QuvGtAY IGGeUnPW2VBMGpg1YlSn9OmziBibrjKOVtXHVmbwYQhZhXOcfzgMT+QBBV2eQ/pQ 0tmDnUk93+ungNnc4slfLZo+uZ8/8kvPRMv8fYPcQjkcXOIRCobup4bqx3vrQVWT zOx05HKBDQihZAxZuHynFaNqA5E1QbhbPac0BsOSLk8r4zSKx58BgNLBYWz51oe6 NN959TJY84womG8/lfFc =jkwG -----END PGP SIGNATURE-----

2 1

Re: [2/2] shell32/tests: Destroy shell view windows.
by Nikolay Sivov July 3, 2015

July 3, 2015

On 02.07.2015 13:36, Thomas Faber wrote: > When calling IShellView::CreateViewWindow, the window itself takes > references to the shell view and related objects (e.g. for a drop > target). This means just calling IShellView::Release is not enough to > properly clean up, the window needs to be destroyed as well. > Could you please also add a test that shows window is still being alive after IShellView was released? It could be a separate patch.

2 1

Re: [PATCH 4/6]: msvcp110: Add tr2_sys__Stat implementation and test.(try 2)
by Piotr Caban July 3, 2015

July 3, 2015

On 07/03/15 05:59, YongHaoHu wrote: > +static file_type stat_set_error(int *err_code) > +{ > + file_type ret; > + > + switch(GetLastError()) { > + case ERROR_FILE_NOT_FOUND: > + case ERROR_BAD_NETPATH: > + case ERROR_INVALID_NAME: > + case ERROR_BAD_PATHNAME: > + case ERROR_PATH_NOT_FOUND: > + ret = file_not_found; > + *err_code = ERROR_SUCCESS; > + break; > + case ERROR_SUCCESS: > + ret = regular_file; > + *err_code = ERROR_SUCCESS; > + break; Why are you handling ERROR_SUCCESS here? stat_set_error function is only called in case of error. Are you planning to reuse this function somewhere else? If not it might be part of tr2_sys__Stat function. Thanks, Piotr

1 0

Re: [PATCH 2/6]: msvcp110: Add tr2_sys__Rename implementation and test. (try 2)
by Piotr Caban July 3, 2015

July 3, 2015

On 07/03/15 05:56, YongHaoHu wrote: > + if(MoveFileExA(old_path, new_path, MOVEFILE_REPLACE_EXISTING|MOVEFILE_COPY_ALLOWED)) According to my testing MOVEFILE_REPLACE_EXISTING flag should not be used here. Thanks, Piotr

1 0

Re: [PATCH 1/6]: msvcp110: Add tr2_sys__Copy_file implementation and test.(try 2)
by YongHaoHu July 3, 2015

July 3, 2015

Hi, all. Found a mistake of tr2_sys__Copy_file, please ignore this patch. Thank you. On 15/7/3 上午11:55, YongHaoHu wrote: > try2 : > Add is_todo in test. > Delete useless SetLastError. > > --- > dlls/msvcp110/msvcp110.spec | 4 +-- > dlls/msvcp120/msvcp120.spec | 4 +-- > dlls/msvcp120/tests/msvcp120.c | 59 > +++++++++++++++++++++++++++++++++++++ > dlls/msvcp120_app/msvcp120_app.spec | 4 +-- > dlls/msvcp90/ios.c | 10 +++++++ > 5 files changed, 75 insertions(+), 6 deletions(-) > >

1 0

Re: [6/12] ntdll/tests: Add tests for threadpool timer merging.
by Sebastian Lackner July 3, 2015

July 3, 2015

On 03.07.2015 01:59, Sebastian Lackner wrote: > --- > dlls/ntdll/tests/threadpool.c | 117 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 117 insertions(+) > The test failure on Windows 7 seems to be random, it worked fine on a second run (and also on several test runs before): https://newtestbot.winehq.org/JobDetails.pl?Key=14968 If it occurs too often in practice we can increase the timeouts, but for now I think it should be fine. BTW: Forgot to mention, the Sleeps() in this patch are necessary because there is no way to do any other kind of synchronization with the Windows internal timer queue thread.

1 0

Re: [6/12] ntdll/tests: Add tests for threadpool timer merging.
by Marvin July 3, 2015

July 3, 2015

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://testbot.winehq.org/JobDetails.pl?Key=14965 Your paranoid android. === w7u (32 bit threadpool) === threadpool.c:856: Test failed: WaitForSingleObject returned 258 threadpool.c:897: Test failed: expected that ticks are nonzero threadpool.c:899: Test failed: expected that timers are merged

1 0

Re: [PATCH 2/4] wined3d: Implement vertex blending in glsl_vertex_pipe.
by Stefan Dösinger July 2, 2015

July 2, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I like this patchset. I can't find anything wrong in it, but Matteo knows the fixed function pipeline replacement better than I do, so I'll wait for his comments. I tested it with various DirectX SDK samples (bend from dx7, SkinnedMesh and VertexBlend from dx8). It works very well, but I noticed a lighting oddity in SkinnedMesh. The lighting differs slightly between your code ("D3D non-indexed" option) and the test program's vertex shader or d3dx9's software vertex blending ("D3D indexed (VS)" / "Software Skinning"). This difference cannot be seen on Windows. I have attached screenshots. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVlPPNAAoJEN0/YqbEcdMwUcIP/jwJsie6/93Ui3RQTqjT8oOP q0ips3E83dHpi0ceL8xXujr0pyO1x7cVuUX+hZ7Tf08bZu86FpieKZkTYZxRKbKj V5+x/bVlWGM+ogB06E7tHx2oM8tBFlh10wwh9M/QnitjtzCM+E3WKfE01W5NsRRL csUMxE1mBHvnp08Me2CZyzgtVWwQuTWH6IMUtmqQPfOmmOgzIoofjjRowjhZovFi D9cufKD/D+CBsuv/Py5AMYWfjv7gTZqB09sotaIzYWuyI/e6GRRFT2wzX1yOIl+I fhOr3AsHeFLWOAYd41DjMuqmqvQ5e/UigYxkDtssOCHVig7VtaQ0RKTEv6mMfDF4 6Ljgyi7RdGrgle41cDo6DBXTr0WZw6Y2eTLs0G+WCNkJ8/OMR9hLAt/YBg1mPEPo QUNTsqwNQ1Poxuxmo5fWqD0MhLAao7Wgm6dZTiECNPNNBsC91XRYR9jXF29xaB3h 3ekVCTdtI1+wUQolGw1/HZ7whaHkWGrxOY4qqiZsgYRYz1yl52Bt4sJDJYUHknbd GZ4JRkVQXD86D5txRLf500e03QCmDTXxjqEKSsNBNCtcpER1mp+3Hs/SImp/adRr 3tNuEMJduA/5jm27Nt+K13DwsazQXCJMDv5dTYlggBI9c3dhFDmjXNNGSvrvkBkf xW9FbSiHRRDoLR3UMuoR =Ghq/ -----END PGP SIGNATURE-----

2 1

Re: [3/3] msvcirt: Implement ios constructors and assignment
by Marvin July 2, 2015

July 2, 2015

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://testbot.winehq.org/JobDetails.pl?Key=14949 Your paranoid android. === wvistau64 (64 bit msvcirt) === No test summary line found === w2008s64 (64 bit msvcirt) === No test summary line found

1 0

Re: [2/3] msvcirt/tests: Add initial tests for ios
by Marvin July 2, 2015

July 2, 2015

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://testbot.winehq.org/JobDetails.pl?Key=14948 Your paranoid android. === wvistau64 (64 bit msvcirt) === No test summary line found === w2008s64 (64 bit msvcirt) === No test summary line found

1 0

A wrapper around the GTK+ rendering engine
by Ivan Akulinchev July 2, 2015

July 2, 2015

Hello, I just want to thank you for Wine and show you my own uxtheme.dll implementation, which uses the GTK+ rendering engine. Thus Wine applications look really native for users. Here is the link: https://github.com/akulinchev/uxthemegtk (see the screenshots at the bottom of the page) If you want, I can help you to add it to the Wine code. If not, I will develop it alone as a third-party project, but then I have a question: what is the best way to replace a Wine library? I think, I shouldn't change anything in /usr/lib/wine. I know about "native libs", but it's an ELF binary, not PE. Regards, Ivan

5 8

Re: [PATCH 4/4] d3d9/tests: Add basic tests for vertex blending.
by Henri Verbeet July 2, 2015

July 2, 2015

On 2 July 2015 at 08:26, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > + static const float quad_upper_right[] = > + { > + -1.0f, -1.0f, 0.0f, 0.0f, 0.0f, 0.0f, > + -1.0f, 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, > + 1.0f, -1.0f, 0.0f, 0.0f, 0.0f, 0.0f, > + 1.0f, 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, > + }, I think it's slightly more readable to specify these as e.g. static const struct { struct vec3 position; struct vec3 blendweights; } quad_upper_right[] = { ... }, instead of an otherwise unstructured collection of floats. You can also potentially fold these into the tests[] array. > + static const struct { > + const float *vertex_data; > + const POINT *quad_points; > + const POINT *empty_points; > + } > + tests[] = Position of the upper brace.

1 0

Re: [PATCH 2/4] wined3d: Implement vertex blending in glsl_vertex_pipe.
by Henri Verbeet July 2, 2015

July 2, 2015

On 2 July 2015 at 08:26, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > @@ -3071,7 +3075,7 @@ static inline BOOL shader_constant_is_local(const struct wined3d_shader *shader, > > void get_identity_matrix(struct wined3d_matrix *mat) DECLSPEC_HIDDEN; > void get_modelview_matrix(const struct wined3d_context *context, const struct wined3d_state *state, > - struct wined3d_matrix *mat) DECLSPEC_HIDDEN; > + int i, struct wined3d_matrix *mat) DECLSPEC_HIDDEN; I think we'll want the index to be unsigned. (Also applies to shader_glsl_ffp_vertex_normalmatrix_uniform() in patch 112562) Looks pretty good otherwise.

1 0

Re: [PATCH 1/2] comctl32: Set the default separator width when notifying a -ve cmd id.
by Marvin July 2, 2015

July 2, 2015

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://testbot.winehq.org/JobDetails.pl?Key=14914 Your paranoid android. === wvistau64 (64 bit toolbar) === toolbar.c:519: Test failed: Images count mismatch - 26 vs 10 toolbar.c:519: Test failed: Icon size mismatch - 8x8 vs 20x20 toolbar.c:523: Test failed: Images count mismatch - 28 vs 22 toolbar.c:523: Test failed: Icon size mismatch - 16x16 vs 20x20 toolbar.c:533: Test failed: Icon size mismatch - 8x8 vs 16x16 toolbar.c:536: Test failed: Icon size mismatch - 30x30 vs 16x16 toolbar.c:544: Test failed: Images count mismatch - 8 vs 13 toolbar.c:544: Test failed: Icon size mismatch - 30x30 vs 16x16 toolbar.c:548: Test failed: Images count mismatch - 208 vs 13 toolbar.c:548: Test failed: Icon size mismatch - 1x1 vs 16x16 toolbar.c:551: Test failed: Images count mismatch - 208 vs 13 toolbar.c:551: Test failed: Icon size mismatch - 1x5 vs 16x16 toolbar.c:554: Test failed: Images count mismatch - 41 vs 13 toolbar.c:554: Test failed: Icon size mismatch - 5x1 vs 16x16 toolbar.c:1331: Test failed: Icon size mismatch - 14x12 vs 16x15

2 1

Re: [PATCH 2/2] comctl32: Implement the legacy notifications during restore.
by Marvin July 1, 2015

July 1, 2015

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://testbot.winehq.org/JobDetails.pl?Key=14915 Your paranoid android. === wvistau64 (64 bit toolbar) === toolbar.c:584: Test failed: Images count mismatch - 26 vs 10 toolbar.c:584: Test failed: Icon size mismatch - 8x8 vs 20x20 toolbar.c:588: Test failed: Images count mismatch - 28 vs 22 toolbar.c:588: Test failed: Icon size mismatch - 16x16 vs 20x20 toolbar.c:598: Test failed: Icon size mismatch - 8x8 vs 16x16 toolbar.c:601: Test failed: Icon size mismatch - 30x30 vs 16x16 toolbar.c:609: Test failed: Images count mismatch - 8 vs 13 toolbar.c:609: Test failed: Icon size mismatch - 30x30 vs 16x16 toolbar.c:613: Test failed: Images count mismatch - 208 vs 13 toolbar.c:613: Test failed: Icon size mismatch - 1x1 vs 16x16 toolbar.c:616: Test failed: Images count mismatch - 208 vs 13 toolbar.c:616: Test failed: Icon size mismatch - 1x5 vs 16x16 toolbar.c:619: Test failed: Images count mismatch - 41 vs 13 toolbar.c:619: Test failed: Icon size mismatch - 5x1 vs 16x16 toolbar.c:1396: Test failed: Icon size mismatch - 14x12 vs 16x15

1 0

Re: ieframe: implement clicking on Properties
by Jacek Caban July 1, 2015

July 1, 2015

Hi Jared, On 06/30/15 16:00, Jared Smudde wrote: > When the user clicks on the properties menu in ieframe, launch inetcpl.cpl. > > dlls/ieframe/iexplore.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/dlls/ieframe/iexplore.c b/dlls/ieframe/iexplore.c > index 08bb167..c1d0d74 100644 > --- a/dlls/ieframe/iexplore.c > +++ b/dlls/ieframe/iexplore.c > @@ -402,6 +402,11 @@ static void ie_dialog_about(HWND hwnd) > DestroyIcon(icon); > } > > +static void ie_dialog_properties(HWND hwnd) > +{ > + ShellExecuteW(hwnd, NULL, L"inetcpl.cpl", NULL, NULL, 0); > +} I think that we should call inetcpl.cpl functions directly here (probably LaunchInternetControlPanel). Also, you can't use L"" for strings due to compatibility problems, see how other strings are declared. > + > static void add_tb_separator(HWND hwnd) > { > TBBUTTON btn; > @@ -629,6 +634,10 @@ static LRESULT iewnd_OnCommand(InternetExplorer *This, HWND hwnd, UINT msg, WPAR > case ID_BROWSE_QUIT: > ShowWindow(hwnd, SW_HIDE); > break; > + > + case ID_BROWSE_PROPERTIES: > + ie_dialog_properties(hwnd); > + break; Broken indention. Thanks, Jacek

1 0

Re: [PATCH 8/8] comctl32: Implement the legacy notifications during restore.
by Marvin July 1, 2015

July 1, 2015

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://testbot.winehq.org/JobDetails.pl?Key=14894 Your paranoid android. === wvistau64 (64 bit toolbar) === No test summary line found === w2008s64 (64 bit toolbar) === No test summary line found

2 1

Re: kernel32: K32EnumProcessModules: Handle NULL pointer gracefully.
by Alex Henrie July 1, 2015

July 1, 2015

> diff --git a/dlls/kernel32/module.c b/dlls/kernel32/module.c > index f495e81..5461881 100644 > --- a/dlls/kernel32/module.c > +++ b/dlls/kernel32/module.c > @@ -1226,6 +1226,12 @@ BOOL WINAPI K32EnumProcessModules(HANDLE process, HMODULE *lphModule, > if (!init_module_iterator(&iter, process)) > return FALSE; > > + if (!lphModule) > + { > + SetLastError(ERROR_NOACCESS); > + return FALSE; > + } > + > if (!needed) > { > SetLastError(ERROR_NOACCESS); Wouldn't it be easier to write "if (!lphModule || !needed)"? Adding a test or two would also be nice. -Alex

2 1

odbccp32: Implement SQLGetPrivateProfileString (try 6 - resend)
by Hugh McMaster July 1, 2015

July 1, 2015

>+ LONG ret = 0; >+ HKEY hkey; >+ DWORD size = 0; >+ BOOL usedefault = TRUE; >+ /* snip */ >+ clear_errors(); >+ >+ if(!cbRetBuffer) >+ return 0; >+ >+ if(RetBuffer) >+ RetBuffer[0] = 0; >+ >+ if(!lpszSection || !lpszEntry || !lpszDefault || !RetBuffer || !cbRetBuffer) >+ return ret; You are checking "if (!cbRetBuffer)" twice. Same in the next function. You don't need to clear RetBuffer. RegGetValue adds a null terminating character if it doesn't already exist. You also "return 0" and "return ret". They are the same at the moment, so be consistent. >+size = cbRetBuffer; >+if(RegGetValueW(hkeysect, NULL, lpszEntry, RRF_RT_REG_SZ, &type, RetBuffer, &size) == ERROR_SUCCESS) cbRetBuffer is the size in characters of the buffer pointed to by RetBuffer.[1] size needs to be in bytes, so unless RetBuffer uses char, this is wrong. >+ ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); >+ if(ret) >+ { >+ WideCharToMultiByte(CP_ACP, 0, retval, -1, RetBuffer, ret+1, NULL, NULL); >+ } This doesn't look right to me. "ret+1" should be the size, in bytes, of RetBuffer. [2] [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868%28v=vs.85… [2] https://msdn.microsoft.com/en-us/library/windows/desktop/dd374130%28v=vs.85…

1 0

Re: [PATCH 1/6]: msvcp110: Add tr2_sys__Copy_file implementation and test.
by Piotr Caban July 1, 2015

July 1, 2015

On 06/27/15 19:49, YongHaoHu wrote: > + ret = p_tr2_sys__Copy_file(tests[i].source, tests[i].dest, tests[i].fail_if_exists); > + ok(ret == GetLastError(), "test_tr2_sys__Copy_file(): test %d expect: %d, got %d\n", i+1, GetLastError(), ret); > + ok(errno == 0xdeadbeef, "test_tr2_sys__Copy_file(): test %d errno expect 0xdeadbeef, got %d\n", i+1, errno); Please check the return value of the function explicitly. Currently your implementation returns error while it should succeed and it's not visible in the tests. Thanks, Piotr

2 6

Proposal: to make binfmt-misc with wine workable and make Wine compadiblity modes more like Windows compadiblity mode.
by Peter Dolding July 1, 2015

July 1, 2015

For binfmt-misc to be workable a few things need to be known. 1) What version of wine 2) What wineprefix 3) What setting overrides. None of these can be done by environmental vars because binfmt-misc might be directly executing the file. Windows compadiblity mode does not use the registry like wine does. Instead it done in two horible halves. Half 1. The application manifest file. The mainfest file may be embedded in the .exe file or be .exe.mainfest https://msdn.microsoft.com/en-us/library/windows/desktop/hh848036%28v=vs.85… Yes this is where you set what version of Windows application was designed to run with. So running XP mode on Windows 7 is here. Half 2. Application Compatilibity Database This is where it gets horible using shims on particular executables to make broken executables work. Also when this gets too large starts slowing windows down as it searching the database to make applications work. Yes reason some old applications don't work with Windows 10 that worked with 7 is that their entries were deleted from this database. To solve the problem I think we could get away with just Half the manifest can include library overrides and some windows configuration tweaks. But we have problems the include library information wine needs because of native and built-in libraries. Due to the fact wine is running on Linux and other OS's some of the configuration tweaks are going to be wine dependant. So we need another schema. http://wiki.winehq.org/UsefulRegistryKeys Because if Microsoft manifest would tolerate alien schema really everything under software\wine\appdefaults could be moved from the registry to the manifest. Advantage 1 this can be write protected per application and second advantage possibility of embedding in the exe itself. Also for binfmt-misc support have in the schema the means to record wineprefix and wine to use. So the program starting wine applications by binfmt-misc looks for either a mainfest or a winemainfest file in the same directory as the exe to see what wine environment the application should be running with. If there is no configured environment possibly ask user what wineprefix they do what to run the application with. What I do not know is if Microsoft application manifest file will tolerate an alien schema. Don't have different versions of Windows to test if Microsoft application manifest with a alien schema parts works or just causes windows to throw error or just results in the manifest being complete ignored. Now if Microsoft application manifest will not tolerate alien I have to ask would creating own own like exe.winemainfest be acceptable. I do hope Microsoft application manifest will tolerate alien because it would be really useful to have applications with a manifest a values saying what versions of wine they were tested with by the maker. Currently there is no way for a application vendor to record in the application they tested with wine. A lot of ways putting what shim modifications the application need in the manifest would also remove having to look up a huge database. Getting binfmt-misc working also will remove having to use setcap on wineloader instead of the .exe. Also would make if someone set a capicapity limitation by logind not break every wine application just because a few application where needing privileged operation.. So this alteration would be getting closer to how Windows does stuff and in the process making Linux integration better. Peter Dolding

4 7

Re: [PATCH 2/2] msvcp90: Implement time_get<char> ctors and dtors (try 2)
by Alexandre Julliard July 1, 2015

July 1, 2015

Daniel Lehman <dlehman(a)esri.com> writes: > Try2: > - remove cast for Locinfo > - handle failed new() > - change 'unsigned int refs' to 'MSVCP_size_t refs' to match the rest of the file It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M msvcp60.dll -p msvcp60_test.exe.so ios && touch ios.ok wine: Unhandled page fault on write access to 0xd8003304 at address 0x7bc4e659 (thread 0009), starting debugger... Unhandled exception: page fault on write access to 0xd8003304 in 32-bit code (0x7bc4e659). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7bc4e659 ESP:0032f4e4 EBP:0032f688 EFLAGS:00010216( R- -- I -A-P- ) EAX:d8003300 EBX:7bcc3540 ECX:00010000 EDX:75003300 ESI:00331c40 EDI:00000018 Stack dump: 0x0032f4e4: 00000000 0032f688 7bc4e4ab 00000000 0x0032f4f4: 00330000 00000000 00000000 00330000 0x0032f504: 00000000 00000002 00000014 00000000 0x0032f514: 7bc6b946 0032f540 00330014 00000000 0x0032f524: 7b8c57ac 0032f558 7bc6ad4a f7532361 0x0032f534: f75324a1 7ed54740 7bc6ad4a 7b810000 Backtrace: =>0 0x7bc4e659 RtlAllocateHeap+0x1e9(heap=<couldn't compute location>, flags=<couldn't compute location>, size=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/../../include/wine/list.h:100] in ntdll (0x0032f688) 1 0x7eceb358 msvcrt_heap_alloc+0x57() in msvcrt (0x0032f6b8) 2 0x7eceb51c MSVCRT_operator_new+0x4b() in msvcrt (0x0032f6d8) 3 0x7eba526d locale__Locimp__Makexloc+0x49c(locinfo=0x32f780, cat=0x3f, locimp=0x3316d8, loc=(nil)) [/home/julliard/wine/wine/dlls/msvcp60/../msvcp90/locale.c:10584] in msvcp60 (0x0032f72c) 4 0x7eba5707 locale__Locimp__Makeloc+0x56(locinfo=0x32f780, cat=0x3f, locimp=0x3316d8, loc=(nil)) [/home/julliard/wine/wine/dlls/msvcp60/../msvcp90/locale.c:10617] in msvcp60 (0x0032f75c) 5 0x7eba5aba locale_ctor_cstr+0xb9(this=0x32f840, locname="German", cat=0x3f) [/home/julliard/wine/wine/dlls/msvcp60/../msvcp90/locale.c:10791] in msvcp60 (0x0032f7dc) 6 0x7eff37a4 test_num_get_get_double+0x353() [/home/julliard/wine/wine/dlls/msvcp60/tests/ios.c:910] in msvcp60_test (0x0032fc78) 7 0x7eff7212 func_ios+0xd91() [/home/julliard/wine/wine/dlls/msvcp60/tests/ios.c:1645] in msvcp60_test (0x0032fd58) 8 0x7eff3063 main+0x352(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/msvcp60/tests/../../../include/wine/test.h:584] in msvcp60_test (0x0032fe08) 9 0x7effac1f __wine_spec_exe_entry+0x6e(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in msvcp60_test (0x0032fe58) 10 0x7b85b55c call_process_entry+0xb() in kernel32 (0x0032fe78) 11 0x7b85c4ea start_process+0x59(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1104] in kernel32 (0x0032fea8) 12 0x7bc7a0b0 call_thread_func_wrapper+0xb() in ntdll (0x0032fec8) 13 0x7bc7cdc1 call_thread_func+0xb0(entry=0x7b85c490, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2732] in ntdll (0x0032ffa8) 14 0x7bc7a08e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 15 0x7bc51b87 start_process+0x16(kernel_start=0x7b85c490) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2868] in ntdll (0x0032ffe8) 16 0xf75fd21d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 17 0xf75fd380 wine_switch_to_stack+0x1f(func=0x7bc51b70, arg=0x7b85c490, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xffb94238) 18 0x7bc56ef1 LdrInitializeThunk+0x1f0(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2922] in ntdll (0xffb94278) 19 0x7b862213 __wine_kernel_init+0x9b2() [/home/julliard/wine/wine/dlls/kernel32/process.c:1276] in kernel32 (0xffb95168) 20 0x7bc57cb3 __wine_process_init+0x152() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3131] in ntdll (0xffb951e8) 21 0xf75fae83 wine_init+0x2c2(argc=0x3, argv=0xffb95724, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:958] in libwine.so.1 (0xffb95238) 22 0x7bf00d6a main+0x79(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:247] in <wine-loader> (0xffb95678) 23 0xf741ca63 __libc_start_main+0xf2() in libc.so.6 (0x00000000) 0x7bc4e659 RtlAllocateHeap+0x1e9 [/home/julliard/wine/wine/dlls/ntdll/../../include/wine/list.h:100] in ntdll: movl %edx,0x4(%eax) 100 elem->next->prev = elem->prev; -- Alexandre Julliard julliard(a)winehq.org

1 0