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(-)
diff --git a/programs/winetest/main.c b/programs/winetest/main.c index 225e9a2548b..6056dee2a75 100644 --- a/programs/winetest/main.c +++ b/programs/winetest/main.c @@ -901,7 +901,7 @@ extract_test_proc (HMODULE hModule, LPCSTR lpszType, LPSTR lpszName, LONG_PTR lP char filename[MAX_PATH]; WCHAR dllnameW[MAX_PATH]; HMODULE dll; - DWORD err; + DWORD err, len; HANDLE actctx; ULONG_PTR cookie; BOOL run; @@ -912,6 +912,14 @@ extract_test_proc (HMODULE hModule, LPCSTR lpszType, LPSTR lpszName, LONG_PTR lP CharLowerA(lpszName); strcpy(dllname, lpszName); *strstr(dllname, testexe) = 0; + len = strlen(dllname); + if (len >= 4 && dllname[len - 4] != '.') + { + /* If there is not a 3 characters extension already, + * assume it should be .dll. + */ + strcat(dllname, ".dll"); + }
if (test_filtered_out( lpszName, NULL )) {
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"?
diff --git a/programs/winetest/main.c b/programs/winetest/main.c index 225e9a2548b..6056dee2a75 100644 --- a/programs/winetest/main.c +++ b/programs/winetest/main.c @@ -901,7 +901,7 @@ extract_test_proc (HMODULE hModule, LPCSTR lpszType, LPSTR lpszName, LONG_PTR lP char filename[MAX_PATH]; WCHAR dllnameW[MAX_PATH]; HMODULE dll;
- DWORD err;
- DWORD err, len; HANDLE actctx; ULONG_PTR cookie; BOOL run;
@@ -912,6 +912,14 @@ extract_test_proc (HMODULE hModule, LPCSTR lpszType, LPSTR lpszName, LONG_PTR lP CharLowerA(lpszName); strcpy(dllname, lpszName); *strstr(dllname, testexe) = 0;
len = strlen(dllname);
if (len >= 4 && dllname[len - 4] != '.')
{
/* If there is not a 3 characters extension already,* assume it should be .dll.*/strcat(dllname, ".dll");}
if (test_filtered_out( lpszName, NULL )) {
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).
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).
On 3/22/21 11: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.
Maybe not winebuild but makedep.
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).
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.)
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.
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@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).
-
Francois Gouget -
Rémi Bernon -
Zebediah Figura (she/her)