August 2016 - 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

Re: libwine: Do not compare strings "ab-c" and a-bc" as equal.
by Marvin Sept. 16, 2016

Sept. 16, 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=25415 Your paranoid android. === w1064 (32 bit locale) === locale.c:2562: Test failed: LCMapStringEx should fail with bad locale name locale.c:2563: Test failed: unexpected error code -559038737 locale.c:2654: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4384: Test failed: IsValidLocaleName should have failed locale.c:4386: Test failed: IsValidLocaleName should have failed locale.c:4769: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4771: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2562: Test failed: LCMapStringEx should fail with bad locale name locale.c:2563: Test failed: unexpected error code -559038737 locale.c:2654: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4384: Test failed: IsValidLocaleName should have failed locale.c:4386: Test failed: IsValidLocaleName should have failed locale.c:4769: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4771: Test failed: For id 7, Expected IVC, got ''

2 1

HLSL compiler
by Fabian Maurer Sept. 6, 2016

Sept. 6, 2016

I'd like to take a try at Directx10 support, firstmost hacking the HLSL compiler (namely implementing "fx_4_0"). No guarantee I'll succeed though. First, is there already someone working on this? Don't wanna duplicate the effort again. Second, since there already is an existing parser: Did you plan to simply extend it and make one parser for all HLSL versions, or to duplicate the code and have it separate for each version like the official compiler did it? I think I'd just add it to d3dcompiler_43.

3 7

Where is my address space?
by Snorri Sturluson Sept. 3, 2016

Sept. 3, 2016

I’m trying to understand the memory usage of Wine. My focus is to make EVE Online run on the Mac as smoothly as possible, and one of the issues I’m running into is that the game runs out of memory in heavy scenes, especially when running at high resolutions on Macs with Retina screens. On Windows, a scene with 300 ships in space may be running in 2.1GB of page file usage, but the same scene under Wine will show a Virtual Memory size of 3.5GB or more. Once the Virtual Memory size (as shown by the Activity Monitor) gets too close to the 4GB mark I start getting errors from Wine, failing to allocate memory, usually leading to a crash. There is a significant difference even when running at the same resolution on both Windows and Mac, and further pronounced if I run in the full 5k resolution of an iMac. Can anyone explain this big difference in memory use between the Windows and Wine sessions? Or give me ideas on how I can figure it out? Or better yet, have suggestions on how to reduce it? Best regards, Snorri Sturluson CCP Games

4 9

Implementing Fiber-Local Storage Callbacks: sharing data between DLLs
by John Sheu Sept. 2, 2016

Sept. 2, 2016

TL;WR: I'd like to share a struct definition between ntdll and kernel32, passed through the PEB. Is this kosher according to Wine style/design, and if so, which header should I stick it in? -- I'd like to have fiber-local storage callbacks in Wine. http://source.winehq.org/git/wine.git/commit/556fef3d http://source.winehq.org/git/wine.git/commit/ab11a5ae http://source.winehq.org/git/wine.git/commit/4e8f43f4 So, after writing the conformance tests, it's time to implement the feature :-) I've got the feature all done, except for one issue. The proximate issue is that when NtTerminateProcess is used on Windows, FLS callbacks are not called for threads that are aborted (and those threads do not get a DLL_THREAD_DETACH notification). However, if during DLL_PROCESS_DETACH the FLS slot is then freed, then the callbacks are called on behalf of those (already-terminated) threads by the process-detaching thread. The behavior appears to be thus: if the thread is exited cleanly (through LdrShutdownThread), then the FLS callbacks are called for that thread; otherwise on an unclean exit the FLS slots for the thread are transferred to some global list, and the callbacks for that list are called when FlsFree is later called. The underlying problem regards doing that transfer to the global list. LdrShutdownThread and its other friends reside in ntdll, so ntdll will have to know how to manage FLS. The FLS API however resides in kernel32, so kernel32 will have to know, as well. For this purpose I'd like to pass a common struct between ntdll and kernel32 through PEB.FlsListHead. What I see though is that include/winternl.h contains (almost all) publicly Microsoft-documented struct definitions, and I don't see anywhere else where such common structs are presently shared between two DLLs. So is it the case that the convention in Wine is to not do such things as sharing structs, or is this also done elsewhere and I just need to find the right header for it? Thanks, -John Sheu

4 6

Re: [3/3] imm32,user32: Create and destroy the default IME window implicitly. (try 9; resend)
by Sebastian Lackner Sept. 2, 2016

Sept. 2, 2016

