August 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 2/4] ntoskrnl.exe: Use static initializer for device_drivers.

by Jacek Caban

On 30.08.2016 22:00, Sebastian Lackner wrote: > 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)? I considered that. In case of list, I believe that motivation for the macro was not about hiding internal structure, but due to non-obvious initialization (it sets two pointer to point to the same struct). I believe that this logic does not apply to wine_rb_tree. However, I'm fine with having the macro. Thanks, Jacek

Aug. 31, 2016

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

by Akihiro Sagawa

On Tue, 30 Aug 2016 21:48:49 +0200, Sebastian Lackner wrote: > 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 (snip) > make: *** [Makefile:197: broadcast.ok] Fehler 17 > > Could you please take a look? Sure. I'll take a look. Thanks for report. Akihiro Sagawa

Aug. 31, 2016

Implementing Fiber-Local Storage Callbacks: sharing data between DLLs

by John Sheu

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

Aug. 31, 2016

Re: [PATCH 3/4] ntoskrnl.exe: Send PnP and Power IRPs to plug and play devices

by Sebastian Lackner

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) > > >

Aug. 31, 2016

Re: [PATCH 2/4] ntoskrnl.exe: Implement loading plug and play devices

by Sebastian Lackner

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); > } > > >

Aug. 31, 2016

Re: [PATCH 1/4] ntoskrnl.exe: Implement IoInvalidateDeviceRelations to initialize device driver store

by Sebastian Lackner

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); > > > >

Aug. 31, 2016

HLSL compiler

by Fabian Maurer

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.

Aug. 31, 2016

Re: [PATCH 1/1] gdiplus: Fix for the "graphics object has no HDC" issue in GdipDrawPath

by Fabian Maurer

On Tuesday, August 30, 2016 6:25:11 PM CEST you wrote: > If there's an HDC, we use a mix of GDI rendering and GDI+ rendering. > If GDI can support a particular drawing operation, we use that. > Otherwise, we render it internally and send it to the HDC using > GdiAlphaBlend. > > At least, that's the general policy. There may be exceptions. I see, thanks for clearing that up. Regarding the crash, in "SOFTWARE_GdipDrawThinPath" the line "GdipDeletePath(path);" seems faulty. It seems odd to delete "path", maybe it should be "flat_path" instead? Fabian Maurer

Aug. 31, 2016

Re: [PATCH 1/1] gdiplus: Fix for the "graphics object has no HDC" issue in GdipDrawPath

by Vincent Povirk

>> Not just because of performance. Gdiplus has some features that gdi32 >> does not, such as anti-aliasing, semi-transparent brushes, and >> gradient brushes. > > I see.. So basically everything with hdc is old GDI and everything without is > GDI+? If there's an HDC, we use a mix of GDI rendering and GDI+ rendering. If GDI can support a particular drawing operation, we use that. Otherwise, we render it internally and send it to the HDC using GdiAlphaBlend. At least, that's the general policy. There may be exceptions.

Aug. 30, 2016

Re: [PATCH 1/1] gdiplus: Fix for the "graphics object has no HDC" issue in GdipDrawPath

by Fabian Maurer

On Tuesday, August 30, 2016 5:01:20 PM CEST you wrote: > Not just because of performance. Gdiplus has some features that gdi32 > does not, such as anti-aliasing, semi-transparent brushes, and > gradient brushes. I see.. So basically everything with hdc is old GDI and everything without is GDI+?

Aug. 30, 2016