Update Windows support

[Eloston]

If anyone wants to work on this, please respond here.

[egorpe]

What's the status of it at the moment?

[Eloston]

Nothing yet.

[egorpe]

I might pick it up if no one else will. I will give it a try over the coming weekend, will report here.

[Eloston]

Alright, sounds good. Most of utilikit should work OOTB. But if something blows up, let me know.

[ghost]

Happy to do some UAT if you require any assistance. Just opened up a bug which I hope it resolved in your version.

https://github.com/Eloston/ungoogled-chromium/issues/224

[egorpe]

I am sorry, I dropped the ball on this one but I picked it back up.

I have a toolchain installed and am able to build official Chromium version.

I'll try to apply patches and re-build in the next few days.

[leedoyle]

@egorpe any luck so far?

[Osahashi]

Please, someone give use a up to date Windows version :(

[mikerockett]

The seems like it's going to take some time. I guess I'm okay sticking with 55 for the time being, but if this nobody is able to provide a newer build for WIndows any time soon, is Iridium safe enough to switch to (temporarily)?

[egorpe]

I stuck at the point when, even though stock Chromium (before patches) builds, the resulting executable is unusable (simply crashes). I lack hands-on Chromium development experience to debug the issue. Hopefully someone more experienced with the project will pick it up.

[Eloston]

@egorpe What do you mean by "stock Chromium" exactly? How are you building it? What are you using and modifying?

[egorpe]

I just follow Google's direction on how to build Chromium. No patches whatsoever. Just a clean check out.

Followed this https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md to the letter.

Build successful, executable runs but crashes with a dead dinosaur in the middle immediately after start.

[titanlab]

@Eloston I got Chromium built on Windows now (working, with VS2017 tools). Will try to apply your patches now.

[titanlab]

@Eloston Somehow the patches differ from what is in the source. For example the url/gurl.cc in both chromiums GIT repo and the downloaded source don't contain code about the trk scheme. What is the reason? E.g.

--- a/url/gurl.cc
+++ b/url/gurl.cc
@@ -504,15 +504,7 @@ size_t GURL::EstimateMemoryUsage() const

 std::string &gurl_strip_trk(std::string &s)
 {
-   auto slen = strlen(url::kTraceScheme);
-   if (!isdigit(s[slen+1]))
-       /* trk:https://... */
-       return s.erase(0, slen);
-   /* trk:123:https://... (or so we hope) */
-   auto pos = s.find(':', slen + 1);
-   if (pos == std::string::npos)
-       return s.erase(0, slen);
-   return s.erase(0, pos + 1);
+   s.clear(); s.append("about:blank"); return s;
 }

 bool gurl_is_trq(const std::string &s)

The code you're referring to here isn't in chromiums source. Am I missing something?

[titanlab]

@Eloston I use your tag 58.0.3029.110 - also I use chromium GIT Tag for that version. And I also tried with the source you downloaded with the utilikit py script...

[Eloston]

@egorpe Well if you followed those instructions to the letter, then you've managed to build a development version of Chromium. It's a bit of a pain to use depot_tools to checkout a stable version to build, which is why I download and build with a compressed tar file containing the (essentially) complete source code in utilikit.

@andrewoesten The order to apply patches in is defined in a utilikit configuration. The resources/patches directory only contains patch files grouped by their origin. There exists a windows configuration that is used to build the Windows version (and needs updating). See the DESIGN document if you need an explanation of the contents.

Also, you managed to build Chromium with the VS 2017 tools? I didn't even think that was possible considering Chromium depends on VS 2015 Update 3 with a specific SDK version. Back when I worked on Windows support, even a slightly newer VS compiler broke compilation.

I should note that there's no build script generator for Windows yet (the utilikit code needs to be written based on the work from buildlib), so you'll need to build GN, run GN, and run Ninja yourself if you want to attempt a build for now.

[titanlab]

@Eloston But on which chromium version do these patches base? It seems the 58 source doesn't have any trk: scheme etc. So the patches must be for a newer version?

At the moment I'm fixing the patches by hand. Already got the build script generator to make a "build.bat" for me where I apply the patches.

Yeah I got it compiled with VS 2017 tools and the specific SDK version:

set DEPOT_TOOLS_WIN_TOOLCHAIN=0
set GYP_MSVS_VERSION=2017

That was working for me.

[Eloston]

@andrewoesten

But on which chromium version do these patches base? It seems the 58 source doesn't have any trk: scheme etc. So the patches must be for a newer version?

Everything that the debian_stretch configuration uses is updated to version 58. Also, the patches have implicit dependencies on each other (mainly ungoogled-chromium patches on other patches), so you need to apply patches in the order defined in a configuration's patch order.

The specific change that you're mentioning is introduced in the Iridium patch that has the trk scheme implementation.

Yeah I got it compiled with VS 2017 tools and the specific SDK version:

It doesn't make sense for GN to use GYP_MSVS_VERSION. Also, do you happen to have VS 2015 installed too? GN didn't blindly use the latest VS in version 55.

[titanlab]

@Eloston

Take a look here: https://chromium.googlesource.com/chromium/src.git/+/58.0.3029.110/build/vs_toolchain.py

Here he reads the GYP_MSVS_VERSION and also seems to support 2017.

OK, I will try again with a corrected patch order :-)

[titanlab]

@Eloston OK, when applying the correct patch order he seems to run through. Now have to fix the windows patches.

[Eloston]

Here he reads the GYP_MSVS_VERSION and also seems to support 2017.

Oh that's neat. Saves me the hassle of downloading an old compiler. The 14393 is still available in VS 2017's installer? If so, that's interesting.

[titanlab]

@Eloston Fortunately yes 👍

[FaceHiddenInsideTheDark]

I can confirm that 58 runs flawlessly on the Windows Subsystem for Linux (https://github.com/Cynede/gentoo-wsl), but I guess that doesn't really mean Windows support. Xming is kind of slow in comparison to the real deal. It's also kind of a nightmare getting modules right.

[Eloston]

@FaceHiddenInsideTheDark Wow, that's pretty neat. I haven't kept up with WSL, but it sounds like they've implemented quite a bit already. Though it doesn't sound like it will be read for end-users anytime soon, so we'll probably leave it for now.

[sergeevabc]

Err… Anyone?

[Eloston]

I just discovered that this issue only has Server Error 500 on the Desktop version. If the Mobile version is used (via changing the user agent), it works fine.

I'm reposting what I stated in #332 here:

I'm letting everyone know that a failed attempt at bringing back Windows support is in 94ee1be3d80c6215ce44d42554ab4039b44c394a.

As the commit states, it fails to link the final binaries with over 600 unresolved externals. I suspect the breakage may be in windows-fix-building-without-safebrowsing.patch, since I was trying to make changes to that patch before I stopped.

I've lost access to the Windows machine I was using, and interest in trying to find the root problem. If anyone wants to finish off what I started, please do so.

[ribatamu]

I can confirm the mobile version is working fine with issue 215.

Hopefully, Eloston can fine a way to bring back Windows support, because there are a lot peoples, which are waiting for updaded ungoogled version.