If we're going to make some kind of fix for this, we need to plan and have answers to some very important questions. The biggest question in mind right now is VAC, since all the solutions I see for getting zstd functionality into older clients is going to require some form of loading external code into the Steam client's walled garden. We need to know how sensitive the guards are to that, what ways might work and might not work, etc.

I've heard people have been using VxKex on the newer Steam clients for a year or so now. I've never tried that myself, but it is a good scenario for testing VAC sensitivity.

We really need solid answers to these questions:
1. Has anyone ever been VAC banned for enabling VxKex on only steamwebhelper[dot]exe? (both with and without propagating VxKex to child processes)
2. Has anyone ever been VAC banned for enabling VxKex on steam[dot]exe and steamwebhelper[dot]exe? (both with and without propagating VxKex to child processes). In the case of the former, that means enabling VxKex on the entire Steam client.
3. Has anyone ever been VAC banned for enabling VxKex on only SteamService[dot]exe? (both with and without propagating VxKex to child processes)
Note: Obviously, you would never enable propagation to child processes when launching a VAC-enabled game. This is just to see if any part of the client itself is sensitive to it. Just running the client only, no games.

If nobody has ever been VAC banned for using VxKex like this in the last two years, and we are confident that no one is hiding or lying about being VAC banned, then we could possibly conclude that 1) the Steam client itself is not sensitive to running external code in any way and/or 2) Steam just doesn't care about verifier DLLs being loaded into its processes. If this happens to be true, then we can safely proceed with at least one of the usual (and possibly only) ways to add missing C interface features (like zstd) to the older clients. If this is false instead, we might just be screwed.

---

Another thing that may be necessary is getting a newer version of Valve's custom CEF build (i.e. steamwebhelper.exe and co) to run in the older clients. I am doubtful this will solve the zstd issue alone, but it may be necessary in combination with other modifications. Back in 2023, I recall we were unable to get the post-vgui-death CEF builds (from sept 2023+ clients) to run in the vgui clients (august 2023- clients), despite both being at M86.

What about the newer clients? Has anyone tried (and maybe succeeded?) to get a M123+ Valve CEF build to work in the M109 CEF clients? For example, has anyone tried to get the latest July 2025 Steam client's CEF build working in the Sept/Nov 2024 Steam client? If that can be done, once again this opens up doors that we may need.

---

NB: Valve's exceptionally retarded & hostile censor thinks things like steam[dot]exe are websites and censors them, which is why I had to write them like steam[dot]exe. What a great new change.

Originally posted by bidulless:

if the solution is easier till now and use the same process , uninstall the faulty update/game,then download it using depotdownloader or steamcmd, copy back files to the right steam folder and then , initiate a new download of the game :
- files will be verifyed and at end it will show you that you succed on downloading the game.

