Jump to content

SuperWorkstationXP

Member
  • Posts

    8
  • Joined

  • Last visited

  • Days Won

    2
  • Donations

    0.00 USD 
  • Country

    United States

SuperWorkstationXP last won the day on May 30 2023

SuperWorkstationXP had the most liked content!

About SuperWorkstationXP

Profile Information

  • OS
    XP Pro x64

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

SuperWorkstationXP's Achievements

29

Reputation

  1. This is a limitation of the licensed operating system. From RemoteApp Tool's compatibility guide: Note that I haven't tested RDPWrapper as RDPWrapper does have warnings about stability. Take a VM snapshot and restore it if things go wrong. Otherwise, let us know how it goes.
  2. IMO, criticizing people's choice of operating system or use case is not good for the retrocomputing community as a whole. I'm sure there are enough nuances for @NotHereToPlayGames to justify XP x64 as the choice for semi-modern hardware. Everyone has different reasons and preferences for choosing to remain with legacy operating systems. Cold boots don't matter to me either as my workstation is always on. There are cron backup jobs that run at midnight when I'm sleeping. However, cold boots might matter to laptop users or retrogamers. Their use cases are equally valid. I used to do software optimization work where we had to optimize below some threshold of human reaction time. The idea is that 50ms, while not technically "instant," is perceived by the user as "instant." Once you cross 100-200ms, the latency is perceptible for the user. We were doing a lot of work to shave 25ms, which just seems ridiculous to the outside world, but, at the UX level, there was a different "feeling" of quality, snappiness, and performance. For a lot of XP users, they "perceive" the operating system as being faster. That perception, mind you, is even more noticeable on modern hardware like NVMe SSDs. Virtualization is able to expose drives from the host to the guest (so you can SSH into a modern Linux host and operate on the files seamlessly), handle TRIM, and expose >2 TB drives to XP. I have a 4tb drive I regularly use in XP that's shared with the host OS. For you, this might seem like blasphemy, but, for XP users that have extra hardware, this is exciting. The benefits of virtualization extend beyond performance. VM snapshots to restore an entire VM -- wiping out viruses, bad installs (*cough* 64-bit Chrome for XP), rolling back bad configs, etc. Migrating to a new build on new hardware is just a copy & paste of a .qcow2 or .vmdk file from the previous PC. Backing up a VM involves just backing up the aforementioned files plus some configs. A virtualized XP on a Linux host can run regular cron backup jobs at midnight from SSD to HDD, with double/triple/off-site delta backups using rsync/duplicity with encryption. So, to your point, the modern hardware *is* running on a modern host OS. Further, my day-to-day is not tied to retrocomputing, retrogaming, RemoteApp, or anything to do with Windows. I have to run long compile jobs and tests for C++ projects targeting mainly Linux amd64 but with occasional cross-compiles to Win/Mac, which occur on external servers, but my main test-code-compile loop is basically on my local workstation. When people complain about the overkill specs for XP because I'm stuffing in modern hardware and then virtualizing it, they're missing the forest for the trees. I need that hardware. It wasn't intended for XP. It was originally for gcc/clang + Linux. All my builds in the last decade have been built with the assumption I would just be running modern Linux, but I somehow re-discovered XP and simultaneously stumbled on coupling it with virtualization around the tail end of 2022. gcc/clang are still running on the Linux host though, as shown in the terminal emulator of the original screenshot. In any case, if the hardware is emerging from necessity and the software is emerging from choice, it's just a matter of squeezing out maximum performance from there. It would be wasteful not to. This is why I explained my background, story, use cases, etc. I realized there would be a minority of users, mainly developers still sympathetic to XP, facing a similar predicament, and I wanted to help. I'm not actually using modern Office or Windows 7/8/10/11 applications enough on a daily basis to need RemoteApp. RemoteApp is a convenience that isn't tied to my main work. Each XP user has a different use case, preference, workflow, or story for why they chose XP over all other seemingly more logical choices, and it almost always boils down to user preference and personal habits. Cold boots, I'm sure, are just one of many nuances, and it's difficult to articulate or enumerate all of them. The beauty of XP is in the sum of its parts.
  3. I haven't done enough testing with VirtualBox to give you a firm answer. Just in terms of how I would approach it, I would probably install the latest version of VirtualBox and see the results you get first. I think the CPU spikes are exclusive to VMware, as I wasn't getting CPU spikes on the latest Linux kernel with qemu/kvm. EDIT: Just saw your edit. The RemoteApp method is for a modern OS host (e.g. latest Debian Linux) that hosts two VMs: one for the application server, and one for XP. WinXP isn't running any VMs inside of it. However, I did post a similar method using VirtualBox running inside WinXP over here, which uses VirtualBox 5.2.44. The methods and hardware requirements are different, but, ultimately, achieves similar results.
  4. First, a screenshot: From my imgur description: Latest Discord running on Windows XP (with tray icon) Chrome 100+ running on Windows XP (with YouTube) Office 2016 (and above) on Windows XP C++17 support via g++ 7.x, shared folders, and SSH (mintty) Newer C++ standards can be supported (e.g. by building clang from source or downloading pre-built binaries) Full Windows XP taskbar and tray icon integration Full Windows XP file association support. For example: associate all *.xlsx documents with Office 2016+ (with proper icons and double-click application launching). Full Windows XP Add/Remove Programs support haiku-os.org cannot be accessed from XP Chrome 49 due to needing ECC cipher suites, as proof of modern Chrome This screenshot uses Windows 7 as the "application server" (for RemoteApp). Windows 10/11 are also supported, allowing you access to the latest software--such as the latest Chrome and Microsoft Office--beyond what is shown in the screenshot. Just for fun, here's a second screenshot showing file association support. The .xlsx document has an Excel 2016 icon and will open with the remote Excel 2016 when double-clicked. The .xls document has an Office XP (Office 2002) icon and will open with Excel 2002 when double-clicked: This method has been tested on both Windows XP Professional SP3 (32-bit) and Windows XP Professional x64 SP2. I've curated the exact files you need. Getting this to work on XP x64 (my preferred OS) was the hardest, but I've done the hard work and will share with you. So now that I have your attention... My Story I've used Linux for over 15 years now. After tolerating Desktop Linux for such a long time, my final verdict is: Linux will never succeed on the desktop. Anyone that has used Desktop Linux long enough, regardless of distro, will immediately know what I'm talking about. The gist of it is that the design & philosophy is not conducive to success in desktop operating systems, UI/UX issues, and, on top of all of that, there are too many minor bugs and annoyances that add up to an overall degraded experience. Even when the distro or desktop environment tries to emulate Windows in design, there are too many nuances that are just missing or wrong, and they inevitably run into a wall due to the overarching design and philosophy of Linux. One example of one of these "minor annoyances" that add up is when Desktop Linux still freezes in 2023. I haven't seen this in Windows since 9x. In some edge cases, I have to actually edit code to get things working in Linux. Linux/OSS fanatics will rejoice, "Yes! This is the way." I don't subscribe to the idea that something being open source is automatically better than fully developed, commercially successful, proprietary software. I don't have time to "edit code" every time something breaks, and anyone whom has been around software development long enough knows that understanding the code you want to edit takes significant time. With all of this aside, Linux is a fantastic server operating system. The average Linux application UI is essentially this though. Finally, the number of eyeballs on "server Linux," like OpenSSH where money can indeed be made or lost, far exceed the number of eyeballs on Leafpad, the attempt at a Notepad clone (which crashes and hasn't been fixed in over a decade) that's been in the Debian package repository for a while. Recently, I migrated back to Windows XP, the last Windows OS I used. I had been doing all kinds of Linux tinkering some 4-5 years ago for remote work (before COVID): SSHFS and remote filesystems, HPN-SSH patches, etc. However, I came to realize, as a developer, I only needed: Editor Compiler SSH All of the above are available on XP, and they don't consume hundreds of megabytes of memory. Furthermore, since I had been on Linux for the last 15-17 years, I haven't really been a heavy gamer. The games I play are from the XP era. I've played DotA 2 on Linux via Steam, but I never really got into it. I can't dedicate enough time to it to reach the threshold needed to not be a liability to a team in multiplayer. Long story short, I migrated back to XP recently. I don't want to get into all the nagging issues with Linux, but I only recently discovered the value of rest and breaks in productivity. Not having the games I actually care to play available on Linux and resorting to doomscrolling social media instead, on top of all the poor UI/UX paradigms in Linux, has led to substantial drops in overall productivity that has worsened over time and were not at the forefront of my consciousness or obvious enough to me until I came back to XP. I sympathize with people whom stubbornly stay on XP because it's where they feel most productive. Since it's the last Windows OS I used, and since it's the only Windows I know inside and out, this is also the most productive OS for me. Motivation I'm still learning and tinkering to get the most out of XP. At some point, I'm going to compile everything I've learned into a website. For convenience, I'm sharing what I've learned on message boards for now. There's a lot to share with the XP community. For example, I've observed (possibly incorrectly) the community has yet to recognize the benefits of hardware virtualization and instead run XP natively on old hardware. If you're running XP for productivity (rather than retrogaming), you should be virtualizing. Just because XP doesn't "officially" support Threadripper doesn't mean you can't run XP on a single Threadripper core and benefit from its 256MB L3 cache. You might have to write custom benchmark code, but I'm almost certain the data will confirm virtualized XP will have full access to the CPU's modern L3 cache. I had an NVMe drive failure, but I was going to set up my website with actual browser benchmarks. I've already tested the latest Firefox on modern Linux to be slower than Chrome 49 XP on the SunSpider and Octane benchmarks with the 4790K. FYI, this has something to do with JIT implementations too, but the XP VM will clearly be using your actual CPU hardware if you do your own tests. The cache is important because program instructions are loaded into memory. The differences in speed from the L1 to L2 to L3 SRAM cache, to DRAM, and, ultimately, to SSD/HDD are significant. Hardware virtualization is the only way to run Windows XP on a modern CPU and take advantage of innovations in CPUs over the last 10-20 years. If you're running XP for retrogaming, you should STILL be virtualizing. Look up qemu/kvm with GPU passthrough. With GPU passthrough, the XP VM will use your actual GPU, rather than the emulated 3D acceleration that Virtualbox/VMware have. You'll still need an XP-era GPU, because GPU passthrough requires XP drivers. However, you can couple it with modern CPUs, DDR5 RAM, NVMe SSDs, etc. Consumer hardware is only just now starting to hit XP's limits. 32-bit XP with the PAE patch should be able to support up to 128gb RAM. XP x64 natively supports 128gb RAM. Mini-ITX motherboards are just now hitting the 128gb limit. Again, at some point, I'll have a website that teaches you how to 1) select hardware most suitable to virtualized XP (it's not Threadripper anyway), 2) how to actually use and properly virtualize the hardware (e.g. CPU pinning, host OS configuration), 3) how to handle SSD TRIM, 4) etc. My motivation is to spread the gospel of virtualization. Running modern software on XP requires virtualization. Today, you'll be dipping your toes into this wonderful new world. 1. What is RemoteApp? RemoteApp is an official feature introduced to Remote Desktop by Microsoft for Server 2008. Rather than showing you the entire desktop, RemoteApp shows only the specific application you want. For example, if you want to edit a .docx file in Word 2021 hosted on Windows 10, Remote Desktop will route your local .docx file (on Windows XP) over to the Win10 server. Instead of showing the entire Win10 desktop to you, it will show you just Word 2021 with the document you opened. Since RemoteApp is a feature officially from Microsoft, integration into Windows is tight. You can create installers for RemoteApps. When you run the installer, it'll install the application as if it were a local application. So I can install a Word 2021 RemoteApp to my XP machine. If I go to Control Panel > Add/Remove Programs, I can uninstall Word 2021 as I would with any local application. As part of the tight Windows integration, RemoteApps can also have file associations. For example, I can install Office XP on my XP machine and associate .doc with Word 2002. However, I can also choose not to install Office XP at all and associate .doc and .docx with the remote Word 2021 hosted on Windows 10. When I double-click a .docx file, RemoteApp will launch Word 2021, forward my local .docx document over to the server, and Word 2021 on the Win10 server will load the file forwarded from the XP client. If I uninstall Word 2021, it will uninstall the .doc, .docx file associations. In other words, "RemoteApp" is an official feature from Microsoft that allows you to run modern applications as if they were local applications existing on Windows XP. The integration is very tight: taskbar, tray icon, install/uninstall, application launching, etc. 2. Hardware and Software Requirements The last post I made here about using VirtualBox seamless mode to achieve something akin to RemoteApp received some flak for having hardware requirements that are too high for the average XP user on older hardware. The benefit of RemoteApp is that you can run the latest Google Chrome on a XP 32-bit machine with 512mb RAM. The resource usage occurs on the server. Buried somewhere in my VirtualBox thread, you'll find a screenshot of Chrome 100+ hosted on Windows 7 using some 25mb memory on the XP32 client. This is because the bulk of the memory consumption is occurring on the Win7 server, not the XP client. For this tutorial, I'm assuming: - 4gb RAM for Windows 7 Ultimate - 4gb RAM for Windows XP x64 (although you can probably get away with 512mb RAM, but I haven't tested this) - 4gb RAM - additional memory available for the host Linux operating system. Use whatever CPU that will support both Windows operating systems running simultaneously. You'll want both Windows operating systems on the same machine for lag-free audio that syncs with streamed videos. If you want to use an operating system besides Windows 7 Ultimate, please make sure you check the compatibility table for RemoteApp Tool here first! In my tests, I was able to get RemoteApp Tool to work on Win7 Ultimate but not on Win7 Professional--which is in line with their compatibility table. You can get Windows 7 Ultimate for about $50 USD on eBay. You can get a stick of 16gb DDR4 RAM for $40 on NewEgg. The requirements here are relatively low, but they aren't minimal. Additionally, you'll need some software: - .NET Framework 4, WiX Toolset (pre-requisites for RemoteApp Tool) - RemoteApp Tool (again, check the compatibility link to make sure your OS is supported if you don't want to use Win7 Ultimate) - RemoteApp Windows updates for your version of Windows XP. You only need RDP 6.1, but I've been able to find updates up to RDP 7.0 for XP 32-bit. You can find the downloads at my archive.org profile here. 3. VMware Workstation You will need virtualization software. VMware Workstation is a Type 2 hypervisor. If you want a Type 1 hypervisor, you can use qemu/kvm, but you'll ideally want to set up GPU passthrough. For the sake of simplicity, Type 2 hypervisors like VMware Workstation are the easiest to set up. You can also use Virtualbox, but VMware has better support for 3D graphics. VMware Player is also free. XP is so old that I haven't seen this tip anywhere else on the internet, so here it is: if you want to play Warcraft III and other XP-era 3D games, you don't need native XP or a Type 1 hypervisor with GPU passthrough. VMware 3D acceleration supports these games. Enable 3D acceleration for the virtual machine and SET YOUR HARDWARE COMPATIBILITY TO VMWARE WORKSTATION 10.0. Modern VMware dropped support for XP a long time ago, so, out of the box, it seems like VMware doesn't have 3D acceleration for XP. By changing the VM's hardware compatibility to a legacy mode (and installing the corresponding VMware Tools), you can play fullscreen XP-era 3D games. Again, this is outside the scope of this article and will need to be put up on my website at some point. However, for the sake of simplicity, I'm going with VMware Workstation because you can enable 3D acceleration on both Windows XP and Windows 7 simultaneously, on a single GPU, by just clicking a checkbox. This is much simpler than writing docs to get graphics working on both operating systems and various hardware configurations. Advanced users can tinker for best results. For the host operating system, I'm using Xubuntu 18.04 LTS. My kernel version is 5.4.0-149-generic. The reason I am using this specific distro (rather than newer Linux distros with newer kernels) is because I have been getting periodic CPU spikes on my XP VMs on both AMD and Intel hardware with the newest distros/kernels. (X)ubuntu 18.04 LTS and Debian 9.5 are the last versions of Debian/Ubuntu I've had without periodic spikes in CPU usage on XP over VMware. In VMware Workstation, make sure you go to Edit > Preferences > Memory and check "Fit all virtual machine memory into reserved host RAM," otherwise, you might find Windows 7 will be incredibly slow. The last VMware hardware compatibility version guaranteed to support Win7 is 12.0. I've tested this setup on VMware Workstation 15.x, with the XP VM set to 10.0 hardware compatibility and the Win7 VM set to 12.0 hardware compatibility. Each Windows VM is assigned 4gb RAM, as previously mentioned. 4. Installing the Updates on the XP Client Since Windows XP predates RemoteApp, you'll need some Windows Updates to enable it. I've compiled the exact updates you need and archived them: https://archive.org/details/@superworkstation Find your version of Windows and install the updates in order. I've numbered each update. Start with 1, then 2, then 3, etc. Always reboot when prompted. For convenience, here are the installation orders taken directly from my archive.org profile: XP SP3 32-bit 1. KB961742-v3 - Updates to RDP 6.1 2. KB969084 - Updates to RDP 7.0 After updating to RDP 7.0, read the included text document, "Enable Network Level Authentication.txt" to enable NLA. Reboot after the registry edit or NLA will not work. XP x64 SP2 1. KB925876-v2 2. KB956744 3. KB2481109 Let me just add that it took many days of searching to find the needed updates for XP x64. At first, I thought Microsoft just never brought RemoteApp over to XP x64. However, I've been able to track down the three updates above, and I've archived them because I truly believe virtualization is the future for XP. So far, I've only been able to get XP x64 up to RDP 6.1 (the bare minimum needed for RemoteApp). The 32-bit XP has RDP up to 7.0 with Network Level Authentication (NLA). I have still yet to find the corresponding updates for XP x64 (if they exist at all). 5. Configuring the Windows 7 Ultimate Application Server 1. I would recommend skinning Win 7/8/10 to look like Windows XP. In this way, your RemoteApps on the XP client will look like native XP applications. This step isn't necessary for Chrome and Office 2016+ as they use their own styling. However, it can be useful if you intend to run other modern applications. 2. Install .NET Framework 4. 3. Install WiX Toolset 3.11. 4. Install RemoteApp Tool 6.0.0.0. Finally, start the RemoteApp Tool. You'll see something like this: Click plus button and select the EXE file you want to create a RemoteApp from. Click the added application and click the "Properties" button (right of the minus button). Now you'll see a screen like this: 1. Give your new RemoteApp a name. This is the name that will go into your Windows XP Control Panel's installed programs. 2. Click "Configure..." for file type associations. 3. Click the plus button to add a file extension you want to associate with the RemoteApp. Example: .xlsx for Excel 2016. Once you create the installer, the installer will install these new file associations on the client machine. RemoteApp Tool will prompt you to choose an icon. This is the icon that will be used for the file association. 4. Click OK once you're done with file associations. 5. Click "Save" Click the RemoteApp you want to export as an installer to your client machine. You should now see a screen like this: 1. Choose "MSI installer" under the "Options" tab. 2. Configure your installer in the "MSI options" tab. I usually keep the "Shortcut tag" checked with "Remote" in the text field to identify my remote applications on the client machine. Example: Excel 2016 (Remote) 3. Click "Create..." 4. Copy the .msi file to your Windows XP client machine. 5. Install your RemoteApp in Windows XP. 6. Done! 6. Quality of Life Issues Use VMware Shared Folders (or network file sharing, etc) to easily share files between the Application Server (Win7) and XP client. For example, when Chrome downloads a file, you want XP to be able to conveniently access it. Make sure "ping" from the client to the server is <1ms. Besides network latency, the reason you want both Windows operating systems (client and server) running on the same machine is for latency-free audio. Specifically, RDP has an option for the audio to be played directly on the server instead of being streamed to the client. For Google Chrome, I would recommend an RDP file instead of an MSI installer. Open the .rdp file in Notepad to edit it. Here's my config: screen mode id:i:2 desktopwidth:i:1920 desktopheight:i:1080 session bpp:i:16 winposstr:s:0,3,0,0,800,600 compression:i:1 keyboardhook:i:2 displayconnectionbar:i:1 username:s:<YOUR USERNAME HERE> disable wallpaper:i:0 disable full window drag:i:0 allow desktop composition:i:1 allow font smoothing:i:1 disable menu anims:i:0 disable themes:i:0 disable cursor setting:i:0 bitmapcachepersistenable:i:1 full address:s:<YOUR SERVER IP HERE> audiomode:i:1 redirectprinters:i:0 redirectcomports:i:0 redirectsmartcards:i:0 redirectclipboard:i:1 redirectposdevices:i:0 drivestoredirect:s:C:;Z:; autoreconnection enabled:i:1 authentication level:i:0 prompt for credentials:i:0 negotiate security layer:i:1 remoteapplicationmode:i:1 remoteapplicationprogram:s:Chrome disableremoteappcapscheck:i:1 alternate shell:s:rdpinit.exe shell working directory:s: gatewayhostname:s: gatewayusagemethod:i:4 gatewaycredentialssource:i:4 gatewayprofileusagemethod:i:0 promptcredentialonce:i:1 Specifically, you want to make sure audiomode:i:1 is set. This plays sounds on the remote computer instead of streaming it to the client. For an overview of RDP configuration settings, see this link. Conclusion I once talked to a technology executive at a major company. What struck me is that he was searching for ways to get the most results with the least amount of work and resources. This is in stark contrast to a lot of hardcore programmers that pride themselves on hard work and showing the results of their passion projects that consume hundreds/thousands of hours of work. I want to spread the gospel of virtualization and get more people to dip their toes into virtualization (starting with RemoteApp) because I truly believe this is the path of least resistance for Windows XP going forward. We're now in an age of Remote Desktop/RDP where you can get 60 FPS remote gaming. It's not just Google Stadia and other promises. For example, this Reddit thread shows a configuration to push RDP to its limits for 60FPS AAA gaming, tested at a AAA game development studio currently working remotely. Level1Techs on YouTube shows virtual machines all streaming graphics from a single server with one GPU. Here's one of their videos with VMware. However, I don't think 60 FPS remote gaming is possible on XP. Looking Glass uses DXGI for 60fps game streaming, which isn't available until Windows 8/10 (with only Win10 being officially tested and supported), but let's hope someone can get it working with RDP alone. There is still work to do. However, the obsession with porting Chrome, which I consider to be a solved problem with virtualization--whether via RemoteApp or VirtualBox Seamless Mode--would be better spent on bringing 60fps Remote Desktop to Windows XP. Microsoft Remote Desktop provides the tightest Windows integration, but the FPS seems to have a hard-coded limit. Try rdesktop (win32 build) with VcXsrv or Xming, and you might find it to be much smoother. Taking the open source rdesktop code and improving the Windows integration (taskbar, tray icon, minimize) would be far more rewarding, more future-proof, and apply to far more applications than a port of Chrome 87. My hope is that this is useful and, ultimately, redirects XP users' attention from ports to virtualization. A quest toward 60fps RemoteApp will be far more rewarding than ports and configs to get <insert application here> working on XP. I hope this helps! Happy computing!
  5. 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.
  6. 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.
  7. Currently listening to music on YouTube while staying in my Windows XP x64 desktop environment. Just 5 steps. Instructions are included in the screenshot.
×
×
  • Create New...