Which got me to wonder: what if Apple were able to introduce a "MacOS subsystem for Windows", which could run most x64 binaries for the latter platform?
The only app that keeps me from switching to my M3 MacBook full-time is Visual Studio (and Mikrotik WinBox, to some extent, but that runs just fine under Wine).
If I could run VS without tanking battery life, that would be sort-of huge...
Where would they get the ‘for Windows’ part? They would eiher have to use Wine (which isn’t 100% compatible), license Windows from Microsoft ($$$), or write their own Wine (takes time)
> If I could run VS without tanking battery life
There’s no guarantee emulating Windows would be as energy-efficient as running MacOS.
Also, if it did, that would open the door for third parties abandoning MacOS (it runs fine "MacOS subsystem for Windows”, so why would we spend time on a Mac port?), just as happened with “OS/2 subsystem for Windows” (https://en.wikipedia.org/wiki/OS/2#OS/2_2.1_and_Windows_comp...)
If anything, Apple can afford to shove a few millions onto Wine. Most of the heavy lifting has already been done, you can run a lot of Windows apps with just a few issues.
The nasty exceptions tend to be anything involving DRM and anti-cheat, as well as stuff requiring interfacing with external hardware directly.
If you need the full Visual Studio experience, then another option would be the Windows/Arm64 build of Visual Studio, and run that on a virtual box.
There is no such thing. "Visual Studio for Mac" is a re-spin of MonoDevelop, and doesn't compare to the actual VS in any way, shape or form.
The closest you can get to VS-on-ARM-Mac right now is using a JetBrains IDE, but, as useful as these are, it's really no competition...
Was attempted by Apple but abandoned ages ago, around Leopard times.
What they do nowadays is to keep good enough platform support to be able to use Wine.
I'd love to hear if this was ever more than rumour!
Instead Microsoft locked down the entire platform iOS-style and nobody bothered.
Every reboot of WinRT tooling required a rewrite, and some tooling was left behind.
But it would be nice to have reciprocal ARM emulation on Intel. That would reduce a lot of friction for such a transition. Both forward and backward CPU compatibility.
This is explained in the docs: https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi
> Call checkers are optional on all other Windows ABIs, but mandatory on Arm64EC. On Arm64EC, call checkers accumulate the task of verifying the architecture of the function being called. They verify whether the call is another EC (“Emulation Compatible”) function or an x64 function that must be executed under emulation. In many cases, this can only be verified at runtime.
After reading the end I found the answer … you do have issue for such long career. God blessed.
“ When I was still at Microsoft in 2022 I was arguing the case that it was time to implement AVX and AVX2 across the board, but I failed to convince management or my peers of the urgency of this proposal.”
Anyhow, the dance around of code and directories make me think of the different in philosophy and trade off of time and space a lot. Once again good read.
0. https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/ma...