On 23.08.2016 15:13, Akihiro Sagawa wrote: > > Try 9: > - Withdraw try 8 changes as we have ImmDisableIME now. > - Rebased and resolve conflicts against ImmDisableIME patch. > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/imm32/imm.c | 99 +++++++++++++++++++++++++++++++++++----------- > dlls/imm32/imm32.spec | 1 + > dlls/imm32/tests/imm32.c | 12 +++--- > dlls/user32/misc.c | 4 +- > dlls/user32/user_private.h | 1 + > dlls/user32/win.c | 26 ++++++++++++ > dlls/user32/win.h | 1 + > 7 files changed, 113 insertions(+), 31 deletions(-) This patch broke various user32 tests in virtual desktop mode, for example: $ (cd dlls/user32/tests/; make broadcast.ok) ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so broadcast && touch broadcast.ok broadcast.c:174: Test failed: Asynchronous message sent instead broadcast.c:152: Test failed: Returned: 0 broadcast.c:153: Test failed: Asynchronous message sent instead broadcast.c:174: Test failed: Asynchronous message sent instead broadcast.c:238: Test failed: Returned: 0 broadcast.c:239: Test failed: Asynchronous message sent instead broadcast.c:257: Test failed: Asynchronous message sent instead broadcast.c:238: Test failed: Returned: 0 broadcast.c:239: Test failed: Asynchronous message sent instead broadcast.c:257: Test failed: Asynchronous message sent instead broadcast.c:298: Test failed: Returned: 0 error 1460 broadcast.c:299: Test failed: Asynchronous message sent instead broadcast.c:309: Test failed: Returned: 0 error 1460 broadcast.c:310: Test failed: Asynchronous message sent instead broadcast.c:320: Test failed: Returned: 0 error 1460 broadcast.c:321: Test failed: Asynchronous message sent instead broadcast.c:332: Test failed: Asynchronous message sent instead make: *** [Makefile:197: broadcast.ok] Fehler 17 Could you please take a look?

2 4

Maximum OpenGL version
by Fabian Maurer Sept. 2, 2016

Sept. 2, 2016

Currently looking at the directx11 implementation, and I noticed I first need to set a "MaxVersionGL" in the registry to enable creation of 4.3 context and so DX11 support. What's the reason behind this? The change is from a1e718ccabc7c330dd16c7face78022965b03e20 (wined3d: Add a setting for the maximum OpenGL version to use). Why do we need to set the maximum version instead of just using the highest context we can get (and still use) ? Fabian Maurer

3 6

Re: Add a simple 3D APIs demo
by Matteo Bruni Sept. 1, 2016

Sept. 1, 2016

2016-08-19 21:41 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>: > This adds a 3d-demo wine application. It will allow users to check that their > system can handle at least basic WGL, D3D8 and D3D9 before they need to look > deeper into their problem. > > Signed-off-by: Ruslan Kabatsayev <b7.10110111(a)gmail.com> > --- > configure | 26 +- > configure.ac | 1 + > programs/3d-demo/Makefile.in | 14 + > programs/3d-demo/common.c | 107 ++++++ > programs/3d-demo/common.h | 36 ++ > programs/3d-demo/d3d.c | 605 ++++++++++++++++++++++++++++++++ > programs/3d-demo/d3d8.c | 2 + > programs/3d-demo/d3d9.c | 2 + > programs/3d-demo/demo.rc | 61 ++++ > programs/3d-demo/main.c | 175 +++++++++ > programs/3d-demo/resource.h | 33 ++ > programs/3d-demo/wgl.c | 473 +++++++++++++++++++++++++ > programs/3d-demo/winehq_logo_glass.png | Bin 0 -> 31512 bytes > 13 files changed, 1517 insertions(+), 18 deletions(-) > create mode 100644 programs/3d-demo/Makefile.in > create mode 100644 programs/3d-demo/common.c > create mode 100644 programs/3d-demo/common.h > create mode 100644 programs/3d-demo/d3d.c > create mode 100644 programs/3d-demo/d3d8.c > create mode 100644 programs/3d-demo/d3d9.c > create mode 100644 programs/3d-demo/demo.rc > create mode 100644 programs/3d-demo/main.c > create mode 100644 programs/3d-demo/resource.h > create mode 100644 programs/3d-demo/wgl.c > create mode 100644 programs/3d-demo/winehq_logo_glass.png I have a few pretty generic suggestions. You don't need to include configure changes in the patch, they will be regenerated by Alexandre anyway since those depend on the version of the autotools. Did you look into adding those tests to dxdiag instead of as a separate program? I don't think a separate program is necessarily bad but if integrating into dxdiag is reasonable it's probably better to do that from the start. Avoid camelCase or similar mixed-case identifier styles, just use lowercase_with_underscores. For pointer declarations you want to stick the '*' to the variable, not the type. Also please avoid LPTYPES, just use explicit pointer types. C++ comments (// comment) aren't allowed in Wine sources. Please replace them with normal C comments (/* comment */), or drop them entirely if they don't add anything that isn't clear from just looking at the code. It would be better to use explicit float constants when assigning to float variables (e.g. D3DMATERIAL). There aren't many other general style rules in Wine (it's mostly about using the style already used in the component so for new components you're mostly free to pick your own) as long as there is consistency. I see you mixing space after ',' with no space, pick one (preferably the space variant IMO) and stick to it. We usually use parentheses with the "sizeof" operator in Wine sources, so while it's not strictly required it would probably be nice to follow the general trend. More specific comments: I'd split this over multiple patches. You can probably make an initial patch adding the program with no real functionality, then multiple patches adding the various graphical API demos. In that regard, the d3d8 / d3d9 "merged" handling via macros seems a bit obfuscating to me. Just replicating the code twice seems cleaner. Maybe you can create a few helper functions for the common code. BTW, you can probably make things a bit more structured by moving the main loop to common code and have it call API backend functions. You'd have for each backend a structure like: static const struct render_backend d3d9_backend { d3d9_list_modes, d3d9_init, d3d9_draw, d3d9_wndproc, d3d9_destroy, }; (just an idea WRT the actual functions, I haven't really looked in detail) and you'd pass the structure from the selected API to the "main loop" function. I don't think you're using GLU anymore (good) so you should drop the glu32 import. I haven't looked in detail at the actual demos / renderers but I think there is enough stuff to work on already :)

4 6

Experimental gcc optimization for 64-bit wine
by Daniel Santos Sept. 1, 2016

Sept. 1, 2016

Over the last two weeks I've been working on an experimental gcc optimization for wine that out-of-lines the expensive prologues & epilogues required for an ms x64 abi function to call a 64-bit sysv function. The theory is that the added expense of each function executing a few extra instructions to facilitate this will be offset by the reduction in instruction cache misses. As far as I can tell, gcc's ix86 back end has never supported any type of out-of-line pro/epilogue stubs, so adding this support has been somewhat tedious as it tends to get broken by subsequent optimization passes. It currently works in many cases, but in other cases produces bad code so this is a work in progress. None the less, I thought it was interesting enough to post the current results in terms of .text size reduction. On gcc 5.4.0 (with the 8-byte aligned stack assumption flaw corrected), the total .text size of all dlls on my build was 45.2MiB while the out-of-lined build was 35.9MiB, a reduction of 20.5%, so it looks promising so far. I presume it will be a little while before all of the flaws are worked out so that it always produces good code, but once there I can start to produce some real performance numbers. It's probably also worth mentioning that the ideal long-term solution is to find ways eliminate the register save/restores through various means-- static analysis, better evaluation of branch costs, and other optimizations in Wine its self. For example, there are many WINAPI functions who's only sysv call is to wine_dbg_log() via a TRACE(). Just marking this function as __attribute__((__cold__)) should reduce the number of unneeded register save/restores in the function's main path by a great amount. (I haven't actually tested it yet.) Daniel

