An application that I have here checks comctl32.dll version information and refuses to run, changing DLL version to 6.0 makes it run.
Signed-off-by: Dmitry Timoshkov dmitry@baikal.ru --- dlls/comctl32/comctl32.h | 2 +- dlls/comctl32/comctl32.rc | 2 +- include/commctrl.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dlls/comctl32/comctl32.h b/dlls/comctl32/comctl32.h index f3e889c4bd..ca1738085a 100644 --- a/dlls/comctl32/comctl32.h +++ b/dlls/comctl32/comctl32.h @@ -192,7 +192,7 @@ INT Str_GetPtrAtoW (LPCSTR lpSrc, LPWSTR lpDest, INT nMaxLen) DECLSPEC_HIDDEN; BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCSTR lpSrc) DECLSPEC_HIDDEN; BOOL Str_SetPtrWtoA (LPSTR *lppDest, LPCWSTR lpSrc) DECLSPEC_HIDDEN;
-#define COMCTL32_VERSION_MINOR 81 +#define COMCTL32_VERSION_MINOR 0
/* Our internal stack structure of the window procedures to subclass */ typedef struct _SUBCLASSPROCS { diff --git a/dlls/comctl32/comctl32.rc b/dlls/comctl32/comctl32.rc index c9aa1ba625..be6e242519 100644 --- a/dlls/comctl32/comctl32.rc +++ b/dlls/comctl32/comctl32.rc @@ -114,7 +114,7 @@ LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL #define WINE_FILEDESCRIPTION_STR "Wine Common Controls" #define WINE_FILENAME_STR "comctl32.dll" #define WINE_FILEVERSION COMCTL32_VERSION, COMCTL32_VERSION_MINOR, 4704, 1100 -#define WINE_FILEVERSION_STR "5.81" +#define WINE_FILEVERSION_STR "6.00.4704.1100" #define WINE_PRODUCTVERSION WINE_FILEVERSION #define WINE_PRODUCTVERSION_STR WINE_FILEVERSION_STR
diff --git a/include/commctrl.h b/include/commctrl.h index 700b335fbb..029a4b4545 100644 --- a/include/commctrl.h +++ b/include/commctrl.h @@ -51,7 +51,7 @@ enum _LI_METRIC HRESULT WINAPI LoadIconWithScaleDown(HINSTANCE, const WCHAR *, int, int, HICON *); HRESULT WINAPI LoadIconMetric(HINSTANCE, const WCHAR *, int, HICON *);
-#define COMCTL32_VERSION 5 /* dll version */ +#define COMCTL32_VERSION 6 /* dll version */
#ifndef _WIN32_IE #define _WIN32_IE 0x0400
On Tue, Nov 12, 2019 at 1:13 PM Dmitry Timoshkov dmitry@baikal.ru wrote:
An application that I have here checks comctl32.dll version information and refuses to run, changing DLL version to 6.0 makes it run.
Signed-off-by: Dmitry Timoshkov dmitry@baikal.ru
dlls/comctl32/comctl32.h | 2 +- dlls/comctl32/comctl32.rc | 2 +- include/commctrl.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dlls/comctl32/comctl32.h b/dlls/comctl32/comctl32.h index f3e889c4bd..ca1738085a 100644 --- a/dlls/comctl32/comctl32.h +++ b/dlls/comctl32/comctl32.h @@ -192,7 +192,7 @@ INT Str_GetPtrAtoW (LPCSTR lpSrc, LPWSTR lpDest, INT nMaxLen) DECLSPEC_HIDDEN; BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCSTR lpSrc) DECLSPEC_HIDDEN; BOOL Str_SetPtrWtoA (LPSTR *lppDest, LPCWSTR lpSrc) DECLSPEC_HIDDEN;
-#define COMCTL32_VERSION_MINOR 81 +#define COMCTL32_VERSION_MINOR 0
/* Our internal stack structure of the window procedures to subclass */ typedef struct _SUBCLASSPROCS { diff --git a/dlls/comctl32/comctl32.rc b/dlls/comctl32/comctl32.rc index c9aa1ba625..be6e242519 100644 --- a/dlls/comctl32/comctl32.rc +++ b/dlls/comctl32/comctl32.rc @@ -114,7 +114,7 @@ LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL #define WINE_FILEDESCRIPTION_STR "Wine Common Controls" #define WINE_FILENAME_STR "comctl32.dll" #define WINE_FILEVERSION COMCTL32_VERSION, COMCTL32_VERSION_MINOR, 4704, 1100 -#define WINE_FILEVERSION_STR "5.81" +#define WINE_FILEVERSION_STR "6.00.4704.1100" #define WINE_PRODUCTVERSION WINE_FILEVERSION #define WINE_PRODUCTVERSION_STR WINE_FILEVERSION_STR
diff --git a/include/commctrl.h b/include/commctrl.h index 700b335fbb..029a4b4545 100644 --- a/include/commctrl.h +++ b/include/commctrl.h @@ -51,7 +51,7 @@ enum _LI_METRIC HRESULT WINAPI LoadIconWithScaleDown(HINSTANCE, const WCHAR *, int, int, HICON *); HRESULT WINAPI LoadIconMetric(HINSTANCE, const WCHAR *, int, HICON *);
-#define COMCTL32_VERSION 5 /* dll version */ +#define COMCTL32_VERSION 6 /* dll version */
So which one does it check, resources or DllGetVersion()?
#ifndef _WIN32_IE
#define _WIN32_IE 0x0400
2.20.1
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=59876
Your paranoid android.
=== debian10 (build log) ===
Task: Patch failed to apply
=== debian10 (build log) ===
Task: Patch failed to apply
Nikolay Sivov bunglehead@gmail.com wrote:
On Tue, Nov 12, 2019 at 1:13 PM Dmitry Timoshkov dmitry@baikal.ru wrote:
An application that I have here checks comctl32.dll version information and refuses to run, changing DLL version to 6.0 makes it run.
...
So which one does it check, resources or DllGetVersion()?
It checks the version information in the DLL resources (GetFileVersionInfo).
On Tue, Nov 12, 2019 at 3:55 PM Dmitry Timoshkov dmitry@baikal.ru wrote:
Nikolay Sivov bunglehead@gmail.com wrote:
On Tue, Nov 12, 2019 at 1:13 PM Dmitry Timoshkov dmitry@baikal.ru
wrote:
An application that I have here checks comctl32.dll version information and refuses to run, changing DLL version to 6.0 makes it run.
...
So which one does it check, resources or DllGetVersion()?
It checks the version information in the DLL resources (GetFileVersionInfo).
In that case I'd suggest to have it tested in staging first, at least until next stable release. It's not an ordinary dll version change because it's up to application to request it.
-- Dmitry.
Nikolay Sivov bunglehead@gmail.com wrote:
An application that I have here checks comctl32.dll version information and refuses to run, changing DLL version to 6.0 makes it run.
...
So which one does it check, resources or DllGetVersion()?
It checks the version information in the DLL resources (GetFileVersionInfo).
In that case I'd suggest to have it tested in staging first, at least until next stable release. It's not an ordinary dll version change because it's up to application to request it.
I have another suggestion: We have a rule to revert patches that cause regressions, it would be better IMO to accept this patch in main tree, test it, and if it will cause regressions for a wide range of applications then revert it before the code freeze.
Dmitry Timoshkov dmitry@baikal.ru writes:
Nikolay Sivov bunglehead@gmail.com wrote:
An application that I have here checks comctl32.dll version information and refuses to run, changing DLL version to 6.0 makes it run.
...
So which one does it check, resources or DllGetVersion()?
It checks the version information in the DLL resources (GetFileVersionInfo).
In that case I'd suggest to have it tested in staging first, at least until next stable release. It's not an ordinary dll version change because it's up to application to request it.
I have another suggestion: We have a rule to revert patches that cause regressions, it would be better IMO to accept this patch in main tree, test it, and if it will cause regressions for a wide range of applications then revert it before the code freeze.
No, we don't have such a rule; in fact, reverts are strongly discouraged.
If a change to fix app A breaks app B, reverting it to repair app B would break app A again. That doesn't get us any closer to our goal of supporting both apps, and there's no good way of deciding which of A or B is less important and deserves to remain broken.
So if a change is expected to break something, we should take steps to avoid that *before* committing it.
Alexandre Julliard julliard@winehq.org wrote:
An application that I have here checks comctl32.dll version information and refuses to run, changing DLL version to 6.0 makes it run.
...
So which one does it check, resources or DllGetVersion()?
It checks the version information in the DLL resources (GetFileVersionInfo).
In that case I'd suggest to have it tested in staging first, at least until next stable release. It's not an ordinary dll version change because it's up to application to request it.
I have another suggestion: We have a rule to revert patches that cause regressions, it would be better IMO to accept this patch in main tree, test it, and if it will cause regressions for a wide range of applications then revert it before the code freeze.
No, we don't have such a rule; in fact, reverts are strongly discouraged.
If a change to fix app A breaks app B, reverting it to repair app B would break app A again. That doesn't get us any closer to our goal of supporting both apps, and there's no good way of deciding which of A or B is less important and deserves to remain broken.
So if a change is expected to break something, we should take steps to avoid that *before* committing it.
Personaly I don't expect this patch to break something.
Personaly I don't expect this patch to break something.
When some programs expect a comctl32 v6, it's to be expected some expect a comctl32 v5. AFAIK the proper fix would be to separate comctl32, so we have both v5 and v6.
Regards, Fabian Maurer
Fabian Maurer dark.shadow4@web.de wrote:
Personaly I don't expect this patch to break something.
When some programs expect a comctl32 v6, it's to be expected some expect a comctl32 v5.
Do you have an example of such an application?
AFAIK the proper fix would be to separate comctl32, so we have both v5 and v6.
Probably, however current maintainer seems to prefer to postpone this forever.
On Donnerstag, 14. November 2019 03:34:28 CET you wrote:
Fabian Maurer dark.shadow4@web.de wrote:
Personaly I don't expect this patch to break something.
When some programs expect a comctl32 v6, it's to be expected some expect a comctl32 v5.
Do you have an example of such an application?
No I don't. As I said, it just seems like a logical assumption.
AFAIK the proper fix would be to separate comctl32, so we have both v5 and v6.
Probably, however current maintainer seems to prefer to postpone this forever.
What makes you say that?
Regards, Fabian Maurer
Fabian Maurer dark.shadow4@web.de wrote:
AFAIK the proper fix would be to separate comctl32, so we have both v5 and v6.
Probably, however current maintainer seems to prefer to postpone this forever.
What makes you say that?
I don't see this as a being worked on target, am I missing something?
fOn Thu, Nov 14, 2019 at 9:09 PM Dmitry Timoshkov dmitry@baikal.ru wrote:
Fabian Maurer dark.shadow4@web.de wrote:
AFAIK the proper fix would be to separate comctl32, so we have both
v5 and
v6.
Probably, however current maintainer seems to prefer to postpone this forever.
What makes you say that?
I don't see this as a being worked on target, am I missing something?
While I understand your frustration, I would like to point out that there are plenty of winapi features that aren't being worked on, but that doesn't mean they're delayed forever.
I.e., https://bugs.winehq.org/show_bug.cgi?id=421
Austin English austinenglish@gmail.com wrote:
AFAIK the proper fix would be to separate comctl32, so we have both
v5 and
v6.
Probably, however current maintainer seems to prefer to postpone this forever.
What makes you say that?
I don't see this as a being worked on target, am I missing something?
While I understand your frustration, I would like to point out that there are plenty of winapi features that aren't being worked on, but that doesn't mean they're delayed forever.
You've probably got me wrong, there's no any frustration at all. It's nice to have a patch accepted to main tree, but that's certainly not a requirement any longer at least for me. As for this particular patch it seems to me that the concern about possible regressions is mostly a speculation, while as was originally stated the patch fixes at least one real application.
-
Alexandre Julliard -
Austin English -
Dmitry Timoshkov -
Fabian Maurer -
Marvin -
Nikolay Sivov