The writing has been on the wall for 32-bit for literally over a decade and it’s not going to magically happen now just because support has been dropped.
Imagine digging up an old project, recompiling it for 64-bit, and finding out that:
1. It doesn’t compile any more, with modern tools.
2. When you get it to compile, it crashes mysteriously.
3. When you get it to run, it again crashes mysteriously when you try a 64-bit build.
Yes, there are a lot of “best practices” out there to avoid this. Any discussion of best practices is moot because people in the field have to work with actual practices and legacy code that might be full of undefined behavior, custom build systems, weird hacks, and lost tribal knowledge. And you are simply not given enough time to go through and fix it.
This is not all about the 32-to-64 bit transition, but that’s the biggest part.
Then consider the smaller shops—which might only have a couple of Apple devices altogether, and not a lot of spare developer-weeks to go through and test old plugins on new systems.
One of the big ones is that integer constants are 32-bit on LP64 / LLP64 systems unless they are large enough, so e.g.
// Equal to 0x80000000 on ILP32
// Undefined behavior on LP64 / LLP64
size_t max = 1u << (sizeof(size_t) * CHAR_BIT - 1);
// Correct version
size_t max = (size_t)1 << (sizeof(size_t) * CHAR_BIT - 1);
This can also happen with e.g. multiplication
#define K 1024
#define M (1024 * K)
#define G (1024 * M)
#define T (1024 * G)
// Undefined behavior, on both 32-bit and 64-bit.
size_t max_object_size = 10 * T;
// Correct version (#1)
size_t max_object_size = 10995116277760;
// Correct version (#2)
static const size_t K = 1024;
static const size_t M = 1024 * M;
... etc ...
Or if you need to align your pointers for some reason, so you do the cast correctly (with uintptr_t) and get
void *align_ptr(void *p) {
// Mask is 0xfffffff0 on 32-bit (correct)
// Is also 0xfffffff0 on 64-bit (mistake)
return (void *)(((uintptr_t)p + 0xf) & ~0xf);
// Correct version
return (void *)(((uintptr_t)p + 0xf) & ~(uintptr_t)0xf);
}
Consider that you might do some pointer alignment e.g. to work with SIMD. This stuff isn’t so crazy and if you haven’t been targeting 64-bit, a lot of it can creep into your code base over the years. Legacy projects may not compile even remotely cleanly with warnings enabled, it’s just a fact, so even though warnings / static analysis will catch some of the errors above you’re not safe.
This is why so many languages have stricter rules about converting integers to narrower / wider types.
I was hoping for some real life examples from some games and reasons why they’d use something like pointer arithmetic in such a way or so often it couldn’t be easily migrated, or why they’d even do it in the first place on a desktop machine. I get the old software.
Of course basic examples between 32 vs 64 are easy to find. I guess I should have clarified as the OP sounded like he knew the topic well.
I’ve never dug hard into C++ gaming architectures and the patterns they use.
In my experience a far more common and much harder issue is dealing with dependencies.
A large project probably has lots of them. If you are lucky there is a 64 bit version of it. Very often though there isn't so you have to find something equivalent and rewrite all interactions with it.
And there might have been very good reasons for choosing those specific dependencies.
That can take ages upon ages and can be quite demotivating. You might have issue even finding out if you have any problems in your own application after you've spent months on replacing dependencies.
It doesn't matter why they decided to. They did. We all know better, we can all point fingers until we are blue in the face, but that doesn't change that people will lose access to software that they purchased.
> except in a well-contained module?
This is probably one of the best reasons. Game developers aren't entirely to blame here, middleware developers seem to be sticking to 32bit like balsamic glazing. Even if you could pry their cold dead hands off their archaic architecture, they'd probably make you pay full price for the 64bit upgrade.
As for DAWs? Think about all the the VST plugins out there. Most of which probably aren't maintained and only exist as zip files on the artist's dropbox.
Dropping 32bit is aspirationally sound. It's grossly inconsiderate of the very most obvious aspects of reality.
I think that's reasonable if we were talking about a tighter time-scale, but we're talking about at least 13 years since it's been 100% obvious that macOS would become 64-bit.
Yeah, but 64 bit doesn't give your users anything usually, so it's a tax that is more of a drain on smaller software shops. Especially consider that lots of programs and especially games have a spike of sales when new and then sales decline to nothing. There may not be new versions, ever. So going back and updating them is pure loss for the developers.
This is one reason why ecosystems like Java are so valuable! The 64 bit transition was so easy for it because of the common insistence on "pure Java" for portability. Combined with pointer compression 64 bit was hardly noticed.
For many audio hardware drivers, it's not simply a matter of recompiling to 64-bit.
Apple has deprecated a lot of things and seems to be trying to move everything over to AudioServerPlugins, which essentially requires a full rewrite of the drivers. The architecture isn't similar at all (AudioServerPlugins actually follow a Microsoft-style COM interface, among other things). I don't even think Apple makes any sample code for updating old Firewire drivers to run on Catalina, so it's a tough slog, and low-level CoreAudio expertise to update old drivers is getting scarce. Traffic on the CoreAudio developer mailing list is down to less than a dozen posts most months. There hasn't been a single post to the mailing list yet in October.
I strongly suspect that some interface vendors are not going to update their 32 bit drivers for Catalina. (MOTU in particular is one, which kind of marks the end of an era because they used to be champions of some of the best CoreAudio features, like Firewire clock syncing.)
As a independent dev I would rather spend my time working on new features and projects on an OS where my older projects continue to work fine rather than spend my time constantly playing catch up with Apples policies. This combined with the notarization requirement has pushed me to stop developing for Mac OS.
This isn't just an OS thing, though, so I think that's crap. This change is a hardware change that's been forecast for literally years. To dismiss it as "playing catch up with Apple's policies" is nonsense.
You have a point, but another thing to note is that the quality of Apple’s developer docs for audio drivers and CoreAudio has been decreasing. Some major behaviours/quirks of new frameworks like AVAudioEngine on OS X are not documented at all. It’s a lot harder to chase the target than it used to be. This is IMHO one of the likely reasons that MOTU chose to implement as much as possible as an on-device web interface on their newer gear.
As a former MOTU engineer who worked on the software side of the new interfaces, the built-in web server was really about cross-device and multi-user access, not avoiding CoreAudio. We still had to write CoreAudio server plug-ins for Thunderbolt and proxy the web server through the driver as well.
I hear they are planning to update their 32-bit drivers for the older MIDI and audio interfaces with the exception of the PCIe devices. (There are no existing Macs that can run Catalina and the old PCIe interfaces with the exception of the new Mac Pros, but there will be no driver so...)
MOTU just released a statement indicating that they’re only working on new drivers for the hybrid and newer devices. Firewire gear like the popular 828mk3 classic aren’t getting drivers.
AVAudioEngine is not a new framework on macOS. It was first available on macOS Yosemite which was in beta in 2013 and released in 2014. Developers have had 6+ years to develop and test using these frameworks.
This literally just boils down to developers complaining that Apple isn't further letting them procrastinate.
That illustrates the problem though... It’s not a new framework, but the documentation is still poor, and important limitations of it on OS X are not documented at all, years later. (I picked this example specifically because it was a subject of traffic on the CoreAudio mailing list last month.)
Apple expects developers to adopt new technologies, but often never gets around to documenting them well enough to drive adoption. It’s been a real issue for low level audio work on the platform.
"forecast for years" is distinct from "totally a good idea."
Time and resources a software publisher spends on the upgrade treadmill is time they can't spend on other efforts, whether or not there's advance notice. Essentially, it's a cost Apple imposes on developers for their platforms. And either that shows up in costs for users or the software folds.
If there's a counter to upgrade treadmill criticisms, one of the few that makes sense is if there are compelling benefits with the upgrade to weigh against the cost.
At the moment, it's entirely unclear to me what benefits I'm supposed to derive from dropping 32 bit support, and moreover, I can't think of a single compelling benefit I've derived from macOS updates since Snow Leopard.
This distinction does not seem very useful. Regardless of whether it was a good idea, developers had to decide at some point whether they should prepare for the transition or cease macOS development (unless they wanted to continue supporting old versions with a dwindling userbase).
This decision could have been made years ago. It seems to me that anyone complaining the change is too soon or too sudden is forgetting the sheer amount of time they had to decide their best course of action. It should be a question of whether to continue development at all, since that should include a transition to 64-bit. If not, then deprecate the project.
I understand may situations will not be this black-and-white, but it seems like many of them are.
> anyone complaining the change is too soon or too sudden
Notably, that's not my complaint or my point. This isn't about the timing (which is why the distinction was important).
No matter how much time someone has to prepare for a change, there's a cost to making it. And if the benefits of the change don't outweigh those costs for the developer (and the user), then a complaint sure makes sense from those perspectives.
This does intersect the issue of timing, because in a resource-constrained situation, you inevitably have to defer some efforts until they're absolutely necessary (and simply rule out doing others). But timing is not the fundamental issue, cost-benefit tradeoffs are.
> [development] should include a transition to 64-bit.
Why? What's the benefit to ending 32 bit application support?
> This change is a hardware change that's been forecast for literally years.
Huh? What x86 processor doesn’t support 32bit code?
If they move to ARM, everything will get broken, regardless if whether it’s 32bit or 64bit. Is breaking things twice really better than breaking them once?
That's the wrong question to be asking. The relevant hardware change is when x86 CPUs that don't support 64-bit code finally disappeared from the market and eventually from the install base.
There is only a very narrow range of use cases for which running 32-bit code on a x86-64 processor is preferable to running the same code compiled as 64-bit. For everything else, going 64-bit is a clear improvement if not an outright necessity. Even if it didn't require any ongoing maintenance, continuing to ship 32-bit versions means wasting storage space and network bandwidth, and leaving on the table the improvements enabled by going 64-bit (eg. better ObjC runtime). For the entire existence of x86-64 processors it has been clear that retaining 32-bit compatibility through the entire software stack has significant downsides and that the cost/benefit balance has been inexorably moving toward eventually dropping 32-bit support.
BBEdit is not a real time audio engine. It’s a text editor. And they’ve released thirteen versions which all require a relatively substantial amount of money to upgrade.
Isn’t that also a good thing - that a company has a business model that allows them to keep supporting an app for almost two decades?
What alternative would you prefer? That Apple ships the latest MacOS with a 68K emulator, a PPC emulator, all of the 32 bit libraries, classic MacOS in a VM, and all of the Carbon libraries forever?
Apple isn’t exactly known for backwards compatibility.
I could never justify a long term hardware life knowing that I’m signing up with a short term software life cycle. Not only a short term software lifecycle, by a short term computer hardware/OS lifecycle. Want more memory or a faster processor? Not with that old OS! Btw, you have to rewrite all of your software if you want that extra memory.
Assuming the vendor is still in business, still supports the product line, and still develops software updates for models that have been obsolete for over a decade.
And they shouldn't have to. Developers should support their working equipment by updating drivers. They've known about the transition to 64-bit for years and it's not something that can just be ignored because all the hardware is now 64-bit. It's not like this was done on a lark.
This was addressed earlier in this subthread. It's not just an upgrade to 64-bit — they're also changing the low-level interfaces, and the new ones are apparently not well documented. So while it probably wasn't done on a lark, it doesn't sound like it was done in a very well considered manner either.
True, but a lot of those devs ignored the 32- to 64-bit transition for so long that now they're having to do both at once. Authors that moved to 64 bit several years ago have a lot more free time right now to concentrate on supporting new APIs.
The low-level interfaces in question were changed almost 4 major versions back. There aren't any new interfaces or APIs that haven't existed for 6+ years already. The only people complaining are the ones that procrastinated because Apple continued to support their outdated apps.
Apple introduced new low-level interfaces four major versions back, and Apple couldn't work up the interest to document them in the intervening years, and then Apple decided to cut off the interfaces that are documented, and somehow any problems resulting from this sequence of choices Apple made are the fault of third-party developers for not jumping to new technology that Apple didn't care enough to document? That interpretation of events seems a bit obsequious to Apple.
If everyone should have been prepared because this change has been in the works for so long, then surely it's inexcusable for Apple to have left the new stuff in a poorly documented state all that time. If you do feel that Apple's lack of preparation is reasonable when they had even more warning than third parties did, then it seems unreasonable to fault developers for also not being prepared.
Is there a reason you don't freeze the version MacOS, disable all the updates(if possible), disconnect it from internet to prevent the zero-day attack on it and continue using it in mojave or whatever your gear works the best with?
But the point is 32-bit apps aren't functional anymore. You either keep up by thinking ahead, or you find yourself suddenly stumped. There's no option to just ignore it.
Interesting. So it's still mixed and has disadvantages of a 64 bit program (no 32 bit plugin support 1) and of a 32 bit program (no compatibility with Catalina) while pretending to be a 64 bit program. Sounds great!
I recently updated my app to be macOS 10.15 compatible. Most of the changes were just annoying and difficult to debug, but some were glaring bugs related to Safari App Extensions which were show-stoppers. I really hope they fixed them before the release...
1) Although everything is "notorized," the Safari extensions aren't installed on app start up like it's supposed to in most cases.
2) The following API call works, UNTIL macOS wakes from sleep mode, in which case it always returns 'false.' SFSafariExtensionManager.getStateOfSafariExtension(...)
With audio hardware it’s looking like substantial rewrites to core code because of underlying is changes. I think it’s just a lot of work on a short timeline for small development shops.
I mean most software that's currently maintained has been 64-bit ready for a decade. The issue is that there's a lot of 3rd party ghostware that isn't, and 32 bit bridging to support that code has been popular for awhile.
That software is a lot like vintage gear, there may be alternatives but they aren't the same, and that's the problem.
Sounds like the software was effectively already dead and it was best to move off it as soon as it became clear there was only one developer and they were hard to get hold of. The problem isn't with macOS.
I would note Chris, given your insistence on all this, that your own project Graal is still shipping on Java 8 despite that being many years old. You're now working on moving to Java 11, which is itself already obsolete.
Imagine if tomorrow nobody could download GraalVM anymore because OpenJDK 8 stopped working for some reason (yes I know it's bundled, this is just a metaphor). It could easily be said you had years to upgrade, so why so sluggish? Well, of course, there were actual features you wanted to ship during this time too, not just doing upgrade work, especially given that Java 9 and 10 maybe didn't deliver many compelling upgrades.
Sure, but so is Mojave. It'll be some years before Apple stops shipping security updates to older releases. Until then app vendors saying "don't upgrade macOS" is no different to Java developers saying "don't run this on Java 11 because it doesn't work yet" and we've seen plenty of that.
In fact, I'm guessing the pain of losing Java 8 will be too much for many organisations after so many years of stability and 9/10/11 breaking so much (current Gradle doesn't even work on Java 13!). Maintaining 8 will be a good business for a long time.
Your software doesn't run in isolation. It needs services of the operating system. Apple has to spend resources maintaining 32-bit software and consumers would rather they didn't do that.
Going to 64 bit can be a lot of work. So there is quite some software which is still lightly maintained for which there isn't a 64 bit update available. Software which has worked perfectly fine up to date.
Only in misleading microbenchmarks. In the real world, the memory bandwidth saved by using 32-bit pointers in some programs that can be guaranteed to not need more than 4GB of memory (or ASLR or other features enabled by x86-64) is completely outweighed by the costs of keeping both 64-bit and 32-bit libraries on disk and in memory and in cache. That's why even on Linux the x32 ABI was never able to gain traction even among Gentoo users, and why retaining traditional 32-bit support is viewed as only a compatibility measure for closed-source code that literally can't be updated.
If a program works fine, with no issues, why should companies be forced to update it simply because Apple decrees they no longer support 32 bit applications? "Sweeping the dust" is an absurd declaration.
I think sidecar uses h265 so it's probably a question of the GPU either having dedicated h265 hardware or having enough grunt to run some kind of shader.
It's not just 64-bit though. There are also some fake-security "notarization" requirements that were notoriously vague and poorly documented for months, as well as some equally vague and unspecific threats that certain non-notarized applications might or might not cease to work on January 2020. I've been developing for Macs since the late 90s and have never seen less clear developer info.
Thankfully I'm not in that position, but many companies can barely keep up with their day to day stuff. There is never time for doing something for the distant (or not so distant) future.
For a game where 95% of the revenue is made in the first year after release, the cost:benefit ratio probably doesn't work out. Especially for games where the rights situation isn't clear or the publisher is defunct
Audio stuff is notoriously prone to issues with updates. This has come up continuously since Classic Mac OS in the 90s. Audio guys are even sensitive to changing their physical setup.
Outside of audio, I know of companies that ignore prerelease stuff because Apple has been known to change APIs during the beta period. It's not like Apple has a GM weeks before it is released publicly.
They have both a developer beta and a public testing beta prior to release. To ignore pre-release access to a codebase that will inevitably become the public release is, in my opinion, stupid and a death sentence. You know it's coming. Sticking your fingers in your ears on the off-chance that something changes before release is really, really silly.
"Ignore" is likely an exaggeration. It sounds like many of these audio companies have tested the betas. People have reported many, many emails over the past week pleading for them not to upgrade yet. I would think that anyone with experience in pro audio would be very careful about any upgrades.
The concern seems to be more of wasted time developing on a moving target. Often people report battery issues after major releases, people are reporting weird hangs after waking from sleep. Audio stuff is real-time in an OS that cannot guarantee it. Accommodating these things is a large undertaking and I'm sure there's gambling going on about what Apple will fix and what you can rewrite before Apple decides to ship.
But no one is saying that these companies are forcing people to move to the new OS. The issue is that there's not even an option to move to the new OS for some users because their software literally can't run. It's not about chasing a moving target when the 64-bit change was announced 4+ years ago. Waiting until the very last possible moment and then complaining that 1 or 2 APIs changed leaves no one to blame but the developer that ignored the warnings and waited to fix their issues.
I'm not talking about dropping 32-bit support. I'm talking about audio glitches that come up with every single major and minor update to macOS (or any OS). Catalina seems to be especially bad in regards to general stability.
Many audio tools have to deal with third-party, paid, and often abandoned drivers and plugins. So the 32-bit transition made for some difficult decisions. Nobody is arguing this is a surprise.
Wait until MacOS move to homemade ($$$) ARM cpu and everything you use except what is made by big publisher is broken, forcing you to buy a huge string of fresh arm software to replace depreciated x64 intel capable softwares.
In every Apple technical decision, there is a financial motivation.
a lot of developers won't update older versions of their software to be compatible either so a serious computer musician has learnt by now to stick with a system that is working
