6 ms·

> Why would an app maker update their old apps before an announcement was made that they would be deprecated? Almost immediately after 64-bit support was added

by comex 6y ago

> Why would an app maker update their old apps before an announcement was made that they would be deprecated? Almost immediately after 64-bit support was added in 2005, it was the recommended path, not only for new apps but for existing ones to migrate to. For example, an document called "64-bit Transition Guide for Cocoa" [1] was first published in 2007. A few years later, another document [2] was more explicit: > Should You Recompile Your Software as a 64-Bit Executable? > As a general rule, in OS X v10.7 and later, the answer is probably yes. OS X 10.7 was released in 2011. Certainly, many – most – app makers did update their old apps. For example, Apple's refusal to support Carbon on 64-bit famously forced Adobe to scramble to update their apps to run on Cocoa, because they considered 64-bit support to be essential. Admittedly, one of the chief benefits of 64-bit was the ability to address more than 4GB of memory, and pro apps needed that more than your average app. But your average app was also easier to recompile, so in practice, pro apps were if anything the slowest to migrate. Even then, most of them did, long before the official deprecation. By the time the deprecation was announced, let alone by the time Catalina was released, most apps that were still 32-bit were the ones that had ceased to receive updates altogether. From that perspective, the exact timing of the deprecation doesn't matter that much: most unmaintained apps aren't going to become maintained again because of an announcement by Apple. It was going to hurt no matter what. [1] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Cocoa64BitGuide/RevisionHistory.html#//apple_ref/doc/uid/TP40004247-CH2-SW1 https://developer.apple.com/library/archive/documentation/Co... [2] https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/64bitPorting/indications/indications.html#//apple_ref/doc/uid/TP40001064-CH206-TPXREF101 https://developer.apple.com/library/archive/documentation/Da...

