5 ms·

I can understand eliminating CarbonLib support, though I would have made CarbonLib an optional component you needed to install on the OS a couple years ago to m

by Aloha 7y ago

I can understand eliminating CarbonLib support, though I would have made CarbonLib an optional component you needed to install on the OS a couple years ago to make it clear this was now an optional component that may no longer be supported in the near future. I also don't get why they would eliminate all 32-bit userspace support though - like why eliminate support for 32-bit Cocoa apps, and I think Apple made a mistake here by eliminating support.

scarface74 7y ago
At what point should they drop support?
- Aloha 7y ago
  For carbonlib? No idea, now seems fine. For 32-bit cocoa apps? I see no obvious technical reason to drop support, unless I'm missing something.
  - ratww 7y ago
    I think their rationale is that they don't want to maintain 32-bit and 64-bit code forever. But IMO, Apple should have removed Carbon last year (six years after deprecation). That would have made the removal of 32-bit Cocoa a bit less traumatic.
    - snuxoll 7y ago
      Even though Linux distributions have been slowly dropping support for running on 32-bit systems nobody is talking about dropping 32-bit multilib support. The cost is primarily disk space, and Apple could just make 32-bit libraries an optional download.
    - Aloha 7y ago
      Making CarbonLib an optional component several years ago would have made it clearer to users that "this is going away"
      - scarface74 7y ago
        “Users” don’t know what CarbonLib is. When Apple announced that they weren’t porting CarbonLib, developers knew.
        Aloha 7y ago
        Users would have noticed when Application X stopped working unless they downloaded this thing that the download page for makes very clear will be unsupported in 2 years.
        scarface74 7y ago
        Do you really think any app developer would ask the users to download a dll from the web to make their app work? They would jusr bundle it like installers bundle the Java runtime or Windows apps bundle the compatible version of msvcrt32.dll
alilthrowaway 7y ago
Just to hazard a guess... "Intel officials believe that ARM Macs could come as soon as 2020": https://appleinsider.com/articles/19/02/21/intel-officials-believe-that-arm-macs-could-come-as-soon-as-2020 https://appleinsider.com/articles/19/02/21/intel-officials-b...
twoodfin 7y ago
My guess: The binary translation support they’re going to build into ARM Macs will exclusively support x64, including low-cost bridging between x64 application code and ARM64 library code. Not to mention Apple never leaves deprecated runtimes around for more than a few years. Once 64-bit Carbon was canned the writing was on the wall.
- Aloha 7y ago
  Thats a fair idea, I believe x86-64 is less complex with fewer addressing modes than x86 is. So that makes sense. I'm still not sure about how I feel about an ARM laptop, I'm not opposed though.
  - notmainacct 7y ago
    Arm architecture is rock-solid. The trick is making an ARM processor fast enough for desktop or laptop use. ARM has unfortunately been relegated to low-end devices even though the architecture could do well for high-end machines. We don't have a good interop for running x_86 or x_64 code on ARM so the compatibility isn't there for most users (like Windows 8 ARM). Linux is mostly fine on ARM if you can compile from source and you have a compiler for that given language that works for ARM.
my123 7y ago
My guess: the old fragile Objective-C runtime ABI. They could have done a new ABI, but that'd have broken compatibility anyway...
- Aloha 7y ago
  Why is it more fragile than the same objc runtime in 64 bit?
  - eschaton 7y ago
    Because the 32-bit runtime has a fragile base class problem that can’t be fixed—without breaking binary compatibility. Class instance variable layout and instance sizes in the i386 runtime are fixed; making this flexible was the major improvement introduced with the x86_64 runtime.

by Aloha 7y ago

scarface74 7y ago

At what point should they drop support?

Aloha 7y ago
For carbonlib? No idea, now seems fine. For 32-bit cocoa apps? I see no obvious technical reason to drop support, unless I'm missing something.
- ratww 7y ago
  I think their rationale is that they don't want to maintain 32-bit and 64-bit code forever. But IMO, Apple should have removed Carbon last year (six years after deprecation). That would have made the removal of 32-bit Cocoa a bit less traumatic.
  - snuxoll 7y ago
    Even though Linux distributions have been slowly dropping support for running on 32-bit systems nobody is talking about dropping 32-bit multilib support. The cost is primarily disk space, and Apple could just make 32-bit libraries an optional download.
  - Aloha 7y ago
    Making CarbonLib an optional component several years ago would have made it clearer to users that "this is going away"
    - scarface74 7y ago
      “Users” don’t know what CarbonLib is. When Apple announced that they weren’t porting CarbonLib, developers knew.
      - Aloha 7y ago
        Users would have noticed when Application X stopped working unless they downloaded this thing that the download page for makes very clear will be unsupported in 2 years.
        scarface74 7y ago
        Do you really think any app developer would ask the users to download a dll from the web to make their app work? They would jusr bundle it like installers bundle the Java runtime or Windows apps bundle the compatible version of msvcrt32.dll

alilthrowaway 7y ago

Just to hazard a guess... "Intel officials believe that ARM Macs could come as soon as 2020": https://appleinsider.com/articles/19/02/21/intel-officials-believe-that-arm-macs-could-come-as-soon-as-2020 https://appleinsider.com/articles/19/02/21/intel-officials-b...

twoodfin 7y ago

My guess: The binary translation support they’re going to build into ARM Macs will exclusively support x64, including low-cost bridging between x64 application code and ARM64 library code. Not to mention Apple never leaves deprecated runtimes around for more than a few years. Once 64-bit Carbon was canned the writing was on the wall.

Aloha 7y ago
Thats a fair idea, I believe x86-64 is less complex with fewer addressing modes than x86 is. So that makes sense. I'm still not sure about how I feel about an ARM laptop, I'm not opposed though.
- notmainacct 7y ago
  Arm architecture is rock-solid. The trick is making an ARM processor fast enough for desktop or laptop use. ARM has unfortunately been relegated to low-end devices even though the architecture could do well for high-end machines. We don't have a good interop for running x_86 or x_64 code on ARM so the compatibility isn't there for most users (like Windows 8 ARM). Linux is mostly fine on ARM if you can compile from source and you have a compiler for that given language that works for ARM.

my123 7y ago

My guess: the old fragile Objective-C runtime ABI. They could have done a new ABI, but that'd have broken compatibility anyway...

Aloha 7y ago
Why is it more fragile than the same objc runtime in 64 bit?
- eschaton 7y ago
  Because the 32-bit runtime has a fragile base class problem that can’t be fixed—without breaking binary compatibility. Class instance variable layout and instance sizes in the i386 runtime are fixed; making this flexible was the major improvement introduced with the x86_64 runtime.