2 3

Re: [PATCH 2/2] winhttp: Also pass hostname to jsproxy
by Nikolay Sivov Aug. 31, 2016

Aug. 31, 2016

On 31.08.2016 22:21, Andrew Eikum wrote: > > +static inline char *strdupWA_sized( const WCHAR *src, DWORD size ) > +{ > + char *dst = NULL; > + if (src) > + { > + int len = WideCharToMultiByte( CP_ACP, 0, src, size, NULL, 0, NULL, NULL ) + 1; > + if ((dst = heap_alloc( len ))) > + { > + WideCharToMultiByte( CP_ACP, 0, src, len, dst, size, NULL, NULL ); > + dst[len - 1] = 0; > + } > + } > + return dst; > +} > + This is usually called strndup* in Wine dlls. Also 'len' and 'size' seem to be misplaced, and I'm not sure it will do the right thing if for negative size, unless it's not meant to ever be negative.

1 0

Re: [PATCH 1/4] xinput1_3: Better trace all functions
by Sebastian Lackner Aug. 31, 2016

Aug. 31, 2016

On 31.08.2016 20:17, Bruno Jesus wrote: > - FIXME("(%d %p %p) Stub!\n", dwUserIndex, pDSoundRenderGuid, pDSoundCaptureGuid); > + FIXME("(index %u, render guid %p, capture guid %p) Stub!\n", index, render_guid, capture_guid); debugstr_guid() would be more appropriate for tracing GUIDs.

2 2

How to find out the source code function from compiled running address
by Bruno Jesus Aug. 31, 2016

Aug. 31, 2016

Hi all. While trying to run a crashing application I used a debugger and found out the crash is inside wined3d, I then started looking for ways to convert that address back into what function it should be so I can breakpoint it and check. At first I got into http://www.nirsoft.net/utils/dll_export_viewer.html and it looked like what I needed but the program does not seem to work in Wine DLLs. Adding +d3d,+relay and checking the calls is awfully verbose, but I'm still trying it. Part of the function showing the addresses, last line crashes: wined3d.dll:7EBCEF19 mov eax, [ebp+8] wined3d.dll:7EBCEF1C mov eax, [eax+0EC54h] wined3d.dll:7EBCEF22 mov edx, [ebp-0Ch] wined3d.dll:7EBCEF25 shl edx, 2 wined3d.dll:7EBCEF28 add eax, edx wined3d.dll:7EBCEF2A mov eax, [eax] Is there anyway to find out where is this function in the source code? Best regards, Bruno

3 3

Re: [PATCH 1/1] gdiplus: Fix for the "graphics object has no HDC" issue in GdipDrawPath
by Vincent Povirk Aug. 31, 2016

Aug. 31, 2016

We really need an implementation that doesn't rely on gdi32.

2 6

Re: [PATCH 2/4] ntoskrnl.exe: Use static initializer for device_drivers.
by Sebastian Lackner Aug. 31, 2016

Aug. 31, 2016

On 30.08.2016 21:30, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/ntoskrnl.exe/ntoskrnl.c | 40 ++++++++-------------------------------- > 1 file changed, 8 insertions(+), 32 deletions(-) > Wouldn't it be better to use a macro similar to LIST_INIT() for that (to allow later changes of the internal structure)?

2 2

Re: [2/8] webservices: Implement WsAddCustomHeader.
by Sebastian Lackner Aug. 31, 2016

Aug. 31, 2016

