64bit Support for macOS Catalina

[alanedwardes]

Hi,

Based on what I have read, it looks like macOS Catalina (slated for release in the next few months) will drop support for 32bit applications. I believe this impacts this SDK, which will mean that my game (Estranged: Act I) and others will cease to run natively on macOS after the user upgrades their OS.

A few questions: 1. Is that assessment correct? I only see 32bit dependencies in this repository for macOS 2. Will this impact Half-Life 2, Episode 1, Episode 2, Team Fortress 2 and Portal? 3. If it does and Valve plans to fix those titles, will that work be upstreamed into this SDK?

Edit - since this is confirmed to be affecting older Valve first party titles, a few questions based on that:

1. Will this be addressed for older Valve first party titles?
2. If it will be, will that work be merged into this SDK?
3. Are there any plans to merge the Vulkan support as described below to this SDK?

Thanks, Alan

[MoOx]

I currently have Catalina installed & cannot start Half-Life 2 anymore. CS:GO works tho.

[neico]

Apple will also drop support for OpenGL (which was deprecated in 10.14 Mojave) if Catalina hasn't already dropped it, which means that not only x64 support is needed, but also Vulkan support (trough MoltenVK) needs to be backported from more recent engine branches like CSGO and Dota 2, as it's unlikely that the engine will ever see native Metal support.

If you want to play games, your best bet is to stay on Mojave and sit it out (it's also a great signal towards Apple that they can't just break stuff whenever they like.) Tough it's primarily valve's fault for not anticipating this and working ahead to bring their own engine on par with today's standards.

[MoOx]

I am a native dev & needs latest macOS softwares, I am sad that I cannot start HL2 again :'(

[MoOx]

Problem is: most people won't know that unless they upgrade & try to start their game...

I even tried Left for Dead 2, same issue... :'(

[alanedwardes]

Yes, asking users to stay on an old version of macOS is not a viable workaround. This is not a surprise annoucement from Apple, it has been several years in the making - as @neico mentioned, this unfortunately sits with Valve as they didn't work ahead and bring the legacy engine branches up to date.

That said, they may not ever do that, I just wanted to express interest in this on behalf of my Mac players in case someone at Valve might have the capacity to do this.

Somewhat related, but if you are in the same position as I am - it looks like Steam will support the distinction between a 32bit and 64bit Mac app and alter the UX accordingly: https://steamcommunity.com/groups/steamworks#announcements/detail/3632639303428097613

[Laim]

Any updates on this? Just went to play HL2 and realised I couldn't... :|

[maxekman]

I would also like to play HL2 on Catalina. Really sad to see it break. Hopefully Valve can rebuild the apps for 64-bit relatively easy!

[Wadmodder]

It's very likely or unlikely that the 64-bit ports of classic Source engine games (pre-Source 2) are in a form of development hell, making this the 3rd Valve project in development hell after Half-Life 3.

[SamWWJD420]

My favorite part of the MacOS user comments is how they blame the developers of old software, for an OS choosing NOT to be backwards compliant. This is CLEARLY intended to steer users to new hardware and software.

What happened to the philosophy that if you CAN keep it backwards compatible without too much trouble, you should! I mean, how hard would it be for the mac dev team to include openGL and 32bit support as a downloadable compatibility package? NOT hard!

But if you read the comments, instead of them adding a SIMPLE option to download and opt to use old code for a game to work properly... they expect valve to COMPLETELY redevelop their 8-15 year old software stack so it can support their new BS driver they prefer now.

Talk about backwards thinking! You've drank the koolaid and I suspect it's too late for you to get good technical representation. You bought the hook, line, the sinker, AND the brooklyn bridge at that point.

It's a little game we play in the industry called, Apple or MS Dev trying to make a name for himself: oh hey guys, if we don't include this old code here, all the old games will stop working, the users will blame the game companies, and we'll sell a TON of new hardware and new games on our app market! Y'know the new expensive ones that people aren't buying because they'd prefer to play through such blockbuster title's as HL2... Apple or MS Exec: LETS DO IT! (I used to just say apple was like this, but MS is copying from the play book lately).

Hey Apple, FIX CATALINA. EVERY mac user I meet that's upgraded to it complains about wanting to downgrade back to Mojave!!

[Laim]

As much as I agree with you Sam that it’s annoying, removing 32bit support is not intended to make Apple more sales. If anything, it would prevent people from upgrading due to backwards compatibility.

32bit needs to die, and Apple gave people more than suitable notice that it was intending to remove 32bit support.

Valve don’t need to redevelop their entire old library, it would be nice but it’s not expected. What they do need to do is update the steam client to be 64bit and any new games they release.

Anyone releasing 32bit games or software in 2020 is a moron.

[Yetoo1]

@SamWWJD420 I don't agree with what Apple is doing at all, but the problem here is that Valve isn't adverting on their source games' steam pages that these games aren't going to work with Catalina. This is false advertisement and can lead many unassuming customers into buying software that was never going to work on their system in the first place.

@Laim

As much as I agree with you Sam that it’s annoying, removing 32bit support is not intended to make Apple more sales. If anything, it would prevent people from upgrading due to backwards compatibility.

Why would Apple intend people not to upgrade? Their entire business model lately has been to prematurely phaseout the old and bring in the new. What, your saying they did this solely because they didn't want to spend money on supporting 32-bit?

[SamWWJD420]

I disagree. 32bit doesn't need to die. No more than 16 bit! I have this cool archive on a 16bit windows 3.0 CD. Not only can I run it, due to phenomenal backwards compatibility, I can also run current 64bit applications.

In truth, 32bit apps take less ram; and for some processes they even perform faster on a 64bit architecture with proper support.

