4 ms·

and of course microsoft haven't built the foundation to encourage an ecosystem that supports both x86/arm (universal binaries) that's in part what makes this p

and of course microsoft haven't built the foundation to encourage an ecosystem that supports both x86/arm (universal binaries) that's in part what makes this plan plan completely useless, and Apple got it right from the beginning back from when they announced Mac Catalyst + their decade old Rosetta tech microsoft is such a joke, glad i am no longer dependent on windows

bdcravens 4y ago
Is anyone shipping Universal Binaries for Mac? I thought most are shipping 2 versions, or just letting Rosetta handle things. Additionally, I don't think this iteration of Rosetta is a "decade old", but rather, is a new product with the same name.
- bombcar 4y ago
  I see lots of "Universal Binaries" listed and I suspect few of them are PowerPC: /Applications/1Password 7.app/Contents/MacOS/1Password 7: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64 - Mach-O 64-bit executable x86_64] [arm64] /Applications/1Password 7.app/Contents/MacOS/1Password 7 (for architecture x86_64): Mach-O 64-bit executable x86_64 /Applications/1Password 7.app/Contents/MacOS/1Password 7 (for architecture arm64): Mach-O 64-bit executable arm64
- cwizou 4y ago
  I think the breakdown is with native/non-native apps and specific build systems. Pretty much all the native apps that get updated for M1 are universal binaries. Xcode is (all things being relative) pretty good at making this work semi-transparently. The only instances where I see separate builds for x86/M1 is with non native apps, a good example that I saw just yesterday being Postman. I would guess either their build system is the culprit, or some libraries that they rely on. It's not systematic though so this is particular to those vendors, it could also be that they chose to do separate builds for other reasons, though it's not what Apple suggests developers do. Teams and Discord both have universal builds and are non-native, as counter examples to Postman. Another good example is that while VS Code [1] is universal, VS Codium [2] makes separate builds (those seem to have been posted in the last 12 hours, yay !), and this is mostly due to their build system [3]. This site is also a good resource that tells you what has native M1 support, and what still runs under Rosetta : https://isapplesiliconready.com/ https://isapplesiliconready.com/ [1]: https://code.visualstudio.com/Download https://code.visualstudio.com/Download [2]: https://github.com/VSCodium/vscodium/releases https://github.com/VSCodium/vscodium/releases [3]: https://github.com/VSCodium/vscodium/issues/597#issuecomment-1112877775 https://github.com/VSCodium/vscodium/issues/597#issuecomment...
- msbarnett 4y ago
  The _vast_ majority of 3rd party apps on my M1 Mac are Universal? Ableton, Alfred, Affinity Photo, 1password, Backblaze, Capture One, CLion, FastRawViewer, Firefox, Irident, Postico, SublimeText/Merge. The only notable non-Universal binaries are: Calibre (Intel-only) and Podman Desktop (Apple Silicon specific build)
xiphias2 4y ago
Microsoft targets slower moving enterprises, where breaking old software has a much higher cost. The problem here for Microsoft is that now finally remote work is getting embraced by knowledge workers, and they don't accept non-remote always-in-office jobs anymore. And for remote / mobile work hardware efficiency and long battery life matters much more than for in office work.
- usrn 4y ago
  You should tell that to corp IT where I work. My macbook fans have been running non-stop all week with the machine doing God only knows what while all I have open is webex, outlook, and a few VTE windows.
  - Tagbert 4y ago
    That sounds like what happens whenever I run WebEx
moondev 4y ago
https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-x86-emulation https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...
pavlov 4y ago
IMO Microsoft has put much more effort into a thoughtful x86 -> ARM transition than Apple did. For one thing, a lot of code on Windows uses the .Net runtime and is JIT-compiled to the target platform. Those programs in general don't need to be ported at all. For transitioning native x86 programs — and there are a lot of those on Windows, of course — Microsoft created a new ABI that lets you mix ARM and emulated x86 code seamlessly: https://blogs.windows.com/windowsdeveloper/2021/06/28/announcing-arm64ec-building-native-and-interoperable-apps-for-windows-11-on-arm/ https://blogs.windows.com/windowsdeveloper/2021/06/28/announ... This is great for something like an audio or video app that uses a lot of third party plugins. The host app can be ported to ARM, but it can still load those x86 plugin binaries. Apple has no solution for this: their Rosetta works on a process level. If you have a Final Cut Pro plugin that hasn't been ported by the developer to ARM, your only option is to run all of FCP in Rosetta emulation.
- my123 4y ago
  > your only option is to run all of FCP in Rosetta emulation. Apple has out of process plugins nowadays for that use case, through the XPC infrastructure. It's more 3rd-party SW that doesn't use XPC out of process plugins that are affected.
  - pavlov 4y ago
    Yes, good point. Let's replace FCP with After Effects, which is a popular plugin host and doesn't use XPC (AFAIK). Rearchitecting native plugins to run out of process is a lot of work, and isn't something Adobe can quickly mandate on their developers.
- GeekyBear 4y ago
  > IMO Microsoft has put much more effort into a thoughtful x86 -> ARM transition than Apple did. Given that the Surface Pro X didn't support 64 bit x86 Windows applications at all, I'm not sure how you can think so. Even after developer channel support was added, it was unlikely to work. >How did Microsoft screw this up? - Surface Pro X (SQ2) vs M1 Macbook Air https://www.youtube.com/watch?v=OhESSZIXvCA https://www.youtube.com/watch?v=OhESSZIXvCA