On 31.08.2016 14:35, Hans Leidekker wrote: > + if (WsXmlStringEquals( desc->elementLocalName, &msg->header[i]->name, NULL ) && > + WsXmlStringEquals( desc->elementNs, &msg->header[i]->ns, NULL ) == S_OK) This looks suspicious because it does not match the follow up patch. are you missing a == S_OK maybe?

1 0

Re: [PATCH 3/4] ntoskrnl.exe: Send PnP and Power IRPs to plug and play devices
by Sebastian Lackner Aug. 31, 2016

Aug. 31, 2016

On 29.08.2016 20:49, Aric Stewart wrote: > 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. > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/ntoskrnl.exe/pnp_manager.c | 64 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 64 insertions(+) > > > > 0003-ntoskrnl.exe-Send-PnP-and-Power-IRPs-to-plug-and-play-.txt > > > diff --git a/dlls/ntoskrnl.exe/pnp_manager.c b/dlls/ntoskrnl.exe/pnp_manager.c > index f1f3109..912f5fd 100644 > --- a/dlls/ntoskrnl.exe/pnp_manager.c > +++ b/dlls/ntoskrnl.exe/pnp_manager.c > @@ -148,6 +148,60 @@ static NTSTATUS get_device_id(DEVICE_OBJECT *device, BUS_QUERY_ID_TYPE type, WCH > return status; > } > > +static NTSTATUS send_deviceIRP(DEVICE_OBJECT* device, IRP *irp) > +{ > + NTSTATUS status; > + IO_STACK_LOCATION *irpsp; > + HANDLE event = CreateEventA(NULL, FALSE, FALSE, NULL); > + > + irp->UserEvent = event; > + irpsp = IoGetNextIrpStackLocation(irp); > + irpsp->CompletionRoutine = internalComplete; > + irpsp->Control = SL_INVOKE_ON_SUCCESS | SL_INVOKE_ON_ERROR; > + > + IoCallDriver(device, irp); > + > + if (irp->IoStatus.u.Status == STATUS_PENDING) > + WaitForSingleObject(event, INFINITE); > + > + status = irp->IoStatus.u.Status; > + IoCompleteRequest(irp, IO_NO_INCREMENT ); > + CloseHandle(event); > + return status; > +} Such a helper function could also be used to simplify get_device_id. > + > +static NTSTATUS send_pnpIRP(DEVICE_OBJECT *device, UCHAR minor) > +{ > + IO_STACK_LOCATION *irpsp; > + IO_STATUS_BLOCK irp_status; > + > + IRP *irp = IoBuildSynchronousFsdRequest(IRP_MJ_PNP, device, NULL, 0, NULL, NULL, &irp_status); It would be better to handle failure of IoBuildSynchronousFsdRequest like in get_device_id. The same also applies to send_powerIRP() below. > + > + irpsp = IoGetNextIrpStackLocation(irp); > + irpsp->MinorFunction = minor; > + > + irpsp->Parameters.StartDevice.AllocatedResources = NULL; > + irpsp->Parameters.StartDevice.AllocatedResourcesTranslated = NULL; > + > + return send_deviceIRP(device, irp); > +} > + > +static NTSTATUS send_powerIRP(DEVICE_OBJECT *device, DEVICE_POWER_STATE power) Please check if its possible to (partially) move this to PoRequestPowerIrp(). If there is not enough information we can keep it like that for now, but according to the description it sounds very similar. > +{ > + IO_STATUS_BLOCK irp_status; > + IO_STACK_LOCATION *irpsp; > + > + IRP *irp = IoBuildSynchronousFsdRequest(IRP_MJ_POWER, device, NULL, 0, NULL, NULL, &irp_status); > + > + irpsp = IoGetNextIrpStackLocation(irp); > + irpsp->MinorFunction = IRP_MN_SET_POWER; > + > + irpsp->Parameters.Power.Type = DevicePowerState; > + irpsp->Parameters.Power.State.DeviceState = power; > + > + return send_deviceIRP(device, irp); > +} > + > static void handle_bus_relations(DEVICE_OBJECT *device) > { > static const WCHAR szDriverW[] = {'\\','D','r','i','v','e','r','\\',0}; > @@ -244,6 +298,16 @@ static void handle_bus_relations(DEVICE_OBJECT *device) > ERR("AddDevice failed\n"); > return; > } > + > + if (device->AttachedDevice) > + { > + send_pnpIRP(device->AttachedDevice, IRP_MN_START_DEVICE); > + send_powerIRP(device->AttachedDevice, PowerDeviceD0); > + } > + else > + { > + ERR("No attached device\n"); > + } > } > > static void initialize_driver_store(void) > > >

1 0

Re: [PATCH 2/4] ntoskrnl.exe: Implement loading plug and play devices
by Sebastian Lackner Aug. 31, 2016

Aug. 31, 2016