Have you heard of backwards compatible? I actually think Steve Jobs promoted this ideal back in the day... but The idea is, as long as you CAN provide backwards support, especially with little or no effort (a line of code that says "include 32bitarchitecture" or something) it isn't as though they have to program something new on 64bit OS software to support 32bit. Like... it's already built and not changing. I haven't heard much about it holding back new technology.

In fact, it only has to do with the size of the DWORD that is available for a variable... If you've ever programmed you'll know it's a cinch between 32bit and 64 bit. It's basically the same code; just 64 bit has longer variables AND can perform more functions. If a programmer uses LESS architecture by choice, and makes a 32bit program, we've all been raised in computers since the 50's to TRY to keep old programs working unless it's something like hardware that breaks things.

Maybe atom's and their arm architecture are what's having trouble supporting 32bit...? I dunno, I guess I can see this clearly:

Mac runs on a version of the Linux kernel. If you have access as a root user on a mac you could in theory compile and add 32 bit support yourself. Why do I know this? Because on any 64 bit linux distribution I install that doesn't have 32 bit architecture, I can download and add that with one to a few lines from the command prompt. It's deception to say that it needs to die; as though it's some anthropomorphic entity that is clawing at the tail of 64 bit like a beast that JUST WONT KEEL OVER AND DIE DARN IT! lol.

No, it's existing code, that works, and you just have to include it. it can't break 64 bit systems UNLESS THEY DON'T INCLUDE THE ALREADY EXISTING CODE!

On Sat, Jan 11, 2020 at 1:50 PM Yetoo1 notifications@github.com wrote:

@SamWWJD420 https://github.com/SamWWJD420 I don't agree with what Apple is doing at all, but the problem here is that Valve isn't adverting on their source games' steam pages that macs aren't going to work with Catalina. This is false advertisement and can lead many unassuming customers into buying software that was never going to work on their system in the first place.

@Laim https://github.com/Laim

As much as I agree with you Sam that it’s annoying, removing 32bit support is not intended to make Apple more sales. If anything, it would prevent people from upgrading due to backwards compatibility. Why would Apple intend people not to upgrade? They're entire business model lately has been to prematurely phaseout the old and bring in the new. What, your saying the did this solely because they didn't want to spend money on 32-bit?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/source-sdk-2013/issues/481?email_source=notifications&email_token=AOIBDYST65YBKC4B2RPGAGDQ5I5LFA5CNFSM4IUPN5D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIWL4HQ#issuecomment-573357598, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIBDYQ7XUL2H2HJ7WRT3PDQ5I5LFANCNFSM4IUPN5DQ .

[Yetoo1]

@SamWWJD420 I think you misread what I said (or what you read was mangled by Github's mailing process and those quotes were omitted and merged with the statement). I agree that 32-bit should be supported, I disagree with Apple removing it along with supporting it. Macs use XNU which is completely different from the Linux kernel (although not relevant to the discussion) and keeps relatively same user land api and abi as FreeBSD and other BSDs as far as my understanding. What makes Macs similar to Unix is the user land which as said earlier is based off of FreeBSD and other BSDs. What my understanding of what they did was drop the internal data structures to handle 32-bit so compiling standalone libraries won't work. They couldn't have alleviated a lot of the concern and possible exodus by implementing a virtualization solution which would be able to virtualize those data structures on 64 bit, but of course the wouldn't because the entire point was to save money by reduction in time spent in unneeded (to them) areas.

[SamWWJD420]

Most likely Steam will go the way they went with SteamOS and linux boxes; and they'll find a way to run in a VM or else include the needed libraries that used to be included in MacOS pre Catalina.

[SamWWJD420]

I think I was mostly replying to Liam :) I didn't see your post Yetoo1 until after I'd already replied, sorry!

And Liam, I kinda think it IS for Mac to profit from upgrades and software sales.. I can't imagine it anything to reduce the time spent supporting things..

[Spirrwell]

I'm not really sure if this is the place to argue about who's right or wrong, Valve, Apple, or whatever.

But 64-bit CPUs have been around for ALMOST two decades and have been pretty much standard for over the last 10 years. Nearly everyone has a 64-bit machine with a 64-bit OS.

I'm sure there's very few people who are developing 32-bit only as an explicit choice.

32-bit is the default target when using Visual Studio. (which it really should target the native architecture of the OS) But why change to 64-bit if everything's already working, right?

The continued support and bias for 32-bit has likely had an impact on developers supporting that only.

It is going to suck to rip off the band-aid, but ultimately it is best if operating systems tend toward completely removing 32-bit support, and developers have had loads of time to move over to a 64-bit ecosystem.

If we continue with this not moving forward to 64-bit development, it will only widen the legacy gap and create an artificial dependence on 32-bit. So developers really need to start supporting 64-bit, and operating systems should PLAN to phase 32-bit out, just as OS X has.

I agree with Laim's sentiment that it's stupid to develop a new application and target 32-bit nowadays. Even relatively new applications still run 32-bit only on Windows, such as Discord, which is silly.

Anyway, since this topic is about the Source SDK, I believe CS:GO is already 64-bit native on OS X and Linux. It would be really nice if we could get an updated SDK with 64-bit support, or a Source 2 SDK. I'd settle for either.

[neico]