Wowfunhappy 6y ago
So then why were there so many 32 bit apps? 2005 is, what, a year after the Intel transition? Surely not all of those apps were written during that one year. Not to mention, for better or worse, games in particular were 32bit through 2018 at least. I imagine this must have had something to do with cross platform compatibility, although I can't imagine what.
- comex 6y ago
  > Not to mention, for better or worse, games in particular were 32bit through 2018 at least. I imagine this must have had something to do with cross platform compatibility, although I can't imagine what. Well, here are the Steam Hardware Survey results from some random date in 2014: http://web.archive.org/web/20140318083854/https://store.steampowered.com/hwsurvey/?platform=pc http://web.archive.org/web/20140318083854/https://store.stea... If you click on "Windows Version", you can see that a substantial percentage (~20%) were running 32-bit versions of Windows, which can't run 64-bit applications. Most of those were likely on 64-bit processors, but had 32-bit Windows installed anyway for whatever reason; IIRC that might include driver support and not needing as much RAM. So game developers were forced to ship 32-bit binaries if they wanted to target those users. (They could ship both 32-bit and 64-bit versions, but that's relatively difficult on Windows; there's no equivalent of Mac "fat binaries". And there wasn't much point.) That's Windows, not macOS. But then as now, game developers targeting PC primarily cared about Windows, with macOS as an afterthought at best. If the Windows version was built as 32-bit, the macOS version likely would be too for simplicity's sake. There's also game consoles to consider. PlayStation and Xbox both switched to 64-bit in 2013, so most games released from then on would have to at least have 64-bit-clean codebases (even if they weren't tested specifically on 64-bit PCs). But earlier games might well not be 64-bit clean; the kind of low-level hacks that make porting to 64-bit difficult are probably more common in game codebases than your average app.
  - marcosdumay 6y ago
    While you are talking about games, it's relevant to remember that Unity had different licenses for their 32 and 64 bits engines just up to a few years ago. I think the free license was 32 bits only, what locked a lot of people in it.
- earthboundkid 6y ago
  > So then why were there so many 32 bit apps? Were there? On iOS, I lost access to a lot of games due to the 32 to 64 transition. On Mac OS, nothing I used was impacted. If your app wasn't 64 bit, it was abandonware. Even the abandonware that I actually use, like Gitbox, was already 64 bit.
vetinari 6y ago
And that's why in 2006 they introduced Macbook Pros which were 32-bit only? If you want to switch to 64-bit, you don't introduce machines that cannot do that, that need their 32-bit ABI and have to be supported for years to follow.
- saagarjha 6y ago
  Apple didn’t really have a choice. The choice required a fairly decent amount of legacy support for the next decade or so; I doubt they really wanted to commit to that if they didn’t have to.
  - Jasper_ 6y ago
    This to me says one of two things: 1. Either their engineering org is so bad they can't afford to spend some of their massive resources on backwards compatibility. 2. They just don't give a shit. Either way, not a great look.
    - saagarjha 6y ago
      What engineering organization would prefer to support an architecture for the next 10 years because they had to use that chip for two?
  - vetinari 6y ago
    Of course, they did have a choice: 1. Wait a few months, Core 2 Duo was on it's way. Previous Nehalem generation did support 64-bit, so obviously, the next Core Duo SKUs with 64-bit support were on the way. This way, they could skip x86 ABI entirely. It's not like Apple doesn't have long periods without updates of specific models. 2. If they really had to release a model that introduces 32-bit ABI, they could support it properly. So by doing it the way they did it, I have to agree with Jasper_. The only difference with his conclusion is, that in my opinion they just took the option 2.
    - bzzzt 6y ago
      Easy with 20/20 hindsight, but back then Apple didn't know it would be a few months. Should Intel have had unforeseen trouble with the Core 2 and decided to delay the release they would not be releasing any hardware. Also, availability of enough processors and ease of porting existing 32-bits x86 Windows software could have been factors.

by comex 6y ago

Wowfunhappy 6y ago

So then why were there so many 32 bit apps? 2005 is, what, a year after the Intel transition? Surely not all of those apps were written during that one year. Not to mention, for better or worse, games in particular were 32bit through 2018 at least. I imagine this must have had something to do with cross platform compatibility, although I can't imagine what.

comex 6y ago
> Not to mention, for better or worse, games in particular were 32bit through 2018 at least. I imagine this must have had something to do with cross platform compatibility, although I can't imagine what. Well, here are the Steam Hardware Survey results from some random date in 2014: http://web.archive.org/web/20140318083854/https://store.steampowered.com/hwsurvey/?platform=pc http://web.archive.org/web/20140318083854/https://store.stea... If you click on "Windows Version", you can see that a substantial percentage (~20%) were running 32-bit versions of Windows, which can't run 64-bit applications. Most of those were likely on 64-bit processors, but had 32-bit Windows installed anyway for whatever reason; IIRC that might include driver support and not needing as much RAM. So game developers were forced to ship 32-bit binaries if they wanted to target those users. (They could ship both 32-bit and 64-bit versions, but that's relatively difficult on Windows; there's no equivalent of Mac "fat binaries". And there wasn't much point.) That's Windows, not macOS. But then as now, game developers targeting PC primarily cared about Windows, with macOS as an afterthought at best. If the Windows version was built as 32-bit, the macOS version likely would be too for simplicity's sake. There's also game consoles to consider. PlayStation and Xbox both switched to 64-bit in 2013, so most games released from then on would have to at least have 64-bit-clean codebases (even if they weren't tested specifically on 64-bit PCs). But earlier games might well not be 64-bit clean; the kind of low-level hacks that make porting to 64-bit difficult are probably more common in game codebases than your average app.
- marcosdumay 6y ago
  While you are talking about games, it's relevant to remember that Unity had different licenses for their 32 and 64 bits engines just up to a few years ago. I think the free license was 32 bits only, what locked a lot of people in it.
earthboundkid 6y ago
> So then why were there so many 32 bit apps? Were there? On iOS, I lost access to a lot of games due to the 32 to 64 transition. On Mac OS, nothing I used was impacted. If your app wasn't 64 bit, it was abandonware. Even the abandonware that I actually use, like Gitbox, was already 64 bit.

vetinari 6y ago

And that's why in 2006 they introduced Macbook Pros which were 32-bit only? If you want to switch to 64-bit, you don't introduce machines that cannot do that, that need their 32-bit ABI and have to be supported for years to follow.

saagarjha 6y ago
Apple didn’t really have a choice. The choice required a fairly decent amount of legacy support for the next decade or so; I doubt they really wanted to commit to that if they didn’t have to.
- Jasper_ 6y ago
  This to me says one of two things: 1. Either their engineering org is so bad they can't afford to spend some of their massive resources on backwards compatibility. 2. They just don't give a shit. Either way, not a great look.
  - saagarjha 6y ago
    What engineering organization would prefer to support an architecture for the next 10 years because they had to use that chip for two?
- vetinari 6y ago
  Of course, they did have a choice: 1. Wait a few months, Core 2 Duo was on it's way. Previous Nehalem generation did support 64-bit, so obviously, the next Core Duo SKUs with 64-bit support were on the way. This way, they could skip x86 ABI entirely. It's not like Apple doesn't have long periods without updates of specific models. 2. If they really had to release a model that introduces 32-bit ABI, they could support it properly. So by doing it the way they did it, I have to agree with Jasper_. The only difference with his conclusion is, that in my opinion they just took the option 2.
  - bzzzt 6y ago
    Easy with 20/20 hindsight, but back then Apple didn't know it would be a few months. Should Intel have had unforeseen trouble with the Core 2 and decided to delay the release they would not be releasing any hardware. Also, availability of enough processors and ease of porting existing 32-bits x86 Windows software could have been factors.