Wine's wusa currently passes the full cabinet path as the `pszCabinet` argument to `FDICopy()` and passes `NULL` as `pszCabPath`. This works with Wine's builtin cabinet implementation, but it does not match the documented FDICopy parameter usage. `FDICopy()` expects `pszCabinet` to contain only the cabinet file name, while `pszCabPath` contains the directory path. Wine's own FDICopy API documentation follows that convention, describing `pszCabinet` as the cabinet filename and `pszCabPath` as the cabinet file path. Microsoft's FDI documentation is more explicit: `pszCabinet` is the cabinet file name excluding path information, and `pszCabPath` is the cabinet path excluding the file name. The full cabinet path is then constructed internally by appending `pszCabinet` to `pszCabPath`. `pszCabPath` is an input `LPSTR` parameter and is not documented as optional. Passing `NULL` is therefore outside the documented API behavior, even though Wine's builtin cabinet.dll currently tolerates it. Native cabinet.dll crashes in this context. These changes are based on the existing path-splitting pattern used by `SetupIterateCabinetA()` in `dlls/setupapi/setupcab.c`, as well as the FDI resource-handling pattern used by `extract_cabinet()` in `dlls/msi/media.c`: - resolve the input path with `GetFullPathNameA()`; - split the result into `pszCabPath` and `pszCabinet`; - pass both values separately to `FDICopy()`; - release allocated memory on failure paths; - destroy the FDI context after `FDICopy()`, regardless of whether extraction succeeds. This improves compatibility with native cabinet.dll, which does not tolerate passing `NULL` for `pszCabPath` in this context. After applying this patch both native (from VistaSP1 and Win7SP1) and built-in cabinet.dll allow the graceful execution of wusa.exe -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10760