Can we assume that all MSW applications use an appropriate manifest?

60 views
Skip to first unread message

Vadim Zeitlin

unread,
Nov 10, 2022, 3:50:05 PM11/10/22
to wx-dev
Hello,

I'm trying to get rid of the code required to support obsolete Windows
versions in wxMSW, but while doing it I've realized that in many places we
are actually checking (or should be checking, as it's done wrongly in some
places, e.g. HasNativeCommandLinkButton(), currently) for comctl32.dll
version and not the OS version itself. And this is important because the
applications without a manifest use comctl32.dll v5.82 even under Windows
10 (not sure about 11, but I suspect it's the case even there), i.e. we
still need to keep a lot of code just in case wxMSW is used without a
manifest including "Microsoft.Windows.Common-Controls version=6.0.0.0"
assembly as a dependency.

It would be really nice to not have to deal with these checks neither, but
I'm afraid that there might be some strange use cases in which manifest is
not being used. OTOH it seems stupid to keep this code if nobody actually
does this. Could we, perhaps, try showing an error message during the
library initialization if it detects that it doesn't use comctl32.dll v6?
At least we'd find out pretty quickly if this actually happens in this
case. Or does anybody already know for sure that we need to keep support
for the old comctl32.dll?

Thanks,
VZ

Tobias T

unread,
Nov 11, 2022, 8:07:32 AM11/11/22
to wx-dev
I can't think of use case for not using a manifest (but that certainly doesn't mean there isn't one).

Maybe just start with the runtime version check for comctl32 v6 and log it as an error?
This way a use case may be identified.
If nobody ever complaints the code targeting comctl v5 could then be eliminated later on.
And the check would have to be implemented anyway.

Eric Jensen

unread,
Nov 11, 2022, 8:54:46 AM11/11/22
to Tobias T
Hello,

i'd just like to add one thing to consider:

On the forum it still happens not often, but regularly that someone
asks a question, and on the screenshot they show, it's clear that
their exe doesn't have a manifest. This usually happens when they
don't use one of the provided build solutions and they build a sample
from scratch and compile by hand.

Eric

Friday, November 11, 2022, 2:07:32 PM, you wrote:

TT> I can't think of use case for not using a manifest (but that certainly
TT> doesn't mean there isn't one).

TT> Maybe just start with the runtime version check for comctl32 v6 and log it
TT> as an error?
TT> This way a use case may be identified.
TT> If nobody ever complaints the code targeting comctl v5 could then be
TT> eliminated later on.
TT> And the check would have to be implemented anyway.

TT> VZ schrieb am Donnerstag, 10. November 2022 um 21:50:05 UTC+1:

