March 2017 - 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

COM tracing ...
by Michael Meeks Aug. 21, 2018

Aug. 21, 2018

Hi guys, Rather a peripheral question; apologies for that - but I'd imagine there are experts here that may be able to help. I have a black-box problem - a Windows app dealing with confidential data that I can't easily touch (and thus can't get to run under Wine) - which does some small but critical automation of MS Office - using VBS / COM scripting. I'd -really- love some input on how best to trace that series of COM method calls on Windows itself ie. the (remote) service activation, and the RPC beyond that - particularly the method names, parameters etc. of the COM/OLE Office API. I've tried (so far): http://www.rohitab.com/apimonitor which, while closed, looks interesting; but traces a lot in a hard-to-search way and doesn't appear to do the trick. https://support.microsoft.com/en-us/help/926098/how-to-enable-com-and-com-d… Sounds useful: using Event Tracing for Windows (ETW) but has this rather unhelpful property: "The binary file must be formatted by Microsoft so that it can be analyzed. Please forward the .etl files to your support contact. ..." ;-) Component models used to be all the rage in my youth ;-) surely someone solved the "strace for COM calls" problem elegantly some-when ! Crazily - might it be possible to instrument, interpose and use Wine's COM impl. on Windows [ which sounds a bit 'exciting' ;-], or ? Anyhow - help much appreciated & sorry for the noise ! Regards, Michael. -- michael.meeks(a)collabora.com <><, Pseudo Engineer, itinerant idiot

2 4

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

Re: [PATCH] server_ioctl_file() - Prefix printed hex values with '0x'
by Alexandre Julliard Oct. 12, 2017

Oct. 12, 2017

Chris Morgan <chmorgan(a)gmail.com> writes: > Avoids the ambiguity with non-alphanumeric hex values. > > Signed-off-by: Chris Morgan <chmorgan(a)gmail.com> > --- > dlls/ntdll/file.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index fd7f3dd..4d081b7 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -1567,7 +1567,7 @@ static NTSTATUS server_ioctl_file( HANDLE handle, HANDLE event, > SERVER_END_REQ; > > if (status == STATUS_NOT_SUPPORTED) > - FIXME("Unsupported ioctl %x (device=%x access=%x func=%x method=%x)\n", > + FIXME("Unsupported ioctl 0x%x (device=0x%x access=0x%x func=0x%x method=0x%x)\n", That's mostly a matter of taste, so I don't think it's necessary to change it. -- Alexandre Julliard julliard(a)winehq.org

3 2

[v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention
by Ricardo Neri May 15, 2017

May 15, 2017

This is v6 of this series. The five previous submissions can be found here [1], here [2], here[3], here[4], and here[5]. This version addresses the comments received in v4 plus improvements of the handling of emulation in 64-bit builds. Please see details in the change log. === What is UMIP? User-Mode Instruction Prevention (UMIP) is a security feature present in new Intel Processors. If enabled, it prevents the execution of certain instructions if the Current Privilege Level (CPL) is greater than 0. If these instructions were executed while in CPL > 0, user space applications could have access to system-wide settings such as the global and local descriptor tables, the segment selectors to the current task state and the local descriptor table. These are the instructions covered by UMIP: * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register If any of these instructions is executed with CPL > 0, a general protection exception is issued when UMIP is enabled. === How does it impact applications? There is a caveat, however. Certain applications rely on some of these instructions to function. An example of this are applications that use WineHQ[6]. For instance, these applications rely on sidt returning a non- accessible memory location[8]. During the discussions, it was proposed that the fault could be relied to the user-space and perform the emulation in user-mode. However, this would break existing applications until, for instance, they update to a new WineHQ version. However, this approach would require UMIP to be disabled by default. The consensus in this forum is to always enable it. This patchset initially treated tasks running in virtual-8086 mode as a special case. However, I received clarification that DOSEMU[8] does not support applications that use these instructions. It relies on WineHQ for this [9]. Furthermore, the applications for which the concern was raised run in protected mode [8]. Please note that UMIP is always enabled for both 64-bit and 32-bit Linux builds. However, emulation of the UMIP-protected instructions is not done for 64-bit processes. 64-bit user space applications will receive the SIGSEGV signal when UMIP instructions causes a general protection fault. === How are UMIP-protected instructions emulated? This version keeps UMIP enabled at all times and by default. If a general protection fault caused by the instructions protected by UMIP is detected, such fault will be fixed-up by returning dummy values as follows: * SGDT and SIDT return hard-coded dummy values as the base of the global descriptor and interrupt descriptor tables. These hard-coded values correspond to memory addresses that are near the end of the kernel memory map. This is also the case for virtual-8086 mode tasks. In all my experiments in x86_32, the base of GDT and IDT was always a 4-byte address, even for 16-bit operands. Thus, my emulation code does the same. In all cases, the limit of the table is set to 0. * STR and SLDT return 0 as the segment selector. This looks appropriate since we are providing a dummy value as the base address of the global descriptor table. * SMSW returns the value with which the CR0 register is programmed in head_32/64.S at boot time. This is, the following bits are enabled: CR0.0 for Protection Enable, CR.1 for Monitor Coprocessor, CR.4 for Extension Type, which will always be 1 in recent processors with UMIP; CR.5 for Numeric Error, CR0.16 for Write Protect, CR0.18 for Alignment Mask. As per the Intel 64 and IA-32 Architectures Software Developer's Manual, SMSW returns a 16-bit results for memory operands. However, when the operand is a register, the results can be up to CR0[63:0]. Since the emulation code only kicks-in in x86_32, we return up to CR[31:0]. * The proposed emulation code is handles faults that happens in both protected and virtual-8086 mode. === How is this series laid out? ++ Fix bugs in MPX address evaluator I found very useful the code for Intel MPX (Memory Protection Extensions) used to parse opcodes and the memory locations contained in the general purpose registers when used as operands. I put some of this code in a separate library file that both MPX and UMIP can access and avoid code duplication. Before creating the new library, I fixed a couple of bugs that I found in how MPX determines the address contained in the instruction and operands. ++ Provide a new x86 instruction evaluating library With bugs fixed, the MPX evaluating code is relocated in a new insn-eval.c library. The basic functionality of this library is extended to obtain the segment descriptor selected by either segment override prefixes or the default segment by the involved registers in the calculation of the effective address. It was also extended to obtain the default address and operand sizes as well as the segment base address. Also, support to process 16-bit address encodings. Armed with this arsenal, it is now possible to determine the linear address onto which the emulated results shall be copied. This code supports Normal 32-bit and 64-bit (i.e., __USER32_CS and/or __USER_CS) protected mode, virtual-8086 mode, 16-bit protected mode with 32-bit base address. ++ Emulate UMIP instructions A new fixup_umip_exception functions inspect the instruction at the instruction pointer. If it is an UMIP-protected instruction, it executes the emulation code. This uses all the address-computing code of the previous section. ++ Add self-tests Lastly, self-tests are added to entry_from_v86.c to exercise the most typical use cases of UMIP-protected instructions in a virtual-8086 mode. ++ Extensive tests Extensive tests were performed to test all the combinations of ModRM, SiB and displacements for 16-bit and 32-bit encodings for the ss, ds, es, fs and gs segments. Tests also include a 64-bit program that uses segmentation via fs and gs. For this purpose, I temporarily, and not as part of this patchset, enabled UMIP support for 64-bit process with the intention to test the computations of linear addresses in 64-bit mode, including the extra R8-R15 registers. Extensive test is also implemented for virtual-8086 tasks. Code of these tests can be found here [10] and here [11]. [1]. https://lwn.net/Articles/705877/ [2]. https://lkml.org/lkml/2016/12/23/265 [3]. https://lkml.org/lkml/2017/1/25/622 [4]. https://lkml.org/lkml/2017/2/23/40 [5]. https://lkml.org/lkml/2017/3/3/678 [7]. https://www.winehq.org/ [8]. https://www.winehq.org/pipermail/wine-devel/2016-November/115320.html [9]. http://www.dosemu.org/ [9]. http://marc.info/?l=linux-kernel&m=147876798717927&w=2 [10]. https://github.com/01org/luv-yocto/tree/rneri/umip/meta-luv/recipes-core/um… [11]. https://github.com/01org/luv-yocto/commit/a72a7fe7d68693c0f4100ad86de6ecabd… Thanks and BR, Ricardo Changes since V5: * Relocate the page fault error code enumerations to traps.h Changes since V4: * Audited patches to use braces in all the branches of conditional. statements, except those in which the conditional action only takes one line. * Implemented support in 64-builds for both 32-bit and 64-bit tasks in the instruction evaluating library. * Split segment selector function in the instruction evaluating library into two functions to resolve the segment type by instruction override or default and a separate function to actually read the segment selector. * Fixed a bug when evaluating 32-bit effective addresses with 64-bit kernels. * Split patches further for for easier review. * Use signed variables for computation of effective address. * Fixed issue with a spurious static modifier in function insn_get_addr_ref found by kbuild test bot. * Removed comparison between true and fixup_umip_exception. * Reworked check logic when identifying erroneous vs invalid values of the SiB base and index. Changes since V3: * Limited emulation to 32-bit and 16-bit modes. For 64-bit mode, a general protection fault is still issued when UMIP-protected instructions are executed with CPL > 0. * Expanded instruction-evaluating code to obtain segment descriptor along with their attributes such as base address and default address and operand sizes. Also, support for 16-bit encodings in protected mode was implemented. * When getting a segment descriptor, this include support to obtain those of a local descriptor table. * Now the instruction-evaluating code returns -EDOM when the value of registers should not be used in calculating the effective address. The value -EINVAL is left for errors. * Incorporate the value of the segment base address in the computation of linear addresses. * Renamed new instruction evaluation library from insn-kernel.c to insn-eval.c * Exported functions insn_get_reg_offset_* to obtain the register offset by ModRM r/m, SiB base and SiB index. * Improved documentation of functions. * Split patches further for easier review. Changes since V2: * Added new utility functions to decode the memory addresses contained in registers when the 16-bit addressing encodings are used. This includes code to obtain and compute memory addresses using segment selectors for real-mode address translation. * Added support to emulate UMIP-protected instructions for virtual-8086 tasks. * Added self-tests for virtual-8086 mode that contains representative use cases: address represented as a displacement, address in registers and registers as operands. * Instead of maintaining a static variable for the dummy base addresses of the IDT and GDT, a hard-coded value is used. * The emulated SMSW instructions now return the value with which the CR0 register is programmed in head_32/64.S This is: PE | MP | ET | NE | WP | AM. For x86_64, PG is also enabled. * The new file arch/x86/lib/insn-utils.c is now renamed as arch/x86/lib/ insn-kernel.c. It also has its own header. This helps keep in sync the the kernel and objtool instruction decoders. Also, the new insn-kernel.c contains utility functions that are only relevant in a kernel context. * Removed printed warnings for errors that occur when decoding instructions with invalid operands. * Added more comments on fixes in the instruction-decoding MPX functions. * Now user_64bit_mode(regs) is used instead of test_thread_flag(TIF_IA32) to determine if the task is 32-bit or 64-bit. * Found and fixed a bug in insn-decoder in which X86_MODRM_RM was incorrectly used to obtain the mod part of the ModRM byte. * Added more explanatory code in emulation and instruction decoding code. This includes a comment regarding that copy_from_user could fail if there exists a memory protection key in place. * Tested code with CONFIG_X86_DECODER_SELFTEST=y and everything passes now. * Prefixed get_reg_offset_rm with insn_ as this function is exposed via a header file. For clarity, this function was added in a separate patch. Changes since V1: * Virtual-8086 mode tasks are not treated in a special manner. All code for this purpose was removed. * Instead of attempting to disable UMIP during a context switch or when entering virtual-8086 mode, UMIP remains enabled all the time. General protection faults that occur are fixed-up by returning dummy values as detailed above. * Removed umip= kernel parameter in favor of using clearcpuid=514 to disable UMIP. * Removed selftests designed to detect the absence of SIGSEGV signals when running in virtual-8086 mode. * Reused code from MPX to decode instructions operands. For this purpose code was put in a common location. * Fixed two bugs in MPX code that decodes operands. Ricardo Neri (21): x86/mpx: Use signed variables to compute effective addresses x86/mpx: Do not use SIB index if index points to R/ESP x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0 x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel x86/insn-eval: Add utility functions to get register offsets x86/insn-eval: Add utility functions to get segment selector x86/insn-eval: Add utility function to get segment descriptor x86/insn-eval: Add utility function to get segment descriptor base address x86/insn-eval: Add functions to get default operand and address sizes x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero insn/eval: Incorporate segment base in address computation x86/insn: Support both signed 32-bit and 64-bit effective addresses x86/insn-eval: Add support to resolve 16-bit addressing encodings x86/insn-eval: Add wrapper function for 16-bit and 32-bit address encodings x86/mm: Relocate page fault error codes to traps.h x86/cpufeature: Add User-Mode Instruction Prevention definitions x86: Add emulation code for UMIP instructions x86/umip: Force a page fault when unable to copy emulated result to user x86/traps: Fixup general protection faults caused by UMIP x86: Enable User-Mode Instruction Prevention selftests/x86: Add tests for User-Mode Instruction Prevention arch/x86/Kconfig | 10 + arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/disabled-features.h | 8 +- arch/x86/include/asm/insn-eval.h | 23 + arch/x86/include/asm/traps.h | 18 + arch/x86/include/asm/umip.h | 15 + arch/x86/include/uapi/asm/processor-flags.h | 2 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/cpu/common.c | 16 +- arch/x86/kernel/traps.c | 4 + arch/x86/kernel/umip.c | 298 +++++++++ arch/x86/lib/Makefile | 2 +- arch/x86/lib/insn-eval.c | 832 ++++++++++++++++++++++++++ arch/x86/mm/fault.c | 88 ++- arch/x86/mm/mpx.c | 120 +--- tools/testing/selftests/x86/entry_from_vm86.c | 39 +- 16 files changed, 1301 insertions(+), 176 deletions(-) create mode 100644 arch/x86/include/asm/insn-eval.h create mode 100644 arch/x86/include/asm/umip.h create mode 100644 arch/x86/kernel/umip.c create mode 100644 arch/x86/lib/insn-eval.c -- 2.9.3

7 109

Re: ntdll: Use environment variable "WINESERVER" first on search for wineserver to start.
by Ralf Habacker April 28, 2017

April 28, 2017

Am 07.03.2017 um 15:20 schrieb Sebastian Lackner: > Was it intentional that you did not CC the wine-devel mailing list? no, I Just replyed to all; fixed that > > On 07.03.2017 10:22, Ralf Habacker wrote: >> In the opposite having wineserver environment variable set in users >> environment will make it sure to always starts wineserver with the >> requested settings. > Well, you could also change $PATH globally to let "wine" point to your > special wrapper executable. This would not really be different from using > a global WINESERVER variable. Really ? Adding an additional path looks more invasive in terms of security and maintenance as using a dedicated environment variable affecting only one executable. > > I think there is a misunderstanding here, each wineprefix uses its own > wineserver instance. Wineservers started for other prefixes will never > inherit any timeout settings. Thanks for this pointer, I wasn't aware of that. >> [...] >> >> With the mentioned patch applied to a local wine build (or with a >> renamed wineserver) the site now runs about two weeks and one noticable >> change is that the initial >> mentioned communication issue did not happens. This let me think that >> there may be a long time running issue with wineserver, which affects >> the dde interface. > It is nice that you have found a workaround, however we would also like > to fix such issues of course. If you find any way to trigger this issue, > please file a bug report. I will do but unfortunally I'm not at this point yet. Observations from the last weeks shows that the error happened two times: 1. wineserver is running 12 days and not restarted because one application showed a message box, therefore did not quit and blocked wineserver restart, which let other wine applications dde communication fail 20170309-061102.523831920: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> last wineserver restart 20170321-150057.967117185: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> manual restarted because of application freeze 2. wineserver is running 3 days and applications dde communications fails because wineserver has been restarted immediatly 20170322-061003.064358739: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> last restart .... 20170325-220751 -> print job starts 20170325-220753.202518273: starting '/srv/www/gauszweb-prod/tools/usr/bin/wineserver --foreground --persistent=3600 ' -> wineserver has been restarted by timeout 20170325-220805 applications dde communication fails and wine reports wine: chdir to /tmp/.wine-37002/server-fd0a-9602cwine: : No such file or directory chdir to /tmp/.wine-37002/server-fd0a-9602c : No such file or directoryThis is expected and not a bug. It can happen when multiple wine > instances try to start up wineserver at the same time. Only the first > wineserver instance will be able to acquire the lock, all others will > exit and then connect to the existing wineserver. Sound reasonable Best regards Ralf

1 1

`setupapi` patch from staging
by Donat Enikeev April 24, 2017

April 24, 2017

Hi Guys, Number of recent well-known games are based on Starling game engine (Adobe Air+Stage3D for gpu rendering), such as: The Banner Saga 2, Samorost 3, The Inner World, Angry Birds. They are are falling into Software rendering mode on plain Wine and thus barely playable (bug #41635) Thanks to Béla Gyebrószki finding @ bug #41653, Wine makes these games consider d3d9 rendering with the following single patch from wine-staging https://github.com/wine-compholio/wine-staging/blob/master/patches/setupapi… This patch implements support of the case when a full driver path is passed to SetupDiGetClassDevs (trace successfully reaching AddDeviceToSet for a game below [1]). I was unable to find @wine-devel discussion around this patch, I would be grateful if one could kindly remind why it was staged, probably it just requires refactoring around the change or additional tests? I am asking this, because Adobe stopped Linux support for the Air years ago and we could never see such games ported, and therefore plain Wine's support of gpu acceleration for such games looks important. Thanks in advance Best regards, Donnie [1] 0009:trace:setupapi:SetupDiGetClassDevsExW {4d36e968-e325-11ce-bfc1-08002be10318} L"PCI\\VEN_0000&DEV_0000" (nil) 0x0000000a (nil) (null) (nil) 0009:warn:setupapi:SetupDiGetClassDevsExW unsupported flags 0000000a 0009:trace:setupapi:SetupDiCreateDeviceInfoListExW {4d36e968-e325-11ce-bfc1-08002be10318} (nil) (null) (nil) 0009:trace:setupapi:SETUPDI_EnumerateDevices 0x464ac90, {4d36e968-e325-11ce-bfc1-08002be10318}, L"PCI\\VEN_0000&DEV_0000", 0000000a 0009:trace:setupapi:SETUPDI_EnumerateMatchingDeviceInstances L"PCI" L"VEN_0000&DEV_0000" 0009:trace:setupapi:SETUPDI_AddDeviceToSet 0x464ac90, {4d36e968-e325-11ce-bfc1-08002be10318}, 0, L"PCI\\VEN_0000&DEV_0000\\13&12345&0", 0

3 6

Re: [PATCH] comctl32/taskdialog: Implement buttons.
by Nikolay Sivov April 23, 2017

April 23, 2017

On 23.03.2017 21:22, Fabian Maurer wrote: > Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> > --- > dlls/comctl32/taskdialog.c | 224 ++++++++++++++++++++++++++++++++------------- > 1 file changed, 161 insertions(+), 63 deletions(-) > > diff --git a/dlls/comctl32/taskdialog.c b/dlls/comctl32/taskdialog.c > index 6b8bcfcae6..037b85e082 100644 > --- a/dlls/comctl32/taskdialog.c > +++ b/dlls/comctl32/taskdialog.c > @@ -41,10 +41,13 @@ WINE_DEFAULT_DEBUG_CHANNEL(taskdialog); > #define ALIGN_LENGTH(_Len, _Align) _Len = ALIGNED_LENGTH(_Len, _Align) > #define ALIGN_POINTER(_Ptr, _Align) _Ptr = ALIGNED_POINTER(_Ptr, _Align) > > -static const UINT DIALOG_MIN_WIDTH = 180; > +static const UINT DIALOG_MIN_WIDTH = 240; > static const UINT DIALOG_SPACING = 5; > -static const UINT DIALOG_BUTTON_WIDTH = 50; > -static const UINT DIALOG_BUTTON_HEIGHT = 14; > +static const UINT DIALOG_BUTTON_WIDTH_MIN = 45; > +static const UINT DIALOG_BUTTON_HEIGHT = 13; This was taken from MSGBOX template, what's a point in making it different? > +static const UINT DIALOG_SPACING_BUTTONS_LEFT = 30; /* minimum distance from the left dialog border */ > +static const UINT DIALOG_SPACING_BUTTON_H = 1; /* Distance between buttons */ > +static const UINT DIALOG_SPACING_BUTTON_W = 4; /* Distance between buttons */ > > static const UINT ID_MAIN_INSTRUCTION = 0xf000; > > @@ -67,6 +70,15 @@ struct taskdialog_template_desc > HFONT font; > }; > > +typedef struct > +{ > + int id; > + const WCHAR *text; > + UINT width; > + UINT x; > + UINT y; > +} button_info; > + > static void pixels_to_dialogunits(const struct taskdialog_template_desc *desc, LONG *width, LONG *height) > { > if (width) > @@ -83,6 +95,44 @@ static void dialogunits_to_pixels(const struct taskdialog_template_desc *desc, L > *height = MulDiv(*height, desc->y_baseunit, 8); > } > > +/* used to calculate size for the controls */ > +static RECT text_get_rect(const struct taskdialog_template_desc *desc, const WCHAR *text) > +{ > + const WCHAR *textW = NULL; > + unsigned int length; > + HFONT oldfont; > + HDC hdc; > + static const WCHAR nulW; > + RECT rect = { 0, 0, desc->dialog_width - DIALOG_SPACING * 2, 0}; /* padding left and right of the control */ > + > + if (IS_INTRESOURCE(text)) > + { > + if (!(length = LoadStringW(desc->taskconfig->hInstance, (UINT_PTR)text, (WCHAR *)&textW, 0))) > + { > + WARN("Failed to load text\n"); > + textW = &nulW; > + length = 0; > + } > + } > + else > + { > + textW = text; > + length = strlenW(textW); > + } > + > + hdc = GetDC(0); > + oldfont = SelectObject(hdc, desc->font); > + > + dialogunits_to_pixels(desc, &rect.right, NULL); > + DrawTextW(hdc, textW, length, &rect, DT_LEFT | DT_EXPANDTABS | DT_CALCRECT | DT_WORDBREAK); > + pixels_to_dialogunits(desc, &rect.right, &rect.bottom); > + > + SelectObject(hdc, oldfont); > + ReleaseDC(0, hdc); > + > + return rect; > +} > + Did you test that buttons are supposed to support multiple lines of text? > static void template_write_data(char **ptr, const void *src, unsigned int size) > { > memcpy(*ptr, src, size); > @@ -90,7 +140,7 @@ static void template_write_data(char **ptr, const void *src, unsigned int size) > } > > static unsigned int taskdialog_add_control(struct taskdialog_template_desc *desc, WORD id, const WCHAR *class, > - HINSTANCE hInstance, const WCHAR *text, short x, short y, short cx, short cy) > + DWORD style, HINSTANCE hInstance, const WCHAR *text, short x, short y, short cx, short cy) > { > struct taskdialog_control *control = Alloc(sizeof(*control)); > unsigned int size, class_size, text_size; > @@ -117,7 +167,7 @@ static unsigned int taskdialog_add_control(struct taskdialog_template_desc *desc > control->template = template = Alloc(size); > control->template_size = size; > > - template->style = WS_VISIBLE; > + template->style = WS_VISIBLE | WS_CHILD | style; You don't use styles in this patch, this is unnecessary change. > template->dwExtendedStyle = 0; > template->x = x; > template->y = y; > @@ -136,78 +186,126 @@ static unsigned int taskdialog_add_control(struct taskdialog_template_desc *desc > > static unsigned int taskdialog_add_main_instruction(struct taskdialog_template_desc *desc) > { > - RECT rect = { 0, 0, desc->dialog_width - DIALOG_SPACING * 2, 0}; /* padding left and right of the control */ > - const WCHAR *textW = NULL; > - unsigned int size, length; > - HFONT oldfont; > - HDC hdc; > + unsigned int size; > + RECT rect; > > if (!desc->taskconfig->pszMainInstruction) > return 0; > > - if (IS_INTRESOURCE(desc->taskconfig->pszMainInstruction)) > - { > - if (!(length = LoadStringW(desc->taskconfig->hInstance, (UINT_PTR)desc->taskconfig->pszMainInstruction, > - (WCHAR *)&textW, 0))) > - { > - WARN("Failed to load main instruction text\n"); > - return 0; > - } > - } > - else > - { > - textW = desc->taskconfig->pszMainInstruction; > - length = strlenW(textW); > - } > - > - hdc = GetDC(0); > - oldfont = SelectObject(hdc, desc->font); > - > - dialogunits_to_pixels(desc, &rect.right, NULL); > - DrawTextW(hdc, textW, length, &rect, DT_LEFT | DT_EXPANDTABS | DT_CALCRECT | DT_WORDBREAK); > - pixels_to_dialogunits(desc, &rect.right, &rect.bottom); > - > - SelectObject(hdc, oldfont); > - ReleaseDC(0, hdc); > + rect = text_get_rect(desc, desc->taskconfig->pszMainInstruction); > > - size = taskdialog_add_control(desc, ID_MAIN_INSTRUCTION, WC_STATICW, desc->taskconfig->hInstance, > + size = taskdialog_add_control(desc, ID_MAIN_INSTRUCTION, WC_STATICW, 0, desc->taskconfig->hInstance, > desc->taskconfig->pszMainInstruction, DIALOG_SPACING, desc->dialog_height, > rect.right, rect.bottom); > - desc->dialog_height += rect.bottom; > + desc->dialog_height += rect.bottom + DIALOG_SPACING; > return size; > } > > -static unsigned int taskdialog_add_common_buttons(struct taskdialog_template_desc *desc) > +static button_info make_button(struct taskdialog_template_desc *desc, int id, const WCHAR *text) > +{ > + RECT rect; > + button_info button; > + > + button.id = id; > + button.text = text; > + rect = text_get_rect(desc, text); > + button.width = rect.right + 10; > + if (button.width < DIALOG_BUTTON_WIDTH_MIN) > + button.width = DIALOG_BUTTON_WIDTH_MIN; > + > + return button; > +} This does not handle "text" correctly. > + > +static unsigned int taskdialog_add_buttons(struct taskdialog_template_desc *desc) > { > - short button_x = desc->dialog_width - DIALOG_BUTTON_WIDTH - DIALOG_SPACING; > DWORD flags = desc->taskconfig->dwCommonButtons; > + const TASKDIALOGCONFIG *taskconfig = desc->taskconfig; > + UINT alignment = DIALOG_SPACING_BUTTONS_LEFT; /* minimum distance from the left dialog border */ > + UINT location_x; > + BOOL first_row = TRUE; > + button_info *buttons; > + int count = 0; > + int i; > unsigned int size = 0; > > -#define TASKDIALOG_ADD_COMMON_BUTTON(id) \ > - do { \ > - size += taskdialog_add_control(desc, ID##id, WC_BUTTONW, COMCTL32_hModule, MAKEINTRESOURCEW(IDS_BUTTON_##id), \ > - button_x, desc->dialog_height + DIALOG_SPACING, DIALOG_BUTTON_WIDTH, DIALOG_BUTTON_HEIGHT); \ > - button_x -= DIALOG_BUTTON_WIDTH + DIALOG_SPACING; \ > - } while(0) > - if (flags & TDCBF_CLOSE_BUTTON) > - TASKDIALOG_ADD_COMMON_BUTTON(CLOSE); > - if (flags & TDCBF_CANCEL_BUTTON) > - TASKDIALOG_ADD_COMMON_BUTTON(CANCEL); > - if (flags & TDCBF_RETRY_BUTTON) > - TASKDIALOG_ADD_COMMON_BUTTON(RETRY); > - if (flags & TDCBF_NO_BUTTON) > - TASKDIALOG_ADD_COMMON_BUTTON(NO); > - if (flags & TDCBF_YES_BUTTON) > - TASKDIALOG_ADD_COMMON_BUTTON(YES); > + /* Allocate enough memory for the custom and the default buttons */ > + if (taskconfig->cButtons && taskconfig->pButtons) > + buttons = HeapAlloc(GetProcessHeap(), 0, (taskconfig->cButtons + 6) * sizeof(button_info)); > + else > + { > + buttons = HeapAlloc(GetProcessHeap(), 0, 6 * sizeof(button_info)); > + } > + > + /* Custom buttons */ > + if (taskconfig->cButtons && taskconfig->pButtons) > + { > + for (i = 0; i < taskconfig->cButtons; i++) > + { > + buttons[count++] = make_button(desc, taskconfig->pButtons[i].nButtonID, taskconfig->pButtons[i].pszButtonText); > + } > + } > + > + /* Default buttons */ > if (flags & TDCBF_OK_BUTTON) > - TASKDIALOG_ADD_COMMON_BUTTON(OK); > - /* Always add OK button */ > - if (list_empty(&desc->controls)) > - TASKDIALOG_ADD_COMMON_BUTTON(OK); > -#undef TASKDIALOG_ADD_COMMON_BUTTON > - > - /* make room for common buttons row */ > - desc->dialog_height += DIALOG_BUTTON_HEIGHT + 2 * DIALOG_SPACING; > + buttons[count++] = make_button(desc, IDOK, MAKEINTRESOURCEW(IDS_BUTTON_OK)); > + if (flags & TDCBF_YES_BUTTON) > + buttons[count++] = make_button(desc, IDYES, MAKEINTRESOURCEW(IDS_BUTTON_YES)); > + if (flags & TDCBF_NO_BUTTON) > + buttons[count++] = make_button(desc, IDNO, MAKEINTRESOURCEW(IDS_BUTTON_NO)); > + if (flags & TDCBF_RETRY_BUTTON) > + buttons[count++] = make_button(desc, IDRETRY, MAKEINTRESOURCEW(IDS_BUTTON_RETRY)); > + if (flags & TDCBF_CANCEL_BUTTON) > + buttons[count++] = make_button(desc, IDCANCEL, MAKEINTRESOURCEW(IDS_BUTTON_CANCEL)); > + if (flags & TDCBF_CLOSE_BUTTON) > + buttons[count++] = make_button(desc, IDCLOSE, MAKEINTRESOURCEW(IDS_BUTTON_CLOSE)); > + > + /* There must be at least one button */ > + if (count == 0) > + buttons[count++] = make_button(desc, IDOK, MAKEINTRESOURCEW(IDS_BUTTON_OK)); > + > + /* Position buttons */ > + location_x = alignment; > + for (i = 0; i < count; i++) > + { > + /* When beginning new row, align the first */ > + if (location_x + buttons[i].width + DIALOG_SPACING_BUTTON_W > desc->dialog_width) > + { > + if (first_row) > + { > + int diff = desc->dialog_width - location_x; > + > + first_row = FALSE; > + for (int j = 0; j < i; j++) /* Align first row to the right */ > + buttons[j].x += diff; > + alignment = buttons[0].x; /* left-align all coming rows to the first row */ > + } > + location_x = alignment; > + desc->dialog_height += DIALOG_BUTTON_HEIGHT + DIALOG_SPACING_BUTTON_H; > + } > + > + buttons[i].x = location_x; > + buttons[i].y = desc->dialog_height; > + > + location_x += buttons[i].width + DIALOG_SPACING_BUTTON_W; > + } > + if (first_row) /* Always align first row to the right */ > + { > + int diff = desc->dialog_width - (buttons[count - 1].x + buttons[count - 1].width + DIALOG_SPACING_BUTTON_W); > + for (int i = 0; i < count; i++) > + buttons[i].x += diff; > + } I don't like this. Why do you need temporary array, and iterating twice seems excessive. > + > + /* Now that we got them all positioned, create all buttons */ > + for (i = 0; i < count; i++) > + { > + size += taskdialog_add_control(desc, buttons[i].id, WC_BUTTONW, BS_PUSHBUTTON, COMCTL32_hModule, > + buttons[i].text, buttons[i].x, buttons[i].y, buttons[i].width, DIALOG_BUTTON_HEIGHT); > + } This won't work for custom buttons. > + > + /* Add height for last row and spacing */ > + desc->dialog_height += DIALOG_BUTTON_HEIGHT + DIALOG_SPACING; > + > + HeapFree(GetProcessHeap(), 0, buttons); > return size; > } > > @@ -295,7 +393,7 @@ static DLGTEMPLATE *create_taskdialog_template(const TASKDIALOGCONFIG *taskconfi > desc.dialog_width = min(desc.dialog_width, screen_width); > > size += taskdialog_add_main_instruction(&desc); > - size += taskdialog_add_common_buttons(&desc); > + size += taskdialog_add_buttons(&desc); I'd rather have it separated if possible. I'll do some testing myself, before commenting further. > > template = Alloc(size); > if (!template) >

2 8

Re: [v2 1/2] d3dx9: Support relative addressing in preshader.
by Matteo Bruni April 10, 2017

April 10, 2017

2017-03-24 23:12 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > @@ -697,13 +739,13 @@ static HRESULT parse_preshader(struct d3dx_preshader *pres, unsigned int *ptr, u > for (i = 0; i < pres->ins_count; ++i) > { > for (j = 0; j < pres_op_info[pres->ins[i].op].input_count; ++j) > - update_table_size(pres->regs.table_sizes, pres->ins[i].inputs[j].table, > - get_reg_offset(pres->ins[i].inputs[j].table, > - pres->ins[i].inputs[j].offset + pres->ins[i].component_count - 1)); > + update_table_size(pres->regs.table_sizes, pres->ins[i].inputs[j].reg.table, > + get_reg_offset(pres->ins[i].inputs[j].reg.table, > + pres->ins[i].inputs[j].reg.offset + pres->ins[i].component_count - 1)); > > - update_table_size(pres->regs.table_sizes, pres->ins[i].output.table, > - get_reg_offset(pres->ins[i].output.table, > - pres->ins[i].output.offset + pres->ins[i].component_count - 1)); > + update_table_size(pres->regs.table_sizes, pres->ins[i].output.reg.table, > + get_reg_offset(pres->ins[i].output.reg.table, > + pres->ins[i].output.reg.offset + pres->ins[i].component_count - 1)); Do these update_table_size() always do the right thing with relative addressing? If I'm not mistaken, they should be fine because we only accept relative addressing for CONST and IMMED and the former is taken care by update_table_sizes_consts() just below while the latter's size is set statically just above this chunk. I think that means though that we don't need to call update_table_size() on the input arguments. If that sounds right to you, you could drop that "for(j)" altogether or, probably better, replace the update_table_size() with a check that the argument is not out of bounds (probably returning failure if the check doesn't pass). That should be a separate patch. > @@ -1088,18 +1130,65 @@ static HRESULT init_set_constants(struct d3dx_const_tab *const_tab, ID3DXConstan > return ret; > } > > +static double exec_get_reg_value(struct d3dx_regstore *rs, enum pres_reg_tables table, unsigned int offset) > +{ > + if (!regstore_is_val_set_reg(rs, table, offset / table_info[table].reg_component_count)) > + WARN("Using uninitialized input, table %u, offset %u.\n", table, offset); > + > + return regstore_get_double(rs, table, offset); > +} > + > static double exec_get_arg(struct d3dx_regstore *rs, const struct d3dx_pres_operand *opr, unsigned int comp) > { > - if (!regstore_is_val_set_reg(rs, opr->table, (opr->offset + comp) / table_info[opr->table].reg_component_count)) > - WARN("Using uninitialized input, table %u, offset %u.\n", opr->table, opr->offset + comp); > + unsigned int offset, base_index, reg_index, table; > + > + table = opr->reg.table; > + > + if (opr->index_reg.table == PRES_REGTAB_COUNT) > + base_index = 0; > + else > + base_index = lrint(exec_get_reg_value(rs, opr->index_reg.table, opr->index_reg.offset)); > + > + /* '4' is used instead of reg_component_count, as immediate constants (which have > + * reg_component_count of 1) are still indexed as 4 values according to the tests. > + */ > + offset = base_index * 4 + opr->reg.offset + comp; Actually, is there any reason why reg_component_count for PRES_REGTAB_IMMED isn't 4? Maybe change it to 4 and in parse_preshader() check that const_count is a multiple of 4 (which is something we're depending on anyway). That would be a separate patch too. Clue me if I'm missing anything. > + reg_index = offset / table_info[table].reg_component_count; > + > + if (reg_index >= rs->table_sizes[table]) > + { > + unsigned int wrap_size; > + > + if (table == PRES_REGTAB_CONST) > + { > + /* As it can be guessed from tests (by iterating base register value and > + * observing the period of result values repeat), offset into floating > + * constant table are wrapped to the nearest power of 2 and not to the > + * actual table size. > + */ > + for (wrap_size = 1; wrap_size < rs->table_sizes[table]; wrap_size <<= 1) > + ; Please close the comment on the last text line (i.e. "*/" shouldn't be on its own line) and maybe remove the part in parentheses which is pretty obvious. I like the comment otherwise. Another thing on this, maybe add a WARN() on wrapped accesses to show what offset (or value) is returned in that case? Ignore it if you don't think that's useful.

2 9

wine-2.0.1-rc1 Available
by Michael Stefaniuc April 4, 2017

April 4, 2017

Hello guys, I have pushed wine-2.0.1-rc1 (with tag) to https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ Nothing particularly special in this release. Slow start into 2.0.x due to lack of time on my side as well as to give the more risky patches some more time to burn in. Same old, same old: one week for feedback followed by another rc if needed with the final release 3-4 days later. And now the interesting parts from the ANNOUNCE file: What's new in this release (see below for details): - Various bug fixes - Deprecated tools/wineinstall ---------------------------------------------------------------- Bugs fixed in 2.0.1 (total 47): 14897 DirectDraw games (Jojo's Fashion Show 2: Las Cruces demo, The Chosen: Well of Souls) try to lock surface with invalid dwSize 14939 Black & White: DXTC to ARGB converter not implemented 17495 Open dialog crashes if the desktop folder is at a Unicode path that cannot be represented in the current locale 18477 Need For Speed Most Wanted crashes after accepting video settings changes 19888 Venom Codename: Outbreak - initial menu screen is black (no menu items) 25700 MessageBox does not display last word if string contains '&' (ampersand) 26603 iMesh 10 crashes at startup (needs wmvcore.dll.WMCreateReaderPriv) 27580 Wine Notepad command line parser eats the first 2 letters when the path starts with / (it should only do this for valid command line options) 30308 Property sheet fails to display Page Title 35993 Graphical Glitches in Agarest Generations of War 38354 Multiple games and applications need msvcr120.dll._except1 (Audacity 2.1.0, Tera Online) 38485 New Marvel Heroes 2015 Launcher crashes on unimplemented function dhcpcsvc.dll.DhcpRequestParams 39048 MIDI Clock Messages are Corrupted Between Wine and ALSA 39920 Nanocad 5.: file open/import dialog does not open 40392 ComicRack 0.9.x (.NET 4.5 app) hangs/crashes on startup when executing WMI query 40938 UE4 games (Ether One Redux, Into the Stars) crash while loading with "BackBuffer->GetResource() has 3 refs, expected 1" error 40952 improper escaping of quotes in command line 41448 Civilization II Unhandled page fault on read access 41579 Rush for Berlin Gold crashes after the intro videos 41623 Odallus The Dark Call crashes while starting if a force feedback enabled controller is plugged in 41648 AmiBroker 6.00 fails, when run, with raise_exception Unhandled exception 41725 Unimplemented function api-ms-win-crt-math-l1-1-0.dll._except1 (Starcraft 2 main menu, Firefox) 41830 Updating group box text causes garbage 41926 Zafehouse demo crashes with Call from 0x7b43c14c to unimplemented function ddraw.dll.GetSurfaceFromDC, aborting 42001 SC2 unimplemented function ucrtbase.dll._except1 42022 The Magic School Bus Explores The Solar System needs msvideo.dll16.DRAWDIBPROFILEDISPLAY 42023 The Magic School Bus Explores The Solar System crashes on launch; appears to be missing some files 42078 Dungeons & Dragons: Chronicles of Mystara needs d3dx11_43.dll.D3DX11CreateShaderResourceViewFromMemory 42093 Git for Windows 2.7.0 needs unimplemented function rstrtmgr.dll.RmShutdown 42094 winamp needs unimplemented function ntoskrnl.exe.IoStopTimer 42096 Steam -> RPGMaker 2003 needs unimplemented function KERNEL32.dll.BaseFlushAppcompatCache 42159 Sega Bug crashes immediately 42212 WOLF RPG Editor: Division by zero when winegstreamer is enabled 42218 mshtml/tests/dom crashes in xul while running test_doc_elem 42244 QQ 2013 needs ntoskrnl.exe.IoCreateFile 42245 QQ 2013 needs ntoskrnl.exe.KeClearEvent 42257 Warpath 21st Century does not have sound 42303 Magic: The Gathering Online 4.0 crashes when entering the battle 42306 One Note Free Retail installer crashes in xmllite 42315 Piriform Speccy 1.3 needs setupapi.dll.CM_Get_Child_Ex 42361 DX Library: PlaySoundFile() doesn't play MP3 files with specific extra headers 42365 Unimplemented function msvcr120.dll.fesetenv 42367 KiriKiri Z based games: main screen doesn't update. 42469 GetOpenFileName should expand environment variables in lpstrInitialDir 42483 Build for Ubuntu Precise fails because MPG123_IGNORE_INFOFRAME is undeclared 42557 NVIDIA GeForce GT 525M detected as GeForce GTX 470 42567 Acid Pro Trial 7.0e fails to install ---------------------------------------------------------------- Changes since 2.0: Adam Bolte (1): wined3d: Add GPU information for AMD FIJI. Akihiro Sagawa (3): d3d9/tests: Add LockRect tests with dynamic textures. d3d8/tests: Add LockRect tests with dynamic textures. wined3d: Upload textures if NO_DIRTY_UPDATE flag is set when locking dynamic textures. Alex Henrie (3): ddraw: Don't crash if writing out a new ddraw1 surface segfaults. comdlg32: Don't crash if an IShellFolder could not be created. user32: Include space for ampersands when determining MessageBox size. Alexandre Julliard (1): make_announce: Update version number parsing for the new versioning scheme. Alistair Leslie-Hughes (1): include: Add dhcpcsdk.h. Andrew Wesie (1): ntdll: Read entry point in LdrInitializeThunk. Andrey Gusev (2): setupapi: Add CM_Get_Child_Ex stub. d3dx11: Add D3DX11CreateShaderResourceViewFromMemory stub. Anton Romanov (1): user32: Add OCR_RDR* cursors. Austin English (6): ntoskrnl.exe: Add IoCreateFile stub. ntoskrnl.exe: Add stub KeClearEvent. kernel32: Add BaseFlushAppcompatCache stub. rstrtmgr: Add RmShutdown stub. dhcpsvc: Add DhcpRequestParams stub. readme: Remove wineinstall. Bruno Jesus (8): winmm: Fix the ordinal number for function PlaySound. dinput: DISFFC_RESET will not release the effects. notepad: Only skip valid command options. winemp3.acm: Ignore XING headers when parsing MP3 files. winemp3.acm: Fixes compilation for older mpg123 library versions. winealsa.drv: Fix handling of system real time MIDI messages. wined3d: Recognize Geforce GT 525M. wined3d: Recognize GeForce 940M. Can Taşan (3): wine.desktop: Add Turkish translation. kernel32: Add Unicode character for Turkish lira. documentation: Update Turkish translation. Christoph Brill (1): setupapi: Stub CM_Open_DevNode_Key and CM_Get_Child. Daniel Lehman (1): msvcrt: Implement nan. Dmitry Timoshkov (4): avifil32: AVIFileGetStream should set stream to NULL in case of an error. user32: BUTTON_CalcLabelRect should use the button font. user32: Fix groupbox rectangle calculation in the button's WM_SETTEXT handler. kernel32: Replace Peb->BeingDebugged check by CheckRemoteDebuggerPresent(). Fabian Maurer (1): msvcr120: Add fesetenv stub. François Gouget (3): readme: Note that Wine may also use Mac APIs. readme: Adjust a couple of section separators. readme: Update and rewrap the French translation. Gerald Pfeifer (1): winedump: Increase buffer size and potential string length inoutput_spec_symbol. Hans Leidekker (1): wbemprox: Only include matching rows in the table row count. Henri Verbeet (5): ddraw/tests: Rewrite GetDCTest(). ddraw: Implement GetSurfaceFromDC(). ddraw: Kill stray tabs. wined3d: Allow decompression blits on system memory resources in arbfp_blit_supported(). wined3d: Disallow upload conversion from compressed formats in surface_convert_format(). Jacek Caban (1): mshtml: Initialize nsAString in IHTMLDocument3::get_dir. Jacob Lifshay (1): kernel32: Fix improper escaping of quotes in command line. Jarkko Korpi (1): ntoskrnl: Add IoStopTimer stub. Jefferson Carpenter (1): wmvcore: Implement WMCreateReaderPriv. Julian Rüger (2): readme: Update German translation. readme: Fix typo in German translation. Józef Kucia (6): d3d11/tests: Add tests showing that views do not keep resource reference. d3d11: Do not keep reference to resources. ddraw: Relax "dwSize" validation in ddraw_surface*_Lock(). ddraw: Implement D3DOP_TEXTURELOAD. ddraw/tests: Add basic test for D3DOP_TEXTURELOAD. d3d9: Do not decrease swapchain surface refcount when it is already 0. Lauri Kenttä (2): readme: Update Finnish translation. readme: Update Swedish translation. Louis Lenders (2): xmllite/reader: Handle NULL node type argument in Read(). wmvcore: Add version resource. Masanori Kakura (1): winegstreamer: Avoid zero division in amt_from_gst_caps_video(). Matteo Bruni (1): d3d9: Fix DrawIndexedPrimitiveUP with non-zero min_vertex_idx. Michael Müller (2): msvideo.dll16: Implement DrawDibProfileDisplay. msvideo.dll16: Check if any 16 bit thunks have been allocated before accessing pointer. Michael Stefaniuc (1): tools: Get the ANNOUNCE bug list from the stable-notes git notes. Nikolay Sivov (5): comdlg32: Always use original Open File dialog template. comctl32/propsheet: Force wizard header if any of pages has title/subtitle. comctl32/propsheet: Only use header bitmap when asked for it. comdlg32: Expand initial directory path for file open dialog. readme: Update Russian translation. Piotr Caban (2): msvcrt: Add fesetenv implementation. msvcr120: Add _except1 implementation. Zebediah Figura (7): storage.dll16: Fix bad type in IStorage16_fnOpenStorage. winebuild: Use unsigned int in spec file variable parameters. compobj: Implement several IIDs. ole2: Implement several IIDs. avifile: Implement several IIDs. ole2disp: Implement several IIDs. typelib: Implement several IIDs. -- Michael Stefaniuc mstefani(a)winehq.org

4 4

APPDB Intro email
by Bijie Zhu April 3, 2017

April 3, 2017

Hi,My name is Bijie Zhu and I am currently a computer science student studying at City University of New York - Queens College. This is my first time participate in an open source project, and I hope I can get some guidance and feedback for the outreach project application process. I want to apply for improving APPDB website project. And I want to improve the app voting system. I would like to design an evaluation metric system for the app voting. So when people votes, we know why they vote for the app. People now can not only search for the most voted app, but also search for the app with the most desired attributes. Thank you,Bijie Zhu

2 1

Re: [PATCH] wmvcore: Add WMReader stubs.
by Alistair Leslie-Hughes March 31, 2017

March 31, 2017

Hi Jefferson, On 30/03/17 10:18, Jefferson Carpenter wrote: > > I have not written unit tests for this code. I would like to add some > wmvcore tests, but am not very familiar with Wine's build system > autotools, and have not been able to get tests to compile and run. > I have a basic patch for adding tests in the works, but I was waiting for my IDL changes to be accepted first. So, If someone wants to review the IDL changes, Since Sebastian has been busy with other stuff. https://source.winehq.org/patches/data/131403 > > Signed-off-by: Jefferson Carpenter > --- > dlls/wmvcore/wmvcore_main.c | 1234 +++++++++++++++++++++++++++++++++++++++++++ > +static HRESULT WINAPI WMHeaderInfo_GetScriptCount(IWMHeaderInfo3 *iface, WORD *pcScripts) > +{ > + WMReader *This = impl_from_IWMHeaderInfo3(iface); > + FIXME("(%p)->(WMHeaderInfo_GetScriptCount)\n", This); This is incorrect. The FIXME will insert the function name into the logs. You need to specify each parameter in the FIXME, there are plenty of examples of how to do this. Best Regards Alistair Leslie-Hughes

3 3

Re: [PATCH 2/2] regedit: Handle comment lines with leading spaces and tabs
by Alexandre Julliard March 31, 2017

March 31, 2017

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > programs/regedit/regproc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/programs/regedit/regproc.c b/programs/regedit/regproc.c > index 131149f..bce551b 100644 > --- a/programs/regedit/regproc.c > +++ b/programs/regedit/regproc.c > @@ -749,6 +749,7 @@ static char *get_lineA(FILE *fp) > next = line; > continue; > } > + while (*line == ' ' || *line == '\t') line++; > if (*line == ';' || *line == '#') > { > line = next; This is going to affect non-comment lines too, is that what you want? If so, the commit message is a bit misleading. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH 04/13] msvcrt: Add CurrentScheduler class stub
by Gijs Vermeulen March 31, 2017

March 31, 2017

Hi, I'm sorry if this is a stupid question. But shouldn't this also change: ?_Get(a)_CurrentScheduler@details(a)Concurrency@@SA?AV_Scheduler(a)23@XZ ?_GetNumberOfVirtualProcessors(a)_CurrentScheduler@details(a)Concurrency@@SAIXZ ?_Id(a)_CurrentScheduler@details(a)Concurrency@@SAIXZ -arch=win32 ?_ScheduleTask(a)_CurrentScheduler@details(a)Concurrency@ @SAXP6AXPAX(a)Z0@Z -arch=win64 ?_ScheduleTask(a)_CurrentScheduler@details(a)Concurrency@ @SAXP6AXPEAX(a)Z0@Z Or do these not do the same? Sorry if I'm wasting your time. Sincerely, Gijs 2017-03-30 22:47 GMT+02:00 Piotr Caban <piotr(a)codeweavers.com>: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/concrt140/concrt140.spec | 40 ++++++++--------- > dlls/msvcr100/msvcr100.spec | 28 ++++++------ > dlls/msvcr110/msvcr110.spec | 40 ++++++++--------- > dlls/msvcr120/msvcr120.spec | 40 ++++++++--------- > dlls/msvcr120_app/msvcr120_app.spec | 40 ++++++++--------- > dlls/msvcrt/scheduler.c | 88 ++++++++++++++++++++++++++++++ > +++++++ > 6 files changed, 182 insertions(+), 94 deletions(-) > > > > > >

2 1

Re: d3d10: sync spec file to Windows 10
by Henri Verbeet March 30, 2017

March 30, 2017

On 29 March 2017 at 23:51, Austin English <austinenglish(a)gmail.com> wrote: > -- We may not necessarily care, but RevertToOldImplementation() is the first export instead of the last on my Windows 10.

3 3

Re: [2/3] windowscodecs: Test for png codec seeking too far
by Vincent Povirk March 30, 2017

March 30, 2017

Is there a reason to switch to SHCreateMemStream to do this test in particular? If not, it would probably make more sense as a separate cleanup project. On Mon, Mar 27, 2017 at 3:09 PM, Viktor Semykin <thesame.ml(a)gmail.com> wrote: > Signed-off-by: Viktor Semykin <thesame.ml(a)gmail.com> > --- > dlls/windowscodecs/tests/Makefile.in | 2 +- > dlls/windowscodecs/tests/pngformat.c | 19 ++++++++++--------- > 2 files changed, 11 insertions(+), 10 deletions(-) > > diff --git a/dlls/windowscodecs/tests/Makefile.in b/dlls/windowscodecs/tests/Makefile.in > index e11d184..e006e3d 100644 > --- a/dlls/windowscodecs/tests/Makefile.in > +++ b/dlls/windowscodecs/tests/Makefile.in > @@ -1,5 +1,5 @@ > TESTDLL = windowscodecs.dll > -IMPORTS = windowscodecs oleaut32 ole32 user32 gdi32 > +IMPORTS = windowscodecs oleaut32 ole32 user32 gdi32 shlwapi > > C_SRCS = \ > bitmap.c \ > diff --git a/dlls/windowscodecs/tests/pngformat.c b/dlls/windowscodecs/tests/pngformat.c > index 34cb533..20b6e93 100644 > --- a/dlls/windowscodecs/tests/pngformat.c > +++ b/dlls/windowscodecs/tests/pngformat.c > @@ -25,6 +25,7 @@ > #include "windef.h" > #include "wincodec.h" > #include "wine/test.h" > +#include "shlwapi.h" > > /* 1x1 pixel PNG image */ > static const char png_no_color_profile[] = { > @@ -277,21 +278,16 @@ static IWICImagingFactory *factory; > > static IWICBitmapDecoder *create_decoder(const void *image_data, UINT image_size) > { > - HGLOBAL hmem; > - BYTE *data; > HRESULT hr; > IWICBitmapDecoder *decoder = NULL; > IStream *stream; > GUID format; > LONG refcount; > + ULARGE_INTEGER pos; > + LARGE_INTEGER zero; > > - hmem = GlobalAlloc(0, image_size); > - data = GlobalLock(hmem); > - memcpy(data, image_data, image_size); > - GlobalUnlock(hmem); > - > - hr = CreateStreamOnHGlobal(hmem, TRUE, &stream); > - ok(hr == S_OK, "CreateStreamOnHGlobal error %#x\n", hr); > + stream = SHCreateMemStream (image_data, image_size); > + ok(stream != NULL, "SHCreateMemStream error\n"); > > hr = IWICImagingFactory_CreateDecoderFromStream(factory, stream, NULL, 0, &decoder); > ok(hr == S_OK, "CreateDecoderFromStream error %#x\n", hr); > @@ -302,6 +298,11 @@ static IWICBitmapDecoder *create_decoder(const void *image_data, UINT image_size > ok(IsEqualGUID(&format, &GUID_ContainerFormatPng), > "wrong container format %s\n", wine_dbgstr_guid(&format)); > > + zero.QuadPart = 0; > + IStream_Seek (stream, zero, STREAM_SEEK_CUR, &pos); > + todo_wine ok(pos.QuadPart < image_size, "seek beyond the end of stream: %lu >= %u\n", > + pos.QuadPart, image_size); > + > refcount = IStream_Release(stream); > ok(refcount > 0, "expected stream refcount > 0\n"); > > -- > 2.12.1 > > >

2 3

Re: [PATCH 3/3] shlwapi/tests: A test to query ISequentialStream from memory stream
by Marvin March 30, 2017

March 30, 2017

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=29831 Your paranoid android. === wxppro (32 bit istream) === istream.c:44: Test failed: got 0x80004002 istream.c:45: Test failed: unexpected interface pointer 09f0:istream: unhandled exception c0000005 at 00405AEC === w2003std (32 bit istream) === istream.c:44: Test failed: got 0x80004002 istream.c:45: Test failed: unexpected interface pointer 05f0:istream: unhandled exception c0000005 at 00405AEC

1 0

Re: [PATCH 2/3] shlwapi: Fix QueryInterface for file-based streams
by Marvin March 30, 2017

March 30, 2017

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=29830 Your paranoid android. === wxppro (32 bit istream) === istream.c:44: Test failed: got 0x80004002 istream.c:45: Test failed: unexpected interface pointer 09ec:istream: unhandled exception c0000005 at 00405AEC === w2003std (32 bit istream) === istream.c:44: Test failed: got 0x80004002 istream.c:45: Test failed: unexpected interface pointer 05f0:istream: unhandled exception c0000005 at 00405AEC

1 0

Re: [PATCH] wmvcore: Add WMReader stubs.
by Alistair Leslie-Hughes March 30, 2017

March 30, 2017

Hi Jefferson, On 30/03/17 10:18, Jefferson Carpenter wrote: > > I have not written unit tests for this code. I would like to add some > wmvcore tests, but am not very familiar with Wine's build system > autotools, and have not been able to get tests to compile and run. > I have a basic patch for adding tests in the works, but I was waiting for my IDL changes to be accepted first. So, If someone wants to review the IDL changes, Since Sebastian has been busy with other stuff. https://source.winehq.org/patches/data/131403 > > Signed-off-by: Jefferson Carpenter > --- > dlls/wmvcore/wmvcore_main.c | 1234 +++++++++++++++++++++++++++++++++++++++++++ > +static HRESULT WINAPI WMHeaderInfo_GetScriptCount(IWMHeaderInfo3 *iface, WORD *pcScripts) > +{ > + WMReader *This = impl_from_IWMHeaderInfo3(iface); > + FIXME("(%p)->(WMHeaderInfo_GetScriptCount)\n", This); This is incorrect. The FIXME will insert the function name into the logs. You need to specify each parameter in the FIXME, there are plenty of examples of how to do this. Best Regards Alistair Leslie-Hughes

1 0

Re: dpnaddr: sync spec file to Windows 10
by Alistair Leslie-Hughes March 30, 2017

March 30, 2017

On 30/03/17 08:51, Austin English wrote: > > > You appear to be comparing the stub version of this DLL. (It would be about 8k in size, the real version is larger). Same goes for dpnlobby. Best Regards Alistair Leslie-Hughes

1 0

Darren Stevens II -- Outreachy Internship
by Darren M. Stevens II March 29, 2017

March 29, 2017

Hello, my name is Darren and I'm a computer science major at the University of Maryland Baltimore County. I've never worked in open source software before, but the idea of letting windows apps run for linux sounds appealing, especially for games. Though it's my first time in open source, I have some experience in C. Looking at the project list, the graphical user interface seems to be the most interesting, but I'm also interested in the resource and dialog editor since I'd like to get some UI experience. I've also worked in html, php, and mysql before, so improving the AppDB website also interests me. If pressed, I'd prefer to work with the gui and learn about what goes into making one. I look forward to potentially working with you all more during the summer. Thank you for your time, -- --------------------------------------------- Darren Stevens II Meyerhoff Scholar [M25] Computer Science (Game Design Track) Major University of Maryland Baltimore County (UMBC)

2 1

Packaging related changes
by Michael Müller March 29, 2017

March 29, 2017

Hi everyone, I would like to announce some very important build server / packaging related changes that will take effect with the next release. As most of you should know, Sebastian and I took care of the Wine Development and Staging builds for more than a year now. So far we were using a collection of scripts which were run on a dedicated machine to build and upload the packages. This solution did not scale very well, so we decided to rework the whole build system. The new system can not only be controlled using a command line utility but also provides an easy to use website which gives us the possibility to provide some great new features. Interested Wine developers will be able to request access to the system so that they can start their own builds. This can for example be used to provide a patched Wine version for testing in a bug report or to verify that a patch is compatible with all platforms and compilers. Nevertheless, in this mail I would like to concentrate on the user related changes. The developer related features need some further polishing and will be announced in a separate mail. Starting with the next release, we will use our new build server to compile the packages, leading to the following differences: ====================================================================== Launchpad is no longer used for the Ubuntu builds ------------------------------------------------- In order to provide the possibility for Wine developers to create their own builds through our system, we had to move away from Launchpad. This will also have the advantage that we can provide older builds (see below). The disadvantage of this change is that our users will have to manually switch from the PPA to the new repository, since there is no way to push prebuilt Debian/Ubuntu packages into a PPA on Launchpad (not even with a commercial subscription). We already added the new Ubuntu repository to the CDN, so that users can start switching by now and don't have to wait till the next release. The repository can be added using the following commands: wget https://dl.winehq.org/wine-builds/Release.key sudo apt-key add Release.key sudo apt-add-repository 'https://dl.winehq.org/wine-builds/ubuntu/' To make sure that all users will be informed about this change, I will push at least one additional update (Wine 2.5) to the PPA that displays a warning during the package upgrade containing the necessary instructions (I hope this also works on Ubuntu, I have only tested it on Debian so far). This means users will have at least two weeks to switch from the PPA to the new repository - maybe a bit more if we push additional builds. Old packages for Ubuntu / Debian -------------------------------- On the last build server we used reprepo to generate the Debian repositories. One disadvantage of the tool is that it does not support multiple versions of a package. We tried several other tools, but they did not fit our needs, so I ended up writing my own tool that does not have this limitation. This will make it easy to download and test old versions of Wine when using the new repository. There are some small packaging changes left, but in the future you will be able to tell apt-get which version you would like to install using: sudo apt-get install winehq-devel=2.4.0-1~stretch You can get a list of all available versions with: apt-cache policy winehq-devel Notes: * The "-1~stretch" part is used for the packaging. * The additional ".0" version component is added for technical reasons, to ensure package managers can determine which version is the latest one. Wine Stable is now available as package --------------------------------------- We will start providing builds for Wine Stable, which will be called "winehq-stable". This is actually a change we have planned for quite some time now, but all the manual steps involved in the old build system and the limited resources blocked us from doing this change earlier. Added / removed distros ----------------------- The following distros have been removed as they are no longer supported or reach their EOL within the next month: * Ubuntu Precise * Fedora 23 * Mageia 4 One new distro has been added: * Fedora 25 We had to temporarily disable the building of packages for Mageia 5. The problem is that the tool used for generating the repository files is not very compatible with other distros and I did not find a working combination of genhdlist2, URPM and librpm that works on Debian without any warnings or errors. We therefore decided to pause the builds until we made sure that we can provide a fully working repository. repos.wine-staging.com changes ------------------------------ This only affects users who are still getting their packages from repos.wine-staging.com. So far we were providing two repositories, the original one at repos.wine-staging.com and the new one at dl.winehq.org. We wanted to get rid of the original one for quite some time now, since both repositories basically contain the same packages. We decided that it is now the perfect time to make this step. In order to receive further updates, those users will have to switch to the dl.winehq.org repository by following the normal installation instructions. We will also post an announcement on the wine-staging.com website to make all users aware of this change. ====================================================================== As you can see there are plenty of changes, and there are even more developer related changes ahead. Although we would like to avoid any inconvenience, there is some manual work involved for some of our users. Ubuntu users will have to switch to the WineHQ repository, and repos.wine-staging.com users will have to update repository paths for all distributions. Nevertheless, we believe that these changes are very useful and will make things much easier in the long term. Regards, Michael

5 5

Re: [PATCH 10/10] xmllite/tests: Added tests for returned string pointers.
by Marvin March 29, 2017

March 29, 2017

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=29805 Your paranoid android. === wxppro (32 bit reader) === reader.c:2517: Test failed: ns != value reader.c:2549: Test failed: xmlns_name != prefix reader.c:2555: Test failed: xmlns_name != prefix reader.c:2560: Test failed: p != prefix reader.c:2561: Test failed: empty != namespace reader.c:2566: Test failed: q != prefix reader.c:2567: Test failed: nsq != namespace reader.c:2570: Test failed: q == qname reader.c:2597: Test failed: ns+1 != p === w2003std (32 bit reader) === reader.c:2517: Test failed: ns != value reader.c:2549: Test failed: xmlns_name != prefix reader.c:2555: Test failed: xmlns_name != prefix reader.c:2560: Test failed: p != prefix reader.c:2561: Test failed: empty != namespace reader.c:2566: Test failed: q != prefix reader.c:2567: Test failed: nsq != namespace reader.c:2570: Test failed: q == qname reader.c:2597: Test failed: ns+1 != p

1 0

Re: [PATCH 3/9] xmllite: Merge reader_lookup_ns and reader_lookup_nsdef implementations.
by Alexandre Julliard March 29, 2017

March 29, 2017

Jacek Caban <jacek(a)codeweavers.com> writes: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/xmllite/reader.c | 53 > +++++++++++++++++++++------------------------------ > 1 file changed, 22 insertions(+), 31 deletions(-) This fails here: ../../../tools/runtest -q -P wine -T ../../.. -M taskschd.dll -p taskschd_test.exe.so scheduler && touch scheduler.ok wine: Unhandled page fault on read access to 0x00000014 at address 0x7e05d1a7 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000014 in 32-bit code (0x7e05d1a7). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7e05d1a7 ESP:0033f4e0 EBP:0033f518 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:00000005 ECX:0013dbf8 EDX:0013dc08 ESI:0013dba8 EDI:0033f4f8 Stack dump: 0x0033f4e0: 0013dba8 00000000 0033f4f8 0033f5ac 0x0033f4f0: 7e09dfe8 7e06d000 0033f518 00000005 0x0033f500: 0013d8b8 7e05d136 0033f530 7e0a7000 0x0033f510: 0013dba8 00008454 0033f5c8 7e08f52d 0x0033f520: 0013d8b8 00000001 7e085061 7e08f52d 0x0033f530: 0013dba8 0033f5ac 00000000 00000000 Backtrace: =>0 0x7e05d1a7 xmlreader_GetValue+0x87(iface=<couldn't compute location>, value=<couldn't compute location>, len=<couldn't compute location>) [/home/julliard/wine/wine/dlls/xmllite/reader.c:3301] in xmllite (0x0033f518) 1 0x7e08f52d TaskDefinition_put_XmlText+0x4fc(iface=<couldn't compute location>, xml=<couldn't compute location>) [/home/julliard/wine/wine/dlls/taskschd/../../include/xmllite.h:366] in taskschd (0x0033f5c8) 2 0x7e08655d TaskFolder_RegisterTask+0xdc(iface=<couldn't compute location>, name=<couldn't compute location>, xml=<couldn't compute location>, flags=<couldn't compute location>, user={n1={n2={vt=0x1, wReserved1=0x11, wReserved2=0xd7e6, wReserved3=0x7bc3, n3={cVal=-16, uiVal=0xf7f0, ulVal=0x33f7f0, intVal=0x33f7f0, uintVal=0x33f7f0, bVal=-16, iVal=0xfffff7f0, lVal=0x33f7f0, fltVal=0.000000, dblVal=1511150729130819689735093992150912839369984728108261507947203237810152168316886087549523621236115883856409333081269449041715263251744478647635819958016247928527492445059748209219694759120105362131911873167308517643014354124272586209814321930163516051621612695826549010655565890397283549184.000000, boolVal=0xfffff7f0, scode=0x33f7f0, date=1511150729130819689735093992150912839369984728108261507947203237810152168316886087549523621236115883856409333081269449041715263251744478647635819958016247928527492445059748209219694759120105362131911873167308517643014354124272586209814321930163516051621612695826549010655565890397283549184.000000, bstrVal="`?????`??3≥?", cyVal={={Lo=0x33f7f0, Hi=0x7bc3d926}, int64=0x7bc3d9260033f7f0}, punkVal=0x33f7f0, pdispVal=0x33f7f0, parray=0x33f7f0, llVal=0x7bc3d9260033f7f0, ullVal=0x7bc3d9260033f7f0, pcVal="`", puiVal="`?????`??3≥?", pulVal=0x33f7f0, pintVal=0x33f7f0, puintVal=0x33f7f0, pbVal="`", piVal=0x33f7f0, plVal=0x33f7f0, pfltVal=0x33f7f0, pdblVal=0x33f7f0, pboolVal=0x33f7f0, pscode=0x33f7f0, pdate=0x33f7f0, pbstrVal=0x33f7f0, pvarVal=0x33f7f0, byref=0x33f7f0, pcyVal=0x33f7f0, pdecVal=0x33f7f0, ppunkVal=0x33f7f0, ppdispVal=0x33f7f0, pparray=0x33f7f0, pllVal=0x33f7f0, pullVal=0x33f7f0, brecVal={pvRecord=0x33f7f0, pRecInfo=0x7bc3d926}}}, decVal={wReserved=0x1, ={={scale=17, sign=0}, signscale=0x11}, Hi32=0x7bc3d7e6, ={={Lo32=0x33f7f0, Mid32=0x7bc3d926}, Lo64=0x7bc3d9260033f7f0}}}}, password={n1={n2={vt=0x1, wReserved1=0x33, wReserved2=0xd7e6, wReserved3=0x7bc3, n3={cVal=0, uiVal=0xf800, ulVal=0x33f800, intVal=0x33f800, uintVal=0x33f800, bVal=0, iVal=0xfffff800, lVal=0x33f800, fltVal=0.000000, dblVal=1511150729130824017523893055520610957737502764212302110344498125717661440571014434062133365926164698282569564768952682214359048014142616051827027404016169084942804013460762242723410078969754872380504678452713624017530338190327992990462096150957280615769007395389364412955620604666965917696.000000, boolVal=0xfffff800, scode=0x33f800, date=1511150729130824017523893055520610957737502764212302110344498125717661440571014434062133365926164698282569564768952682214359048014142616051827027404016169084942804013460762242723410078969754872380504678452713624017530338190327992990462096150957280615769007395389364412955620604666965917696.000000, bstrVal="`??3≥?", cyVal={={Lo=0x33f800, Hi=0x7bc3d926}, int64=0x7bc3d9260033f800}, punkVal=0x33f800, pdispVal=0x33f800, parray=0x33f800, llVal=0x7bc3d9260033f800, ullVal=0x7bc3d9260033f800, pcVal="`", puiVal="`??3≥?", pulVal=0x33f800, pintVal=0x33f800, puintVal=0x33f800, pbVal="`", piVal=0x33f800, plVal=0x33f800, pfltVal=0x33f800, pdblVal=0x33f800, pboolVal=0x33f800, pscode=0x33f800, pdate=0x33f800, pbstrVal=0x33f800, pvarVal=0x33f800, byref=0x33f800, pcyVal=0x33f800, pdecVal=0x33f800, ppunkVal=0x33f800, ppdispVal=0x33f800, pparray=0x33f800, pllVal=0x33f800, pullVal=0x33f800, brecVal={pvRecord=0x33f800, pRecInfo=0x7bc3d926}}}, decVal={wReserved=0x1, ={={scale='3', sign=0}, signscale=0x33}, Hi32=0x7bc3d7e6, ={={Lo32=0x33f800, Mid32=0x7bc3d926}, Lo64=0x7bc3d9260033f800}}}}, logon=<couldn't compute location>, sddl={n1={n2={vt=0x1, wReserved1=0x33, wReserved2=0x9000, wReserved3=0x7bcd, n3={cVal='X', uiVal=0xf858, ulVal=0x33f858, intVal=0x33f858, uintVal=0x33f858, bVal='X', iVal=0xfffff858, lVal=0x33f858, fltVal=0.000000, dblVal=1599434225947997951839798187977314197247957319428824144722608502103490780437150503599313505255422560087677850314482444820949235532773538977575659441663949722412271782696123659963005719660434825558687050651416890927056302450102863675852450005771357260534626948999518468080309345769339486208.000000, boolVal=0xfffff858, scode=0x33f858, date=1599434225947997951839798187977314197247957319428824144722608502103490780437150503599313505255422560087677850314482444820949235532773538977575659441663949722412271782696123659963005719660434825558687050651416890927056302450102863675852450005771357260534626948999518468080309345769339486208.000000, bstrVal="?3????????", cyVal={={Lo=0x33f858, Hi=0x7bc501ff}, int64=0x7bc501ff0033f858}, punkVal=0x33f858, pdispVal=0x33f858, parray=0x33f858, llVal=0x7bc501ff0033f858, ullVal=0x7bc501ff0033f858, pcVal="ê°3", puiVal="?3????????", pulVal=0x33f858, pintVal=0x33f858, puintVal=0x33f858, pbVal="ê°3", piVal=0x33f858, plVal=0x33f858, pfltVal=0x33f858, pdblVal=0x33f858, pboolVal=0x33f858, pscode=0x33f858, pdate=0x33f858, pbstrVal=0x33f858, pvarVal=0x33f858, byref=0x33f858, pcyVal=0x33f858, pdecVal=0x33f858, ppunkVal=0x33f858, ppdispVal=0x33f858, pparray=0x33f858, pllVal=0x33f858, pullVal=0x33f858, brecVal={pvRecord=0x33f858, pRecInfo=0x7bc501ff}}}, decVal={wReserved=0x1, ={={scale='3', sign=0}, signscale=0x33}, Hi32=0x7bcd9000, ={={Lo32=0x33f858, Mid32=0x7bc501ff}, Lo64=0x7bc501ff0033f858}}}}, task=<couldn't compute location>) [/home/julliard/wine/wine/dlls/taskschd/../../include/taskschd.h:2719] in taskschd (0x0033f668) 3 0x7ed666c6 test_GetTask+0x385() [/home/julliard/wine/wine/dlls/taskschd/tests/../../../include/taskschd.h:2140] in taskschd_test (0x0033fd18) 4 0x7ed6bd20 func_scheduler+0x2f() [/home/julliard/wine/wine/dlls/taskschd/tests/scheduler.c:1488] in taskschd_test (0x0033fd28) 5 0x7ed6bf56 run_test+0x115(name=<is not available>) [/home/julliard/wine/wine/dlls/taskschd/tests/../../../include/wine/test.h:589] in taskschd_test (0x0033fd58) 6 0x7ed63c5b main+0x14a(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/taskschd/tests/../../../include/wine/test.h:673] in taskschd_test (0x0033fe08) 7 0x7ed6c95b __wine_spec_exe_entry+0x4a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in taskschd_test (0x0033fe48) 8 0x7b45e5cc call_process_entry+0xb() in kernel32 (0x0033fe68) 9 0x7b45f509 start_process+0x68(entry=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1116] in kernel32 (0x0033fea8) 10 0x7bc80aac call_thread_func_wrapper+0xb() in ntdll (0x0033fec8) 11 0x7bc83869 call_thread_func+0xa8(entry=0x7b45f4a0, arg=0x7ed6c910, frame=0x33ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2759] in ntdll (0x0033ffa8) 12 0x7bc80a8a call_thread_entry_point+0x11() in ntdll (0x0033ffc8) 13 0x7bc540f3 start_process+0x12(arg=0xffb0e178) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3054] in ntdll (0x0033ffe8) 14 0xf755a8dd __x86.get_pc_thunk.di+0x2a() in libwine.so.1 (0x00000000) 15 0xf755aa40 wine_switch_to_stack+0x1f(func=0x7bc540e0, arg=0xffb0e178, stack=0x340000) [/home/julliard/wine/wine/libs/wine/port.c:77] in libwine.so.1 (0xffb0e148) 16 0x7bc59ca6 LdrInitializeThunk+0x235(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:3115] in ntdll (0xffb0e198) 17 0x7b46540f __wine_kernel_init+0xa4e() [/home/julliard/wine/wine/dlls/kernel32/process.c:1310] in kernel32 (0xffb0f088) 18 0x7bc5ab03 __wine_process_init+0x152() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3324] in ntdll (0xffb0f0f8) 19 0xf7558b43 wine_init+0x2a2(argc=0x3, argv=0xffb0f644, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:956] in libwine.so.1 (0xffb0f148) 20 0x7c000b58 main+0x97(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:254] in <wine-loader> (0xffb0f598) 21 0xf7362276 __libc_start_main+0xf5() in libc.so.6 (0x00000000) 0x7e05d1a7 xmlreader_GetValue+0x87 [/home/julliard/wine/wine/dlls/xmllite/reader.c:3301] in xmllite: movl 0x14(%eax),%edx -- Alexandre Julliard julliard(a)winehq.org

2 1