Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.

[Vibhav Pant (＠vibhavp)]

> I don't think adding custom structs is justified at this point, especially as it requires rewriting large parts of the code in multiple modules at the same time.

`wine/dbt.h` doesn't really _add_ a new struct. It merely makes `struct device_notification_details` a common public declaration. The struct is currently [a private def in `dlls/sechost/service.c`](https://gitlab.winehq.org/wine/wine/-/blob/055bddab4f14a1f73e887b88b86408d65...), and needs to be defined again for any component that utilizes `I_ScRegisterDeviceNotification`. [`dlls/user32/input.c` seems to be the only place where it gets used ATM](https://gitlab.winehq.org/wine/wine/-/blob/055bddab4f14a1f73e887b88b86408d65...), and the motivation behind shifting the definition to a common header was to preempt the possibility of the struct's definition accidentally diverging in the future.
> However, passing process-private handles around ~~to other processes~~ and later getting them back looks wrong. What happens if you register for notification on a handle then close it right away? Does the notification keep firing with the old handle value? It seem surprising and it would be a nice thing to test for instance.

Yeah, this is something I've been curious about as well. I suppose one way to test this would be to also add an implementation for`IoReportTargetDeviceChange` (thanks @zfigura!) to this MR, and test `RegisterDeviceNotification`'s behavior in `dlls/ntoskrnl.exe/tests/driver_pnp.c`.