From: Fabian Maurer dark.shadow4@web.de
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45455 --- dlls/setupapi/query.c | 10 ++++++++++ dlls/setupapi/setupapi.spec | 1 + 2 files changed, 11 insertions(+)
diff --git a/dlls/setupapi/query.c b/dlls/setupapi/query.c index 88efea17473..d8571e0c7b4 100644 --- a/dlls/setupapi/query.c +++ b/dlls/setupapi/query.c @@ -732,6 +732,16 @@ BOOL WINAPI SetupGetInfDriverStoreLocationW( return FALSE; }
+HRESULT WINAPI DriverStoreFindDriverPackageW(WCHAR *path_in, void *unk2, void *unk3, DWORD flags, void *unk5, WCHAR *path_out, DWORD *path_size) +{ + FIXME("%s, %p, %p, %lu, %p, %p, %p, %lu stub!\n", debugstr_w(path_in), unk2, unk3, flags, unk5, path_out, path_size, path_size ? *path_size : 0); + if (!path_in || !path_out || !path_size) + return E_INVALIDARG; + + wcscpy(path_out, path_in); + return S_OK; +} + BOOL WINAPI SetupQueryInfVersionInformationA(SP_INF_INFORMATION *info, UINT index, const char *key, char *buff, DWORD size, DWORD *req_size) { diff --git a/dlls/setupapi/setupapi.spec b/dlls/setupapi/setupapi.spec index 7578fb25c9c..f80d389daac 100644 --- a/dlls/setupapi/setupapi.spec +++ b/dlls/setupapi/setupapi.spec @@ -208,6 +208,7 @@ @ stub DelimStringToMultiSz @ stub DestroyTextFileReadBuffer @ stdcall DoesUserHavePrivilege(wstr) +@ stdcall DriverStoreFindDriverPackageW(ptr ptr ptr long ptr ptr ptr) @ stdcall DuplicateString(wstr) @ stdcall EnablePrivilege(wstr long) @ stub ExtensionPropSheetPageProc
Hi,
It looks like your patch introduced the new failures shown below. Please investigate and fix them before resubmitting your patch. If they are not new, fixing them anyway would help a lot. Otherwise please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=139685
Your paranoid android.
=== debian11b (64 bit WoW report) ===
dinput: device8.c:2238: Test failed: 0x700: got key_state[0] 0
Does this actually let the driver install successfully, or does it just avoid the crash?
Unless the driver actually works I don't think this stub makes sense.
From the bug report:
This fixes the issue for me, both in the linked installer and in LabView.
On Thu Nov 9 01:37:31 2023 +0000, Zebediah Figura wrote:
Does this actually let the driver install successfully, or does it just avoid the crash? Unless the driver actually works I don't think this stub makes sense.
They are registered in that fake DriverStore path. I don't expect the drivers themselves to be usable, but that would be a different issue. Main point for me is, that installing those drivers is what's currently blocking the labview installer. And labview itself doesn't need that driver, it should only be needed for some optional additional devices.
On Thu Nov 9 01:37:30 2023 +0000, Fabian Maurer wrote:
They are registered in that fake DriverStore path. I don't expect the drivers themselves to be usable, but that would be a different issue. Main point for me is, that installing those drivers is what's currently blocking the labview installer. And labview itself doesn't need that driver, it should only be needed for some optional additional devices.
Yes, this all started because I need to run a program written in LabView that does not depend on any peripheral hardware, but the LabView installer wants to install its drivers no matter what.
Alex Henrie (@alexhenrie) commented about dlls/setupapi/query.c:
return FALSE;}
+HRESULT WINAPI DriverStoreFindDriverPackageW(WCHAR *path_in, void *unk2, void *unk3, DWORD flags, void *unk5, WCHAR *path_out, DWORD *path_size) +{
- FIXME("%s, %p, %p, %lu, %p, %p, %p, %lu stub!\n", debugstr_w(path_in), unk2, unk3, flags, unk5, path_out, path_size, path_size ? *path_size : 0);
- if (!path_in || !path_out || !path_size)
return E_INVALIDARG;
There should probably be a couple of tests that call this function and check for E_INVALIDARG. The tests would show that we have at least a vague idea of what the parameters do, and they would prove that calling the function with the cleanly-reverse-engineered signature does not crash. I suspect that DriverStoreFindDriverPackageW also returns E_INVALIDARG when *path_in or *path_size is 0, so I think it would be a good idea to check that too.
Alex Henrie (@alexhenrie) commented about dlls/setupapi/query.c:
return FALSE;}
+HRESULT WINAPI DriverStoreFindDriverPackageW(WCHAR *path_in, void *unk2, void *unk3, DWORD flags, void *unk5, WCHAR *path_out, DWORD *path_size) +{
- FIXME("%s, %p, %p, %lu, %p, %p, %p, %lu stub!\n", debugstr_w(path_in), unk2, unk3, flags, unk5, path_out, path_size, path_size ? *path_size : 0);
- if (!path_in || !path_out || !path_size)
return E_INVALIDARG;- wcscpy(path_out, path_in);
- return S_OK;
Do you have any idea what the function returns if it fails to find the driver? I wonder if the LabView installer would work if we returned that specific error code instead of copying path_in to path_out.
I left a couple of comments on the code but overall this patch looks great. Thanks Fabian!
On Thu Nov 9 04:51:47 2023 +0000, Alex Henrie wrote:
Do you have any idea what the function returns if it fails to find the driver? I wonder if the LabView installer would work if we returned that specific error code instead of copying path_in to path_out.
I think I tried that, but I'll recheck to make sure! I'll add the tests in the next days, and report back regarding the error code.
On Thu Nov 9 18:55:06 2023 +0000, Fabian Maurer wrote:
I think I tried that, but I'll recheck to make sure! I'll add the tests in the next days, and report back regarding the error code.
I just checked, it deosn't work with an error code. We need to fake success.
-
Alex Henrie (＠alexhenrie) -
Etaash Mathamsetty (＠etaash.mathamsetty)
-
Fabian Maurer
-
Fabian Maurer (＠DarkShadow44)
-
Marvin -
Zebediah Figura (＠zfigura)