Good to have a workaround, but this is an extreme amount of work, especially for games that may update multiple times daily (such as Garry's Mod). Workshop content also is a problem (is zstd being used on UGC addons yet?).

Maybe steamcmd could be used to make this painful, like always launching steamcmd before launching the library, and having steamcmd pointed at your client's library folders so that it can update the games in-place (hopefully no need to move files, uninstall, move back, re-"install", etc).

Originally posted by bidulless:

till now it's easy but i fear that it will be a game over when zstd will be use for cloud save/download because you will need to manually download/uplooad them to/from your account and it will become really, really annoying ....

Yeah... this could be pretty bad.

Originally posted by bidulless:

it's spreading trought update for games released after cef 109 ( zstd has been added to cef 123+ ) but now also on any game update

So far I've noticed this happening for all updates to all games I own, except Garry's Mod. So far... Knock on wood.

Maybe we should revisit the old idea of shoehorning a newer Valve CEF build (post M123) into the older clients. It might be the best way forward (eugh...).

This just started affecting me last week. I didn't realize it started as early as May, and it's sad that there is no solution here yet :c

Assuming VAC wont throw a fit, shimming the necessary zstd interface into the older clients may be all that is needed.

Originally posted by lightwo:

Originally posted by TiberiumFusion:

This will change in the nearish future once Valve adds the missing dates to the retail client.

Oh, I doubt that. If Windows 7 was supported by Steam for 15 or so years by now, and Windows 10 is only going to stop receiving support in about 2 years, there's no reason to deprecate Steam for that platform yet.

Read the trends and spend more time in the Windows world. Or work in the software industry. You are gravely mistaken about what "Windows 7" is versus what "Windows 10" is and how much the world has changed.

M$'s "official" support for 5.1 and 5.2 client skus ended in April 2014 (real support notwithstanding). Valve abandoned those platforms on Jan 1 2019, or five years later. Market share of those skus declined ultimately at the decision of end users. It remained profitable to support these skus for a while as users slowly changed platforms. Most (Steam) users purchased os services instead of os products.

M$'s "official" support for 6.1 and 6.3 client skus ended in Jan 2023 (real support notwithstanding). Valve will abandon those platforms in Jan 2024, or one year later (not five). Market share of those skus declined ultimately at the decision of end users. It remained profitable to support these skus for a little longer as users changed platforms, but by now most (Steam) users no longer purchase os products anymore.

M$'s "official" support for 10.0 retail client service skus ends in Oct 2025 (non-retail service skus notwithstanding). These are services, not products. Market share of these skus ultimately declines per M$'s decisions to shutter their services, not the end user's. Services cease to exist once they are shuttered, and the 10.0 retail client service skus ("Windows 10" and "Windows 11") are no different.

The consumer license for 10.0 retail client service skus stipulates that M$ reserves the right to cease offering this service at the end of the support term. This has been well known for the last 8 years. Like all giant software organizations that have created a permanent dependency for themselves on M$'s os services and extremely powerful consumer license, Valve is preparing for this contingency. They will not waste any further resources on a highly expensive os service if/when M$ ceases to offer it and 100 million Steam users on "Windows 10" now have zero operation system. Valve's goal is to make money, and there is absolutely no money to be made by selling their product on a service that no longer exists. If/when M$ eliminates service for the "Windows 10" service retail skus by Feb 2026, Valve will quickly follow suit. Observe the same pattern in all other large forces in the current Windows saas ecosystem.

This will not be 5-10 years from now. This is coming in 2 years, i.e. a time frame shorter than the majority of negotiated support contracts for enterprise software of this era at this scale. Aka the nearish future.

Accordingly, Steam users who are 10.0 client service customers (notably, "Windows 10" users) should also be preparing for this contingency.

Originally posted by lightwo:

Though, I guess it would be a good idea to test with a system date many years in the future to check if Valve already decided when to discontinue Windows 10 and macOS 13.

I re-investigated the switches in the Sept 2023 client. There are no dates attached to -pretendeol-w10 and -pretendeol-mac-13, but the framework for the abandonment messages is in place. Either Valve has not yet decided on an abandonment date for those systems, or they have selected one but haven't yet included that information in a retail release of the Steam client.

So, for all contemporary releases of the Steam client so far, using either of the mentioned switches effectively permanently disables the countdown banner, regardless of the time when it is used. This will change in the nearish future once Valve adds the missing dates to the retail client.

This doesn't modify any files and it doesn't require a skin. It works on all versions of the Steam client, both in vgui mode and in desktopui mode.

Steam has a variety of hidden switches for faking the various platform abandonment messages. Since May 2023 (possibly earlier), they are currently:
-pretendeol-xp
-pretendeol-w7
-pretendeol-w8
-pretendeol-w10
-pretendeol-mac-7
-pretendeol-mac-11
-pretendeol-mac-13

This list grows as Valve continues to add platforms to the list that they will abandon in the nearish future.

If you launch steam with one of these switches, the "you're getting screwed soon" messages will be based on the platform you specified in the switch, not the platform of your computer that Steam is running on.

For example, if you launch steam with -pretendeol-xp, the countdown nag will appear and be set to 0 days, since the abandonment of XP already happened.
And If you launch steam on a mac machine with -pretendeol-w8, the countdown nag will appear and says steam abandons windows 8 on Jan 1 2024.

This can be exploited to hide the countdown nag, by launching steam with a -pretendeol-xxx switch for a platform whose abandonment date is too far away for the countdown nag to automatically appear.

For example, launch steam on Windows 7, 8, or 8.1 with -pretendeol-mac-13 and the countdown nag will disappear.

Originally posted by re11ding:

I just realized but with the new guide, profile popouts don't happen when hovering over your avatar, even your own. This, surprisingly, worked on the -nofriendsui when the package folder was renamed. Can the patch not grab that information?

See: https://github.com/TiberiumFusion/FixedSteamFriendsUI/issues/1

Yesterday and today I am on a much needed hiatus from all this so please excuse my absence. But I've checked in with the comments so far and I am happy to see the patch is working for people. Issues with non-English languages have been reported and will be addressed in a day or so when I get back to this.

Originally posted by re11ding:

I had one question actually just for safety's sake. Where did you source the JS files? I'd love to compare hashes for security's sake to make sure there's nothing modified that steals data or anything. I'm not saying I don't trust you- not even close. I'm just paranoid about that sort of thing and like to be absolutely sure.

All PWA files were obtained from Valve's various cdn edges. The known url to the files were obtained through deep searching the hierarchy of files at this starting point: https://steam-chat.com/chat/clientui/?l=english&cc=US&build=1685488080
Redacted versions of the PWA files were extracted from steamwebhelper's cef cache on one of my PCs that infrequently launches Steam.
This is a process that took me about 3-4 hours, then another 2-3 hours to repeat on a later day to acquire then-contemporary versions of necessary that weren't in my cache. There is no manifest of PWA files; you must determine the known urls to the files by closely inspecting the 100000-ish lines of javascript. If you want to repeat this process yourself and obtain all the files you are looking to hash & compare, you will need:
1) An understanding of web suite languages, especially bastardized and minified javascript
2) An understanding of http requests
3) An understanding of the PWA structure, how Valve structures their CDNs and how they serve the files
4) Patience exploring the hierarchy of PWA files to determine the known urls of the various files, requires 1, 2, and 3
5) A time machine; or, a PC with Steam installed that you launched around July 30th and did not launch since then, as well as a second PC with Steam installed that you launched around September 27th and did not launch since then.
And maybe some other things that I am forgetting. Good luck.