Software developers all around have seen increase in performance ever since removing support for XP and x86 (32 bit). Why? Simple, because those things require lots of workarounds and sometimes outright block new features that are a no-brainer on x64. It not only increases the address space of memory, it also introduces faster instructions that sometimes were provided as extensions on x86 (but inconsistently, so you couldn't blindly rely upon them) which are now part of the core instruction set in x64

On the other hand we have Microsoft, the only company still having a major OS still supporting x86 as the default choice (on all other platforms you need to get active to even get your hands on it) And until VS2017 VS was even x86 only (except for the compiler tools) which caused some severe bottlenecks in regard to memory usage. At Valve, their founding members originally came from Microsoft so you'd expect them to have a similar mindset regarding that.

Even then, all their recent games are native x64, CS:GO (source1-2 hybrid), Dota2 (source2) and Half-Life: Alyx is going to be x64 game only for the sole reason that Source 2 doesn't even support x86 anymore. (and would probably cause again some bottlenecks because of VR being pretty demanding)

So the move of apple to remove support to that should be nothing new to a person decently aware of computers. (Even Android is 64 bit per default nowadays)

The real neck breaker here is that they are also removing support for OpenGL, which is very much still one of the major graphics API's, especially cross-platform (second only to Vulkan), there is a decent wrapper for Vulkan (MoltenVK, which wraps around apple's Metal API), but source1 doesn't even support Vulkan. Something that again is a non-issue for Source 2, but the chances of Source2013 getting another update to fix this all up are slim.

The best you can do is watch carefully what will happen to Team Fortress 2, which is an updated branch of Source2013, if that doesn't get those needed changes then mods never will.

[psychonic]

Source 2 doesn't even support x86 anymore

That's not accurate. Dota 2 still ships a 32-bit build on Windows (in addition to 64-bit) and is on Source 2.

[Wadmodder]

Many of the older DirectX versions are not officially supported by Microsoft anymore. List of versions and possible same EOL dates as main support for Microsoft's operating systems: DirectX 1.0, 2.0, and 3.0: EOL dates unknown DirectX 4.0: unreleased, never made supported DirectX 5: Windows 95's EOL date (12-31-2001) DirectX 6: Windows 98's EOL date (7-11-2006) DirectX 7: Windows 2000's EOL date (7-13-2010) DirectX 8: Windows XP RTM & SP1's EOL date (10-10-2006) DirectX 9: Windows XP's final EOL date (4-8-2014) DirectX 10: Windows Vista's EOL date (4-11-2017) Either Valve doesn't care about development on currently supported DirectX versions or developing on newer DirectX releases cost more than the older releases, or developing stuff exclusive to 64-bit processors is more expensive than the 32-bit counterparts. So in my speculations, Valve is likely buying most 64-bit PCs but are mislabeling them as 32-bit PCs to call it their own 64-bit PCs. To me, that translates to ViacomCBS buying HTML5 development books but are mislabeling them as HTML4 development books to call it their own HTML5 development books. This means that the 64-bit version of Steam for Windows & Linux, as well as all 64-bit updates for all older pre-Source 2 games are currently in development hell.

[Wadmodder]

So in other words to Valve, re-release all Source Engine games on macOS again and then will buy them, but this time ship it with a new codebase and a cleaner optimized version, by using the CS:GO Source 1-2 hybrid codebase, rather than just the aging & now crappy Source 2013/Orange Box codebase stuff we get multiple patches for patched out exploits multiple times a year. Give us what we want.

GoldScr, kind of a different story, still not officially in 64-bit beta, and even if Valve backported 64-bit code from either Source 2 or some Quake 1 source port with a native 64-bit release, it's very unlikely if the latter engine is getting upgraded to 64-bit.

[booherbg]

I upgraded to 10.15 and didn't realize that I would lose access to all of my HL2 games :(. It's really too bad, I cherish that I can still play these games that I bought over 12 years ago. I still have my linux laptop but it isn't quite the same as the performance on my MBP.

[Elaryo]

why does nobody mention bootcamp here? I think it‘s the best option.

[Laim]

why does nobody mention bootcamp here? I think it‘s the best option.

Bootcamp is good, and it's an ok alternative, but it shouldn't need to be used tbh

[joaormatos]

I upgraded to 10.15 and didn't realize that I would lose access to all of my HL2 games :(. It's really too bad, I cherish that I can still play these games that I bought over 12 years ago. I still have my linux laptop but it isn't quite the same as the performance on my MBP.

Here's an idea for you to entertain: make a portable installation of your favorite gaming/MBP friendly Linux distro on an USB drive and then boot your MBP off of it.

Personally, I would just replace macOS entirely but I can guess you don't want to do that and I can't recommend a dual boot since those are usually a hassle to do in a completely safe manner.

[booherbg]

I upgraded to 10.15 and didn't realize that I would lose access to all of my HL2 games :(. It's really too bad, I cherish that I can still play these games that I bought over 12 years ago. I still have my linux laptop but it isn't quite the same as the performance on my MBP.

Here's an idea for you to entertain: make a portable installation of your favorite gaming/MBP friendly Linux distro on an USB drive and then boot your MBP off of it.

Personally, I would just replace macOS entirely but I can guess you don't want to do that and I can't recommend a dual boot since those are usually a hassle to do in a completely safe manner.

Yeah, an extra step but not a bad idea. Unfortunately I think this is the main option, other than dual booting windows (so that I can get double my civ6 performance, the mac client crashes continuously and wont run on my linux setup ugh).

[nex86]

Wait for Half Life 3.

No but seriously. not even the most frequently updated games like Team Fortress 2 are supported anymore. Why can't they just compile the engine in 64bit and push an engine update for all the games?

I have an older Macbook running Catalina, the OS itself runs fine. But most new games that are 64bit run really bad. The source engine games were the only games that ran really well on this book. Now can't even play portal...

I would downgrade to Mojave but some apps like Xcode won't run under Mojave.

[nex86]

source was leaked, now other devs can compile it to 64bit if valve won't do it.

[lilalinux]

why does nobody mention bootcamp here? I think it‘s the best option.

The bootcamp touchpad driver is a disaster and the Touchpad++ driver looks completely untrustworthy to say the least.