bdcravens 4y ago

Is anyone shipping Universal Binaries for Mac? I thought most are shipping 2 versions, or just letting Rosetta handle things. Additionally, I don't think this iteration of Rosetta is a "decade old", but rather, is a new product with the same name.

bombcar 4y ago
I see lots of "Universal Binaries" listed and I suspect few of them are PowerPC: /Applications/1Password 7.app/Contents/MacOS/1Password 7: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64 - Mach-O 64-bit executable x86_64] [arm64] /Applications/1Password 7.app/Contents/MacOS/1Password 7 (for architecture x86_64): Mach-O 64-bit executable x86_64 /Applications/1Password 7.app/Contents/MacOS/1Password 7 (for architecture arm64): Mach-O 64-bit executable arm64
cwizou 4y ago
I think the breakdown is with native/non-native apps and specific build systems. Pretty much all the native apps that get updated for M1 are universal binaries. Xcode is (all things being relative) pretty good at making this work semi-transparently. The only instances where I see separate builds for x86/M1 is with non native apps, a good example that I saw just yesterday being Postman. I would guess either their build system is the culprit, or some libraries that they rely on. It's not systematic though so this is particular to those vendors, it could also be that they chose to do separate builds for other reasons, though it's not what Apple suggests developers do. Teams and Discord both have universal builds and are non-native, as counter examples to Postman. Another good example is that while VS Code [1] is universal, VS Codium [2] makes separate builds (those seem to have been posted in the last 12 hours, yay !), and this is mostly due to their build system [3]. This site is also a good resource that tells you what has native M1 support, and what still runs under Rosetta : https://isapplesiliconready.com/ https://isapplesiliconready.com/ [1]: https://code.visualstudio.com/Download https://code.visualstudio.com/Download [2]: https://github.com/VSCodium/vscodium/releases https://github.com/VSCodium/vscodium/releases [3]: https://github.com/VSCodium/vscodium/issues/597#issuecomment-1112877775 https://github.com/VSCodium/vscodium/issues/597#issuecomment...
msbarnett 4y ago
The _vast_ majority of 3rd party apps on my M1 Mac are Universal? Ableton, Alfred, Affinity Photo, 1password, Backblaze, Capture One, CLion, FastRawViewer, Firefox, Irident, Postico, SublimeText/Merge. The only notable non-Universal binaries are: Calibre (Intel-only) and Podman Desktop (Apple Silicon specific build)

xiphias2 4y ago

Microsoft targets slower moving enterprises, where breaking old software has a much higher cost. The problem here for Microsoft is that now finally remote work is getting embraced by knowledge workers, and they don't accept non-remote always-in-office jobs anymore. And for remote / mobile work hardware efficiency and long battery life matters much more than for in office work.

usrn 4y ago
You should tell that to corp IT where I work. My macbook fans have been running non-stop all week with the machine doing God only knows what while all I have open is webex, outlook, and a few VTE windows.
- Tagbert 4y ago
  That sounds like what happens whenever I run WebEx

moondev 4y ago

https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-x86-emulation https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...

pavlov 4y ago

IMO Microsoft has put much more effort into a thoughtful x86 -> ARM transition than Apple did. For one thing, a lot of code on Windows uses the .Net runtime and is JIT-compiled to the target platform. Those programs in general don't need to be ported at all. For transitioning native x86 programs — and there are a lot of those on Windows, of course — Microsoft created a new ABI that lets you mix ARM and emulated x86 code seamlessly: https://blogs.windows.com/windowsdeveloper/2021/06/28/announcing-arm64ec-building-native-and-interoperable-apps-for-windows-11-on-arm/ https://blogs.windows.com/windowsdeveloper/2021/06/28/announ... This is great for something like an audio or video app that uses a lot of third party plugins. The host app can be ported to ARM, but it can still load those x86 plugin binaries. Apple has no solution for this: their Rosetta works on a process level. If you have a Final Cut Pro plugin that hasn't been ported by the developer to ARM, your only option is to run all of FCP in Rosetta emulation.

my123 4y ago
> your only option is to run all of FCP in Rosetta emulation. Apple has out of process plugins nowadays for that use case, through the XPC infrastructure. It's more 3rd-party SW that doesn't use XPC out of process plugins that are affected.
- pavlov 4y ago
  Yes, good point. Let's replace FCP with After Effects, which is a popular plugin host and doesn't use XPC (AFAIK). Rearchitecting native plugins to run out of process is a lot of work, and isn't something Adobe can quickly mandate on their developers.
GeekyBear 4y ago
> IMO Microsoft has put much more effort into a thoughtful x86 -> ARM transition than Apple did. Given that the Surface Pro X didn't support 64 bit x86 Windows applications at all, I'm not sure how you can think so. Even after developer channel support was added, it was unlikely to work. >How did Microsoft screw this up? - Surface Pro X (SQ2) vs M1 Macbook Air https://www.youtube.com/watch?v=OhESSZIXvCA https://www.youtube.com/watch?v=OhESSZIXvCA