Including WebView2 (Edge) support in Windows Binaries?

[Tobias T]

Right now the windows binaries for the wxWebView library just contain support for the outdated and deprecated Internet Explorer backend. In my opinion that makes them near useless in most scenarios.

Unfortunately the license of WebView2 contains a little expanded BSD style license, containing this clause:

* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

There have been discussions in the WebView2 feedback repo about this license (e.g. here in a comparable scenario to wxWidgets with another open source library) .

Maybe one could argue that just using the headers (which are generated from an IDL) isn't a redistribution in binary form?

But maybe it would make sense to build wxWebView with the WebView2 backend enabled and include a note about the differing license requirements for that library?

If such a step would be required anyway it would even make sense to link the loader static for the best integration experience for developers.

Just my thoughts on the issue, maybe people come up with other ideas. It's not the most pressing issue of course. I just think it would be nice for developers using the Windows binaries.

[Vadim Zeitlin]

On Wed, 15 Feb 2023 02:26:40 -0800 (PST) Tobias T wrote:

TT> Right now the windows binaries for the wxWebView library just contain
TT> support for the outdated and deprecated Internet Explorer backend. In my
TT> opinion that makes them near useless in most scenarios.
TT>
TT> Unfortunately the license of WebView2
TT> <https://www.nuget.org/packages/Microsoft.Web.WebView2/1.0.1518.46/License>
TT> contains a little expanded BSD style license, containing this clause:
TT> * Redistributions in binary form must reproduce the above copyright notice,
TT> this list of conditions and the following disclaimer in the documentation
TT> and/or other materials provided with the distribution.

This is not necessarily a problem, we could add a section about this in
docs/readme.txt, as we already do for a couple of other third party
libraries.

TT> There have been discussions in the WebView2 feedback repo about this
TT> license (e.g. here
TT> <https://github.com/MicrosoftEdge/WebView2Feedback/issues/907> in a
TT> comparable scenario to wxWidgets with another open source library) .

But after a brief look at this discussion it looks like there could be
worse problems with it, i.e. I haven't seen the ffmpeg licence issue being
addressed... It's not clear to me whether this affects the loader DLL too?

TT> Maybe one could argue that just using the headers (which are generated from
TT> an IDL) isn't a redistribution in binary form?

Using the headers is definitely not a redistribution in binary form. Only
including WebView2Loader.dll in our distribution would count as such.

TT> Just my thoughts on the issue, maybe people come up with other ideas. It's
TT> not the most pressing issue of course. I just think it would be nice for
TT> developers using the Windows binaries.

Yes, it would be, but convenience can't trump licencing concerns...

Anyhow, if we can build wx with WebView2 support but avoid including their
binaries and letting the users who need them download (and distribute) them
themselves, this definitely could be done. Otherwise we need to spend more
time/effort on understanding what we can and can't do.

Regards,
VZ

[Tobias T]

TT> There have been discussions in the WebView2 feedback repo about this
TT> license (e.g. here
TT> <https://github.com/MicrosoftEdge/WebView2Feedback/issues/907> in a
TT> comparable scenario to wxWidgets with another open source library) .

But after a brief look at this discussion it looks like there could be
worse problems with it, i.e. I haven't seen the ffmpeg licence issue being
addressed... It's not clear to me whether this affects the loader DLL too?

I don't think the ffmpeg license has anything todo with the loader DLL.

That could just be an issue for a static edge runtime a developer uses, not the system installed one.

Anyway nothing of out concern regarding binaries.

 

TT> Maybe one could argue that just using the headers (which are generated from
TT> an IDL) isn't a redistribution in binary form?

Using the headers is definitely not a redistribution in binary form. Only
including WebView2Loader.dll in our distribution would count as such.

TT> Just my thoughts on the issue, maybe people come up with other ideas. It's
TT> not the most pressing issue of course. I just think it would be nice for
TT> developers using the Windows binaries.

Yes, it would be, but convenience can't trump licencing concerns...

Anyhow, if we can build wx with WebView2 support but avoid including their
binaries and letting the users who need them download (and distribute) them
themselves, this definitely could be done. Otherwise we need to spend more
time/effort on understanding what we can and can't do.

