December 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

Running WineTest every day the easy way
by Francois Gouget Feb. 10, 2016

Feb. 10, 2016

So this time I've done things in the right order: first publish the code and then announce it. So here's wt-daily, a script to "orchestrate all the daily WineTest runs and related tasks." Here's the 'quickstart guide': git clone https://github.com/fgouget/wt-daily.git cd wt-daily vi wt-daily.config In this file set the following environment variables: email="your email address here" tag="a-tag" desc="A description of your system for Wine developers" shutdown="suspend" Then when you know you won't be needing your computer for a while, just type ./wt-daily. This will update and rebuild Wine, run the tests and finally suspend your machine. It's that simple! If you'd rather not suspend your machine you can set shutdown to "poweroff", "reboot" or even leave it out to keep the computer on. By default wt-daily will ask for your green light before starting the tests. So you can start it while still using the computer and click 'Ok' once you take off. To have the tests run automatically (e.g. from cron), pass --auto-test on the command line or set default_options="--auto-test" in the configuration file. If you have a 64-bit system then you can also set the {tag,desc}wow32 and {tag,desc}wow64 variables to run the tests in a mixed 32/64-bit WinePrefix. If you have a Mac, set the {tag,desc}mac variables to run the tests using the Mac driver instead of (or in addition to) X11. The script should work on OS/X though I have obviously not tested it in a long time. I'ĺl be happy to get feedback on that, particularly in the form of patches. Now you can totally stop reading here. But there's a ton more that the script can do. Read on if you want to discover more. You can have the script start an application that will prevent the tests from running until you close it. I used that to run the tests on a MythTV client box. Wine would get updated and rebuilt in the background while I was watching TV and once that was done the script would run the tests and finally power off the computer. You can also take an image of a suitably configured Windows partition and have wt-daily restore that image to the partition, reboot to Windows which will automatically run WineTest (you'll find the batch script for that in the repository), then reboot back to Linux (or shutdown the computer). This functionality is used on the cw1-hd6800 and xw2-gtx560 CodeWeavers boxes to run the tests on Linux, then Windows 8.1 and then Windows 10. All automatically. The script actually runs every hour and skips the tests (and rebooting) if nothing changed since the last run. I also have this Windows image thing set up on my fg-acer64 laptop but there I interactively select which Windows image to restore, with a choice of Windows 8, 8.1 and 10 (or nothing if I don't feel like going through a reboot). You can also extend wt-daily to add non Wine tasks. For instance on my laptops it runs another script that synchronizes the Documents folder with my desktop and runs 'git fetch --all' in all my Git repositories. This way the next time I go offline everything is up to date. The repository also contains a number or scripts that you may find useful in your own automation tasks as they support not just Linux but OS/X too. wt-image Creates, checks, restores or reboots to a disk image. wt-bot Update, build and check the Wine source code, and run the tests. wt-make Seeks to automatically fully use CPU and I/O parallelism when running make. wt-ask Asks a simple Yes/No question to the user. wt-notify Displays a notification to the user. wt-power Powers off, reboots, suspends or hibernates the computer. wt-screensaver Controls the screensaver. In particular it can prevent it from triggering. wt-nice Runs the specified command with the lowest possible CPU and I/O priority. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

1 1

Re: [PATCH] cmd: Consistently wrap lines to 75 characters.
by Francois Gouget Jan. 27, 2016

Jan. 27, 2016

On Fri, 3 Jul 2015, Alex Henrie wrote: > 75 characters is the maximum length of a line before gettext breaks it, > so this convention will cause each translatable string to fit snugly > into the po files. It's also about what we were doing anyway, just not > consistently. I think this patch and particularly its justification does not make any sense. The command line tool messages were wrapped to the typical width of a terminal: 80 characters. So with this change the messages now take more lines and lose in readability for the user. So now we gettext does not wrap the messages as much in the PO files. But that's totally irrelevant and invisible to the users. It's also totally irrelevant and invisible to a translator as soon as he uses a tool like poedit or a web GUI like Pootle. So what we have here is a change made solely to make things look a bit nicer to the few developers who look at PO files, at the cost of making them slightly worse for our users. Not a good tradeoff in my book and never a good justification for a patch. > I removed Hebrew "translations" of cmd.rc that were just copies of > the English strings, There was a reason for these. Has anything changed? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.

2 5

steam web browsing on OS X
by Theodore Dubois Jan. 18, 2016

Jan. 18, 2016

Wine Staging includes some patches to fix Steam web browsing, but they are deactivated on Mac because they apparently require special build flags. Does anyone know what this refers to? ~Theodore

5 15

Re: [PATCH] user32: Allow WM_CAPTURECHANGE indicating SetCapture() parameter.
by Alexandre Julliard Jan. 18, 2016

Jan. 18, 2016

Christopher Thielen <cthielen(a)gmail.com> writes: > Fixes https://bugs.winehq.org/show_bug.cgi?id=13683 > > A window may be notified with WM_CAPTURECHANGED about itself > gaining mouse capture if it calls SetCapture() twice. You'd need to review all places where we handle that message, I don't think we've taken that behavior into account. Because of this risk, I'm afraid it will have to wait until after code freeze. -- Alexandre Julliard julliard(a)winehq.org

4 7

[RFC] Removing 200XXXXX versions from Bugzilla
by Austin English Jan. 8, 2016

Jan. 8, 2016

Howdy all, I'd like to remove the old 200XXXXX from Bugzilla, and replace them with a pre-0.9 version instead. My reasoning is that it's obnoxious to have to find the latest release in the middle of the list (or type it in to find it), but if we removed all the 200XXXXX versions, it would be the second to last (next to -unknown). For that matter, I'd be okay with merging everything pre-1.0, but I'm mostly concerned about the 200XXXXX versions. Comments would be appreciated. -- -Austin

3 3

Re: [PATCH v3] user32: Add MOUSEHOOKSTRUCTEX to fix mouse wheel support for JA2 1.13 and other apps which use it
by Nikolay Sivov Jan. 3, 2016

Jan. 3, 2016

Hello again. > +typedef struct > +{ > + MOUSEHOOKSTRUCT MOUSEHOOKSTRUCT; > + DWORD mouseData; > +} MOUSEHOOKSTRUCTEX, *PMOUSEHOOKSTRUCTEX, *LPMOUSEHOOKSTRUCTEX; Apparently that's not how Windows SDK defines it. For some obscure reason they didn't define EX struct simply as non-EX + extra field, but used cpp style, kind of. Older versions don't even have field name for MOUSEHOOKSTRUCT portion, only type, but this won't work, not with gcc at least. SDK 10 uses DUMMYSTRUCTNAME as a field name, which resolves to 's', if NONAMELESSSTRUCT is defined. I guess we have to follow version 10 definition.

3 4

Re: user32/tests: Add message tests for EM_SETSEL when getting/losing focus in combo boxes
by Marvin Jan. 1, 2016

Jan. 1, 2016

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=19318 Your paranoid android. === wvistau64 (32 bit msg) === msg.c:10877: Test failed: expected PeekMessage to return FALSE, got 1 msg.c:10889: Test failed: msg.message = 275 instead of WM_USER msg.c:10891: Test failed: expected PeekMessage to return FALSE, got 1 msg.c:10900: Test failed: msg.message = 1024 instead of WM_TIMER msg.c:10902: Test failed: expected PeekMessage to return FALSE, got 1 msg.c:13824: Test failed: 0: WaitForSingleObject failed === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

2 1

Re: [PATCH 3/3] msxml3/tests: Fix a stream leak (Valgrind)
by Marvin Dec. 31, 2015

Dec. 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=19305 Your paranoid android. === w1064 (32 bit httpreq) === httpreq.c:1627: Test failed: got 0x80070057, expected 0x00000000

2 1

Re: user32/tests: Add message tests for EM_SETSEL when getting/losing focus in combo boxes
by Marvin Dec. 31, 2015

Dec. 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=19315 Your paranoid android. === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

1 0

Re: [4/6] gdi32: Fix the advance width in synthetic bold glyphs with scaling.
by Marvin Dec. 31, 2015