On 29.08.2016 20:49, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/ntoskrnl.exe/pnp_manager.c | 150 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 150 insertions(+) > > > > 0002-ntoskrnl.exe-Implement-loading-plug-and-play-devices.txt > > > diff --git a/dlls/ntoskrnl.exe/pnp_manager.c b/dlls/ntoskrnl.exe/pnp_manager.c > index 5b42a0a..f1f3109 100644 > --- a/dlls/ntoskrnl.exe/pnp_manager.c > +++ b/dlls/ntoskrnl.exe/pnp_manager.c > @@ -17,6 +17,7 @@ > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > */ > > +#define NONAMELESSUNION > #include <stdarg.h> > #include "ntstatus.h" > #define WIN32_NO_STATUS > @@ -27,6 +28,7 @@ > #include "cfgmgr32.h" > #include "winsvc.h" > #include "winreg.h" > +#include "wine/unicode.h" > #include "wine/debug.h" > #include "wine/list.h" > > @@ -34,6 +36,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > > #define MAX_SERVICE_NAME 260 > > +typedef NTSTATUS WINAPI (*pAddDevice)(DRIVER_OBJECT *DriverObject, DEVICE_OBJECT *PhysicalDeviceObject); My Win10 header files contain DRIVER_EXTENSION with the appropriate definition, which would make the casts unnecessary. > + > typedef struct _device_driver { > struct list entry; > > @@ -105,6 +109,143 @@ static device_driver* register_device_driver(const WCHAR *drivername, const WCHA > return ptr; > } > > +static NTSTATUS WINAPI internalComplete(DEVICE_OBJECT *deviceObject, IRP *irp, > + void *context ) > +{ > + SetEvent(irp->UserEvent); > + return STATUS_MORE_PROCESSING_REQUIRED; > +} > + > +static NTSTATUS get_device_id(DEVICE_OBJECT *device, BUS_QUERY_ID_TYPE type, WCHAR **id) > +{ > + NTSTATUS status; > + IO_STACK_LOCATION *irpsp; > + IO_STATUS_BLOCK irp_status; > + IRP *irp; > + HANDLE event = CreateEventA(NULL, FALSE, FALSE, NULL); > + > + irp = IoBuildSynchronousFsdRequest(IRP_MJ_PNP, device, NULL, 0, NULL, NULL, &irp_status); > + if (irp == NULL) > + return STATUS_NO_MEMORY; The return path here will leak the event handle. The same issue was recently fixed in hidclass.sys. Also I'm wondering a bit, do we need to keep this identical code at both places? > + > + irp->UserEvent = event; > + irpsp = IoGetNextIrpStackLocation(irp); > + irpsp->MinorFunction = IRP_MN_QUERY_ID; > + irpsp->Parameters.QueryId.IdType = type; > + irpsp->CompletionRoutine = internalComplete; > + irpsp->Control = SL_INVOKE_ON_SUCCESS | SL_INVOKE_ON_ERROR; > + > + IoCallDriver(device, irp); > + > + if (irp->IoStatus.u.Status == STATUS_PENDING) > + WaitForSingleObject(event, INFINITE); > + > + *id = (WCHAR*)irp->IoStatus.Information; > + status = irp->IoStatus.u.Status; > + IoCompleteRequest(irp, IO_NO_INCREMENT ); > + CloseHandle(event); > + > + return status; > +} > + > +static void handle_bus_relations(DEVICE_OBJECT *device) > +{ > + static const WCHAR szDriverW[] = {'\\','D','r','i','v','e','r','\\',0}; > + > + NTSTATUS status; > + WCHAR *id, *idptr; > + device_driver *driver = NULL; > + WCHAR fullname[MAX_PATH]; > + DRIVER_OBJECT *driver_obj; > + UNICODE_STRING driverName; > + > + TRACE("Device %p\n", device); > + > + /* We could(should?) do a full IRP_MN_QUERY_DEVICE_RELATIONS query, > + * but we dont have to, We have the DEVICE_OBJECT of the new device > + * so we can simply handle the process here */ > + > + status = get_device_id(device, BusQueryCompatibleIDs, &id); > + if (status != ERROR_SUCCESS || !id) > + { > + ERR("Failed to get device IDs\n"); > + return; > + } > + > + idptr = id; > + do { > + device_driver *ptr; > + > + TRACE("Checking for id %s\n",debugstr_w(idptr)); > + > + /* Check loaded drivers */ > + LIST_FOR_EACH_ENTRY(ptr, &device_drivers, device_driver, entry) > + { > + int i; > + for (i = 0; i < ptr->id_count; i++) > + { > + if (lstrcmpW(idptr, ptr->matching_ids[i]) == 0) > + { > + driver = ptr; > + break; Is it intentional that this does not abort the outer loop? > + } > + } > + } > + idptr += (lstrlenW(idptr) + 1); > + } while (!driver && *idptr != 0); > + > + HeapFree(GetProcessHeap(), 0, id); > + > + if (!driver) > + { > + ERR("No matching driver found for device\n"); > + return; > + } > + > + strcpyW(fullname, szDriverW); > + strcatW(fullname, driver->driver_name); > + RtlInitUnicodeString(&driverName, fullname); > + > + if (!driver->loaded) > + { > + static const WCHAR servicesW[] = {'\\','R','e','g','i','s','t','r','y', > + '\\','M','a','c','h','i','n','e', > + '\\','S','y','s','t','e','m', > + '\\','C','u','r','r','e','n','t','C','o','n','t','r','o','l','S','e','t', > + '\\','S','e','r','v','i','c','e','s', > + '\\',0}; > + WCHAR driverKey[MAX_PATH]; > + UNICODE_STRING driverPath; > + > + strcpyW(driverKey, servicesW); > + strcatW(driverKey, driver->driver_name); > + RtlInitUnicodeString(&driverPath, driverKey); > + if (ZwLoadDriver(&driverPath) != STATUS_SUCCESS) > + { > + ERR("Failed to load driver %s\n",debugstr_w(driver->driver_name)); > + return; > + } > + driver->loaded = TRUE; > + } > + > + if (ObReferenceObjectByName(&driverName, OBJ_CASE_INSENSITIVE, NULL, > + 0, NULL, KernelMode, NULL, (void**)&driver_obj) != STATUS_SUCCESS) > + { > + ERR("Failed to locate loaded driver\n"); > + return; > + } > + > + status = ((pAddDevice)driver_obj->DriverExtension->AddDevice)(driver_obj, device); It would be better to handle the lack of a AddDevice routine. > + > + ObDereferenceObject(driver_obj); > + > + if (status != STATUS_SUCCESS) > + { > + ERR("AddDevice failed\n"); > + return; > + } > +} > + > static void initialize_driver_store(void) > { > static const WCHAR criticalW[] = > @@ -181,5 +322,14 @@ VOID WINAPI IoInvalidateDeviceRelations(DEVICE_OBJECT *DeviceObject, DEVICE_RELA > initialized = TRUE; > initialize_driver_store(); > } > + > + switch (Type) > + { > + case BusRelations: > + handle_bus_relations(DeviceObject); > + break; > + default: > + FIXME("Unhandled Relation %i\n", Type); > + } > LeaveCriticalSection(&pnp_cs); > } > > >

