Signed-off-by: Aric Stewart aric@codeweavers.com --- dlls/ntoskrnl.exe/ntoskrnl.c | 216 ++++++++++++++++++++++++++++++++++++ dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 +- include/ddk/wdm.h | 1 + 3 files changed, 218 insertions(+), 1 deletion(-)
On 14/09/18 13:59, Aric Stewart wrote:
Signed-off-by: Aric Stewart aric@codeweavers.com
dlls/ntoskrnl.exe/ntoskrnl.c | 216 ++++++++++++++++++++++++++++++++++++ dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 +- include/ddk/wdm.h | 1 + 3 files changed, 218 insertions(+), 1 deletion(-)
Can this go directly through setupapi instead?
On 9/14/18 2:02 PM, Zebediah Figura wrote:
On 14/09/18 13:59, Aric Stewart wrote:
Signed-off-by: Aric Stewart aric@codeweavers.com
dlls/ntoskrnl.exe/ntoskrnl.c | 216 ++++++++++++++++++++++++++++++++++++ dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 +- include/ddk/wdm.h | 1 + 3 files changed, 218 insertions(+), 1 deletion(-)
Can this go directly through setupapi instead?
Sorry, I dont know if I understand your question...
What do you mean go through setupapi? Not that we have or enforce this in any way, but technically setupapi is user level and IoRegisterDeviceInterface is kernel level.
-aric
On 17/09/18 11:44, Aric Stewart wrote:
On 9/14/18 2:02 PM, Zebediah Figura wrote:
On 14/09/18 13:59, Aric Stewart wrote:
Signed-off-by: Aric Stewart aric@codeweavers.com
dlls/ntoskrnl.exe/ntoskrnl.c | 216 ++++++++++++++++++++++++++++++++++++ dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 +- include/ddk/wdm.h | 1 + 3 files changed, 218 insertions(+), 1 deletion(-)
Can this go directly through setupapi instead?
Sorry, I dont know if I understand your question...
What do you mean go through setupapi? Not that we have or enforce this in any way, but technically setupapi is user level and IoRegisterDeviceInterface is kernel level.
-aric
I mean that we could implement this on top of setupapi routines instead of essentially reimplementing them here. I know that it's architecturally upside-down, but we call call user-mode functions elsewhere in ntoskrnl, and as long as we're going to keep drivers in user-mode I don't see any reason to avoid that.
On 9/17/18 11:55 AM, Zebediah Figura wrote:
On 17/09/18 11:44, Aric Stewart wrote:
On 9/14/18 2:02 PM, Zebediah Figura wrote:
On 14/09/18 13:59, Aric Stewart wrote:
Signed-off-by: Aric Stewart aric@codeweavers.com
dlls/ntoskrnl.exe/ntoskrnl.c | 216 ++++++++++++++++++++++++++++++++++++ dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 +- include/ddk/wdm.h | 1 + 3 files changed, 218 insertions(+), 1 deletion(-)
Can this go directly through setupapi instead?
Sorry, I dont know if I understand your question...
What do you mean go through setupapi? Not that we have or enforce this in any way, but technically setupapi is user level and IoRegisterDeviceInterface is kernel level.
-aric
I mean that we could implement this on top of setupapi routines instead of essentially reimplementing them here. I know that it's architecturally upside-down, but we call call user-mode functions elsewhere in ntoskrnl, and as long as we're going to keep drivers in user-mode I don't see any reason to avoid that.
Yeah, Looking at the SetupDiCreateDeviceInterfaceW APIs in setupapi I can see how you think that. They where clearly the inspiration and base for my work. However the top level entry points vary quite a bit. BOOL WINAPI SetupDiCreateDeviceInterfaceW(HDEVINFO DeviceInfoSet, PSP_DEVINFO_DATA DeviceInfoData, const GUID *InterfaceClassGuid, PCWSTR ReferenceString, DWORD CreationFlags, SP_DEVICE_INTERFACE_DATA *iface_data) vs NTSTATUS WINAPI IoRegisterDeviceInterface(DEVICE_OBJECT *device, const GUID *class_guid, UNICODE_STRING *reference_string, UNICODE_STRING *symbolic_link)
Because creating WINE custom entry points into existing dlls is frowned upon I felt it easier to reimplement instead of try to shoehorn. However if you are seeing something I did not then maybe it should be done differently!
-aric
On 17/09/18 13:20, Aric Stewart wrote:
On 9/17/18 11:55 AM, Zebediah Figura wrote:
On 17/09/18 11:44, Aric Stewart wrote:
On 9/14/18 2:02 PM, Zebediah Figura wrote:
On 14/09/18 13:59, Aric Stewart wrote:
Signed-off-by: Aric Stewart aric@codeweavers.com
dlls/ntoskrnl.exe/ntoskrnl.c | 216 ++++++++++++++++++++++++++++++++++++ dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 +- include/ddk/wdm.h | 1 + 3 files changed, 218 insertions(+), 1 deletion(-)
Can this go directly through setupapi instead?
Sorry, I dont know if I understand your question...
What do you mean go through setupapi? Not that we have or enforce this in any way, but technically setupapi is user level and IoRegisterDeviceInterface is kernel level.
-aric
I mean that we could implement this on top of setupapi routines instead of essentially reimplementing them here. I know that it's architecturally upside-down, but we call call user-mode functions elsewhere in ntoskrnl, and as long as we're going to keep drivers in user-mode I don't see any reason to avoid that.
Yeah, Looking at the SetupDiCreateDeviceInterfaceW APIs in setupapi I can see how you think that. They where clearly the inspiration and base for my work. However the top level entry points vary quite a bit. BOOL WINAPI SetupDiCreateDeviceInterfaceW(HDEVINFO DeviceInfoSet, PSP_DEVINFO_DATA DeviceInfoData, const GUID *InterfaceClassGuid, PCWSTR ReferenceString, DWORD CreationFlags, SP_DEVICE_INTERFACE_DATA *iface_data) vs NTSTATUS WINAPI IoRegisterDeviceInterface(DEVICE_OBJECT *device, const GUID *class_guid, UNICODE_STRING *reference_string, UNICODE_STRING *symbolic_link)
Because creating WINE custom entry points into existing dlls is frowned upon I felt it easier to reimplement instead of try to shoehorn. However if you are seeing something I did not then maybe it should be done differently!
-aric
Hmm, right, I see that setupapi doesn't expose a way to specify the symbolic link.
Another alternative is to implement some of setupapi on top of ntoskrnl, though I'm not sure to what degree that's worth doing.
On 9/17/18 1:39 PM, Zebediah Figura wrote:
On 17/09/18 13:20, Aric Stewart wrote:
On 9/17/18 11:55 AM, Zebediah Figura wrote:
On 17/09/18 11:44, Aric Stewart wrote:
On 9/14/18 2:02 PM, Zebediah Figura wrote:
On 14/09/18 13:59, Aric Stewart wrote:
Signed-off-by: Aric Stewart aric@codeweavers.com
dlls/ntoskrnl.exe/ntoskrnl.c | 216 ++++++++++++++++++++++++++++++++++++ dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 +- include/ddk/wdm.h | 1 + 3 files changed, 218 insertions(+), 1 deletion(-)Can this go directly through setupapi instead?
Sorry, I dont know if I understand your question...
What do you mean go through setupapi? Not that we have or enforce this in any way, but technically setupapi is user level and IoRegisterDeviceInterface is kernel level.
-aric
I mean that we could implement this on top of setupapi routines instead of essentially reimplementing them here. I know that it's architecturally upside-down, but we call call user-mode functions elsewhere in ntoskrnl, and as long as we're going to keep drivers in user-mode I don't see any reason to avoid that.
Yeah, Looking at the SetupDiCreateDeviceInterfaceW APIs in setupapi I can see how you think that. They where clearly the inspiration and base for my work. However the top level entry points vary quite a bit. BOOL WINAPI SetupDiCreateDeviceInterfaceW(HDEVINFO DeviceInfoSet, PSP_DEVINFO_DATA DeviceInfoData, const GUID *InterfaceClassGuid, PCWSTR ReferenceString, DWORD CreationFlags, SP_DEVICE_INTERFACE_DATA *iface_data) vs NTSTATUS WINAPI IoRegisterDeviceInterface(DEVICE_OBJECT *device, const GUID *class_guid, UNICODE_STRING *reference_string, UNICODE_STRING *symbolic_link)
Because creating WINE custom entry points into existing dlls is frowned upon I felt it easier to reimplement instead of try to shoehorn. However if you are seeing something I did not then maybe it should be done differently!
-aric
Hmm, right, I see that setupapi doesn't expose a way to specify the symbolic link.
Another alternative is to implement some of setupapi on top of ntoskrnl, though I'm not sure to what degree that's worth doing.
Agreed, I do not know how much it is worth doing. I think having them be parallel is just fine.
-aric
On 17/09/18 13:39, Zebediah Figura wrote:
On 17/09/18 13:20, Aric Stewart wrote:
On 9/17/18 11:55 AM, Zebediah Figura wrote:
On 17/09/18 11:44, Aric Stewart wrote:
On 9/14/18 2:02 PM, Zebediah Figura wrote:
On 14/09/18 13:59, Aric Stewart wrote:
Signed-off-by: Aric Stewart aric@codeweavers.com
dlls/ntoskrnl.exe/ntoskrnl.c | 216 ++++++++++++++++++++++++++++++++++++ dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 2 +- include/ddk/wdm.h | 1 + 3 files changed, 218 insertions(+), 1 deletion(-)
Can this go directly through setupapi instead?
Sorry, I dont know if I understand your question...
What do you mean go through setupapi? Not that we have or enforce this in any way, but technically setupapi is user level and IoRegisterDeviceInterface is kernel level.
-aric
I mean that we could implement this on top of setupapi routines instead of essentially reimplementing them here. I know that it's architecturally upside-down, but we call call user-mode functions elsewhere in ntoskrnl, and as long as we're going to keep drivers in user-mode I don't see any reason to avoid that.
Yeah, Looking at the SetupDiCreateDeviceInterfaceW APIs in setupapi I can see how you think that. They where clearly the inspiration and base for my work. However the top level entry points vary quite a bit. BOOL WINAPI SetupDiCreateDeviceInterfaceW(HDEVINFO DeviceInfoSet, PSP_DEVINFO_DATA DeviceInfoData, const GUID *InterfaceClassGuid, PCWSTR ReferenceString, DWORD CreationFlags, SP_DEVICE_INTERFACE_DATA *iface_data) vs NTSTATUS WINAPI IoRegisterDeviceInterface(DEVICE_OBJECT *device, const GUID *class_guid, UNICODE_STRING *reference_string, UNICODE_STRING *symbolic_link)
Because creating WINE custom entry points into existing dlls is frowned upon I felt it easier to reimplement instead of try to shoehorn. However if you are seeing something I did not then maybe it should be done differently!
-aric
Hmm, right, I see that setupapi doesn't expose a way to specify the symbolic link.
Another alternative is to implement some of setupapi on top of ntoskrnl, though I'm not sure to what degree that's worth doing.
Actually, now that I actually look at the documentation for this function, symbolic_link is an output parameter. So it should be perfectly possible to use SetupDiCreateDeviceInterface() to register the interface and SetupDiGetDeviceInterfaceDetail() to retrieve the symbolic link.
-
Aric Stewart -
Zebediah Figura