WebKit/Windows buildbot build ought to ship with Apple Application Support libraries

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Henk Poley]

WebKit for Windows can be downloaded from the buildbot.

But to run it secretly requires an old unsupported non-Windows-Store iTunes installation from 2018, for which the download is hidden for Windows 10 users.

This brittle setup will probably keep working for the near future. But it is not wise to depend on unmentioned unmaintained legacy installers that need workarounds to download.

(I could also mutter a bit about missing optimizations, but works, so it is fine for my occasional use.)

[Fujii Hironori]

I'm also worry about availability of AppleApplicationSupport64.msi for the future.

And, I want 64 bit version of WebKitAuxiliaryLibrary.zip and WebKitSupportLibrary.zip to build out 64bit AppleWin port.

BTW, you can try WinCairo port.
https://trac.webkit.org/wiki/BuildingCairoOnWindows#DownloadbuildartifactsfromBuildbot

[Alexey Proskuryakov]

> But to run it secretly requires an old unsupported non-Windows-Store iTunes installation from 2018 

Are you talking about following the instructions at <https://webkit.org/webkit-on-windows/#installing-developer-tools>?

> And, I want 64 bit version of WebKitAuxiliaryLibrary.zip and WebKitSupportLibrary.zip to build out 64bit AppleWin port.

I am not up to date about the big picture here. Hopefully others on CC list will eighteenths in.

[Alexey Proskuryakov]

weigh in*

[Henk Poley]

No I didn't follow any instructions.

My process was more like:

* Ah, someone has a problem with my company's API when using Safari, but I don't have my private MacBook at work, and I don't know how to attach a Web Inspector to my iPhone from Windows
* Ah, I remember there is a WebKit buildbot running.
* Okay, this needs some libraries, that I remember were shipped with iTunes.

If the WinCairo build is better, maybe a nightly build should be available from WebKit itself?

I'm not developing or building WebKit, I just needed a passable semblance of recent Safari, on Windows.

[Henk Poley]

Btw, if you follow point 10 on Windows 10, you will not get the correct download


```
10. iTunes. This is only needed for the AppleWin port, not for the WinCairo port. http://www.apple.com/itunes/download/ This is needed because it includes the .dlls which implement Apple frameworks like CoreGraphics, CoreAnimation, etc.
```

On Windows 10 you will be directed to the Windows Store, which has a containerized version of iTunes, that WebKit will not be able to access the libraries from.

[Henk Poley]

I see that 'build artifacts' is the in the continuous integration meaning, and not 'files that are required for building/compiling'.

So I tried downloading the WinCairo build and WinCairoRequirements as described here: https://trac.webkit.org/wiki/BuildingCairoOnWindows#DownloadbuildartifactsfromBuildbot

MiniBrowser starts but will not navigate to any website 🤷‍♂️.

Could get ProcExp64 to get to show anything useful about things it is silently missing.

[Henk Poley]

ProcMon64..

[Don Olmstead]

So there are a couple different use cases and associated problems.

For WebKit developers they are...

The actual dlls for running the AppleWin port are not distributed outside of iTunes. The .msi version, apparently pre-Windows Store version, can be unzipped in 7Zip so you can get at the actual msi installer. That's more or less hidden knowledge.

The Apple Win port has moved to 64-bit but the library files distributed in the WebKitAuxiliaryLibrary.zip and WebKitSupportLibrary.zip are 32-bit. At least the last time I checked.

At this time anyone outside of Apple cannot build or run the AppleWin port in 64-bit. So this makes it harder for WebKit developers outside of Apple to fix issues with that build. Whether or not that's a big issue I don't know 🤷 since its an Apple decision.

For someone who wants to run a version of WebKit on Windows for whatever reason they are...

Its possibly not clear to someone outside of WebKit developers that there's really no reason to use the AppleWin port. It requires Apple specific libraries, CoreFoundation, CoreGraphics etc, that someone outside of Apple cannot redistribute. It only uses WebKitLegacy so its not a good comparison for someone whose on Windows and might want to see how their site looks in Safari without having a Mac. The features enabled are also not the same so an API in Safari is probably not there in AppleWin.

The only completely open source version of WebKit for Windows that has build artifacts is WinCairo. If someone wanted to embed WebKit in a Windows app WinCairo is what you would use at this time.

Sony is largely supporting WinCairo development due to the shared platform, curl, cairo, etc, and to support our internal developers. At this time we don't have any releases for WinCairo. So the only way to get a Windows build of WebKit is by downloading WinCairo and its requirements.

I'm not entirely sure what Henk's motivations are but those are the problems I see.

For getting the minibrowser working the directions on the site are lacking the fact that the dlls in the bin64 directory need to be copied to the same directory as the MiniBrowser.exe. If it still doesn't work its likely that a MSVC runtime isn't there. We use Visual Studio 2019 so that'll need to be installed.

If the MiniBrowser.exe runs successfully then it'll display https://webkit.org. For further debugging https://github.com/lucasg/Dependencies can be used which will figure out what dlls are not loading.

[Radar WebKit Bug Importer]

<rdar://problem/89481579>

[Fujii Hironori]

Apple Windows port has gone. Closed.