1 0

Re: [PATCH 1/4] ntoskrnl.exe: Implement IoInvalidateDeviceRelations to initialize device driver store
by Sebastian Lackner Aug. 31, 2016

Aug. 31, 2016

On 29.08.2016 20:49, Aric Stewart wrote: > We are not handling installing drivers just yet, so we 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 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 > specify a [Service] value representing the driver. > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/ntoskrnl.exe/Makefile.in | 3 +- > dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 +- > dlls/ntoskrnl.exe/pnp_manager.c | 185 ++++++++++++++++++++++++++++++++++++ > include/ddk/wdm.h | 1 + > 4 files changed, 189 insertions(+), 2 deletions(-) > create mode 100644 dlls/ntoskrnl.exe/pnp_manager.c > At some places the patch does not really use a consistent style yet (for example VOID <-> void, placement of "*" inbetween of type and variable name, "sz" prefix for variables, ...), however I will focus mainly on the technical aspects in this review. > > > 0001-ntoskrnl.exe-Implement-IoInvalidateDeviceRelations-to-.txt > > > diff --git a/dlls/ntoskrnl.exe/Makefile.in b/dlls/ntoskrnl.exe/Makefile.in > index b459c54..2fa768b 100644 > --- a/dlls/ntoskrnl.exe/Makefile.in > +++ b/dlls/ntoskrnl.exe/Makefile.in > @@ -4,6 +4,7 @@ IMPORTS = advapi32 > > C_SRCS = \ > instr.c \ > - ntoskrnl.c > + ntoskrnl.c \ > + pnp_manager.c > > RC_SRCS = ntoskrnl.rc > diff --git a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > index 119d406..c94b902 100644 > --- a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > +++ b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > @@ -400,7 +400,7 @@ > @ stdcall IoInitializeIrp(ptr long long) > @ stdcall IoInitializeRemoveLockEx(ptr long long long long) > @ stdcall IoInitializeTimer(ptr ptr ptr) > -@ stub IoInvalidateDeviceRelations > +@ stdcall IoInvalidateDeviceRelations(ptr long) > @ stub IoInvalidateDeviceState > @ stub IoIsFileOriginRemote > @ stub IoIsOperationSynchronous > diff --git a/dlls/ntoskrnl.exe/pnp_manager.c b/dlls/ntoskrnl.exe/pnp_manager.c > new file mode 100644 > index 0000000..5b42a0a > --- /dev/null > +++ b/dlls/ntoskrnl.exe/pnp_manager.c > @@ -0,0 +1,185 @@ > +/* HID plug and play Manager like functionality > + * > + * Copyright 2016 CodeWeavers, Aric Stewart > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include <stdarg.h> > +#include "ntstatus.h" > +#define WIN32_NO_STATUS > +#include "windef.h" > +#include "winbase.h" > +#include "winternl.h" > +#include "ddk/wdm.h" > +#include "cfgmgr32.h" > +#include "winsvc.h" I don't think this include is required anymore. > +#include "winreg.h" > +#include "wine/debug.h" > +#include "wine/list.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > + > +#define MAX_SERVICE_NAME 260 > + > +typedef struct _device_driver { > + struct list entry; > + > + BOOL loaded; > + > + WCHAR **matching_ids; > + INT id_count; > + > + WCHAR *driver_name; > +} device_driver; > + > +struct list device_drivers = LIST_INIT(device_drivers); > +static BOOL initialized = FALSE; > + > +static CRITICAL_SECTION pnp_cs; > +static CRITICAL_SECTION_DEBUG critsect_debug = > +{ > + 0, 0, &pnp_cs, > + { &critsect_debug.ProcessLocksList, &critsect_debug.ProcessLocksList }, > + 0, 0, { (DWORD_PTR)(__FILE__ ": pnp_cs") } > +}; > +static CRITICAL_SECTION pnp_cs = { &critsect_debug, -1, 0, 0, 0, 0 }; > + > +static inline LPWSTR strdupW(LPCWSTR src) > +{ > + LPWSTR dest; > + > + if (!src) > + return NULL; > + > + dest = HeapAlloc(GetProcessHeap(), 0, (lstrlenW(src) + 1) * sizeof(WCHAR)); > + if (dest) > + lstrcpyW(dest, src); For new code it would be better to follow the current Wine style guidelines, which means no LP* types and strlenW/strcpyW without l prefix. > + > + return dest; > +} > + > +static device_driver* register_device_driver(const WCHAR *drivername, const WCHAR* match) > +{ > + device_driver *ptr; > + > + LIST_FOR_EACH_ENTRY(ptr, &device_drivers, device_driver, entry) > + { > + if (lstrcmpW(drivername, ptr->driver_name) == 0) > + { > + int i; > + /* Check matching ids */ > + for (i = 0; i < ptr->id_count; i++) > + if (lstrcmpW(match, ptr->matching_ids[i]) == 0) > + return ptr; > + /* Add a new matching id, this should be reletivly rare, > + no exponental growth needed */ > + ptr->matching_ids = HeapReAlloc(GetProcessHeap(), 0, ptr->matching_ids, sizeof(WCHAR*) * (ptr->id_count+1)); > + ptr->matching_ids[ptr->id_count] = strdupW(match); > + ptr->id_count++; If it is very rare, wouldn't it be better to add them as separate driver entries then? This would simplify the code and avoid nested loops at some places. The current way of organizing the driver db also has the disadvantage that the same "matching id" could be added for multiple drivers. > + > + return ptr; > + } > + } > + > + ptr = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*ptr)); > + ptr->driver_name = strdupW(drivername); > + ptr->loaded = FALSE; > + ptr->matching_ids = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR*)); > + ptr->matching_ids[0] = strdupW(match); > + ptr->id_count = 1; > + list_add_tail(&device_drivers, &ptr->entry); > + > + return ptr; > +} > + > +static void initialize_driver_store(void) > +{ > + static const WCHAR criticalW[] = > + { 'S','y','s','t','e','m','\\', > + 'C','u','r','r','e','n','t','C','o','n','t','r','o','l','S','e','t','\\', > + 'C','o','n','t','r','o','l', '\\', > + 'C','r','i','t','i','c','a','l','D','e','v','i','c','e','D','a','t','a','b','a','s','e', 0}; > + static const WCHAR serviceW[] = {'S','e','r','v','i','c','e',0}; > + HKEY hkey_root; > + WCHAR szMatch[MAX_DEVICE_ID_LEN]; > + int i; > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, criticalW, &hkey_root)) > + { > + TRACE("No drivers found\n"); > + return; > + } > + > + for (i = 0; TRUE; i++) > + { > + HKEY hkey_service; > + DWORD rc; > + device_driver *driver; > + DWORD len = 0; > + WCHAR szService[MAX_SERVICE_NAME]; > + > + rc = RegEnumKeyW(hkey_root, i, szMatch, MAX_DEVICE_ID_LEN); > + if (rc == ERROR_NO_MORE_ITEMS) > + break; > + > + if (rc != 0) > + { > + ERR("Error %d reading key %d - skipping\n", rc, i); > + continue; > + } > + > + if (RegOpenKeyW(hkey_root, szMatch, &hkey_service)) > + { > + ERR("Error opening key %s - skipping\n",debugstr_w(szMatch)); > + continue; > + } > + > + len = sizeof(szService); > + rc = RegQueryValueExW(hkey_service, serviceW, NULL, NULL, (BYTE*)szService, &len); It might be useful to check the type of the registry key here. > + if (rc != ERROR_SUCCESS) > + { > + ERR("Error querying service from key %s - skipping\n",debugstr_w(szMatch)); > + RegCloseKey(hkey_service); > + continue; > + } > + RegCloseKey(hkey_service); > + > + TRACE("Registering service '%s' to match '%s'\n", debugstr_w(szService), debugstr_w(szMatch)); > + > + driver = register_device_driver(szService, szMatch); > + if (!driver) > + ERR("failed to load driver %s\n", debugstr_w(szService)); The message is actually a bit misleading. It will only occur for duplicate entries, which should not happen anyway. > + > + } > + > + RegCloseKey(hkey_root); > +} > + > +/*********************************************************************** > + * IoInvalidateDeviceRelations(NTOSKRNL.EXE.@) > + */ > +VOID WINAPI IoInvalidateDeviceRelations(DEVICE_OBJECT *DeviceObject, DEVICE_RELATION_TYPE Type) > +{ > + TRACE("(%p %i)\n", DeviceObject, Type); > + > + EnterCriticalSection(&pnp_cs); > + if (!initialized) > + { > + initialized = TRUE; > + initialize_driver_store(); > + } > + LeaveCriticalSection(&pnp_cs); > +} > diff --git a/include/ddk/wdm.h b/include/ddk/wdm.h > index 68694af..bd3b323 100644 > --- a/include/ddk/wdm.h > +++ b/include/ddk/wdm.h > @@ -1233,6 +1233,7 @@ NTSTATUS WINAPI IoGetDeviceProperty(PDEVICE_OBJECT,DEVICE_REGISTRY_PROPERTY,ULO > PVOID WINAPI IoGetDriverObjectExtension(PDRIVER_OBJECT,PVOID); > PDEVICE_OBJECT WINAPI IoGetRelatedDeviceObject(PFILE_OBJECT); > void WINAPI IoInitializeIrp(IRP*,USHORT,CCHAR); > +void WINAPI IoInvalidateDeviceRelations(PDEVICE_OBJECT,DEVICE_RELATION_TYPE); > VOID WINAPI IoInitializeRemoveLockEx(PIO_REMOVE_LOCK,ULONG,ULONG,ULONG,ULONG); > NTSTATUS WINAPI IoWMIRegistrationControl(PDEVICE_OBJECT,ULONG); > > > >