Sounds like a good solution to balance license and ease of use.

Build Window wxWebView Binaries with Edge support enabled (effectively  just using headers

from the webview2 SDK) and documenting the user that WebView2Loader.dll is required at runtime.

I'll have a look integrating that into the build scripts.

[Vadim Zeitlin]

On Wed, 15 Feb 2023 07:00:38 -0800 (PST) Tobias T wrote:

TT> Sounds like a good solution to balance license and ease of use.
TT>
TT> Build Window wxWebView Binaries with Edge support enabled (effectively
TT> just using headers from the webview2 SDK) and documenting the user that
TT> WebView2Loader.dll is required at runtime.

The only thing to check is that wx can still be used (without wxWebView)
even if this DLL is not available at runtime -- but I think it should be
fine, shouldn't it?

TT> I'll have a look integrating that into the build scripts.

Thanks in advance!

And if, by chance, you can also look into setting up building the binaries
on GitHub Actions while doing this, it would be really excellent.

Thanks again,
VZ

[Tobias T]

The only thing to check is that wx can still be used (without wxWebView)
even if this DLL is not available at runtime -- but I think it should be
fine, shouldn't it?

This is already handled in the current implementation.

 

And if, by chance, you can also look into setting up building the binaries
on GitHub Actions while doing this, it would be really excellent.

I've had a quick look at github actions to create offical builds.

Building vc14x is certainly possible with a few more minor tweaks.

See here for a first try.

The software installed on the github runners only include Visual Studio 2022.

Thats should be fine for vc14x builds, but older VS builds would require a

silent install of these versions in the runner before building wxWidgets.

Which I'm not sure would be possible.

