Apple caused a stir when it announced at WWDC this year that macOS 11 would migrate to the ARM platform. Apple said it would replace Intel’s X86 platform with its self-developing ARM platform on Mac computers and migrate the ecosystem, including operating systems and software, which means ARM is a step toward suprapacing the X86 in the field of personal PCs.
macOS 11 will be compatible with ARM chips.
People have high hopes for Apple’s move. MacOS isn’t the first horse change, and in the first decade of the twenty-first century, Mac moved from the IBM PowerPC platform to the Intel X86 platform and was successful, which is one of the reasons people are so confident that Mac will still be able to provide a good experience with ARM.
Apple’s announcement comes at a time when many people also think of Microsoft, which has been groping for years in arm, introducing special systems such as Windows RT and, more recently, making Windows 10 running on ARM, compatible with a lot of previous software. However, the Win10 ARM strategy doesn’t seem to have had much of a response, and Windows RT has even gone straight to death.
Microsoft has already dabbled in ARM, launching arm-based Windows tablets.
Mac migration platforms are in full swing, and people generally expect it to be smooth sailing, while Win10 has repeatedly hit the wall. Win10 on ARM’s path, what did the bad track go wrong? Let’s talk about it today.
X86 Transfer ARM: What’s the pit?
As we all know, the biggest difference between ARM and X86 platforms is the difference in microarchitecture. ARM belongs to the RISC simple instruction set, while X86 is the CISC complex instruction set, the program to these two different platforms to run, need to compile different versions. Of course, with the middle tier, you can also achieve compatibility between two different platforms.
However, either option would come at a cost to the previousX86-compatible operating system to migrate the ecosystem to ARM.
If you abandon the compatibility of old software on the X86 platform and only make the new software compatible with the ARM platform, it means that the ecosystem needs to start from scratch, and it will be very difficult to start with new systems. During the transition, newly developed software needs to be compatible with both the X86 and ARM platforms, meaning either developers are putting more effort into compiling different versions themselves, or the operating system’s development suite provides the ability to compile simultaneously. In any case, more work is needed.
And if you want to seamlessly connect ecologically and make the new ARM platform start smoothly, it is best to allow the old software of the X86 platform to run directly on the new ARM platform, then the middle layer needs to work. Android, for example, is a good example, through HAL to blur the hardware interface, the use of cross-platform JAVA as the upper layer of the application, whether running on X86 Android or ARM Android, can be compatible with the vast majority of apps at the same time.
The disadvantage of this approach is that the middle tier can be a bottleneck to efficiency. Android’s middle layer is thick and inefficient for a long time.
The X86 instruction shave sedation for ARM is compatible, and performance degradation is inevitable.
In addition, because ARM is more used for mobile platforms, if the desktop operating system wants to migrate to ARM, it will often also play through the mobile platform already ecological blood-making attention, that is, to migrate to ARM desktop operating system, compatible with mobile platform app. Of course, there are big holes in this, such as UI adaptation is a hassle – the phone tablet screen and desktop PC display is different, to experience good visual effects, UI needs flexible deformation, which the automatic arrangement of UI elements put forward very high requirements, is also a need to invest a lot of effort to study the subject.
2 What exactly did Apple migrate ARM do?
What exactly did Apple move ARM to do?
It mentions the problems that the X86 migration ARM may encounter, but there is confidence in Apple’s move. To understand this, let’s first look at what Apple has prepared for the MIGRATION of the ARM platform.
A new development ecology that is well-developed in advance.
Apple’s plan to move its Mac to the ARM platform has long been a sign of the end. In order to smooth the transition to the ARM platform, Apple had been prepared to do a lot of work on the development kit, in a unified way, began to transform its application ecology.
Much of what Apple has done over the past two years is to solve ARM’s migration to the X86 platform. Apple unveiled SwiftUI and Mac Catalyst at the 2019 WWDC conference. The purpose of these two suites is to build bridges between ARM and X86, as well as cross-platform development between mobile and desktop platforms – Apple itself has a proven ARM mobile ecosystem that will undoubtedly be a powerful boost to desktop platform migration to ARM.
First, Mac Catalyst, a development suite across ARM and X86 platforms. With Mac Catalyst, developers build an iPad app that can also become a native app for macOS. In one way, Mac Catalyst will be the new development benchmark for iPad OS and macOS, and iPad OS will be a deep blend of macOS applications. Since then, even if macOS migrates to the ARM platform, mac Catalyst-based software applications are seamlessly compatible.
Mac Catalyst allows a software application to be compatible with both iPad OS and macOS.
SwiftUI, on the other hand, provides a cross-platform UI adaptation for mobile and desktop platforms. With SwiftUI, developers can develop software UI that fits multiple platforms at once with simpler code. For example, developers want to do software applications for macOS and iOS, iPad OS, then SwiftUI can easily make a UI that can adapt to these platform applications. It can be said that SwiftUI greatly reduces the threshold for developing software applications for different Apple platforms, which is of great significance.
SwiftUI allows the UI of the same app to fit multiple Apple platforms at the same time.
Whether it’s Mac Catalyst or SwiftUI, it’s already in action, with new xcode and high-quality development documentation that allows every Apple developer to produce high-quality software applications based on new technologies.
To a large extent, Apple has addressed the development of new software compatible with both X86/ARM and mobile/desktop platforms. Please note that this is the work done before the release of arm version macOS, can be said to be terracotta food and grass first. At present, Apple has not released the ARM version of the Mac computer, but its supporting development components, but is quite complete. By the time macOS actually migrates to arm platforms, software applications based on Mac Catalyst and SwiftUI are already in full bloom, and macOS is migrating ARM’s software ecosystem without “shock”.
Step by step for the ecological migration of the camp.
Mac Catalyst solves the problem of code compilation on the X86 and ARM platforms, while SwiftUI addresses UI adaptation for mobile and desktop platforms, but this is for newly developed software applications. Apple has also offered its tricks on macOS’s old software.
At this year’s WWDC conference, Apple announced that it will smooth the transition to the ARM platform for macOS, introducing the Rosetta 2 Intermediate Conversion Layer. If you’re old fruit powder, you must be familiar with the word Rosetta – Apple Mac computer migrated from the IBM PowerPC architecture to the Intel X86 platform that year, using a transformation layer that is Rosetta.
Mac migration platform this thing, Apple has done this once, when the Mac from pPC to X86 compatibility layer is called “Rosetta”
The purpose of Rosetta 2 is that it allows the ARM platform’s macOS to run most of the X86 software directly through instruction translation. And Rosetta 2’s performance is quite good, it is not when the software is running, only to translate instructions, but when the software is installed to do a good job of conversion. Of course, this is not to say that Rosetta 2 can achieve complete performance without loss, it is not good for AVX instruction compatibility, if x86 software relies on AVX or even AVX2, then on the ARM platform because there is no corresponding high-performance instructions, operating efficiency will be significantly degraded. Not all software uses the AVX instruction set, and overall, Rosetta 2 performance is acceptable.
This time the Mac moved from the X86 to ARM, rosetta 2 also plays a critical role in the compatibility of older X86 software.
Like Rosetta, Rosetta 2 is just a temporary move that is meant to provide a smooth transition to the ARM platform. We can refer to Rosetta’s progress: Apple announced a switch to the X86 at WWDC in 2005, then Apple launched a Mac computer based on the X86 platform in 2006 and deployed Rosetta, and by 2009 Apple Mac OS X 10.6 no longer supports PowerPC Macs, and in 2011 Mac OS X 11.7 no longer supports Rosetta, giving up support for the PowerPC era. Since then, Apple Mac Eco has completely moved to the X86 platform, the whole process did not have much pain.
From Rosetta’s history, macOS moved to ARM, and the old X86 software will be transitioned over several years. In the next few years, we may also see that the new macOS 11 no longer supports older X86 Mac computers and nodes like Rosetta 2 in a future release. In the end, macOS 11 was left with new software developed specifically for ARM, and ARM’s software applications were already in full bloom.
Apple is well aware that the change of old and new platforms is by no means a one-off. On the one hand, Apple through SwiftUI and Mac Catalyst slowly for the ARM platform Mac to create a new ecology, on the other hand through Rosetta 2 to maintain the original ecology does not lose, and both aspects of the completion is very high, can be said to be both hands to grasp, both hands to be hard typical. Coupled with the success of switching platforms from PowerPC to X86, it is only natural that there is great expectation of Mac switching to ARM architecture.
Where did the 3Win10 ARM fail?
Where did win10 ARM fail?
In many people’s perceptions, Microsoft’s Windows system moved toward ARM earlier than Apple’s macOS. Indeed, Microsoft launched the Windows RT system for the ARM platform in 2012 and loaded it on to the first generation of Surface tablets. More recently, Microsoft has moved its Entire Windows 10 desktop system to ARM, and the SnapDragon-based Windows 10 tablet has been on the market, while Microsoft itself has launched the SnapDragon ARM-based Surface Pro X.
Running the Windows RT system on the ARM platform.
Judging from the progress of the market, Microsoft is undoubtedly far ahead of Apple, macOS ARM products have not yet been on the market, and Microsoft’s ARM Windows products have been on sale for a long time. However, these products have not made much waves in the market, Window RT has come to an end, and Windows 10 ARM products such as the Surface Pro X have fallen behind the poor reputation for poor performance and have not performed well in the market.
Why is this so? We look edited back and forth as Microsoft Windows takes a journey on the ARM platform.
In 2012, Microsoft launched its Surface tablet line to compete with the iPad. However, the Windows RT system used on the SURFACE tablet of the ARM platform has many limitations.
From the outside, Windows RT is no different from the Windows 8 desktop operating system. However, Windows RT is not compatible with all traditional Windows programs developed based on X86. Windows RT gets only apps from the Store, which at one time left Windows RT with virtually no third-party software available. In fact, this is because Microsoft has restricted third-party applications through digital signatures, breaking Microsoft’s restrictions, and traditional X86 software can run on Windows RT by recompiling it into ARM applications.
Windows RT is not compatible with traditional desktop software and must be downloaded from the Windows Store.
Why is Microsoft doing this? In Microsoft’s idea, Windows RT and Windows Phone share the app store, and the two eco-se-ops, developers can develop apps for Windows Phone while also taking into account Windows RT. However, this is nothing more than a wonderful fantasy, and these flaws in Windows RT send it to the grave.
The interaction base difference between mobile phone and tablet is too large. Both Windows Phone and Windows RT push the Metro design, but there is an insurmountable gap between small and big screens. Coupled with the fact that Windows RT still has a lot of desktop UI left, it’s anachronistic to give Windows RT eco-transfusions with the help of apps on Windows Phone.
· Windows Phone doesn’t have a strong ecosystem. Microsoft has repeatedly changed the development route of Windows Phone, and the development tools have been changed. Windows Phone’s development environment is very unstable, the system itself from the beginning of the CE kernel to NT kernel, and the application from the beginning XAP to APPX, to Win10M requires developers to develop UWP applications … Developers can’t even keep up with the changing development environment of Windows Phone, and finally watch the dying of WP/Win10M, not to mention the edge product Windows RT? In this situation, it is impractical to give a blood transfusion to Windows RT through WP.
The Windows Store is unstable, and from time to time the big problem of not being able to install apps.
· Arm platform performance is too weak. Surface uses a Tegra 3 chip, which doesn’t even perform as well as the Atom of the times, and the system’s own Office runs like a card. Counting on the ARM chips of the time to support the desktop-level experience? It’s not up to it at all.
Other factors. The developers found that by cracking the digital signature restrictions on the Windows RT system, the Win32 program on the X86 platform could be recompiled, installed on Windows RT and running smoothly. Microsoft, however, has further weakened the scalability of Windows RT by closing the vulnerabilities.
Simply put, although Microsoft let Sids Windows RT run on the ARM platform, it did not have an ideal development environment, nor did it directly compatible with traditional X86 software applications, while Windows RT has UI fragmentation, platform performance weakness and other issues, failure is reasonable.
By the recent version of Windows 10 ARM, many problems seemto been resolved. Arm chip performance has improved dramatically, even close to the desktop low-voltage X86 processor, while the UWP application development environment, which supports ARM and X86 across platforms, is relatively stable compared to the past, and Microsoft has allowed Windows 10 ARM to run X86 software directly. However, Windows 10 ARM still has the following defects.
Poor compatibility. Microsoft’s intermediate compatibility layer for Windows 10 ARM is not perfectly compatible with all X86 software, and only 32-bit software can be compatible. In fact, the Thumb2 instruction set used by Windows 10 ARM is consistent with Windows RT, but this time it’s open to Win32 programs, but it’s not compatible with the X86-64 (the Windows RT ERA ARM processor is still not 64-bit) and will need to be overhauled to be compatible with 64-bit software.
Windows 10 ARM runs Win32 software in general.
Low performance. The X86 software running on Windows 10 ARM, which runs side-by-side transcoding, doesn’t do the better code work at installation like Apple Rosetta 2 does, and doesn’t need to transcode again when it runs. This resulted in Windows 10 ARM running X86 software performance is not satisfactory.
· The uWP’s future is in doubt. UWP application still has many limitations, can achieve limited functions, less stability, development environment is not as mature as the traditional WPF. You know, with Mac Catalyst to develop the application, is at least a mature iPad eco-bottom, compatible macOS is a bonus point; Only in the face of strong competition from traditional Win 32 software, developers in the UWP and Win32 software development, what choice will be self-evident.
The UWP’s big cake is really fragrant, but it’s not enough for the developers.
Microsoft has no control over ARM hardware. Windows 10 ARM runs on the SnapDragon platform, and Microsoft doesn’t design its own ARM chips, as Apple does, and the combination of hardware and software is naturally lacking. Apple can make sure that the macOS will run on the performance-level ARM chips of the future, and Microsoft can only rely on Qualcomm. In the ARM performance of the X86 is still in a catch-up situation, this is a hidden element of the dark mine.
Apple can sacrifice its own chips, and Microsoft can only work with Qualcomm.
· Windows has a heavier legacy compatibility issue. MacOS for ARM, Apple still only needs to focus on building a new Mac, while Windows to ARM, Microsoft must take into account the many hardware manufacturers, as well as a lot of old software, the transformation is doomed to not be as fast as Apple.
Here, we can sum up why Apple’s macOS switch arm can be a sensation, while Microsoft Windows transfer ARM is not satisfactory.
Apple offers a high-quality development solution (SwiftUI and Mac Catalyst) that compiles applications that are compatible with both the X86 and ARM platforms, and Microsoft is uncertain in this regard;
There is no macOS ARM products available, but the development machine is already available, Apple’s readiness can be seen.
Apple offers X86 software compatible solutions on arm platforms (Rosetta 2), which is efficient. While Windows RT is not compatible with X86 software, Windows 10 ARM runs X86 software inefficient and does not support 64-bit;
Apple can design its own high-performance ARM chip, Microsoft does not have such a ability, ARM chip performance is not enough to support the desktop environment when the start of Windows RT, now Windows 10 ARM tablet performance can not be compared with the price of other X86 tablets;
Apple in advance layout of ARM ecological transfer work, and set up a sufficient transition period, the corresponding products from start to finish to maintain a high degree of completion, and Microsoft is not ready to match the premature products rushed to market;
Apple has a greater degree of ecological control, which can prompt developers to update the iteration to adapt to the new platform, while Microsoft carries a heavy compatibility burden.
At the moment, the X86 is still the absolute mainstream of desktop platforms. But the ARM platform has shown its advantages in energy efficiency, if Microsoft iron to take into account the ARM platform, must solve the current problems, in order to bring a good experience, look forward to Microsoft can do better in the future.