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@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.