Currently, we have hooklib/setupapi handling handles IIDX ezusb1/2 and jubeat P4IO, and, upcoming with a PR, a separate iidxhook8/setupapi hook for handling IIDX bio2. This isn't a great issue right now, but once we need to either re-use or copy/paste this with slight tweaks for more USB devices, we should consider a refactoring to either:
Merge them all into a single setupapi module
Properly split them to copy-pastes for each game only covering what they need to emulate
I would like to a avoid a mixed approach with some impls re-used and a few copy-pasted ones.
Currently, we have hooklib/setupapi handling handles IIDX ezusb1/2 and jubeat P4IO, and, upcoming with a PR, a separate iidxhook8/setupapi hook for handling IIDX bio2. This isn't a great issue right now, but once we need to either re-use or copy/paste this with slight tweaks for more USB devices, we should consider a refactoring to either:
- Merge them all into a single setupapi module
- Properly split them to copy-pastes for each game only covering what they need to emulate
<br>
I would like to a avoid a mixed approach with some impls re-used and a few copy-pasted ones.
I would strongly recommend making separate boilerplate setupapi hooks for each of our Xemu static libraries a la p3ioemu/devmgr.c.
While some Win32 APIs are small and orthogonal enough that they can be hooked universally setupapi is not one of them. It has a massive API surface and data model, and some games (iidx25+ I think?) even use the ancient Win95-era "Configuration Manager" API as well (the one whose identifiers start with CM_). We cannot realistically emulate anything close to the entire API so our best bet is to write hooks designed to mate with particular code sequences in particular games.
In GitLab by @tau on Oct 13, 2019, 19:24
I would strongly recommend making separate boilerplate setupapi hooks for each of our Xemu static libraries a la p3ioemu/devmgr.c.
While some Win32 APIs are small and orthogonal enough that they can be hooked universally setupapi is not one of them. It has a massive API surface and data model, and some games (iidx25+ I think?) even use the ancient Win95-era "Configuration Manager" API as well (the one whose identifiers start with CM_). We cannot realistically emulate anything close to the entire API so our best bet is to write hooks designed to mate with particular code sequences in particular games.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Currently, we have hooklib/setupapi handling handles IIDX ezusb1/2 and jubeat P4IO, and, upcoming with a PR, a separate iidxhook8/setupapi hook for handling IIDX bio2. This isn't a great issue right now, but once we need to either re-use or copy/paste this with slight tweaks for more USB devices, we should consider a refactoring to either:
I would like to a avoid a mixed approach with some impls re-used and a few copy-pasted ones.
In GitLab by @tau on Oct 13, 2019, 19:24
I would strongly recommend making separate boilerplate setupapi hooks for each of our Xemu static libraries a la p3ioemu/devmgr.c.
While some Win32 APIs are small and orthogonal enough that they can be hooked universally setupapi is not one of them. It has a massive API surface and data model, and some games (iidx25+ I think?) even use the ancient Win95-era "Configuration Manager" API as well (the one whose identifiers start with CM_). We cannot realistically emulate anything close to the entire API so our best bet is to write hooks designed to mate with particular code sequences in particular games.
Great input, thanks.