[PATCH] winetest: Guess when to append the .dll extension.

[Zebediah Figura (she/her)]

On 3/22/21 5:39 AM, Rémi Bernon wrote:
> On 3/22/21 11:28 AM, Francois Gouget wrote:
>> On Sun, 21 Mar 2021, Zebediah Figura (she/her) wrote:
>>
>>> On 3/21/21 1:11 PM, Francois Gouget wrote:
>>>> WineTest derives the dll name from the test executable filename. However
>>>> the '.dll' extension is omitted in the executable filename. So if the
>>>> guessed library name does not already have a three-letter extension
>>>> (such as .ocx, .sys, etc.), assume it should have the '.dll' extension.
>>>>
>>>> Signed-off-by: Francois Gouget <fgouget at codeweavers.com>
>>>> ---
>>>> This allows WineTest to retrieve the version information for
>>>> windows.media.speech.dll.
>>>> This is pretty ugly but at least it's a simple patch. Plus three
>>>> letters should be enough for any library extension ;-)
>>>> ---
>>>>     programs/winetest/main.c | 10 +++++++++-
>>>>     1 file changed, 9 insertions(+), 1 deletion(-)
>>>>
>>>
>>> I don't know if any WinRT DLLs end in a three-letter word, but it seems not
>>> implausible...
>>>
>>> Wouldn't it be more consistent and easier just to name the directory
>>> "windows.media.speech.dll", and the test "windows.media.speech.dll_test.exe",
>>> and then the rule everywhere becomes "if there's no dot in the name already,
>>> append .dll or .exe"?
>>
>> That's how Rémi's patches started but then they switched to not
>> including the trailing .dll.
>>
>> Compare: https://www.winehq.org/pipermail/wine-devel/2021-March/182127.html
>> To:      https://www.winehq.org/pipermail/wine-devel/2021-March/182686.html
>>
>> Apparently there was also a setupapi issue (which he fixed) but
>> presumably there was a decision at some point to keep omitting the .dll
>> extension (I don't see it in the mailing list archives though).
>>
> 
> Yes, omitting the .dll extension was done because of how differently
> winetest computes the test executable names compared to winebuild. The
> testbot uses (used?) the module directory name, while winebuild uses the
> TESTDLL makefile variable (which could be different). It was easier imho
> to just use the existing logic and not use .dll in the folder names.
> 
> Also all other modules have an implicit .dll extension, unless otherwise
> specified. It seemed more consistent to have the implicit .dll extension
> for these modules too (considering that the extension is what differs
> between the module folder and the MODULE makefile variable, not
> something about dots in the name).
> 
> There's also several other places where the implicit .dll is used (ntdll
> loader code for instance, when looking for modules in the build tree,
> which I had patches for at some point, but maybe others).
> 

That's the thing—it looks like windows.gaming.input *does* have a 
different extension specified. Obviously we know that .input is not a 
DLL extension (probably), but it's harder for tools (including ntdll and 
setupapi) to be sure of that. I don't see what's wrong with explicitly 
specifying .dll in those cases; that makes everything clear and consistent.

I just realized also that this winetest patch isn't correct as-is; we 
have a DLL called "ksproxy.ax" (although it doesn't have any tests yet.)