• Blake [he/him]
    link
    fedilink
    arrow-up
    5
    ·
    edit-2
    1 year ago

    What’s your experience here? I’m interested to hear about projects that you have done this for.

    The source engine has code that’s over 20 years old. A monolithic project like a game engine, which is statically and dynamically linked with god knows how many libraries they don’t even have code for, let alone permission, to compile in a different architecture, is not gonna be an easy thing to do.

    • OfficialThunderbolt@beehaw.org
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      I’ve brought various apps, bundles, and frameworks from PowerPC to Intel to 64-bit to ARM ever since macOS 10.0 first launched. Usually the most difficult parts were:

      1. During the PPC to Intel transition, converting code that expected all data to be big-endian over to handling little-endian data, and catching integer division by zero before sending such operations to the CPU
      2. During the 64-bit transition, switching from all the APIs Apple removed over to newer APIs, if not already done, and converting all code that expected integers and pointers to be 32-bit over to 64-bit
      3. During the ARM transition, converting code that abused variadic functions to code that used them properly, and converting all code that expected long doubles to be 128-bit over to 64-bit (I know some developers were burned by the VM page size change, but that didn’t affect anything I did)

      But yeah, usually the most difficult part of the transition is managing the dependencies. Whenever Apple transitions CPU architectures, if your app depends on a closed-source third-party library or kernel extension made by developers that went out of business years ago, you’re more or less screwed unless you can find or build a replacement.