With MinGW/MSYS there is also only one version (which I think isn't one we currently build for).

But maybe just building vc14x builds as part of the create release workflow would be good start?

Apart from that what would you think about building the official binaries with CMake ?

That would get rid of the usage of nmake  and could simplify the build scripts significantly (archive, checksums, etc could simply be an additional "package" target).

[Vadim Zeitlin]

On Thu, 16 Feb 2023 13:02:29 -0800 (PST) Tobias T wrote:

TT> I've had a quick look at github actions to create offical builds.

Thanks!

TT> Building vc14x is certainly possible with a few more minor tweaks.

This is already good news!

TT> See here for a first try.

Just to check: is it intentional that the artefact produced by this build
contains just the build logs and not the files themselves?

TT> The software installed on the github runners only include Visual Studio 2022.
TT> Thats should be fine for vc14x builds,

Actually, unfortunately, not quite, 64 bit code generated by relatively
recent versions of 2019 (and all versions of 2022) is incompatible with the
MSVS 2017 CRT any longer and so the libraries built with them can't be used
with MSVS 2017 out of the box (it still works in 32 bits).

TT> but older VS builds would require a silent install of these versions in
TT> the runner before building wxWidgets. Which I'm not sure would be
TT> possible.

Me neither :-( FWIW I know that AppVeyor still has images with old MSVS
versions, see https://www.appveyor.com/docs/windows-images-software/, but
it's not as convenient to use as GHA.

TT> With MinGW/MSYS there is also only one version (which I think isn't one
TT> we currently build for).

We should be able to install any version of MinGW we need at least.

TT> But maybe just building vc14x builds as part of the create release
TT> workflow would be good start?

I really don't know. If you look at the download statistics, all binaries
seem to be downloaded about the same number of times (a few thousands). I
strongly suspect that there is something fishy going on, e.g. maybe there
is some automated process downloading each of them daily or something like
that because I just can't believe that there are as many people developing
with ancient MSVS versions as with much newer ones, but I can't really be
sure.

TT> Apart from that what would you think about building the official
TT> binaries with CMake ? That would get rid of the usage of nmake and
TT> could simplify the build scripts significantly (archive, checksums, etc
TT> could simply be an additional "package" target).

I'm still ambivalent towards CMake but even it is certainly better than
nmake (and should also build much faster as it would use all the CPUs), so
I guess that objectively this would be a good idea. We would need to check
that the binaries produced by it for 3.2 are ABI-compatible with the ones
we have now (normally I don't see why they shouldn't be, but who knows),
but other than that I don't have any objections to it.

Of course, as long as Danny (and Xavier, if you also think that CMake can
be used for MinGW binaries) actually build these binaries, it's their
opinion which really matters and not mine.

Thanks again for looking at this!
VZ

[Danny Scott]

On Fri, Feb 17, 2023 at 10:17 AM Vadim Zeitlin <va...@wxwidgets.org> wrote:

On Thu, 16 Feb 2023 13:02:29 -0800 (PST) Tobias T wrote:

 Actually, unfortunately, not quite, 64 bit code generated by relatively
recent versions of 2019 (and all versions of 2022) is incompatible with the
MSVS 2017 CRT any longer and so the libraries built with them can't be used
with MSVS 2017 out of the box (it still works in 32 bits).

This article:

https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170

implies the vc14x builds should be compatible  with VS 2015 through VS 2022 runtime libraries. Am I missing something?

TT> Apart from that what would you think about building the official
TT> binaries with CMake ? That would get rid of the usage of nmake  and
TT> could simplify the build scripts significantly (archive, checksums, etc
TT> could simply be an additional "package" target).

 I'm still ambivalent towards CMake but even it is certainly better than
nmake (and should also build much faster as it would use all the CPUs), so
I guess that objectively this would be a good idea. We would need to check
that the binaries produced by it for 3.2 are ABI-compatible with the ones
we have now (normally I don't see why they shouldn't be, but who knows),
but other than that I don't have any objections to it.

 Of course, as long as Danny (and Xavier, if you also think that CMake can
be used for MinGW binaries) actually build these binaries, it's their
opinion which really matters and not mine.

For 3.2.x official builds I prefer to stick with the current system. My build platform is a KVM Windows 11 image with all of the old compilers installed (it started as a Virtualbox Windows 8 image). It's (last time I tried) impossible to find installation packages for the old compilers. I build all packages at the same time, so the cpu cores are put to full use.

For 3.3.x official builds I am assuming (from what I have read on the mail list) that only the vc14x builds will be required. I'm also assuming that the makefile will disappear (because of bakefile disappearing). I'm open to using any package, but I've reached that stage in life where I'm not too keen on learning how to use something new. I'm still willing to do the actual builds if someone prepares good instructions on what to do.

--

Danny Scott

[Vadim Zeitlin]

On Fri, 17 Feb 2023 19:24:06 -0400 Danny Scott wrote:

DS> On Fri, Feb 17, 2023 at 10:17 AM Vadim Zeitlin <va...@wxwidgets.org> wrote:
DS>
DS> > On Thu, 16 Feb 2023 13:02:29 -0800 (PST) Tobias T wrote:
DS> >
DS> > Actually, unfortunately, not quite, 64 bit code generated by relatively
DS> > recent versions of 2019 (and all versions of 2022) is incompatible with the
DS> > MSVS 2017 CRT any longer and so the libraries built with them can't be used
DS> > with MSVS 2017 out of the box (it still works in 32 bits).
DS> >
DS> >
DS> This article:
DS> https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170
DS> implies the vc14x builds should be compatible with VS 2015 through VS 2022
DS> runtime libraries. Am I missing something?

The binaries built by MSVS 2015 (and 2017) are compatible with the later
versions, but using the binaries produced by MSVS 2019 (and 2022) with the
earlier versions doesn't work. This is covered by

> However, you must link by using a toolset at least as recent as the most
> recent binary in your app

in the URL above, as it implies that using MSVS 2022 for building the DLLs
requires using MSVS 2022 for linking them (which, again, actually isn't the
case for 32-bit binaries, but is indeed required for 64-bit ones).

DS> For 3.2.x official builds I prefer to stick with the current system. My
DS> build platform is a KVM Windows 11 image with all of the old compilers
DS> installed (it started as a Virtualbox Windows 8 image). It's (last time I
DS> tried) impossible to find installation packages for the old compilers. I
DS> build all packages at the same time, so the cpu cores are put to full use.

The real problem is what happens if this image is lost for any reason...
We would basically be unable to rebuild 3.2 binaries then because I also
have no idea how to install the old compilers any more (I think the only
way to do it is to install them under an older system, such as Windows 7 or
maybe even XP (!) and then upgrade the system before installing the newer
ones). I guess it's not the end of the world, but if we could have a backup
of this image somewhere, it would be nice.

DS> For 3.3.x official builds I am assuming (from what I have read on the mail
DS> list) that only the vc14x builds will be required.

Yes, but this includes MSVS 2015 and 2017, so we still need to find a way
to build the binaries compatible with them, i.e. _not_ using MSVS 2022...

Regards,
VZ

[Danny Scott]

On Sat, Feb 18, 2023 at 8:55 AM Vadim Zeitlin <va...@wxwidgets.org> wrote:

On Fri, 17 Feb 2023 19:24:06 -0400 Danny Scott wrote:

DS> On Fri, Feb 17, 2023 at 10:17 AM Vadim Zeitlin <va...@wxwidgets.org> wrote:
DS>
DS> > On Thu, 16 Feb 2023 13:02:29 -0800 (PST) Tobias T wrote:
DS> >
DS> >  Actually, unfortunately, not quite, 64 bit code generated by relatively
DS> > recent versions of 2019 (and all versions of 2022) is incompatible with the
DS> > MSVS 2017 CRT any longer and so the libraries built with them can't be used
DS> > with MSVS 2017 out of the box (it still works in 32 bits).
DS> >
DS> >
DS> This article:
DS> https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170
DS> implies the vc14x builds should be compatible  with VS 2015 through VS 2022
DS> runtime libraries. Am I missing something?

 The binaries built by MSVS 2015 (and 2017) are compatible with the later
versions, but using the binaries produced by MSVS 2019 (and 2022) with the
earlier versions doesn't work. This is covered by

> However, you must link by using a toolset at least as recent as the most
> recent binary in your app

in the URL above, as it implies that using MSVS 2022 for building the DLLs
requires using MSVS 2022 for linking them (which, again, actually isn't the
case for 32-bit binaries, but is indeed required for 64-bit ones).

OK, nothing has changed. That's why we build with VS 2015.

DS> For 3.2.x official builds I prefer to stick with the current system. My
DS> build platform is a KVM Windows 11 image with all of the old compilers
DS> installed (it started as a Virtualbox Windows 8 image). It's (last time I
DS> tried) impossible to find installation packages for the old compilers. I
DS> build all packages at the same time, so the cpu cores are put to full use.

 The real problem is what happens if this image is lost for any reason...
