Earlier quoted context omitted.
Which is, sadly, discontinued. It's still available for download though but the latest OS is 6.0 and many versions missing.
They pressured google. That was the point. Google does not give a flying fuck about developer experience. I am not saying that is wrong or right. I am saying this was the case for Google for many years. They just didn't give fuck about the experience. But look at the timing. Everyone was nagging on google for years about slow emulator. They didn't do shit for years. Microsoft released an emulator, which was superior…
Windows 10 on ARM
211–220 of 290 posts
Re: Windows 10 on ARM
#212Earlier quoted context omitted.
I think you are wrong on the Google front. Google did everything to please devs. Take apple for example, they won't think twice about refusing your app. Google OTOH, since the early days, lacked so much in the Appstore, that they let all sort of trash inside. They just wanted the devs more than quality.
Wait till you have someone file a wrongful copyright complaint against your Google Play App. Google took ours down two weeks ago and won't respond to our appeals despite clearly owning the copyright for all work done on the app.
Re: Windows 10 on ARM
#213Earlier quoted context omitted.
I guess not. It requires hardware features from Snapdragon 820/835.
Do you know particular details what these hardware features are?
Snapdragon 835 will probably be the minimum level of ARM performance Microsoft will accept. We may start seeing Samsung's Exynos and a high-end MediaTek processor being supported in a year or two.
Re: Windows 10 on ARM
#214Earlier quoted context omitted.
Microsoft appears to have apps that are native to ARM, but the real value of the Windows ecosystem is all the Win32 apps that have been built over the last 2 decades. The emulation layer addresses that so that "it just works" with old apps. I assume they will be releasing a build configuration for native ARM software deployment on Windows.
I would not assume such. They actively seem to hate this scenario.
https://developer.microsoft.com/en-us/windows/bridges/deskto...
Re: Windows 10 on ARM
#215I'm surprised that nobody has mentioned FX!32. That was the binary translation layer that Windows NT on DEC Alpha used back in 1996 or so to run x86 Windows binaries. There is an old Digital Technical Journal article about it here: http://www.hpl.hp.com/hpjournal/dtj/vol9num1/vol9num1art1.pd... Everything old is new again!
Re: Windows 10 on ARM
#216Great potential for a Win10 phablet I can develop on that also lets me make phonecalls. Not for big projects, but an anywhere device. Does Win10 support non VoIP calls?
Re: Windows 10 on ARM
#217Ha-ha, Microsoft will do it again. For Windows on all devices!
Re: Windows 10 on ARM
#218Earlier quoted context omitted.
Feature parity does not mean the exact same tools on every platform. Trying to be identical across 3 platforms always means adopting the lowest common denominator and always results in being equally shit on every platform. It's astounding that people still try to ignore the last 30 years of evidence of this.
So Linux users should get the shaft because they're the minority? Android Studio and the emulator work very well on all 3 platforms. >Trying to be identical across 3 platforms always means adopting the lowest common denominator and always results in being equally shit on every platform. In that case we're fortunate that Xcode isn't cross platform.
Linux users should get the best possible experience on the system, so should the windows users. If a better emulator is available on windows why should they get shafted? Linux tools even have the advantage that they may not need full emulation in the first place, but instead we end up with the worst of both worlds.
> Android Studio and the emulator work very well on all 3 platforms.
In my experience nothing about android development works very well on any platform. I'm not a huge fan of MS, but windows phone development and tools are an absolute dream in comparison.
Re: Windows 10 on ARM
#219Re: Windows 10 on ARM
#220Earlier quoted context omitted.
5. How do they solve the problem that x86 has a much stronger memory model than ARM, which makes emulation of multithreaded x86 code pretty hard without introducing a huge performance disadvantage?
Why is that? We are talking user space applications rather than drivers/etc. Properly coded applications will be using some form of sync primitives to shared data structures. So, when the emulator hits a LOCK xxx instruction it simply replaces it with a LDAXR/STLXR (load acquire exclusive, store release exclusive which have implied barriers) pair, or drops a barrier in. Generally though, you would expect that most we…
This is about memory order. How CPU is allowed to reorder normal unsynchronized loads and stores. X86 has strong order, but ARM CPUs can reorder loads and stores significantly more. Thus on ARM you very often need memory barriers on ARM where x86 needs none.
If memory order is not handled according to specifications, programs executing simultaneously on more than one CPU core, relying on CPU memory model/ordering will not work correctly.
You don't want to make every ordinary load and store atomic, because that would incur a rather high performance cost.