[nex86]

Because its a Mac and not a PC.

[dimhotepus]

source was leaked, now other devs can compile it to 64bit if valve won't do it.

As smb told me leaked sources miss vphysics, so it will be hard to do without (use vphysics from 2003 engine leak + patch it, maybe). Also, sources are extremely outdated.

May be Valve release Source 1 engine for public one day :)

[dimhotepus]

No but seriously. not even the most frequently updated games like Team Fortress 2 are supported anymore. Why can't they just compile the engine in 64bit and push an engine update for all the games?

It is not so easy.

Many Source 1 parts must be modified to support x86-64 mode - at least tier1 collections (mostly x86), memory allocators and memory subsystem, internal studiomdl structs are using pointers and integers mix, dependencies like Bink and Miles Sound System need x86-64 versions, etc.

As Source 2 is successor of Source 1 and is x86-64 compatible, may be smb port old games to this, when engine becomes free (looking at you, Gaben).

[monroewilliams]

Evidently they had a version of the Source engine running on x86-64 in 2005 (!). (AMD64 is the original name for what turned into x86-64, they're basically identical outside of supervisor mode.)

https://www.shacknews.com/article/40054/source-engine-goes-64-bit

If this is accurate, I'm really curious why they wouldn't have done a MacOS 64 bit build sometime in the last 15 YEARS. It became clear that Apple was moving to 64 bit over 10 years ago, and this should have been clear to anyone doing Mac development in that time. (I was just looking at the history of one of my personal projects, and I added an x86_64 slice to the build in 2009...)

If it ever were properly open-sourced, I would absolutely volunteer to work on getting a 64 bit Mac build going in my spare time. (I've been doing Mac development since 1991, so this is the sort of thing I would be able to help with.)

[Wadmodder]

Aside from the 2003 HL2 leak, a 2012 leak of Source 2007, and 2016-2017 facepunch leaks, Source code to an older codebase of CS:GO, an older codebase of TF2, as well as Postal III were leaked, but it's unlikely anybody is going to use those source codes as a basis for open source projects, since Valve own 64-bit macOS version of Source 1 is in development hell.

And also the 64-bit version of Steam for Windows (& Linux) currently still remains in development hell since as early as the mid-2000s.

[dimhotepus]

And also the 64-bit version of Steam for Windows (& Linux) currently still remains in development hell since as early as the mid-2000s.

In general, 64 bit programs take more ram space due to extended pointers size and more heavy function calling convention (prolog / epilog). IMHO, Steam client should steal from system as little resources, as possible. But now client is kinda fat thing, and looks like they use fork process model to overcome 32 bit memory limitation.

[username0x0a]

Dear @ValveSoftware, would you be so kind and do something about 64bit support, on Mac in particular?

Apple moved to 64bit some 15 years ago. The only period 32bit apps were in production was the temporary, transfer timespan of Mac OS X Leopard and the first Intel Core Macs. Since Snow Leopard release in 2009, there was ABSOLUTELY no reason to even care about 32bit for future anymore, that's 11 years ago where the future development has been clearly set.

It's 2020. 3 years after announcing a final deprecation of 32-bit, Valve is still living in 200X, not being able to provide products for future.

In this same 2020, Apple is making another transition where moving to ARM 64-bit, Windows will probably follow as well sooner or later, Linux has been 64-bit for ages due to the progress there…

And this Valve can't even provide proper client & game updates in last 9 YEARS. What's more eminent –

32-BIT-ONLY VERSIONS OF STEAM AND SOURCE GAMES SHOULD'VE NEVER EXISTED!

Since Day 0 of Steam on Mac, Apple was fully supporting 64-bit architecture for years already. Valve should be hardly penalised from customers for introducing products with unreliable timespan, built on legacy technologies there were not supposed to use with future in mind.

It's 2020, I have two 2019 MacBooks on the desk, attempting to play Portal 2 in co-op…and I have to install GODDAMN CROSSOVER TO PLAY OVER WINE! 🤦‍♂️

What can we expect from this pipe company? Apple has succeeded 2 architecture transitions when Valve wasn't even able to follow with proper evolution with the surrounding world – they're just stuck in 2008, only concentrated on sacking up money. When is any ARM support going to happen, both on Mac and Windows eventually? Apple will architecture and move forward 4 more generations of home-made CPUs and GPUs while this company won't even perform a recompile of existing games. And it certainly is possible, as CS:GO is probably the only Source Valve game available on Mac now – yeah, you know why, 'cause they can suck even more money. Even 3rd-party, indie game devs are more flexible here than this multibillion company.

Please, do something about this. There's a huge technical debt followed by many angry users whose Steam library is worthless as an effect.

[micwoj92]

Just dont buy inferior, closed apple products lol

[dimhotepus]

Dear @ValveSoftware, would you be so kind and do something about 64bit support, on Mac in particular?

Apple moved to 64bit some 15 years ago. The only period 32bit apps were in production was the temporary, transfer timespan of Mac OS X Leopard and the first Intel Core Macs. Since Snow Leopard release in 2009, there was ABSOLUTELY no reason to even care about 32bit for future anymore, that's 11 years ago where the future development has been clearly set.

It's 2020. 3 years after announcing a final deprecation of 32-bit, Valve is still living in 200X, not being able to provide products for future.

In this same 2020, Apple is making another transition where moving to ARM 64-bit, Windows will probably follow as well sooner or later, Linux has been 64-bit for ages due to the progress there…

And this Valve can't even provide proper client & game updates in last 9 YEARS. What's more eminent –

32-BIT-ONLY VERSIONS OF STEAM AND SOURCE GAMES SHOULD'VE NEVER EXISTED!

Since Day 0 of Steam on Mac, Apple was fully supporting 64-bit architecture for years already. Valve should be hardly penalised from customers for introducing products with unreliable timespan, built on legacy technologies there were not supposed to use with future in mind.

It's 2020, I have two 2019 MacBooks on the desk, attempting to play Portal 2 in co-op…and I have to install GODDAMN CROSSOVER TO PLAY OVER WINE! man_facepalming

What can we expect from this pipe company? Apple has succeeded 2 architecture transitions when Valve wasn't even able to follow with proper evolution with the surrounding world – they're just stuck in 2008, only concentrated on sacking up money. When is any ARM support going to happen, both on Mac and Windows eventually? Apple will architecture and move forward 4 more generations of home-made CPUs and GPUs while this company won't even perform a recompile of existing games. And it certainly is possible, as CS:GO is probably the only Source Valve game available on Mac now – yeah, you know why, 'cause they can suck even more money. Even 3rd-party, indie game devs are more flexible here than this multibillion company.

Please, do something about this. There's a huge technical debt followed by many angry users whose Steam library is worthless as an effect.

Unfortunately, that's hard to port such huge codebase to x86-64 at once. From 2016-2017 facepunch leaks we can see that some work has been done in porting Source 1 to x86-64: presence and usage of PLATFORM_64BITS and COMPILER_MSVC64 preprocessor macroses, removing inline assembly not supported by MSVC under x86-64, etc.

But much more effort is needed to port tier0 memory management, tier1 collections, find and fix a lot of pointer truncation's inside engine (Valve likes to store pointers, structs, etc. inside ints for optimization, but it makes a hell for x86-64 port), break some API/ABI relying on 32 bit CPU architecture - so break mods (can't simple recompile them in x86-64, need to port, too). Even more, dependencies, like entire old Havoc engine (a-la Ipion physics) used by Valve for vphysics also need porting, or buying additional license with 25000$+ (i'm not talking about Rubikon, as it is Source 2 thing). Also at least Miles Sound System and Bink video require x86-64 versions, which may lead to additional license fees. Some dependencies so old that x86-64 versions even don't exist!

As you see, there is a lot of work to be done, but where is profit? Old games already bought and played on 32 bit systems (at least through Wine), their new auditory is not large (? check Steam statistics to support this claim) on one side and high risks of releasing broken x86-64 versions (as was done before - hard to fix and test, need much time and, hence, money) and low $ outcome (may be loyalty becomes higher?) on the other one are factors leading us to a sad conclusion - Source 1 port to x86-64 unlikely to be done by Valve.

One possible solution is to release Source 2 (successor of Source1 - Valve already done x86-64 porting :)) to the public one day (as Gabe has promised) and port old games by the community. Another less likely one is to release Source 1 to the public and community will port the games again (why unlikely? TF2 and CS:GO are still alive and releasing sources breaks "black box" for script-kiddies and exploit writers, as it was with facepunch leaks. Also need to mention bad habit of missing array bounds checks in engine for performance, which is a paradise for buffer overflow exploits, like https://www.oneupsecurity.com/research/remote-code-execution-in-source-games?t=r).

[SamWWJD420]

LOL oh wow, the mac users that don't understand code are MAD at use for still having access to software NO ONE WANTS TO REWRITE FROM THE GROUND UP, on ALL INFRASTRUCTURE including ARM, x86, and x64, AND ON MACS TOO!! But poor cry baby MacOS can't understand that Macs USED to still work, and could EASILY choose to include libraries that would make software work again. But they have chosen to go against ALL personal computing ethic and philosophy and backward compatibility efforts; ethics once held by Steve Jobs which helped build his empire. One Apple KEEPS nerfing over and over again, losing more and more clients.

AAPL has another 5 years before they join open source, mark my words.

BTW, you can always boot windows or linux on your mac device and run ANY steam game you wanna. (unless the graphics chip just can't support it, which is common too)

We'll see about this new chip architecture they have, my hunch is it will alienate all but the most loyal of early adopters. which will KILL them, because they base their marketing plan on early adopters RAVING about the product and it being impossible to find.

On Fri, Dec 4, 2020 at 3:20 PM Dmitry Tsarevich notifications@github.com wrote:

Dear @ValveSoftware https://github.com/ValveSoftware, would you be so kind and do something about 64bit support, on Mac in particular?

Apple moved to 64bit some 15 years ago. The only period 32bit apps were in production was the temporary, transfer timespan of Mac OS X Leopard and the first Intel Core Macs. Since Snow Leopard release in 2009, there was ABSOLUTELY no reason to even care about 32bit for future anymore, that's 11 years ago where the future development has been clearly set.

It's 2020. 3 years after announcing a final deprecation of 32-bit, Valve is still living in 200X, not being able to provide products for future.

In this same 2020, Apple is making another transition where moving to ARM 64-bit, Windows will probably follow as well sooner or later, Linux has been 64-bit for ages due to the progress there…

And this Valve can't even provide proper client & game updates in last 9 YEARS. What's more eminent –

32-BIT-ONLY VERSIONS OF STEAM AND SOURCE GAMES SHOULD'VE NEVER EXISTED!

Since Day 0 of Steam on Mac, Apple was fully supporting 64-bit architecture for years already. Valve should be hardly penalised from customers for introducing products with unreliable timespan, built on legacy technologies there were not supposed to use with future in mind.

It's 2020, I have two 2019 MacBooks on the desk, attempting to play Portal 2 in co-op…and I have to install GODDAMN CROSSOVER TO PLAY OVER WINE! man_facepalming

What can we expect from this pipe company? Apple has succeeded 2 architecture transitions when Valve wasn't even able to follow with proper evolution with the surrounding world – they're just stuck in 2008, only concentrated on sacking up money. When is any ARM support going to happen, both on Mac and Windows eventually? Apple will architecture and move forward 4 more generations of home-made CPUs and GPUs while this company won't even perform a recompile of existing games. And it certainly is possible, as CS:GO is probably the only Source Valve game available on Mac now – yeah, you know why, 'cause they can suck even more money. Even 3rd-party, indie game devs are more flexible here than this multibillion company.

Please, do something about this. There's a huge technical debt followed by many angry users whose Steam library is worthless as an effect.

Unfortunately, that's hard to port such huge codebase to x86-64 at once. From 2016-2017 facepunch leaks we can see that some work has been done in porting Source 1 to x86-64: presence and usage of PLATFORM_64BITS and COMPILER_MSVC64 preprocessor macroses, removing inline assembly not supported by MSVC under x86-64, etc.

But much more effort is needed to port tier0 memory management, tier1 collections, find and fix a lot of pointer truncation's inside engine (Valve likes to store pointers, structs, etc. inside ints for optimization, but it makes a hell for x86-64 port), break some API/ABI relying on 32 bit CPU architecture - so break mods (can't simple recompile them in x86-64, need to port, too). Even more, dependencies, like entire old Havoc engine (a-la Ipion physics) used by Valve for vphysics also need porting, or buying additional license with 25000$+ (i'm not talking about Rubikon, as it is Source 2 thing). Also at least Miles Sound System and Bink video require x86-64 versions, which may lead to additional license fees. Some dependencies so old that x86-64 versions even don't exist!

As you see, there is a lot of work to be done, but where is profit? Old games already bought and played on 32 bit systems (at least through Wine), their new auditory is not large (? check Steam statistics to support this claim) on one side and high risks of releasing broken x86-64 versions (as was done before - hard to fix and test, need much time and, hence, money) and low $ outcome (may be loyalty becomes higher?) on the other one are factors leading us to a sad conclusion - Source 1 port to x86-64 unlikely to be done by Valve.

One possible solution is to release Source 2 (successor of Source1 - Valve already done x86-64 porting :)) to the public one day (as Gabe has promised) and port old games by the community. Another less likely one is to release Source 1 to the public and community will port the games again (why unlikely? TF2 and CS:GO are still alive and releasing sources breaks "black box" for script-kiddies and exploit writers, as it was with facepunch leaks. Also need to mention bad habit of missing array bounds checks in engine for performance, which is a paradise for buffer overflow exploits, like https://www.oneupsecurity.com/research/remote-code-execution-in-source-games?t=r ).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/source-sdk-2013/issues/481#issuecomment-739072956, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIBDYTYZJ4XFHWFE6SFRT3STFVDDANCNFSM4IUPN5DQ .

[Spirrwell]

Bashing Apple users for the sake of it doesn't help anyone. If that's all you want to do, please leave.

dimhotepus explained it quite well. It really isn't easy to port, but it's not like Valve couldn't. I personally think that if Valve were to do anything, they should port their pre-CS:GO games to Source 2, instead of porting Source 1 to different CPU architectures.

Whether that's of value to Valve or not is up in the air. I'm certain people would buy the games again, especially if they went with a remaster approach. That's just something Valve RARELY does.

[SamWWJD420]

Sigh. you are right. I was meaning to bash apple, not their victims.

But the thing is, WHY get rid of 32 bit. So 64bit is better... but there is code that makes 32 bit software run just fine on ARM or AMD64 or Intel x86 (32bit) as well. And that code USED to be included in MacOS. And now, they have a new solution, force ALL developers that want to keep making money to rewrite all their code, INSTEAD of using the library that is backwards compatible. Literally NOONE thinks this is a good plan except for Apple. They also only control less than what, 15% of users and servers online? The rest are windows, linux, or some derivative, or something based on linux like android is. MacOS literally just decided to delete a ton of code and make a ton of old software just stop working, for no other reason than, we're apple, we determine progress, we don't like dealing with this library and fixing issues with it everytime our inept programmers release something that breaks the libraries, and we're gonna delete it and make everyone else suffer, and we'll blame everyone else that can still use their old code, as being the problem for not following how Apple wanna do it WAHHHH

Sorry, but you can't just decide that ALL 32 bit apps are outdated and in need of revision. It's incredibly ignorant and selfish and short sighted. The fact that mac users wanna bash on valve for not playing apples games, makes me shake my head! The LEAST steam should do, is make mac allow them to install their own 32bit libraries to fix what's missing that breaks most of their games.

Blaming valve and saying, aww if they want money they should bow to apple's ridiculous coding demands, is simply another way that Apple redirects their users anger at other companies and users, while trying to gate-keep their ecosystem and force users into buying new games and software from their app market instead of using something that WORKED JUST FINE. Steve Jobs would be irritated to say the least; god rest his soul. Prove to me that there is ANY motivation from Apple, other than MAKING users buy new software instead of using existing software they were perfectly happy with.

On Fri, Dec 4, 2020 at 7:04 PM Spirrwell notifications@github.com wrote:

Bashing Apple users for the sake of it doesn't help anyone. If that's all you want to do, please leave.

dimhotepus explained it quite well. It really isn't easy to port, but it's not like Valve couldn't. I personally think that if Valve were to do anything, they should port their pre-CS:GO games to Source 2, instead of porting Source 1 to different CPU architectures.

Whether that's of value to Valve or not is up in the air. I'm certain people would buy the games again, especially if they went with a remaster approach. That's just something Valve RARELY does.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/source-sdk-2013/issues/481#issuecomment-739113428, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIBDYVIEZW3AKNDC5DCTW3STGPLPANCNFSM4IUPN5DQ .

[Spirrwell]

While I do agree that it's unfair to expect Valve to stop and do everything they can to support new Apple products, I'd argue Apple isn't wrong for ditching 32-bit and switching to ARM. Apple already had universal binaries as a build option for a long time for both 32/64-bit. Desktop CPUs have been 64-bit for well over a decade now. It still boggles my mind that Visual Studio's default target is 32-bit.

The switch to ARM is even more obvious I feel. It has the performance and power efficiency that will inevitably leave x86 far behind. RISC-V CPUs may be an even bigger game changer in the future.

I'm not saying that Apple isn't anti-competitive. They've done scummy things. But these particular decisions are totally fair.

I would love to see Windows support ARM more or try out RISC-V. It's going to be important that they come up with solutions to there being many different CPU architectures. x86 is very likely (arguably already is) going to be hitting a wall with silicon and architectural limitations.

That's not Apple's fault.

[fel1x-developer]

I think Valve gave up this SDK because it takes a lot of time to maintain. They have to reprogram and rebuild Source SDK 2013 Singleplayer and Multiplayer and Valve Project Creator, and update Xcode projects. In Valve, staffs do what they want. Gabe Newell does not order something to them except special cases. There is no profit to Valve when they update the SDK. We just have to wait for updated SDK or Source 2 SDK, or just give up.

[dimhotepus]

Another reason to not release full Source 1 engine to the public is a required usage of proprietary components, like Havoc, Bink, Miles Sound System - all of them require license fees. Some workarounds are possible, but unlikely to be done by the regular modders. Community can't port the games to x86-64 without full engine. In case Source 2 also requires proprietary components (AFAIK new physics engine Rubikon doesn't use Havoc middleware, so at least such dependency is gone), than it also may not be open-sourced entirely.

In a summary, at least three ways of solving x86-64 problem are known:

1. Wait till Valve ports Source 1 SDK to x86-64 and ports old games too. Lot of work, small profit for them (why invest into the old engine at all?).
2. Wait till Source 2 SDK released and Valve rewrites old games. Cons: time & money - rewriting from ground up is a huge work, takes much time which can be spend on the other projects, prices are unlikely to be high. Pros: loyalty - fix and polish Source 2 on old games, add modern features to the remakes, increase loyalty from old fan base, may be rebirth of modding community.
3. Wait till Source 2 SDK released and community rewrites old games. Cons: time & money, but much less than in the second way. Pros: same as in the second way.

Looks like third option is the way to go :).

So as @mintchoco0122 already said, we just have to wait for updated SDK or Source 2 SDK, or just give up.

[username0x0a]

Thanks for your comments, guys. I pretty much understand both sides or arguments, to some extend. But – stick with simple facts.

In 2007 (13 years ago) Apple released first OS (Leopard) with initial support for Intel CPUs and BOTH 64-bit (x86_64) and 32-bit (x86) architecture. Since then, any app could've been built as x86_64, as well as x86_32 and ppc32. All in one fat binary.

The message is clear: people, do x64 asap, but we will keep that older stuff for some time, too, so you have enough time to port.

This is important. Support for 32-bit binaries on Intel CPUs was mainly meant for previously available, 32-bit PPC apps on Carbon to be, IN SHORT TERM, easily ported to x86 (similarly as today x86_64 apps can be recompiled to M1 arm64 by just one click in most cases). That gave PPC apps some transition time to fully adopt 64-bits, replace Carbon GUI with Cocoa, etc. These apps had some nice 11 years to successfully convert. Damn, that's one hell of a time of support/deprecation span.

But what's important – that's not Valve's case at all.

In 2010 (3 YEARS and almost 2 macOS releases later), Valve announced Steam on Mac OS X. Damn. They had a fresh start on Mac platform, with huge show, promoted support from Apple (I think there was some presentation at Apple event as well?), etc. 3 years later Valve announced something built on top of tech that was deprecated since day 0, meant only for a completely different reason than introducing NEW software. Or were they planning to keep PPC32 and Intel Solo CPUs in mind? I highly doubt so. If they wanted a serious platform support, they could've go 64-bit only from the start. Instead they were just looking for easy win there – taking the existing 32-bit code and do relatively quick ports.

That wouldn't be that much painful and bothering, if they've had some vision and future plans on the platform.

Today, 10 years later, the situation is no different, well even worse, as the deprecated, transition-only architecture was dropped for good. Any regularly updated software with a foresight of some income released during those 10 years is fully integrated with 64-bits & all modern Mac frameworks today. Many of them already supporting or planning ARM64/M1 support in near future. Apple deprecating OpenGL is a no-brainer on one side and I'm really mad at Apple for this, even more for keeping away from Vulkan, I don't really get that, but – Metal seems really well-performing and deeply integrated and I believe Valve has enough capital to either support Metal natively or look after some solutions (like MoltenVK? – they're pushing Wine forward enormously in these days, this could be another win for the community).

What about other game engines & devs? I'm expecting Unity & Unreal to support Apple Silicon pretty soon. Developers on those platforms will be quite happy to support ARM64 as they could sell well-performing games even to people with an entry-level $999 laptop / $699 Mac mini. That's huge from some point of view. Valve is stuck 10 years back (outside the Windows world) on an unsupported 32-bit technology never meant for such use.

Are there limitations like Havoc (can surely be replaced), Blink (omg, this sucked in early 2000s in soo many games, do we really need this in 2020?) – yeah, just like the rest, probably relicts of the past combined with really bad dependency decisions, also I think Valve has enough power to control and demand some requirements from external suppliers & dynamic support if they want to be taken as a dynamic company with some foresight. It certainly is possible (see CS:GO reference – do we really miss some tech or engine there for other games like HL1/2, Portal, L4D etc.? I doubt so). It's only Valve lacking their will to support something they wanted to sell us longer than the initial year.

[ChampionCynthia]

Everything regarding 64-bit support was already said, but it's most likely just that porting older Source Engine branches is simply not worth it for Valve, and they most likely lack the required motivation for that (which is understandable).

However, something I have not seen mentioned and yet that I find interesting is that Garry's Mod has a working Beta x86-64 version that you can currently play on Windows, macOS 10.15 Catalina and later, as well as GNU/Linux just fine. This is important because Garry's Mod probably has the codebase which is the closest to the Source Engine 2013 Multiplayer one. It probably has a large amount of changes, and notably has many bugs fixed and various internal changes (like higher technical limits), but I still believe the work made for Garry's Mod could be reused for other titles, more specifically Team Fortress 2 (which uses a slightly more advanced Source 2013 MP engine). It's not as "modified" as, let's say, CS:GO's branch of the engine.

I honestly think that if Valve can reuse the work from the Garry's Mod development team into their Source Engine 2013, they could port their older Source games (at least the Multiplayer ones) to x86-64, and I don't really see what is holding them back (unless Valve cannot access Garry's Mod's work, but I believe they have a contract with their team so I believe they somehow could). There may be changes to do on the game's code indeed, and all of the code is spaghetti, but I don't know if it would be that much of a complex task; I cannot evaluate that.

Note that I don't directly have a problem with the lack of 64-bit because I'm stuck on older macOS versions and I have other operating systems at my disposal, but considering that even Ubuntu planned to drop 32-bit support in 2019 (archive, mirror), I think it would not necessarily be such a bad idea to do the port. But hey, I'm not at Valve and I don't necessarily want to work on such porting either, so, in the end I can understand the lack of motivation to do it.

The next biggest problem may be the transition from AMD64/x86-64 over to ARM64 that might happen in the 2020s (not only for Mac systems; Microsoft Windows 10 has an ARM64 edition since a few years now and GNU/Linux has been built for ARM64 since early in the architecture's lifespan), although that's mostly speculation for now. The second, macOS-specific problem may be Apple dropping OpenGL support completely for Metal (which is honestly just an option to "lock" customers even more since they don't bring Vulkan support), but if I had to guess Garry's Mod would actually be updated for this considering they ported the game to x86-64 especially because of macOS Catalina (I would source that claim but I believe it was lost to the Facepunch forums).

[Spirrwell]

That isn't a realistic expectation. An update to existing games to port their Source branches to 64-bit isn't going to happen. I don't think some collaboration with Garry's Mod would somehow make it any easier. The CS:GO branch is already 64-bit for OS X and Linux anyway.

An update to the SDK right now would be of incredibly little benefit to mods for just 64-bit support. For existing games, I'm sure nobody wants some half-baked 64-bit support that's janky and broken that's maintained by one or two people from Valve if we're lucky.

Source 2 is the best chance for the future of the modding community and Valve's first party titles. All of these problems including ARM support are already solved.

[ChampionCynthia]

Well, I agree that the Source SDK itself will most likely not be updated, as Source 2 will simply replace it for mod development, so this would not be surprising. However, I believe it's not totally impossible when it comes to Valve's first-party titles.

In my opinion, as long as 32-bit support exists for at least Microsoft Windows, nothing will be ported. 32-bit support on GNU/Linux is crucial for Source dedicated servers, but said support will probably still exist for many years to come through specific distributions (like Debian).

However, I have my doubts on earlier Valve games being ported to Source 2. I guess it happened for Half-Life with Half-Life: Source, so it's not impossible and since the code for Half-Life 2 and its episodes is available, a port of Half-Life 2 and its episodes to Source 2 could happen.

However, other multiplayer games like Team Fortress 2, I don't think so. The game is a huge mess and has so many things that porting everything properly might take non-profitable years. I guess the community could do something out of the leaked 2008 TF2 code, but the full PC game from today, I'm not so sure.

[fel1x-developer]

It is true that there are 64-bit version of Source Engine. Valve already developed it. However, they have to build and release source-sdk-2020(I don't like this name) and Source Engine SinglePlayer and Multiplayer. Also, it is not compatible with Half-life 2 series.

I think Valve is very busy nowadays. Players and customers want Half-life 3, CS:GO Source 2 and etc. They don't have time for modding. But the good news is that if half life 3 is released, maybe we can mod with Source 2.

[Wadmodder]

Development Hell table of Steam Version dependent on platform:

Microsoft Windows: Since 2005

macOS: Since it's launch in 2010 - the only 64-bit version released as of 2019

Linux: Since it's launch in 2012

Hand-by-Hand Development Hell should finally be dead by the 2020s to every entertainment industry (including the movie, music & gaming industries) thanks to the rise of 4K to 8K resolution media, Ai-based technology for software development, the HTML5 victory of superior & open-source web standards over Adobe Flash Player, & many advancements in technology thanks to Microsoft, Apple & other companies.

[kode54]

All Hail the Apple Silicon, and the backwards compatibility layer that only runs x86 64 code, not 32 bit, that is already getting code added to facilitate disabling it outright with a notice that it's unavailable in your region, possibly because Intel may sue it out of existence, then even more backwards compatibility goes in the trash, and Steam stops working entirely.

Time to Give Up and admit that the only real gaming platforms on Macs are the Mac App Store and Apple Arcade. And since the games have to exist on mobile devices as well, the only gaming platform Apple truly cares about, maybe the desktop games released there will not languish into development hell. Until some other backwards compatibility hurdle throws everyone under the bus again.

The future of Macs is mobile processors retrofit into desktop or laptop machines. The future of Mac gaming is games designed from the ground up to be mobile games, retrofit with desktop controls.