Jump to content

Modern browsing in a Linux VM on XP x64


SuperWorkstationXP

Recommended Posts


Just to provide some context:

1. The problem is that Chrome does not support ECC (elliptic-curve cryptography) cipher suites. Firefox supports ECC, but, like Chrome, Firefox dropped support for Windows XP a long time ago. Even if you're able to get around the ECC barrier, you run into...

2. The latest version of JavaScript is ES2018. Chrome 49 was released in 2016 and does not support async-await and modules. Since async-await essentially gets abused, even if you're able to render the HTML, you won't be able to interact with any scripted elements.

3. A lot of websites use React, which, as you can see, also makes extensive use of async-await. This is why you'll see websites initially rendered for a second on Chrome 49 XP and then immediately flash into a white screen. There was a DOM update followed by a runtime script error.

4. Even with a TLS proxy, you still run into problems with #2 and #3. At the proxy level, you can write an ES5 transpiler which blocks <script> elements until a successful transpile (<script> elements naturally block until the resource arrives from the server anyway), which is what I intended to do, but this runs into more problems: 1) the open source implementations are written in JavaScript and therefore slow, 2) it's too much work to re-implement this in C/C++, and 3) the specification is constantly evolving. By "slow," I mean you can be adding an additional 1-2 second overhead in CPU time per large script on top of the network latency.

5. For #4, you will also need to do this for newer features in HTML5, CSS3, and, potentially, WebAssembly (if it gets any adoption). For HTML5 in particular, there isn't always a suitable shim where newer features can be re-implemented with older features. In a contrived example that doesn't actually reflect real-world implementation issues, you can emulate 64-bit integers using 32-bit registers in WASM, but it's a little different trying to get a video to autoplay if autoplay was never implemented for your version of HTML5.

6. Another alternative is to port browsers. MyPal infamously blue screens. Most attempts of porting newer versions of Chrome to XP have been abandoned, are too buggy to use, or seem suspicious.

7. The web is constantly evolving at a "break the web" pace. Developers simply don't care anymore and will just tell you to upgrade your browser instead of doing the work to support legacy systems.

8. Windows 7/8/8.1 support will be dropped by Chrome by the end of 2023.

Overall, the amount of effort in porting or coding needed to make modern websites work with XP is tremendous. I was able to come up with a workaround requiring just five steps. It's true the Debian package manager can run into dependency issues in the future once Chrome starts using newer libraries, but it'll just be a matter of building from source, which I'm sure the community can more than handle. For now, dpkg -i ... is enough to install the latest Chrome, and I set up the instructions, picked the OS, and picked the exact versions so you can install the latest Chrome today as easily as possible.

The latest Chrome browser feels like it's natively running in XP, and this was the lowest-effort, highest-reward path.

Edited by SuperWorkstationXP
Link to comment
Share on other sites

Welcome to MSFN SuperWorkstationXP. :) Your hardware must be relatively Super. Many diehards running XP x86 have old hardware that just won’t die, and would be hard-pressed to run two OS at the same time even if Chrome supported 32-bit Linux (which it doesn’t). On the other hand, with the right hardware, this concept is by no means restricted to XP diehards. Chrome has now ended support for everything older than Windows 10. For fans of Windows Vista, this might be an alternative to the extended kernel.

Link to comment
Share on other sites

Thanks for the warm welcome, Vistapocalypse. Thanks for noticing my username :). You're also right that this solution isn't restricted to XP and can be applied to Vista/7/8/8.1/etc.

As you pointed out, the disadvantage to this method is that it requires more hardware. However, there's another way for XP users on lower-end hardware: RemoteApp. (Config instructions included in the link.) I've attached a screenshot of 32-bit XP Pro SP3 with 2GB RAM running Chrome 100+ via Windows 7.

RemoteApp does not show the entire Windows 7 desktop. It shows only the application you're streaming. No additional third-party software is required. RemoteApp is a feature of Windows Remote Desktop, but you'll need KB961742 for XP SP3.

The advantage is that it only consumes ~25mb of memory on the XP client (with all the memory consumption being delegated to the Win7 server machine). The disadvantage to streaming is that it can be a little choppy. For YouTube, you can use yewtu.be on XP Chrome 49 natively instead of YouTube.com via RemoteApp.

In both cases, for VirtualBox seamless mode and RemoteApp, hardware to run a modern OS is still required for hosting the browser.

xpchrome.jpg

Link to comment
Share on other sites

  • Dave-H changed the title to Modern browsing in a Linux VM on XP x64
On 5/14/2023 at 2:55 PM, SuperWorkstationXP said:

3. A lot of websites use React, which, as you can see, also makes extensive use of async-await. This is why you'll see websites initially rendered for a second on Chrome 49 XP and then immediately flash into a white screen. There was a DOM update followed by a runtime script error.

Finally a good explanation. A bitmap cache, perhaps?. I'm transitioning in the different direction. I want a linux with openbsd for non-smb home networking, and want to run XP (as I like it, all stripped down of tricks and in shinny leather, so to speak), for non-internet related stuff and apps. But thank you very much for sharing this.

Edited by dmiranda
Link to comment
Share on other sites

I want to post something about this. Firstly, what do you think about a creation of a proxy in node.js with Puppeteer? Puppeteer is a JavaScript library that "eat Javascript for lunch" and return the html. So, since we could live without CSS grid and the newest CSS3 stuff, our deal is JavaScript! So, a proxy in node.js using puppeteer could solve some anoyances, and it might make some React sites to work such as Mastodon instances, or that's my opinion at least. It could be useful for old Windows 9x users. And this was the philosofy of Opera Mini on Symbian mobile devices as far as I know. Moreover, node.js and Puppeteer is using Chrome's V8 engine.

Last but not least, you should put a description of the image and steps using text, some people might not be able to read it. I sometimes do some of my work on a Linux VM with latest Ubuntu Mate inside my Vista X64 system.

Link to comment
Share on other sites

On 5/14/2023 at 5:55 PM, SuperWorkstationXP said:

8. Windows 7/8/8.1 support will be dropped by Chrome by the end of 2023.

excuse me, maybe you wanted to say by the end of 2022.

Google support article and the last Chrome 109 dated Oct 24, 2022

Chrome 109 is the last version of Chrome for Windows 7, Windows 8/8.1, Windows Server 2012, and Windows Server 2012 R2. 

Chrome 110 (tentatively scheduled for release on February 7th, 2023) is the first version of Chrome that requires Windows 10 or later.

https://support.google.com/chrome/thread/185534985/sunsetting-support-for-windows-7-8-8-1-and-windows-server-2012-and-2012-r2-in-early-2023?hl=en

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...