wine-devel August 2016

wine-devel@winehq.org

55 participants
282 discussions

Experimental gcc optimization for 64-bit wine
by Daniel Santos 01 Sep '16

01 Sep '16

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 31 Aug '16

31 Aug '16

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 31 Aug '16

31 Aug '16

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 31 Aug '16

31 Aug '16

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 31 Aug '16

31 Aug '16

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 31 Aug '16

31 Aug '16

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 31 Aug '16

31 Aug '16

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 31 Aug '16

31 Aug '16

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 31 Aug '16

31 Aug '16

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 31 Aug '16

31 Aug '16

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel August 2016