| |
| ▲ | electroly 14 hours ago | parent | next [-] | | Surface Pro 11 owner here. SQL Server won't install on ARM without hacks. Hyper-V does not support nested virtualization on ARM. Most games are broken with unplayable graphical glitches with Qualcomm video drivers, but fortunately not all. Most Windows recovery tools do not support ARM: no Media Creation Tool, no Installation Assistant, and recovery drives created on x64 machines aren't compatible [EDIT: see reply, I might be mistaken on this]. Creation of a recovery drive for a Snapdragon-based Surface (which you have to do from a working Snapdragon-based Surface) requires typing your serial code into a Microsoft website, then downloading a .zip of drivers that you manually overwrite onto the recovery media that Windows 11 creates for you. Day-to-day, it's all fine, but I may be returning to x64 next time around. I'm not sure that I'm receiving an offsetting benefit for these downsides. Battery life isn't something that matters for me. | | |
| ▲ | goosedragons 14 hours ago | parent | next [-] | | You ABSOLUTELY do not have to create a recovery drive from a Snapdragon based device. I've done it multiple times from x64 Windows for both a SPX and 11. | | |
| ▲ | electroly 14 hours ago | parent [-] | | Hmm, thank you, that's good to know. Did you just apply the Snapdragon driver zip over the x64 recovery drive? It didn't work for me when my OS killed itself but I could easily have done something wrong in my panic over the machine not working. Since I only have the one Snapdragon device, I was making the assumption that it would have worked if I had a second one, but I didn't actually know that. | | |
| |
| ▲ | brokencode 14 hours ago | parent | prev | next [-] | | That’s brutal.. I wonder why the Apple Silicon transition seemed so much smoother in comparison. | | |
| ▲ | magic_hamster 8 hours ago | parent | next [-] | | Apple had a great translation layer (Rosetta) that allows you to run x64 code, and it's very fast. However, Apple being Apple, they are going to discontinue this feature in 2026, that's when we'll see some Apple users really struggling to go fully arm, or just ditch their MacBook. I know if Apple does follow through with killing Rosetta, I'll do the latter. | | |
| ▲ | menaerus 7 hours ago | parent [-] | | It's a transpiler that takes the x86-64 binary assembly and spits out the aarch64 assembly only on the first run AFAIK. This is then cached on storage for consecutive runs. | | |
| ▲ | timschmidt 6 hours ago | parent [-] | | Apple also implemented x86 memory semantics for aarch64 to allow for simpler translation and faster execution. | | |
|
| |
| ▲ | wmf 13 hours ago | parent | prev | next [-] | | For one thing Apple dropped 32-bit before they transitioned to ARM while Windows compatibility goes back 30 years. | |
| ▲ | viraptor 14 hours ago | parent | prev | next [-] | | Did it? From that list: SQL server doesn't work on Mac and there's no Apple equivalent, virtualisation is built into the system so that kind of worked but with restrictions, games barely exist Mac so a few that cared did the ports but it's still minimal. There's basically no installation media for Macs in the same way as windows in general. What I'm trying to say is - the scope is very different / smaller there. There's a tonne of things that didn't work on Macs both before and after and the migration was not that perfect either. | | |
| ▲ | electroly 13 hours ago | parent [-] | | Out of the gate, Apple silicon lacked nested virtualization, too. They added it in the M3 chip and macOS 15. Macs have different needs than Windows though; I think it's less of a big deal there. On Windows we need it for running WSL2 inside a VM. | | |
| ▲ | fulafel 8 hours ago | parent | next [-] | | I'd guess the M3 features aren't required for nested virtualization, and it was more of a sw design decision to only add the support when some helpful hardware features were shipped too. Eg here's nested virtualization support for ARM on Linux in 2017: https://lwn.net/Articles/728193/ | | |
| ▲ | justincormack 4 hours ago | parent [-] | | Nested virt does need hardware support to implement efficiently and securely. The Apple chips added that over time, eg M2 actually had somewhat workable support but still incomplete and hacky https://lwn.net/Articles/928426/ - the GIC (interrupt controller) was a mess to virtualise in older versions, which is different from the instruction set of the CPU. |
| |
| ▲ | pjmlp 8 hours ago | parent | prev [-] | | On Windows nested virtualization already existed before WSL, all the kernel and device drivers security features introduced on Windows 10, and made always enabled on Windows 11, require running Hyper-V, which is a type 1 hypervisor. So it is rather easy having to deal with nested virtualization, even those of us that seldom use WSL. |
|
| |
| ▲ | kwanbix 14 hours ago | parent | prev | next [-] | | Because Apple controls verything vs Windows/Linux world where hundres (thouthands?) of OEM create things? | | |
| ▲ | leidenfrost 10 hours ago | parent [-] | | I agree with you on the Windows side. Linux is different. Decades of being tied to x86 made the OS way more coupled with the processor family than one might think. Decades of bugfixes, optimizations and workarounds were made assuming a standard BIOS and ACPI standards. Specially on the desktop side. That, and the fact that SoC vendors are decades behind on driver quality. They remind me of the NDiswrapper era. Also, a personal theory I have is that have unfair expectations with ARM Linux. Back then, when x86 Linux had similar compatibility problems, there was nothing to be compared with, so people just accepted that Linux was going to be a pain and that was it. Now the bar is higher. People expect Linux to work the way it does in x86, in 2025. And manpower in FOSS is always limited. | | |
| ▲ | StopDisinfo910 2 hours ago | parent | next [-] | | Linux runs perfectly on MIPS, Power, Sparc, obviously ARM - cue the millions of phone running Linux today, RiscV, and at least a dozen other architectures with little to no user. It's absolutely not tied to x86. | |
| ▲ | close04 5 hours ago | parent | prev | next [-] | | > Decades of being tied to x86 This doesn't pass the smell test when Linux powers so many smart or integrated devices and IoT on architectures like ARM, MIPS, Xtensa, and has done so for decades. I didn't even count Android here which is Linux kernel as first class citizen on billions of mostly ARM-based phones. | |
| ▲ | daoistmonk 8 hours ago | parent | prev | next [-] | | my asahi linux m1 mac book air would disagree with you | |
| ▲ | BoredPositron 7 hours ago | parent | prev [-] | | You are talking out of your ass here. If you make bold statements like this you need to provide evidence. Linux works fine on many platforms... |
|
| |
| ▲ | someNameIG 10 hours ago | parent | prev | next [-] | | Every Mac transitions to ARM, only a very small amount of Windows PCs are running ARM. SO right now there's not an large user base to incentivise software to be written for it. | | |
| ▲ | chithanh 6 hours ago | parent [-] | | You are right that Windows on ARM cannot be called a success. But if you make Windows/macOS cross platform software then your software needs to be written for ARM anyway. So if you support macOS/x86, macos/ARM, and Windows/x86, then the additional work to add Windows/ARM is rather small, unless you do low-level stuff (I remember Fortnite WoA port taking almost a year from announcement to release due to anticheat). |
| |
| ▲ | bdcravens 10 hours ago | parent | prev | next [-] | | The first few months were a little tricky depending on what software you needed, but it did smooth out pretty quickly. | |
| ▲ | unconed 13 hours ago | parent | prev | next [-] | | Apple already went through this before with PowerPC -> x86. They had universal binaries, Rosetta, etc. to build off of. And they got to do it with their own hardware, which includes some special instructions intended to help with emulation. | | |
| ▲ | musicale 8 hours ago | parent [-] | | > Apple already went through this before with PowerPC -> x86 Not to mention 68K -> PowerPC. Rhapsody supported x86, and I think during the PowerPC era Apple kept creating x86 builds of OS X just in case. This may have helped to keep things like byte order dependencies from creeping in. |
| |
| ▲ | bitwize 14 hours ago | parent | prev [-] | | Because it was handled by the only tech company left that actually cares about the end user. Not exactly a mystery. | | |
| ▲ | okanat 14 hours ago | parent | next [-] | | Having a narrow product line helped Apple a lot. Similarly being able to deprecate things faster than business-oriented Microsoft. Apple also controls silicon implementation. So they could design hardware features that enabled low to zero overhead x86 emulation. All in all Rosetta 2 was a pretty good implementation. Microsoft is trying to retain binary compatibility across architectures with ARM64EC stuff which is intriguing and horrifying. They, however, didn't put any effort into ensuring Qualcomm is implementing the hardware side well. Unlike Apple, Qualcomm has no experience in making good desktop systems and it shows. | | |
| ▲ | andsoitis 9 hours ago | parent [-] | | > Apple also controls silicon implementation. People sometimes say that as if came without foresight or cost or other complexities in their business. No, in the end they are hyper strategic and it pays off. |
| |
| ▲ | cmxch 13 hours ago | parent | prev [-] | | Given how Apple makes it maintenance hostile and secures against their end customers, no. |
|
| |
| ▲ | throw37272835 11 hours ago | parent | prev | next [-] | | Does Remote Desktop into the Surface work well? When I'm home, I often just remote desktop into my laptop. I'm wondering if remoting into ARM Windows is as good? | | |
| ▲ | mcbridematt 10 hours ago | parent | next [-] | | I have a similar Windows Arm64 machine (Lenovo "IdeaPad 5 Slim"), RDP into it works OK. There is one issue I ran into that I haven't on my (self-built) Windows desktops: when Windows Hello (fingerprint lock) is enabled, and neither machine is on a Windows domain, the RDP client will just refuse to authenticate. I had to use a trick to "cache" the password on the "server" end first, see https://superuser.com/questions/1715525/how-to-login-windows... | |
| ▲ | dboreham 10 hours ago | parent | prev [-] | | Yes everything in user space works as expected. Note that NT has supported non-x86 processors since 1992. | | |
| ▲ | steve1977 5 hours ago | parent [-] | | According to some accounts, the name NT even was a reference to the Intel i860, which was the original target processor. |
|
| |
| ▲ | evanjrowley 9 hours ago | parent | prev [-] | | On the bright side, there's a good chance that Windows on ARM is not well supported by malware. There's a situation where you benefit from things being broken. |
| |
| ▲ | christopher8827 14 hours ago | parent | prev | next [-] | | Most apps for dev work actually work;
- RStudio
- VS Code
- WSL2
- Fusion 360
- Docker Only major exception is:
- Android Studio's Emulator (although, the IDE does work) | | |
| ▲ | nulld3v 12 hours ago | parent [-] | | Yeah, I too was surprised to find the dev experience very good: all JetBrains IDEs work well, Visual Studio appears to work fine, and most language toolchains seem well supported. | | |
| ▲ | MBCook 10 hours ago | parent [-] | | JetBrains stuff (love it!) is built on Java, so I’m not terribly surprised. I don’t know how much native code there is though. Plus they’ve been through the Apple Silicon change, so it’s not the first time they’ve been on non-x86 either. |
|
| |
| ▲ | jasoneckert 14 hours ago | parent | prev | next [-] | | Have I had any app compatibility issues?
To quote Hamlet, Act 3, Scene 3, Line 87: "No." The Prism binary emulation for x86 apps that don't have an ARM equivalent has been stellar with near-native performance (better than Rosetta in macOS). And I've tried some really obscure stuff! | | |
| ▲ | GeekyBear 11 hours ago | parent | next [-] | | That's certainly not what the reviews say. Adobe apps that ran fine on Rosetta didn't work at all on Prism. https://www.pcmag.com/articles/how-well-does-windows-on-arms... | |
| ▲ | Derbasti 4 hours ago | parent | prev | next [-] | | Same here. I've not had any issues with my Surface Pro 11. | |
| ▲ | tobias3 13 hours ago | parent | prev [-] | | For me it is too slow to run Age of Empires 2: DE multiplayer. More than ten year old Laptops with Intel chips are faster there. | | |
| ▲ | nulld3v 12 hours ago | parent [-] | | I suspect that's due to the GPU and not due to Prism, because they basically just took a mobile GPU and stuffed it into a laptop chip. Generally performance seems to be on par with whatever a typical flagship Android devices can do. Desktop games that have mobile ports generally seem to run well, emulation is pretty solid too (e.g. Dolphin). Warcraft III runs OK-ish. | | |
|
| |
| ▲ | ack_complete 11 hours ago | parent | prev [-] | | Ironically, the app I've had the most trouble with is Visual Studio 2022. Since it has a native ARM64 build and installation of the x64 version is blocked, there are a bunch of IDE extensions that are unavailable. |
|