We would basically be unable to rebuild 3.2 binaries then because I also
have no idea how to install the old compilers any more (I think the only
way to do it is to install them under an older system, such as Windows 7 or
maybe even XP (!) and then upgrade the system before installing the newer
ones). I guess it's not the end of the world, but if we could have a backup
of this image somewhere, it would be nice.

Microsoft has install packages for VS 2013 and newer at:

https://visualstudio.microsoft.com/vs/older-downloads/

You can find older install packages with google, but last time I tried to build a new VM from scratch I couldn't get at least one of the older packages to install.

We provide the binaries as a convenience, and should the day come when we can't build anything older than VS 2013, anyone needing the binaries will have their own compiler and can use our utilities to build their own image.

I maintain three backups of the image:

 - cloud (wasabi) : daily backup, retained for 60 days, using restic

 - local to NAS : daily backup, retained for 60 days, using restic

 - local to 2nd NAS : manually initiated after successful Windows updates and many successful boots, using rsync

The raw size of the image is approx. 300 GB

DS> For 3.3.x official builds I am assuming (from what I have read on the mail
DS> list) that only the vc14x builds will be required.

 Yes, but this includes MSVS 2015 and 2017, so we still need to find a way
to build the binaries compatible with them, i.e. _not_ using MSVS 2022...

We only build with 2015, and that is still available from Microsoft, so starting a new build environment on a virtual machine is easy.

--

Danny Scott

[Vadim Zeitlin]

