Live data from Hacker News

Windows 10 on ARM

channel9.msdn.com

211–220 of 290 posts

Re: Windows 10 on ARM

#211
post #106

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…

Well, Intel introduced HAXM a long time ago. It made it run quit faster.

Re: Windows 10 on ARM

#212

Earlier 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.

Just like Chrome extensions that get removed without warning and you can't even get an answer of why and how you can fix the situation (submitting it for manual review fixes nothing).

Re: Windows 10 on ARM

#213
post #101

Earlier quoted context omitted.

I guess not. It requires hardware features from Snapdragon 820/835.

Do you know particular details what these hardware features are?

I'm guessing it's both a performance issue and a "let's not support too many different ARM chips from the beginning" issue.

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

#214

Earlier 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.

Microsoft also has this project, and UWP apps should work on ARM as well:

https://developer.microsoft.com/en-us/windows/bridges/deskto...

Re: Windows 10 on ARM

#215

I'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!

Ah, DEC Alpha! I had one that ran NT 4.0 and pre-release copies of Windows 2000 (amongst other things) and the day Microsoft decided not to release Windows 2000 for it was one of the saddest of my life (until then).

Re: Windows 10 on ARM

#216

Great 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?

I doubt Microsoft would be going the phablet direction, even if Windows on ARM now supports "desktop apps". There's still the issue of having a horrendous desktop UI on a phone. Heck, it still pisses me off that legacy Windows apps don't even properly support 1080p screens. It should be way worse to squeeze them in a small screen as well.

Re: Windows 10 on ARM

#217

Ha-ha, Microsoft will do it again. For Windows on all devices!

Not really. This is more about allowing ARM to enter the PC market. ARM couldn't break into the PC market without Microsoft's help and by being fully supported by Windows. The only other alternative were Chromebooks, and even Google didn't bother to make a big push for ARM in Chromebooks.

Re: Windows 10 on ARM

#218
post #189

Earlier 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.

> So Linux users should get the shaft because they're the minority?

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

#220
post #43

Earlier 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…

You're talking about atomic operations and synchronization. This is not about that.

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.

Post reply on HN