Dec. 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=19284 Your paranoid android. === wvistau64 (32 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) === wvistau64 (64 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

1 0

Re: [2/6] gdi32/tests: Add font advance tests for synthetic bold face with scaling.
by Marvin Dec. 31, 2015

Dec. 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=19283 Your paranoid android. === wvistau64 (64 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

1 0

Re: [1/6] gdi32/tests: Refactor test_fake_bold_font() to avoid code duplications.
by Marvin Dec. 31, 2015

Dec. 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=19282 Your paranoid android. === wvistau64 (32 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9) === wvistau64 (64 bit font) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

1 0

Re: [PATCH 1/4] ntdll: Use correct parameter types instead of casting.
by Sebastian Lackner Dec. 31, 2015

Dec. 31, 2015

On 30.12.2015 06:37, Alex Henrie wrote: > Casting has not been necessary here ever since this code was converted > to use wineserver requests circa Wine 1.0. > > Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> > --- > dlls/ntdll/file.c | 13 ++++--------- > 1 file changed, 4 insertions(+), 9 deletions(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 1027b54..6524f32 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -411,10 +411,8 @@ static struct async_fileio *alloc_fileio( DWORD size, HANDLE handle, PIO_APC_ROU > } > > /* callback for irp async I/O completion */ > -static NTSTATUS irp_completion( void *user, IO_STATUS_BLOCK *io, NTSTATUS status, void **apc, void **arg ) > +static NTSTATUS irp_completion( struct async_irp *async, IO_STATUS_BLOCK *io, NTSTATUS status, void **apc, void **arg ) > { It would no longer match the prototype in dlls/ntdll/server.c then: NTSTATUS (*func)(void *, IO_STATUS_BLOCK *, NTSTATUS, void **, void **) = wine_server_get_ptr( call->async_io.func );

2 1

Re: [PATCH 2/2] odbccp32: Implement SQLRemoveDriver/SQLRemoveDriverW
by Marvin Dec. 31, 2015

Dec. 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=19279 Your paranoid android. === w2003std (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === wvistau64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w2008s64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7u (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7pro64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w8 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w864 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w1064 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === wvistau64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w2008s64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7pro64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w864 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w1064 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0

1 0

Re: [PATCH 1/2] odbccp32: Implement SQLInstallDriverEx correctly
by Marvin Dec. 31, 2015

Dec. 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=19278 Your paranoid android. === w2003std (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === wvistau64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w2008s64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7u (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7pro64 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w8 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w864 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w1064 (32 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === wvistau64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w2008s64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w7pro64 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w864 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0 === w1064 (64 bit misc) === misc.c:450: Test failed: RegGetValueA failed misc.c:451: Test failed: UsageCount expected 1 got 0

1 0

Re: [PATCH v2] ole32: Properly implement OleRegGetUserType()
by Marvin Dec. 30, 2015

Dec. 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=19269 Your paranoid android. === wvistau64 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w7u (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w7pro64 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w8 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w864 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w1064 (32 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === wvistau64 (64 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w7pro64 (64 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w864 (64 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null) === w1064 (64 bit compobj) === compobj.c:2332: Test failed: got 0x80040154 compobj.c:2333: Test failed: got (null) compobj.c:2338: Test failed: got 0x80040154 compobj.c:2339: Test failed: got (null) compobj.c:2344: Test failed: got 0x80040154 compobj.c:2345: Test failed: got (null) compobj.c:2350: Test failed: got 0x80040154 compobj.c:2351: Test failed: got (null) compobj.c:2356: Test failed: got 0x80040154 compobj.c:2357: Test failed: got (null) compobj.c:2362: Test failed: got 0x80040154 compobj.c:2363: Test failed: got (null)

2 1

Plug and Play and Wine
by Aric Stewart Dec. 30, 2015

Dec. 30, 2015

Hello All, Yay 1.8! So in discussions with Alexandre, he expressed that he would really like there to be a Plug and Play system in wine to support the HID work I have been doing. Others at WineConf also expressed a desire for a plug and play system. So I have been doing research, reading and work to try to design out how this system will work. I promised him that while I would do research and testing I would wait until after the release before initiating this conversation. We also discussed at WineConf that design processes like this should happen more out in the open so here is my proposed design, with my thinking, so that people who have interest and maybe more knowledge about parts of this than I can help improve the design. I have done some basic proof of concept coding on most of this so that I know it can work, but have flexibility. Long discussion below. The main thing I have learned is that this side of Plug and Play (The system side) is very complicated and pretty much completely undocumented. So this beginning design is going to be greatly simplified but hopefully in enough of a good framework state that it can be expanded as needed. A few definitions, these are borrowed terms but may not be specifically defined exactly the same as on windows: Bus driver : this is whatever lump of code that it talking to the underlying devices, this should be talking to platform native devices. For the purposes of our PnP the bus driver will be only really responsible for enumerating devices, detecting addition and removal of devices and being able to generate device IDs for these devices. This will all be wine code as far as I can determine. Device Driver: This is the code that is actually trying to do something with the device enumerated but the bus driver. This too will likely be wine code. Think a hid minidriver or usb.sys. Generally any supported native drivers will have to sit above this particular device driver level. But that could maybe change, we will see Plug and Play manager: This is the chunk of code that manages all the driver, devices and does the plug and play work. I have chosen to make the existing Programs/plugplay.exe be the plug and play manager. No INF processing or install: The most important part of this that is missing and that I am not addressing is anything about driver installation or inf files. Right now everything in this process is wine builtin code, so there is no need to have inf processing, and that is a seriously complicated part of this process. I have not fully figured out how we should manage the driver store and do the full driver on demand installation and such. But a basic framework can be put together without it. The Plug and Play process, (As I see it for wine) Ok, here is the meat of what is interesting. Starting at the bottom. Plug and Play bus drivers will be written for OS/X HID devices as well as udev hidraw devices. When I discussed this with Alexandre he did not feel like these need to be individual dlls, so they will be included in the plugplay.exe manager. However they will be designed in such a way that if a compelling reason why we need to pull them out becomes apparent it will not be difficult. These bus drivers will not be full device driver really, they just handle the Plug and play aspects of the bus, the device->DeviceExtension will be simply be a handle to the native device in question. The driver will only handle IRP_MJ_PNP ioctls. Having these be loaded into the plugplay.exe manager process space makes many things much easier. When the bus driver detects a new device it will call PNP_IoInvalidateDeviceRelations, and internal function inside of plugplay.exe that mirrors IoInvalidateDeviceRelations. Because the bus drivers are living inside of the plugplay manager there is no need to implement and deal with the ntoskrnl.exe version of IoInvalidateDeviceRelations. Again this will be coded to be able to be pulled out if needed. If we decide to handle any bus drivers that live outside of the plugplay.exe process space then we will need to have this functionality, probably via RPC like the service manager. Here is where the fun comes. Because we are not handling installing drivers (yet) we can just make use of the critical device store. These are drivers that, on windows, are automatically loaded on boot every time. This database is maintained in [CurrentControlSet/Control/CriticalDeviceDatabase] The keys in this registry key represent a HardwareID that will match a device. We query the IDs from the bus device’s BusQueryHardwareIDs and if we find a match (from most specific to most general) we look at that registry key. The CriticalDeviceDatabase entry will specify a [Service] value. All the first round builtin drivers will specify the [Service]. Further implementations when we start supporting inf files will also look at supporting the [ClassGUID] value where a driver inf can be specified. That Service will specify a key in [CurrentControlSet\Services]. These services will need to be [type] of 0x1 (device driver) and [start] of 0x3 (on demand), finally they will have an [ImagePath] that points to the .sys file for this driver. The plug and play manager will determine if it has loaded that driver or not, and if not then it will load the driver into its process space and call the drivers DriverEntry. Part of this will be done via the advapi service APIs to query the service and then I was planing to reuse code from winedevice.exe for the actual loading of the driver.sys into the plugplay.exe process space. With the loaded driver we then call the driver’s extension.AddDevice entry point with the new bus device. The drivers AddDevice function will be well behaved and call IoAttachDeviceToDeviceStack. The Plug and Play manager will look at the bus device after AddDevice and if there is an AttachedDevice then will proceed to call IRP_MN_START_DEVICE on the attached device. Then a IRP_MJ_POWER/IRP_MN_SET_POWER to PowerDeviceD0. It is an important point that having the bus drivers and function drivers all loaded into the same process space means that they have a common process stack for sharing memory and handles and such. Driver will expect this so if we end up having to change this we will have to deal with the complexities of the memory management. Device removal will be more simplistic. When the bus driver detects that a device has been removed then we again make a PNP_IoInvalidateDeviceRelations. Then the plug and play manager will send a IRP_MN_SURPRISE_REMOVAL followed by a IRP_MN_REMOVE_DEVICE ioctl to the AttachedDevice. That will represent the entirety of the process, as I see it on the first pass, for plug and play. Some of the many things this does not do, it does not make use of or maintain a driver store (I think maintained as keys under the [CurrentControlSet/Control/Class/<GUID>] keys). It does not do any of the complicated driver INF, install on demand work and it does not allow for new drivers to be installed via any of the installation processes. But it does not prevent this from being expanded on for next passes. Another big unanswered part of this is the integration with the Plug and Play configuration manager (cfgmgr32.dll) and all the CM_XXX functions. I am only working on the HID bus and drivers, however I feel like we could expand this pretty easily into USB or even mountmgr bus and driver architectures as we move forward. Comments? Thoughts? Anyone actually get to the end here? -aric

2 2

Re: configure: Detect MinGW-w64 Clang cross toolchain
by Alexandre Julliard Dec. 30, 2015

Dec. 30, 2015

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -171,17 +171,19 @@ LIBS="$ac_wine_check_funcs_save_LIBS"]) > > dnl **** Check for a mingw program, trying the various mingw prefixes **** > dnl > -dnl Usage: WINE_CHECK_MINGW_PROG(variable,prog,[value-if-not-found],[path]) > +dnl Usage: WINE_CHECK_MINGW_PROG(variable,progs,[value-if-not-found],[path]) > dnl > AC_DEFUN([WINE_CHECK_MINGW_PROG], > [case "$host_cpu" in > i[[3456789]]86*) > ac_prefix_list="m4_foreach([ac_wine_prefix],[w64-mingw32, pc-mingw32, mingw32msvc, mingw32], > - m4_foreach([ac_wine_cpu],[i686,i586,i486,i386],[ac_wine_cpu-ac_wine_prefix-$2 ])) > + m4_foreach([ac_wine_cpu],[i686,i586,i486,i386], > + m4_foreach([ac_wine_prog],[$2],[ac_wine_cpu-ac_wine_prefix-ac_wine_prog ]))) > mingw32-$2" ;; Do we need to duplicate all the names? Or would it be sufficient to check only the w64-mingw one? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [2/2] kernel32: add tests for GetSystemPreferredUILanguages
by Marvin Dec. 30, 2015

Dec. 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=19262 Your paranoid android. === w1064 (32 bit locale) === locale.c:2339: Test failed: LCMapStringEx should fail with bad locale name locale.c:2340: Test failed: unexpected error code -559038737 locale.c:2431: Test failed: Expected lcid == 0, got got 00001000, error -559038737 locale.c:4154: Test failed: IsValidLocaleName should have failed locale.c:4156: Test failed: IsValidLocaleName should have failed locale.c:4521: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4523: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [PATCH] user32: Properly handle WM_DEVICECHANGE in is_pointer_message(). (resend)
by Marvin Dec. 30, 2015

Dec. 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=19261 Your paranoid android. === w1064 (32 bit msg) === msg.c:6138: Test failed: Update region shouldn't be empty msg.c:6372: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6374: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6144: Test failed: Regions are different msg.c:6144: Test failed: Regions are different msg.c:6144: Test failed: Regions are different

1 0

Re: [PATCH] user32: Properly handle WM_DEVICECHANGE in is_pointer_message().
by Marvin Dec. 30, 2015

Dec. 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=19260 Your paranoid android. === w1064 (32 bit msg) === msg.c:6138: Test failed: Update region shouldn't be empty msg.c:6372: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6374: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6144: Test failed: Regions are different msg.c:6144: Test failed: Regions are different msg.c:6144: Test failed: Regions are different

1 0

Re: [PATCH] ole32: Properly implement OleRegGetUserType()
by Dmitry Timoshkov Dec. 30, 2015

Dec. 30, 2015

> dlls/ole32/ole2.c | 85 +++++++++++++++++++++++++++++-------------------------- > 1 file changed, 45 insertions(+), 40 deletions(-) It would be helpful to know why this implementaion is considered more "proper" than an existing one, especially taking into account lack of any tests or reference to a bug report. -- Dmitry.

2 2

Re: 0001-winedbg-Add-a-debug-button-on-crash-dialog-get-rid-of-
by Jactry Zeng Dec. 30, 2015

Dec. 30, 2015

Hi Changhui, I like this patch, too. '&Debug' and 'Show &Details' use a same shortcut key here. @@ -58,6 +50,7 @@ BEGIN IDC_STATIC_TXT2,"SysLink",0,27,60,224,100 DEFPUSHBUTTON "Close", IDOK, 205, 151, 60, 16, WS_TABSTOP PUSHBUTTON "Show &Details", ID_DETAILS, 140, 151, 60, 16, WS_TABSTOP + PUSHBUTTON "&Debug", ID_DEBUG, 75, 151, 60, 16, WS_TABSTOP END I think push this debug button in the left corner seems better? Maybe we also need some text in IDC_STATIC_TXT2 to let users know what it means. Thanks. 2015-12-28 17:21 GMT+08:00 Changhui LIU <liuchanghui(a)linuxdeepin.com>: > > > > > > > ------------------ > Regards, > Changhui Liu > > > > > -- Regards, Jactry Zeng

1 0

Re: 0001-winedbg-Add-a-debug-button-on-crash-dialog-get-rid-of-
by Alex Henrie Dec. 30, 2015

Dec. 30, 2015

I'm pretty sure that the Debug button on the crash dialog is hidden so that people who don't know what they're doing don't try to use it. -Alex

2 1

Re: [PATCH 1/1] msvcr120: Enable MSVCRT__nextafterf when _MSVCR_VER>=120.
by Piotr Caban Dec. 29, 2015

Dec. 29, 2015

Hi, On 12/28/15 08:19, YongHao Hu wrote: > dlls/msvcr120/msvcr120.spec | 6 +++--- > dlls/msvcr120_app/msvcr120_app.spec | 6 +++--- > dlls/msvcrt/math.c | 18 +++++++++--------- > 3 files changed, 15 insertions(+), 15 deletions(-) Please also update: ucrtbase/ucrtbase.spec api-ms-win-crt-math-l1-1-0/api-ms-win-crt-math-l1-1-0.spec files. Thanks, Piotr

2 2

Re: [PATCH] ole32: Zero out pointer in CreateFileMoniker() on error
by Marvin Dec. 29, 2015

Dec. 29, 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=19236 Your paranoid android. === wvistau64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w7u (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w7pro64 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w8 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w864 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === w1064 (32 bit moniker) === moniker: unhandled exception c0000005 at 0042A889 === wvistau64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA === w7pro64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA === w864 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA === w1064 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004241FA

1 0

Re: [2/2] shell32: ShellExecute() should not exec non-executable files.
by Francois Gouget Dec. 29, 2015

Dec. 29, 2015

On Tue, 29 Dec 2015, Francois Gouget wrote: [...] > + > + if ((sei_tmp.lpVerb && *sei_tmp.lpVerb) || PathIsExeW(wszApplicationName)) Please don't apply. I think this test is wrong. It should probably be checking that no was specified, or maybe that no class was specified. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Bugzilla changes
by Austin English Dec. 29, 2015

Dec. 29, 2015

Howdy all, As Alexandre mentioned [1], at WineConf we made several decisions to modify bugzilla in a few ways. I've now implemented those changes, which are outlined below: * New wine-staging product: This should be used for bugs caused by patches that are in wine-staging, but that do not occur in wine-development (i.e., wine-staging patch regressions) * New STAGED resolution: This is to differentiate bugs that are FIXED (in wine-development) from bugs that are not present in wine-staging because of one or more patches. The anticipated workflow is: UNCONFIRMED > bug confirmed, NEW > patch written and sent to wine-patches, if it's accepted, FIXED. If not, and the patch is integrated into wine-staging, then the bug is STAGED. When the patch is revised and eventually integrated into wine-development, the bug should move to FIXED. * New NEEDINFO resolution: There's a lot of confusion and different handling by triagers for what to do with bug reports that are incomplete (i.e., leaving it open versus closing invalid). To mitigate this, I've added a NEEDINFO resolution. If a bug report lacks needed information, set it to this status. Bug that have been open NEEDINFO for more than 1 year can be closed. * Renamed UPSTREAM to NOTOURBUG: This is more in line with what other projects do, and eliminates confusion about the upstream/downstream distinction. Please let me know if there are any questions or ideas for further enhancements. [1] https://www.winehq.org/pipermail/wine-devel/2015-September/109392.html -- -Austin

6 11

Re: hidclass.sys: Properly quit hid_device_thread when both completion event and halt event are signaled.
by Aric Stewart Dec. 29, 2015

Dec. 29, 2015

Sorry for the delayed review, I have been traveling. I understand the issue your trying to fix, but I worry that you could get yourself into a bad state where if a driver is misbehaving and is blocked or crashes while processing an IRP then the halt event will never get processed as we will be waiting INFINITE on an event that may never come. I dont know which is the more likely or problematic case. What I may suggest is keep the WaitForMultipleObjects(2, events, FALSE, INFINITE) and instead of relying on the return code you could do an additional WaitForSingleObject(ext->halt_event, 0) to determine if exit_now should be set. -aric

2 1

Re: [PATCH 2/2] user32/tests: Add tests for WM_DEVICECHANGE message. (try 3)
by Marvin Dec. 29, 2015

Dec. 29, 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=19233 Your paranoid android. === w1064 (32 bit msg) === msg.c:6140: Test failed: Update region shouldn't be empty msg.c:6374: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6376: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6146: Test failed: Regions are different msg.c:6146: Test failed: Regions are different msg.c:6146: Test failed: Regions are different

1 0

Re: [2/2] shell32: ShellExecute() should not exec non-executable files.
by Marvin Dec. 29, 2015

Dec. 29, 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=19232 Your paranoid android. === wvistau64 (32 bit shlexec) === shlexec.c:142: Test failed: ShellExecute(verb="QuotedUpperL", file="C:\Users\winetest\AppData\Local\Temp\wtD519.tmp\test file.shlexec") WaitForSingleObject returned 258 shlexec.c:1566: Test failed: argvA3 expected 'QuotedUpperL', but key not found or empty shlexec.c:1574: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD519.tmp\test file.shlexec', but key not found or empty === w1064 (32 bit shlexec) === shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1008.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1008.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1008.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt1008.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2286: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2667: Test failed: argvA3 expected 'Exec', but key not found or empty shlexec.c:2668: Test failed: longPath expected 'C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test2.exe', but key not found or empty shlexec.c:556: childTimeout called shlexec.c:2679: Test failed: argcA expected 4, but got 3 shlexec.c:2680: Test failed: argvA3 expected 'Exec', but key not found or empty shlexec.c:2681: Test failed: longPath expected 'C:\Users\winetest\AppData\Local\Temp\wt43A.tmp\test2.exe', got 'C:\Users\winetest\Documents\shell32_test64.exe'

1 0

Re: [1/2] shell32/tests: Make sure the test executable has an executable name.
by Marvin Dec. 28, 2015

Dec. 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=19231 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2300: Test failed: ddeExec expected '[ifexec("C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde")]', got '[open("C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde")]' shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtEB96.tmp\test file.sde") failed: rc=29 err=2 === w1064 (64 bit shlexec) === shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtF5C.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtF5C.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtF5C.tmp\test file.sde") failed: rc=29 err=2 shlexec.c:2288: Test failed: ShellExecuteEx(mask="0x500", file="C:\Users\winetest\AppData\Local\Temp\wtF5C.tmp\test file.sde") failed: rc=29 err=2

1 0

Re: 0001-winedbg-Add-a-debug-button-on-crash-dialog-get-rid-of-
by Qian Hong Dec. 28, 2015

Dec. 28, 2015

I like this change, thank you for the patch. On Mon, Dec 28, 2015 at 5:21 PM, Changhui LIU <liuchanghui(a)linuxdeepin.com> wrote: > > > > > > > ------------------ > Regards, > Changhui Liu > > > > -- Regards, Qian Hong - http://www.winehq.org

1 0

Out-of-date gcc and ld on the testbot build VM
by Hugh McMaster Dec. 28, 2015

Dec. 28, 2015

The testbot seems to have an out-of-date version of mingw32, or at least, its linker, ld.exe. I'm trying to run tests for GetConsoleScreenBufferInfoEx, a function available on Vista and higher. But the build VM's linker is failing with an undefined reference: reg.o: In function `test_GetConsoleScreenBufferInfoEx': /home/winetest/tools/testbot/var/build-mingw32/programs/reg/tests/../../../../wine/programs/reg/tests/reg.c:489: undefined reference to `__imp__GetConsoleScreenBufferInfoEx(a)8' collect2: ld returned 1 exit status winegcc: i686-w64-mingw32-gcc failed My machine is able to compile the tests. It also has no trouble building a separate .exe using i686-w64-mingw32-gcc. My machine has: - mingw32 gcc version 4.8.2 (GCC) - mingw32 ld version: GNU ld (GNU Binutils) 2.23.52.20130620 -- Hugh McMaster

3 5

Re: shell32: add SHCreateSessionKey stub (try 2)
by Nikolay Sivov Dec. 28, 2015

Dec. 28, 2015

> +/************************************************************************* > + * SHCreateSessionKey [SHELL32.723] NT 4.0 > + * > + */ > +HRESULT WINAPI SHCreateSessionKey(REGSAM access, HKEY *hkey) > +{ > + FIXME("stub: %u %p\n", access, hkey); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} 'access' is a 32bit bit mask, return value is HRESULT.

1 0

Re: shell32: add SHCreateSessionKey stub
by Nikolay Sivov Dec. 28, 2015

Dec. 28, 2015

On 28.12.2015 8:15, Austin English wrote: > +HRESULT WINAPI SHCreateSessionKey(REGSAM access, HKEY *hkey) > +{ > + FIXME("stub: %d %p\n", access, hkey); > + return ERROR_SUCCESS; > +} This is wrong regarding tracing format, return value and formatting. I'll try to find time this week to send an actual implementation. It's fine to have fixed stub in before that of course.

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 4).
by Stefan Dösinger Dec. 27, 2015

Dec. 27, 2015

> Am 23.12.2015 um 16:46 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > > + file = create_bitmap("palette.bmp", 3, 39, TRUE); > + > + hr = Direct3DRMCreate(&d3drm1); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", hr); > + > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM2, (void **)&d3drm2); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRM2 interface (hr = %x)\n", hr); > + > + file = create_bitmap("8bpp.bmp", 100, 100, FALSE); The first line here seems to be a leftover from the last patch version. The same applies to the V3 function

2 4

Re: ntdll: add RtlCreateUserProcess stub
by Dmitry Timoshkov Dec. 27, 2015

Dec. 27, 2015

Austin English <austinenglish(a)gmail.com> wrote: > +NTSTATUS WINAPI RtlCreateUserProcess(UNICODE_STRING *path, ULONG attributes, RTL_USER_PROCESS_PARAMETERS *parameters, > + PSECURITY_DESCRIPTOR *process_descriptor, PSECURITY_DESCRIPTOR *thread_descriptor, > + HANDLE parent, BOOLEAN inherit, HANDLE debug, HANDLE exception, > + PRTL_USER_PROCESS_INFORMATION info) Some of the parameters use wrong pointer information. Probably it would be better to completely avoid Pxxx prefixes and use normal pointers for all parameters? -- Dmitry.

2 1

Re: pdh: Fix prototype of PdhGetLogFileType[A/W].
by Austin English Dec. 27, 2015

Dec. 27, 2015

Thanks for fixing it so quickly Sebastian. I came back from holiday and it was already done :). On Thu, Dec 24, 2015 at 4:08 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > As pointed out on the mailing list yesterday, the first parameter can't be a handle. > Output after this patch: > > fixme:pdh:PdhGetLogFileTypeW L"dummy.log", 0x33fd9c: stub > > dlls/pdh/pdh.spec | 4 ++-- > dlls/pdh/pdh_main.c | 8 ++++---- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/pdh/pdh.spec b/dlls/pdh/pdh.spec > index 529b92d..41900c8 100644 > --- a/dlls/pdh/pdh.spec > +++ b/dlls/pdh/pdh.spec > @@ -62,8 +62,8 @@ > @ stub PdhGetFormattedCounterArrayW > @ stdcall PdhGetFormattedCounterValue(ptr long ptr ptr) > @ stub PdhGetLogFileSize > -@ stdcall PdhGetLogFileTypeA(ptr ptr) > -@ stdcall PdhGetLogFileTypeW(ptr ptr) > +@ stdcall PdhGetLogFileTypeA(str ptr) > +@ stdcall PdhGetLogFileTypeW(wstr ptr) > @ stub PdhGetLogSetGUID > @ stub PdhGetRawCounterArrayA > @ stub PdhGetRawCounterArrayW > diff --git a/dlls/pdh/pdh_main.c b/dlls/pdh/pdh_main.c > index 036d28b..8854fd7 100644 > --- a/dlls/pdh/pdh_main.c > +++ b/dlls/pdh/pdh_main.c > @@ -1273,17 +1273,17 @@ PDH_STATUS WINAPI PdhSetDefaultRealTimeDataSource( DWORD source ) > /*********************************************************************** > * PdhGetLogFileTypeA (PDH.@) > */ > -PDH_STATUS WINAPI PdhGetLogFileTypeA(PDH_HLOG log, DWORD *type) > +PDH_STATUS WINAPI PdhGetLogFileTypeA(const char *log, DWORD *type) > { > - FIXME("%p, %p: stub\n", log, type); > + FIXME("%s, %p: stub\n", debugstr_a(log), type); > return PDH_NOT_IMPLEMENTED; > } > > /*********************************************************************** > * PdhGetLogFileTypeW (PDH.@) > */ > -PDH_STATUS WINAPI PdhGetLogFileTypeW(PDH_HLOG log, DWORD *type) > +PDH_STATUS WINAPI PdhGetLogFileTypeW(const WCHAR *log, DWORD *type) > { > - FIXME("%p, %p: stub\n", log, type); > + FIXME("%s, %p: stub\n", debugstr_w(log), type); > return PDH_NOT_IMPLEMENTED; > } > -- > 2.6.4 > > -- -Austin

1 0

Re: [PATCH 7/7] dwrite: Fix identical ranges merging
by Marvin Dec. 26, 2015

Dec. 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=19166 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 6/7] dwrite: Locale layout ranged attribute is case-insensitive
by Marvin Dec. 26, 2015

Dec. 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=19165 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 5/7] dwrite: Store optical alignment property
by Marvin Dec. 26, 2015

Dec. 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=19164 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 4/7] dwrite: Store last line wrapping property
by Marvin Dec. 26, 2015

Dec. 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=19163 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/7] dwrite: Store per-range typography property
by Marvin Dec. 26, 2015

Dec. 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=19162 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/7] dwrite/tests: One more test for duplicates in IDWriteTypography
by Marvin Dec. 26, 2015

Dec. 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=19161 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: mshtml: Add IHTMLXMLHttpRequest::responseXML() method implementation. (resend)
by Nikolay Sivov Dec. 26, 2015

Dec. 26, 2015

On 25.12.2015 10:30, Zhenbo Li wrote: > +static void test_illegal_xml(IXMLDOMDocument *xmldom) > +{ > + IXMLDOMNode *first, *last; > + VARIANT variant; > + HRESULT hres; > + BSTR bstr; > + > + hres = IXMLDOMDocument_get_baseName(xmldom, NULL); > + ok(hres == E_INVALIDARG, "Expect E_INVALIDARG, got %08x\n", hres); > + hres = IXMLDOMDocument_get_baseName(xmldom, &bstr); > + ok(hres == S_FALSE, "get_baseName failed: %08x\n", hres); > + ok(bstr == NULL, "bstr(%p): %s\n", bstr, wine_dbgstr_w(bstr)); > + SysFreeString(bstr); > + > + hres = IXMLDOMDocument_get_dataType(xmldom, NULL); > + ok(hres == E_INVALIDARG, "Expect E_INVALIDARG, got %08x\n", hres); > + hres = IXMLDOMDocument_get_dataType(xmldom, &variant); > + ok(hres == S_FALSE, "get_dataType failed: %08x\n", hres); > + ok(V_VT(&variant) == VT_NULL, "got %s\n", debugstr_variant(&variant)); > + VariantClear(&variant); > + > + hres = IXMLDOMDocument_get_text(xmldom, &bstr); > + ok(!strcmp_wa(bstr, ""), "text = %s\n", wine_dbgstr_w(bstr)); > + SysFreeString(bstr); > + > + hres = IXMLDOMDocument_get_firstChild(xmldom, NULL); > + ok(hres == E_INVALIDARG, "Expect E_INVALIDARG, got %08x\n", hres); > + > + first = (void*)0xdeadbeef; > + hres = IXMLDOMDocument_get_firstChild(xmldom, &first); > + ok(hres == S_FALSE, "get_firstChild failed: %08x\n", hres); > + ok(first == NULL, "first != NULL\n"); > + > + last = (void*)0xdeadbeef; > + hres = IXMLDOMDocument_get_lastChild(xmldom, &last); > + ok(hres == S_FALSE, "get_lastChild failed: %08x\n", hres); > + ok(last == NULL, "last != NULL\n"); > +} It makes no sense to test every method on empty tree, test for text string. > + hres = IXMLDOMDocument_QueryInterface(xmldoc, &IID_IObjectSafety, (void**)&safety); > + assert(SUCCEEDED(hres)); > + hres = IObjectSafety_SetInterfaceSafetyOptions(safety, NULL, > + INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA | INTERFACE_USES_SECURITY_MANAGER, > + INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA | INTERFACE_USES_SECURITY_MANAGER); > + assert(SUCCEEDED(hres)); > + IObjectSafety_Release(safety); This looks weird to me, why the asserts? Did Jacek suggest that?

2 2