On Sat, 18 Feb 2023 09:19:31 -0400 Danny Scott wrote:

DS> Microsoft has install packages for VS 2013 and newer at:
DS> https://visualstudio.microsoft.com/vs/older-downloads/

It's nice that they do, but we can't download them automatically from this
page and, anyhow, installing them for each build would take too long.

DS> We provide the binaries as a convenience, and should the day come when we
DS> can't build anything older than VS 2013, anyone needing the binaries will
DS> have their own compiler and can use our utilities to build their own image.

Yes, of course, this is why I said it wasn't the end of the world.

DS> We only build with 2015, and that is still available from Microsoft, so
DS> starting a new build environment on a virtual machine is easy.

Manually -- yes. But automatically probably not easy at all and I'd really
like to automate building the releases, at least in 3.3.

If anybody has any ideas about how could we build using MSVS 2015 (on
GitHub Actions VMs or somewhere else), I'd like to know about it!

Regards,
VZ

[Tobias T]

If anybody has any ideas about how could we build using MSVS 2015 (on
GitHub Actions VMs or somewhere else), I'd like to know about it!

I've started an experiment that might work:

1. I've create a modified appveyor.yml that includes 2 build matrixes
2. Normal builds (commits, PRs) are unmodified and get built as currently configured
   
3. All commits containing [official] in the commit title will instead run officialbuild.bat
4. Result looks somthing like this

So far I've only added vc14x and vc120. Older than vc14x currently fails to build, but as appveyor has

all the required Visual Studio Versions installed I'm sure thats can be made to work.

Instead of the commit message filter a filter for tags could be configured.

My idea for integration would be something like:

1. Create release via GH action make_release.yml
2. This could trigger the appveyor "official build" matrix
3. The build artifacts could then be deployed to the draft release from appveyor

I'll look a little further into this, but I think it could work. Any comments are of course welcome.

[Vadim Zeitlin]

On Sat, 18 Feb 2023 09:33:54 -0800 (PST) Tobias T wrote:

TT> I've started an experiment that might work:
TT>
TT> 1. I've create a modified appveyor.yml
TT> <https://github.com/TcT2k/wxWidgets/blob/build_binaries/appveyor.yml>
TT> that includes 2 build matrixes

Nice, thanks, I didn't know we could do this.

TT> 2. Normal builds (commits, PRs) are unmodified and get built as
TT> currently configured
TT> 3. All commits containing [official] in the commit title will instead
TT> run officialbuild.bat

This is ingenuous but I think we should rather use tags to decide whether
we need to build the official binaries if possible.

TT> 4. Result looks somthing like this
TT> <https://ci.appveyor.com/project/TcT2k/wxwidgets/builds/46272720>