1 0

Re: [PATCH 1/5] ddraw/tests: Move IDirect3DViewport::TransformVertices tests to ddraw1.c.
by Henri Verbeet Aug. 30, 2016

Aug. 30, 2016

On 29 August 2016 at 23:01, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > + * is transformed, and this vertex is offscreen.· Trailing whitespace. As an aside, those float comparisons are probably safe enough, but perhaps those should use compare_vec4()?

1 0

Re: kernel32: Stub CAL_RETURN_GENITIVE_NAMES flag.
by Nikolay Sivov Aug. 30, 2016

Aug. 30, 2016

On 29.08.2016 22:24, David Keijser wrote: > This stops GetCalendarInfoW from reporting unknown caltype when it's > really a case of unsupported flags. > > Signed-off-by: David Keijser <keijser(a)gmail.com> > --- > dlls/kernel32/time.c | 4 +++- > include/winnls.h | 7 ++++--- > 2 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/dlls/kernel32/time.c b/dlls/kernel32/time.c > index b7a7918..e1fd107 100644 > --- a/dlls/kernel32/time.c > +++ b/dlls/kernel32/time.c > @@ -860,6 +860,8 @@ int WINAPI GetCalendarInfoW(LCID Locale, CALID Calendar, CALTYPE CalType, > FIXME("flag CAL_NOUSEROVERRIDE used, not fully implemented\n"); > if (CalType & CAL_USE_CP_ACP) > FIXME("flag CAL_USE_CP_ACP used, not fully implemented\n"); > + if (CalType & CAL_RETURN_GENITIVE_NAMES) > + FIXME("flag CAL_RETURN_GENITIVE_NAMES used, not fully implemented\n"); Hi, David. LOCALE_RETURN_GENITIVE_NAMES itself is implemented, you should pass it to GetLocaleInfo instead of stripping it from caltype. P.S. anyone working on translations please take another look at SMONTHNAME* constants for your language, to make sure genitive forms are there, if applicable. > > if (CalType & CAL_RETURN_NUMBER) { > if (!lpValue) > @@ -878,7 +880,7 @@ int WINAPI GetCalendarInfoW(LCID Locale, CALID Calendar, CALTYPE CalType, > > /* FIXME: No verification is made yet wrt Locale > * for the CALTYPES not requiring GetLocaleInfoA */ > - switch (CalType & ~(CAL_NOUSEROVERRIDE|CAL_RETURN_NUMBER|CAL_USE_CP_ACP)) { > + switch (CalType & ~(CAL_NOUSEROVERRIDE|CAL_RETURN_NUMBER|CAL_USE_CP_ACP|CAL_RETURN_GENITIVE_NAMES)) { > case CAL_ICALINTVALUE: > if (CalType & CAL_RETURN_NUMBER) > return GetLocaleInfoW(Locale, LOCALE_RETURN_NUMBER | LOCALE_ICALENDARTYPE, > diff --git a/include/winnls.h b/include/winnls.h > index 1a7baaf..3d950f6 100644 > --- a/include/winnls.h > +++ b/include/winnls.h > @@ -471,9 +471,10 @@ static const WCHAR LOCALE_NAME_SYSTEM_DEFAULT[] = {'!','s','y','s','-','d','e',' > #define MAX_DEFAULTCHAR 2 > > /* Defines for calendar handling */ > -#define CAL_NOUSEROVERRIDE LOCALE_NOUSEROVERRIDE > -#define CAL_USE_CP_ACP LOCALE_USE_CP_ACP > -#define CAL_RETURN_NUMBER LOCALE_RETURN_NUMBER > +#define CAL_NOUSEROVERRIDE LOCALE_NOUSEROVERRIDE > +#define CAL_USE_CP_ACP LOCALE_USE_CP_ACP > +#define CAL_RETURN_NUMBER LOCALE_RETURN_NUMBER > +#define CAL_RETURN_GENITIVE_NAMES LOCALE_RETURN_GENITIVE_NAMES > > #define CAL_ICALINTVALUE 0x01 > #define CAL_SCALNAME 0x02 >

2 1

Re: [PATCH 5/5] ddraw/tests: Extend TransformVertices invalid data tests.
by Marvin Aug. 29, 2016

Aug. 29, 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=25440 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 3/5] ddraw: Fix offscreen flag handling in TransformVertices.
by Marvin Aug. 29, 2016

Aug. 29, 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=25439 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 2/5] ddraw: Copy extra vertex data in viewport::TransformVertices.
by Marvin Aug. 29, 2016

Aug. 29, 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=25438 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2215: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0