Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Future ARM Mac owners who rely on Bootcamp/Intel VMs and kexts etc - what are you going to do?
- Thread starter evilzardoz
- Start date
- Sort by reaction score
Christ, you're talking about running friggin word processing programs dude. Macs 1/1000 the speed of current macs could do that Easily 30 years ago.
How can you hold that up as an example of how well 'web' apps perform!!!
I’ve heard a couple of very vocal people on the forum state they are done with the Mac because they can’t run something that to the best of my knowledge can’t run on 64 bit code in Windows and probably hasn’t been upgraded to Windows 7 let alone Windows 10.
If you’re in that boat, I get that it sucks, but ecosystem matters.
It seems ridiculous that Windows is so far up it’s own rear on supporting stuff that people running VB6 (pre-2000) and Classic ASP (also pre-2000) people are complaining about not being to run something.
Windows on ARM is running apparently very well now on a Raspberry Pi. I expect Windows will run on Apple Silicon.
I truly love all of you guys, but if the code base is seriously that old, and it seriously can’t run well on ARM running emulated x86 commands the problem goes a lot further than anyone in this forum can help.
I know it sucks, but Microsoft and the vendor who made whatever niche hardware played those cards for you.
If you’re in that boat, I get that it sucks, but ecosystem matters.
It seems ridiculous that Windows is so far up it’s own rear on supporting stuff that people running VB6 (pre-2000) and Classic ASP (also pre-2000) people are complaining about not being to run something.
Windows on ARM is running apparently very well now on a Raspberry Pi. I expect Windows will run on Apple Silicon.
I truly love all of you guys, but if the code base is seriously that old, and it seriously can’t run well on ARM running emulated x86 commands the problem goes a lot further than anyone in this forum can help.
I know it sucks, but Microsoft and the vendor who made whatever niche hardware played those cards for you.
If I can't get Vagrant or Docker to work on ARM Mac then I might just build a little local server to run everything for me. For now I just went ahead and bought a 16" MBP because I'm tired of waiting and figure things will be kinda glitchy and complicated at the start and I'll just skip the next 2-3 years of that and then upgrade.
I agree with some others on here, where if you need some windows apps, then buy a PC and either remote into it, or use natively.
Until recently I was running bootcamp on my 16” MBP, but decided to buy a PC to allow me to do some more hardcore 3D work and also something that will keep me covered in the transition [fingers burnt on the last one....]. I know my way around windows as much as a mac, and the reality is I havent touched my MBP since I got the PC, as it is a far far better experience in the apps I use and I have been very productive.
So my situation moving forward is going to be PC for work, Mac for personal, until I can see with some clarity that the apps I use are fully supported [this includes unreal engine........].
I will be, as ever, an early adopter of AS, and trust Apple to deliver.
Until recently I was running bootcamp on my 16” MBP, but decided to buy a PC to allow me to do some more hardcore 3D work and also something that will keep me covered in the transition [fingers burnt on the last one....]. I know my way around windows as much as a mac, and the reality is I havent touched my MBP since I got the PC, as it is a far far better experience in the apps I use and I have been very productive.
So my situation moving forward is going to be PC for work, Mac for personal, until I can see with some clarity that the apps I use are fully supported [this includes unreal engine........].
I will be, as ever, an early adopter of AS, and trust Apple to deliver.
The key to all of this is whether Microsoft will put an X86/x64 emulator/translator (whatever you want to call the equivalent of Rosetta 2 in the Windows world) into the Arm version of Windows. If they do, and they do a really good job of it, bootcamp or VMs on AS will work. If they don't, people who need to keep running Windows apps will need to get a Windows machine.
It’s all good if you are just doing this at home and it isn’t critical but I don’t think it is worth risking my whole business on what if’s..... which is why buying a PC is no big deal to see the transition through.
Also surely all the complicated pro apps would need converting to ARM just so a couple of people can use them on AS bootcamp, or am I missing something?
I don't understand what you are saying. The idea is to get the ARM version of Windows to load on an AS Mac. This could be a bootcamp/dual boot type environment, or a VM (Parallels, VMware, VBox, etc.). Inside that environment, there is an equivalent to Rosetta 2, but it runs on ARM Windows. This will need to be created by Microsoft. Then within Windows, you could run x86/x64 apps as they currently exist (no need to rewrite or recompile). There may be a performance hit, which may or may not be an issue, depending on how fast the AS SoCs actually are.
There used to be emulators on the PPC, but they weren't great in terms of performance. When the Intel CPUs came to the Mac, you could (after a while) dual boot using bootcamp into Windows, or use a VM (like the ones I called out above). no need to rewrite or recompile. With the move to AS, this goes away.
There used to be emulators on the PPC, but they weren't great in terms of performance. When the Intel CPUs came to the Mac, you could (after a while) dual boot using bootcamp into Windows, or use a VM (like the ones I called out above). no need to rewrite or recompile. With the move to AS, this goes away.
I understand what you are saying now.
For me it sounds like there are too many things to go wrong and would prefer just to have full windows on x86.
I agree, and its where I am at now [except the PC is for rendering, and will make a very fine gaming computer]
If the Apple Silicon Macs don't have UEFI there it is highly unlikely there is going to be a "dual boot" environment because Apple would have taken the boot environment into a highly proprietary zone.
A virtual machine can get its own virtual UEFI "boot" environment which make make it viable., but "raw on the iron" basically so far Apple has said no. And if that "no" comes from them not implementing UEFI, then that will be a pretty hard "no". ( i.e., if the iOS systems are the primary drivers of the boot system design then Macs will be decoupling from the legacy , generic PC boot design restrictions. Macs will boot a little looser ( to boot macOS off of an external drive ), but lots of pointers to it won't be what it was. )
The VM option is a much bigger hit on GPU heavy applications. While the modern Intel/AMD x86-64 CPUs support hardware virtualization the hardware support on the GPU is generally much further behind. Apple doesn't have a proven high skill set in the hardware virtualized GPU area either.
Microsoft has one of these and it is mainly focused on Win32 apps. Largely for results pointed out elsewhere in the thread as a significant number of people on Windows want "maximum" legacy app coverage. There is a smaller portion that solely want bleeding edge x86-64 support. ( and where they do want bleeding edge support a sizable portion probably don't want to throw away AVX. )
Windows is much larger than the macOS ecosystem. That can be a dual edge sword. One downside is that it has much larger software inertia . While that means more customers that need it (more potential sales of replacement systems) , it also means there are more customers that have old stuff. [ windows has a vm 'box' to run DOS programs in. ]
Apple periodically "cleans house". Apple dumped 32-bit kernel and booting more than several years ago. Apple dump all 32-bit x86 apps that were still lingering around last macOS upgrade.
[/quote] Then within Windows, you could run x86/x64 apps as they currently exist (no need to rewrite or recompile). There may be a performance hit, which may or may not be an issue, depending on how fast the AS SoCs actually are. [/quote]
32-bit , Win32 apps run fine on Windows ARM. There should be Cortex-X1 ( semi-customized A78 )
Introducing the Arm Cortex-X Custom program
Read this introduction to the Arm Cortex-X Custom Program, outlining what the new program entails and providing details about the new Arm Cortex-X1 CPU which is part of the program.
community.arm.com
coming in the next round of Windows ARM systems.
The AS Macs will have a hypervisor processor (it is in the WWDC diagram that went with the AS announcement). As much as Apple would like to demonstrate its silicon expertise, there must be a reason it is in the SoC. It could be strictly for the MacOS (perhaps Apple is envisioning a future in which MacOS may become a hypervisor type OS), or it might be there for other reasons. i don't know if UEFI is strictly required for Windows, or at least the ARM Windows version.
I suppose there is the "other" way of doing this: Apple themselves (or even more likely, contract an outside software house) create the X64 translator for ARM Windows, or a third party could do it on their own, as a stand alone product. This would be helped if the ARM Windows laptops ever really got going. The above Cortex-X1 would be a big help in that regard.
I suppose there is the "other" way of doing this: Apple themselves (or even more likely, contract an outside software house) create the X64 translator for ARM Windows, or a third party could do it on their own, as a stand alone product. This would be helped if the ARM Windows laptops ever really got going. The above Cortex-X1 would be a big help in that regard.
Then within Windows, you could run x86/x64 apps as they currently exist (no need to rewrite or recompile). There may be a performance hit, which may or may not be an issue, depending on how fast the AS SoCs actually are. [/quote]
32-bit , Win32 apps run fine on Windows ARM. There should be Cortex-X1 ( semi-customized A78 )
Introducing the Arm Cortex-X Custom program
Read this introduction to the Arm Cortex-X Custom Program, outlining what the new program entails and providing details about the new Arm Cortex-X1 CPU which is part of the program.
community.arm.com
coming in the next round of Windows ARM systems.
[/QUOTE]
I think it’s pretty likely you’ll be able to run Windows 10 for Arm under Parallels. If you look on you tube it’s easy to find instructions on how to install Windows 10 for Arm (not Windows IOT) on a Raspberry api 3/4.
Of course the next question is why ?
Docket will definitely be available. It’s mentioned as work in progress in the WWDC developer videos.
Yeah saw that right after in some of the responses, which I felt corrected it adequately. I thought I had searched for that quite recently when I wrote the response, but I was wrong.
Software. Depending on what you do with your Mac, some people must run Windows based software. For example, a vendor I work with only has their tools available for Windows or 32 bit Linux.
Ergo, you would need a Windows VM if a Mac is your only machine
A hack that is running ( with some subset of the memory) is different from a cleanly licensed (paid for) instance. Apple isn't going to support the former. Microsoft has to be involved in some way in the latter.
Microsoft has put formal virtualization support into place for Windows 10 on ARM (on Hyper-V) . There aren't huge technological show stoppers here. But without Apple's involvement won't have access to the Mac specific stuff on the device either. (e.g., only a generic virtualized GPU, generic track pad , no hardware video compression/decompression, etc. )
Of course the next question is why ?
As long as there is relatively very low uptake on Windows 10 on ARM that would be a question. But 'why?' in the Q4 2020 - 1H 2021 time period.... probably because it is the fastest ARM laptop Windows 10 would run on by a large margin. ( Apple Silicon for Mac versus the Snapdragon 8cx isn't really a contest performance wise and likely similar system battery lifetimes. )
If Microsoft's upcoming x86-64 emulator has high overhead, then will need pretty hefty "grunt' to make it more widely viable. It wouldn't be enough for "hard core" Windows folks to switch over to buying a Mac to run Windows. But it probably would be a stop gap to keep folks currently primarily macOS users that need some mainstream Windows 10 apps from bolting because couldn't get "good enough" performance for their Win 10 workload subset .
He's saying that he used to only need one computer to accomplish his needs and now he'll need two. From his standpoint, that is within fairness to be considered "horsecrap". It may not be the majority of users, but it's enough users to be inconvenienced by it, for sure.
It's sounding like it won't be something that Apple immediately allows. Not saying it won't be doable. But it may not be something we see for a long while, if ever.
If you are running Office 2016 for Mac, then no, that will not get updated for Apple Silicon. Furthermore, Microsoft is no longer going to be supporting Office 2016 for Mac with any kind of updates (security or otherwise) starting in October of this year. So, if you have Office 2016 for Mac, you'll want to stop using it imminently.
If you are running Office 2019 for Mac, then I honestly don't know. I'm not even sure if Microsoft has released any information about that. I would guess they will wait until the next perpetual release of Office for Mac to provide an Apple Silicon native and/or Universal 2 binary version as they did with Office 2008 circa the PowerPC-to-Intel transition. That being said, if you are in this boat and Microsoft doesn't update Office 2019 to be Apple Silicon native; odds are decent that you won't notice the speed hit that Rosetta 2 would entail. I never noticed the speed hit on either Office v.X for Mac or Office 2004 for Mac via the original PowerPC-to-Intel Rosetta.
If you are running some form of Microsoft 365 subscription (formerly Office 365), then, as others have stated, you will very likely be able to install an Apple Silicon native version on day 1.
No one is complaining about needing to run 32-bit code. The need to natively run or natively virtualize 64-bit x86 Windows isn't niche. It's pretty common and, for those that don't want to own two computers, it's crippling.
Ecosystem really doesn't matter. You have iTunes and iCloud for Windows. The only things that you might miss are copying and pasting things from your iPhone or iPad to your Mac (which is nice, but not everything) and replying to iMessages and SMS from your Mac. Otherwise, there's not much in the way of mandatory ecosystem hooks that makes it so that iPhone and iPad people have to own a Mac instead of a PC. Certainly there's far more tying the iPhone and iPad together than anything else. Same with the watch and the iPhone. So, no, ecosystem doesn't really mean much.
Bro, I think your knowledge of Windows is pretty dated. Microsoft IS pushing things forward in big ways with Windows 10 they're just baking in this thing called "backwards compatibility" that is required when 85% of the PCs in the world run your platform. Apple can afford to cut off support for things on the Mac because, relative to Windows, there aren't that many people using it. Plus, home users are less change averse than business users (many of whom need to use niche software that will never make it to any Mac - Intel Apple Silicon or otherwise). But make no mistake, they're pushing that platform forward in some sizable ways.
The version of Windows 10 on ARM64 that you're referencing is an IoT specific version that is not intended to be used for general computing. It's intended to run a single app and be operated as an appliance not as a personal computer. That is not an accurate benchmark for anything, especially given that the SoC present in the Surface Pro X is more capable than that of a Raspberry Pi and the former still runs like crap. I also expect Windows 10 for ARM64 will make its way to Apple Silicon Macs in some form or another, but the hurdles to get it there are not insubstantial.
Again, I don't know why you're spinning a lack of backwards compatibility as progress. Unless you have more money than your deity of choice and can afford to buy new versions of expensive software whenever Apple decides to drop support for things like 32-bit support switch to an entirely different processor architecture, and are willing to help the people who aren't as privileged, quit spinning this into being a positive thing.
All Microsoft did was bake in support that made it so that people who can't move to new versions of things don't have to. They did nothing to inhibit progress. Software developers are the ones at fault here. But even then, Apple has, in the last fifteen years, forced developers to move from 32-bit PowerPC to 32-bit Intel, to 64-bit Intel, and now to 64-bit ARM. And that doesn't even include the host of other changes to the operating system that it has made during those periods of time. Apple is not a friendly platform for developers. They will force you to change your code regularly in the name of progress, forcing a kind of Darwinian survival-of-the-fittest kind of development market, which ultimately limits software choice for the user of a Mac. There are several more apps available for Windows than there ever will be for Mac and that's why. Again, not sure how you can spin that as being a good thing for the platform.
I'm not saying that Apple shouldn't be allowed to advance the platform, but when you're in a constant state of flux, it's not exactly inviting developers to play along. I've always wanted to develop for the iPad because I believe it to be a very important and influential computing device. Apple is almost discouraging me to hop on board.
They're not putting an x86-64/x64 translator into Windows 10 for ARM64. They already have a 32-bit x86 translator built-in for 32-bit Windows apps. It runs slowly, but that's because Windows 10 for ARM64 also runs slowly because the hardware it runs on is also slow hardware. Apple Silicon may make that kind of emulation sluggishness a thing of the past. But they've stated nothing about working on getting x86-64 native apps to be translated. If anything, they should spend their energy trying to get their version of universal binaries out there.
Then within Windows, you could run x86/x64 apps as they currently exist (no need to rewrite or recompile). There may be a performance hit, which may or may not be an issue, depending on how fast the AS SoCs actually are. [/quote]
32-bit , Win32 apps run fine on Windows ARM. There should be Cortex-X1 ( semi-customized A78 )
Introducing the Arm Cortex-X Custom program
Read this introduction to the Arm Cortex-X Custom Program, outlining what the new program entails and providing details about the new Arm Cortex-X1 CPU which is part of the program.
community.arm.com
coming in the next round of Windows ARM systems.
[/QUOTE]
Apple is likely ditching UEFI as we currently know it on Apple Silicon Macs. But that doesn't mean anything as far as being able to dual-boot Apple Silicon macOS and Windows 10 for ARM64. Apple could just add in a compatibility layer similar to the CSM support they added in during the early days of Boot Camp to enable booting and installing Windows XP, Windows Vista, and Windows 7. Microsoft didn't start pushing UEFI booting until the launch of original Windows 8 and for all Apple systems (and most PCs), the legacy BIOS layer is merely being emulated. Similarly, in a VM, it REALLY doesn't matter as only the VM needs to have a UEFI based firmware and that can merely be software-defined.
Again, this x86-64/AMD64/x64 translator for Windows 10 for ARM64 ain't happening unless Microsoft reverses course. They need to prove that ARM64 is as good of an architecture to develop Windows apps on as x86-64/AMD64/x64. That may naturally come anyway given Intel's troublesome trajectory. AMD can step things up here and take the crown in a big way, but even then, with Apple running a very powerful ARM64 implementation, everyone else (AMD included) is going to be looking at ARM as potentially being the future of standard computing.
AGAIN, the x86-64 emulator isn't happening unless Microsoft reverses course. Their only hope for Windows 10 for ARM64 is to either hop on Apple's bandwaggon in a big way (either via a dual-boot solution or via very competent virtualization) and/or to invest further in making their own silicon as Apple has to push performance further. They may be behind Apple considerably on this, but that's not to say that they couldn't do something similar, at least for the future of their Surface devices (which may yet inspire Dell, HP, Lenovo, Asus, Acer, MSI, Razer, Toshiba, and Samsung to do something similar).
Docker will definitely be available but probably not to build and run x86 containers. It will probably only run ARM containers.
Brew is written mostly in Ruby which is an interpreted language. I am certain the ARM version of Big Sur includes Ruby. It depends on git but again, git is included with Xcode so that must already be working. The issue is the software that brew installs, that will all need to be ported to ARM and Brew will have to pull the right version for the architecture.