>> Hello,
>>
>> I'm trying to get rid of the code required to support obsolete Windows
>> versions in wxMSW, but while doing it I've realized that in many places we
>> are actually checking (or should be checking, as it's done wrongly in some
>> places, e.g. HasNativeCommandLinkButton(), currently) for comctl32.dll
>> version and not the OS version itself. And this is important because the
>> applications without a manifest use comctl32.dll v5.82 even under Windows
>> 10 (not sure about 11, but I suspect it's the case even there), i.e. we
>> still need to keep a lot of code just in case wxMSW is used without a
>> manifest including "Microsoft.Windows.Common-Controls version=6.0.0.0"
>> assembly as a dependency.
>>
>> It would be really nice to not have to deal with these checks neither, but
>> I'm afraid that there might be some strange use cases in which manifest is
>> not being used. OTOH it seems stupid to keep this code if nobody actually
>> does this. Could we, perhaps, try showing an error message during the
>> library initialization if it detects that it doesn't use comctl32.dll v6?
>> At least we'd find out pretty quickly if this actually happens in this
>> case. Or does anybody already know for sure that we need to keep support
>> for the old comctl32.dll?
>>
>> Thanks,
>> VZ
>>




--

Vadim Zeitlin

unread,
Nov 11, 2022, 9:23:47 AM11/11/22
to wx-...@googlegroups.com
On Fri, 11 Nov 2022 14:54:52 +0100 Eric Jensen wrote:

EJ> On the forum it still happens not often, but regularly that someone
EJ> asks a question, and on the screenshot they show, it's clear that
EJ> their exe doesn't have a manifest. This usually happens when they
EJ> don't use one of the provided build solutions and they build a sample
EJ> from scratch and compile by hand.

I don't worry that much about this case because I think it would actually
be better if people doing this got a clear error on the application startup
telling them that they're missing the manifest instead of letting them
struggle with it. Wouldn't it?

What I'm worried instead is about using wxWidgets in a plugin loaded into
some application which doesn't use comctl32.dll v6. I think it's very
unlikely that any such applications still exist, but I can't be totally
sure that they don't and this scenario is much more problematic as you
might not be able to actually fix the problem in it.

In any case, I rather like the proposal by Tobias: let's add a warning
about not using comctl32.dll v6 and see if anybody complains. Of course,
this means that we won't be able to actually drop comctl32.dll v5 support
until after 3.3.0, but better late than never.

Thanks,
VZ

Kenneth Porter

unread,
Nov 11, 2022, 5:27:54 PM11/11/22
to wx-...@googlegroups.com
--On Friday, November 11, 2022 3:23 PM +0100 Vadim Zeitlin
<va...@wxwidgets.org> wrote:

> What I'm worried instead is about using wxWidgets in a plugin loaded into
> some application which doesn't use comctl32.dll v6. I think it's very
> unlikely that any such applications still exist, but I can't be totally
> sure that they don't and this scenario is much more problematic as you
> might not be able to actually fix the problem in it.

Where do you make this check? Hopefully it's only for GUI initialization.
I'm providing a non-GUI DLL that uses wx internally, mainly for wxXml,
wxThread, and the mutex/semaphore stuff. But I'm pretty sure I use a
manifest. (This was originally written over a decade ago so I haven't
messsed with the project details in a long time.)

Vadim Zeitlin

unread,
Nov 12, 2022, 8:16:09 AM11/12/22
to wx-...@googlegroups.com
On Fri, 11 Nov 2022 14:27:44 -0800 Kenneth Porter wrote:

KP> --On Friday, November 11, 2022 3:23 PM +0100 Vadim Zeitlin
KP> <va...@wxwidgets.org> wrote:
KP>
KP> > What I'm worried instead is about using wxWidgets in a plugin loaded into
KP> > some application which doesn't use comctl32.dll v6. I think it's very
KP> > unlikely that any such applications still exist, but I can't be totally
KP> > sure that they don't and this scenario is much more problematic as you
KP> > might not be able to actually fix the problem in it.
KP>
KP> Where do you make this check?

This is a good question. Right now I think it should be done in
wxApp::OnInitGui() overridden in wxMSW.

KP> Hopefully it's only for GUI initialization.

If we do it in OnInitGui() it would indeed be limited to GUI.

Regards,
VZ

Vadim Zeitlin

unread,
Dec 4, 2022, 8:54:47 AM12/4/22
to wx-...@googlegroups.com
On Fri, 11 Nov 2022 14:27:44 -0800 Kenneth Porter wrote:

KP> --On Friday, November 11, 2022 3:23 PM +0100 Vadim Zeitlin
KP> <va...@wxwidgets.org> wrote:
KP>
KP> > What I'm worried instead is about using wxWidgets in a plugin loaded into
KP> > some application which doesn't use comctl32.dll v6. I think it's very
KP> > unlikely that any such applications still exist, but I can't be totally
KP> > sure that they don't and this scenario is much more problematic as you
KP> > might not be able to actually fix the problem in it.
KP>
KP> Where do you make this check? Hopefully it's only for GUI initialization.
KP> I'm providing a non-GUI DLL that uses wx internally, mainly for wxXml,
KP> wxThread, and the mutex/semaphore stuff. But I'm pretty sure I use a
KP> manifest. (This was originally written over a decade ago so I haven't
KP> messsed with the project details in a long time.)

I've added this check in (the not yet merged, but I plan to merge it soon)

https://github.com/wxWidgets/wxWidgets/pull/23003

Please let me know if anybody already sees any problems with this.

Thanks,
VZ

Randalph

unread,
Dec 4, 2022, 11:51:57 AM12/4/22
to wx-...@googlegroups.com
Probably more rare, but in my case I provided a manifest without realizing it was broken (neither msvc or rc compiler complained), so I didn't even realize there was a problem until it resulted in an odd bug with wxWidgets. All of which is to say that having a warning would have saved me a lot of headache trying to track down the problem. I suspect that might be the case for other folks as well -- either letting them know they don't have the expected manifest, or they do and it's either broken or not being linked in correctly.

I verified that wxPython and wxLua both include wx/msw/wx.rc so they will both get the manifest. I couldn't find a .rc file or .manifest file in the wxPHP sources, so I'm not sure if they load it or not. The reason I checked on the languages is that a user is going to have a tough time adding comctl32 if the app/dll that exposes wxWidgets to the language doesn't load it.

Idle speculation -- would it make sense if XRC initialization on MSW loaded comctl32 if it isn't already loaded? Of course that would mean anyone using XRC could not use the older UI appearance, but it does resolve the problem of an app that uses XRC but doesn't use a manifest for the app since the UI is presumably being supplied by XRC.

Vadim Zeitlin

unread,
Dec 4, 2022, 12:40:35 PM12/4/22
to wx-...@googlegroups.com
On Sun, 4 Dec 2022 08:51:44 -0800 Randalph wrote:

R> Probably more rare, but in my case I provided a manifest without realizing
R> it was broken (neither msvc or rc compiler complained), so I didn't even
R> realize there was a problem until it resulted in an odd bug with wxWidgets.
R> All of which is to say that having a warning would have saved me a lot of
R> headache trying to track down the problem. I suspect that might be the case
R> for other folks as well -- either letting them know they don't have the
R> expected manifest, or they do and it's either broken or not being linked in
R> correctly.

Yes, this is a good point and I agree that this should help some people,
even though I mostly thought about those who don't use any manifest at all:
telling them that they need one should be hopefully helpful.

R> I verified that wxPython and wxLua both include wx/msw/wx.rc so they will
R> both get the manifest.

Thanks!

R> I couldn't find a .rc file or .manifest file in the wxPHP sources, so
R> I'm not sure if they load it or not.

I don't know anything about wxPHP (or even PHP more generally), so I can't
say anything useful here.

R> Idle speculation -- would it make sense if XRC initialization on MSW loaded
R> comctl32 if it isn't already loaded?

I'm not sure if this is really possible, i.e. if you can load v6 without
using the manifest. It might be, but I don't know how. And, to be honest,
even if it is, I'm not sure it's a good idea.

Regards,
VZ
Reply all
Reply to author
Forward
0 new messages