I guess we need to add "artifacts" section to appveyor.yml to actually get
the binaries? Or can/would it better to use its support for deploying to
GitHub Releases (https://www.appveyor.com/docs/deployment/github/)?

TT> So far I've only added vc14x and vc120. Older than vc14x currently fails to
TT> build, but as appveyor has all the required Visual Studio Versions
TT> installed I'm sure thats can be made to work. Instead of the commit
TT> message filter a filter for tags could be configured.

IMHO it would be enough to make this work for 3.3, where only vc14x is
needed, at least initially, to reduce the amount of work needed.

TT> My idea for integration would be something like:
TT>
TT> 1. Create release via GH action *make_release.yml*
TT> 2. This could trigger the appveyor "official build" matrix
TT> 3. The build artifacts could then be deployed to the draft release from
TT> appveyor
TT>
TT> I'll look a little further into this, but I think it could work. Any
TT> comments are of course welcome.

Thanks again for looking at this, I agree that it should work and it looks
like the best way forward. And according to

https://www.appveyor.com/docs/windows-images-software/#mingw-msys-cygwin

they have MinGW 7.3 and 8.1 too (although the former in 64 bits only?) as
well as MSYS2, so we don't have to install anything.

Regards,
VZ

[Tobias T]

So I've tried little more with appveyor. The results can be seen here

I've left the officialbuild.bat untouched for now except for mingw paths when run under appveyor.

There are a few problems:

• A debug and release mingw build for one architecture takes a little more than 1 hour and is therefor canceled. This could be worked around by running debug and release as separate jobs.
• TDM-GCC 10.3 isn't available at all and MinGW-w64 7.3 isn't available as 32 bit.
• A complete set of build jobs would run around 9 hours. Not sure how fast the offical builds are now.

Is the current set of mingw compilers still be current for 3.3 release?

If some compilers have to be installed anyway, it might make sense to run all mingw builds as github actions (which would also decrease overall build time, because of the parallel execution there).

Than just msvs would be built on appveyor to take advantage of the installed older visual studio versions (just 2015 for 3.3).

[PB]

Hi,

IMO, there should be a discussion about Windows binaries for 3.3.

Is there really a need for MSYS2 binaries? AFAICT, MSYS2 mingw-64 GCC package is a moving target and it may not be possible to (easily) obtain the compatible GCC version wxWidgets was built with if MSYS2 moved on? Moreover, it seems that even developer branch releases have been provided as MSYS2 package, since 3.1.something (for msvcrt as well as ucrt).

TDM-GCC has not been really maintained for a long time and since mingw-w64's own distributions are not made anymore either, there is no maintained and popular (not sure how much are WinLibs or niXman popular) separate mingw-w64 installation.

Regarding MSVC compatibility - not sure which version is the minimum required now and if wxWidgets DLLs built with MSVS 2015 and v140 toolset can be used without issues or limitations with any later MSVS version and toolset, i.e. if just one package for MSVS would be enough...

Disclaimer: I am all for self-built wxWidgets and believe people who want prebuilt libraries are better off using a package manager such as MSYS2 or vcpkg, so...

Regards,

PB

[Vadim Zeitlin]

On Tue, 21 Feb 2023 11:03:46 -0800 (PST) PB wrote:

P> IMO, there should be a discussion about Windows binaries for 3.3.
P>
P> Is there really a need for MSYS2 binaries?

If we trust the download numbers (4-5k for them), there is. The trouble is
that I'm really not sure if we can trust them -- but I don't know how to
check them neither.

P> TDM-GCC has not been really maintained for a long time

It has been somewhat resurrected recently.

P> Regarding MSVC compatibility
P> <https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170>
P> - not sure which version is the minimum required now and if wxWidgets DLLs
P> built with MSVS 2015 and v140 toolset can be used without issues or
P> limitations with any later MSVS version and toolset, i.e. if just one
P> package for MSVS would be enough...

Yes, this is the plan for 3.3.x releases.

P> Disclaimer: I am all for self-built wxWidgets and believe people who want
P> prebuilt libraries are better off using a package manager such as MSYS2 or
P> vcpkg, so...

It's true that both MSYS2 and vcpkg packages seem to be quite up to date,
e.g. they already provide 3.2.2.1, see

https://packages.msys2.org/base/mingw-w64-wxwidgets3.2
https://github.com/microsoft/vcpkg/tree/master/ports/wxwidgets

but I'm not sure if this is going to be the case for 3.3.0 too. And it's
also true that many more people use vcpkg now that when we started building
our own binaries. But not everybody still does and I think unpacking the
"dev" archive might still be much simpler than starting to use vcpkg to
many of them.

Anyhow, my own personal position is that I'd like to have MSVS binaries
because I believe people using MSVS often expect to get the libraries in
the binary form and would be very glad if we could produce them
automatically, but, of course, I also don't mind much as long as someone
else builds them (thanks Danny!). And, personally, I think that gcc
binaries might be less necessary because people using gcc are either more
used to building software themselves or are complete beginners (e.g.
students who had never done any programming in their lives) that providing
just the binaries doesn't help them that much anyhow. But I could be
perfectly wrong about this and, again, I'm definitely glad to have them as
long as they're built by somebody else (thanks Xavier!).

So, to also reply to the original Tobias' post, I'd be quite happy with
just a way to produce the MSVS binaries automatically and ask Xavier to
build the gcc ones. If we could start with this, it would be great, so
please don't hesitate to submit your changes if you can do this already.

Thanks again!
VZ