Fix stub DllGetVersion implementation to read Dll version
and put it in correct structure.
Implement GetDllVersion by using DllGetVersion function
and return version
--
v14: cabinet/tests: add tests for DllGetVersion & GetDllVersion
https://gitlab.winehq.org/wine/wine/-/merge_requests/564
Fix stub DllGetVersion implementation to read Dll version
and put it in correct structure.
Implement GetDllVersion by using DllGetVersion function
and return version
--
v12: cabinet/tests: add tests for DllGetVersion & GetDllVersion
https://gitlab.winehq.org/wine/wine/-/merge_requests/564
Fix stub DllGetVersion implementation to read Dll version
and put it in correct structure.
Implement GetDllVersion by using DllGetVersion function
and return version
--
v11: cabinet/tests: add tests for DllGetVersion & GetDllVersion
https://gitlab.winehq.org/wine/wine/-/merge_requests/564
Fix stub DllGetVersion implementation to read Dll version
and put it in correct structure.
Implement GetDllVersion by using DllGetVersion function
and return version
--
v10: cabinet/tests: add tests for DllGetVersion & GetDllVersion
https://gitlab.winehq.org/wine/wine/-/merge_requests/564
Fix stub DllGetVersion implementation to read Dll version
and put it in correct structure.
Implement GetDllVersion by using DllGetVersion function
and return version
--
v9: cabinet/tests: add tests for DllGetVersion & GetDllVersion
https://gitlab.winehq.org/wine/wine/-/merge_requests/564
On Tue Aug 2 05:00:46 2022 +0000, Chip Davis wrote:
> > Is there any way to manually trigger the test bot?
> You can submit patches yourself to [the
> testbot](https://testbot.winehq.org/). Note that you will need an
> account on the testbot in order to do this, which I believe is separate
> from your account here.
> > the pipeline fails due to a (more or less) unrelated issue in another
> dll (msi). They have a function with the same name, DllGetVersion.
> That is because `DllGetVersion()` is also the name of an optional
> function supported by COM server DLLs. That's what those definitions in
> `<shlwapi.h>` are for.
> > Could it be that the dev defined it in shlwapi.h? The issue is that I
> can't define my function correctly with this definition (probably the
> reason why the first implementation used it, wrongly), but they can't
> use it without (or probably can, but didn't).
> Or, you could give `cabinet`'s `DllGetVersion()` a new name, and then in
> `cabinet.spec`, export the new name under the correct name:
> ```
> 2 stdcall -private DllGetVersion(ptr) cabinet_dll_get_version
> ```
> (Why did you remove the ordinals? The commit in which this happened has
> somehow vanished, but I remember seeing that.)
OK, I'll try to submit the patch manually to the test bot to see if it works now as expected :)
Oh, I see, o I should leave the definition of DllGetVersion in it I guess.
Renaming the function in cabinet.dll seems more like a workaround than a fix tbh, but I'll do as you say.
Removing the ordinals didn't have a specific reason, I just noticed that in some spec files there are ordinals and in some there are just @'s. I couldn't find anything on the difference, so I swapped them. Especially since I don't know how to numerate the imports, this seemed easier and worked fine.
Do the ordinals have any meaning/is there a reason to keep them?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/564#note_5485