Originally posted by DSDDukeNukem:

Many thanks for the massive work you've done Tiberium. Just a quick question before I do shizz, I'm using the nofriendsUI method, and added a "/*" in front of my version in "steam_client_win32.manifest".
Can you confirm to make your patch work, I just have to delete that "/*" in steam_client_win32.manifest to restore it, then remove the "nofriendsui" line in my exe, then apply your patch, and just launch with -vgui. Am I good?

Originally posted by DSDDukeNukem:

Didn't work at 1st. So I manually installed patch, made a backup of friend.JS, removed the /* i manifest, started only with VGUI, and it's back. Kudos to Tiberium ^^

Good to hear it's working for you. I would recommend undoing the -nofriendsui workaround when using my patch, but the whole "steam store doesn't work" thing is news to me. I use May 31 client and I haven't made a purchase through the steam client in a month so I cant verify this myself. But it's very plausible that the steam client attaches its build number to all http requests made to Valve servers, and Valve arbitrarily refuses purchases if that number is too small to force people to install updates. This behavior is common in other parts of their web service. Sounds like another topic needs to be created to discuss this.

I am relieved to announce that my patch is finally available for everyone to download. Please refer to the following Steam guide I created for information on how to download and install it: https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=3045036713
I created an application which makes installing & uninstalling the patch as fast & easy as possible, so I highly recommend trying it out. It'll take about 1 minute, and It's much better than using the -nofriendsui workaround.

Don't get me wrong, I love classic friends/chat and I hated when it was replaced by the modern Discord-clone version back in 2018. But there are numerous reports of many things being broken in the classic version, and there is a chance Valve will completely nuke it sooner than later when they bring armageddon in Y2K24.

In contrast, when using my patch, everything (that I could test) in modern friends/chat is working correctly. You can chat, group chat, voice chat, add/remove friends, invite friends to games, set your status, show your game presence, etc etc and it all works. It's just like Valve never fucked it up all in the first place. That was the goal.

If you've been waiting for this, thank you for bearing with me and the great deal of time it took to get to this point. It has been a 2 week long slog and I'd like to wash my hands of this whole ordeal and get back to my life. But I will maintain this patch for the foreseeable future and update it if needed, and respond to comments questions and all that. If there are bugs, please let me know.

Originally posted by DSDDukeNukem:

Can only wish you best of luck to finish and publish your guide on github or elsewhere, Tiberium. Valve's methods of censor are vomiting.

Yes. Yes it is.

I ended up going with the "dump everything on the github repo" route, and as of right now all that stuff is finally done. Guide -> Wiki migration is done, tree refactoring is done, releases are made, everything else to make the repo a halfway decent looking front page for the problem, etc. I don't like that users will have to navigate away from steamhost.cn/steamcommunity_com to get information on the patch, because there will inevitably be users that don't want to continue reading something on a different website, but that's how it's going to be for now.

Which means at last I can now finally make this next post: