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

[Zebediah Figura (she/her)]

On 3/22/21 11:23 AM, Rémi Bernon wrote:
> On 3/22/21 4:42 PM, Zebediah Figura (she/her) wrote:
>> 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.)
>>
> 
> Well, I don't know, it's probably never going to be the case but one
> could argue that it should be possible to have a what.ever.drv module,
> with "MODULE = what.ever.drv" and "TESTDLL = what.ever.drv" in the tests
> Makefile and that it should work too.
> 
> In makedep.c we create test executable names by removing ".dll" from
> "TESTDLL", and it doesn't matter how the directory is named (the tests
> could even very well be located in a completely unrelated folder).
> 
> I think the correct fix is either to make sure the testbot
> scripts/winetest are able to make the same transformation from the
> TESTDLL variable, or change this makedep.c logic to always put the full
> dll name in the test executable name, so that the testbot/winetest can
> deduce it back from it.
> 

That, or makedep.c does the same transformation as I'm envisioning, and 
only strips .dll from a test DLL name if there's no other dots (so e.g. 
quartz_test.exe, but windows.gaming.input.dll_test.exe).