Live data from Hacker News

Windows 10 on ARM

channel9.msdn.com

261–270 of 290 posts

Re: Windows 10 on ARM

#261

Emulation should be a last resort. They should ship an SDK with all the proper import libs and a cl.exe etc. that can target proper Win32 on ARM.

The import libs for Windows IoT seems to contain the full api surface, so we already have those - it's just that a lot of the functions are stubbed out in the actual dlls on the system.

Re: Windows 10 on ARM

#262
post #243
post #89

Please correct me If I am wrong. But I think with WSL and this, Microsoft proved they are much much more superior than Google and Apple when it comes to serious system software development (they have to be, they have developed one of the most complex Kernel of the all times and maintained and improved it for decades. Yes I am linux guy too. But Widnows Kernel is extremely complex and well architectured piece of softw…

I agree this is harder and more impressive, but I thought Google's idea to run the entire Android framework at near-native speeds on Chrome OS inside a container was quite a smart technical solution as well.

Which they haven't implemented it yet. have you any experience with it? It is terrible, laggy, and doesn't work sometimes. Even google does not advertise it like they did before.

Re: Windows 10 on ARM

#263
post #214

Earlier quoted context omitted.

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

Neither of those are what I am talking about.

Re: Windows 10 on ARM

#264
post #218

Earlier quoted context omitted.

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

Ive previously done iOS development (on the side) and tried Android development in the last few weeks and it feels like a massive, horrible hacked together pipeline. Why go through this horrible hack of a pipeline, recompiling and modifying .class files when you can instead create a compiler which does it directly?

Re: Windows 10 on ARM

#265

Earlier quoted context omitted.

A phone form factor device that can run a full desktop OS, or something close to it. Canonical was getting close with Ubuntu Touch but that's essentially dead now. I don't want a gimped version of Windows like I'd get with Continuum, I don't want a "desktop-like" version of Android like Samsung is doing, I want a full version of Linux or Windows that can run desktop applications.

You may be interested in the Gemini PDA (which I've funded on IndieGoGo) which provides an Android/Linux PDA. https://www.indiegogo.com/projects/gemini-pda-android-linux-...

That looks really interesting, I'm going to keep an eye on it.

Re: Windows 10 on ARM

#266

Earlier quoted context omitted.

A phone form factor device that can run a full desktop OS, or something close to it. Canonical was getting close with Ubuntu Touch but that's essentially dead now. I don't want a gimped version of Windows like I'd get with Continuum, I don't want a "desktop-like" version of Android like Samsung is doing, I want a full version of Linux or Windows that can run desktop applications.

Have you seen this? http://pgslab.com/ It's billed as a handheld gaming system but you don't have to play games on it. Runs Windows 10 on a 5.9-inch 1920 x 1080 screen. Atom processor. Whether it will lever get made is another matter (it's an ex-Kickstarter project now taking pre-orders), but the approach is interesting.

Dual booting isn't a perfect solution but I'm sure it's a lot easier than trying to design a UI that can adapt to screen sizes as disparate as a phone screen and a monitor. I'm a little leary of hardware pre-orders as it's easy to get burned but I'll definitely keep an eye on it.

Re: Windows 10 on ARM

#267

Earlier quoted context omitted.

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

Yes it is (about atomics/sync). ARM like every other major core is "sequentially consistent" with respect to the core executing the code. The memory order only matters for external visibility (aka other threads or devices). This means that the load/store order from a single thread doesn't matter to the other threads except at synchronization points (aka locks/etc). Those sync primitives have implied barriers.

If someone has a program which is depending on load/store order in userspace then they likely have bugs on x86 as well since threads can be migrated between cores and the compilers are fully allowed to reorder load/stores as well as long as visible side effects are maintained.. I could go into the finer points of how compilers have to create internal barriers (this has nothing to do with DMB/SFENCE/etc) across external function calls as well (which plays into why you should be using library locking calls rather than creating your own) but that is another whole subject.

The latter case is something I don't think most people understand... Particularly as GCC and friends get more aggressive about determining side effects and tossing code. Also, volatile doesn't do what most people think it does and trying to create sync primitives simply by forcing load/store does nothing when the compiler is still free to reorder the operations.

An emulator is also going to maintain this contract as well. That is why things like qemu work just fine to run x86 binaries on random ARMs today without having to modify the hardware memory model.

Re: Windows 10 on ARM

#268
post #35

I am seriously impressed with Microsoft. I haven't used windows in years but they are releasing tons of useful things. VSCode is great on Ubuntu and every version of OS X I have run it on. Plus tons of other cool things like bash on win; etc. Also, I have a bizspark Azure subscription and it's not a perfect UX; but man does it beat AWS

> VSCode is great on Ubuntu and every version of OS X I have run it on.

VSCode barely worked for me on Ubuntu, it has a lot of glitches and just a rebrand for atom.

> Plus tons of other cool things like bash on win; etc.

Bash is everything but cool.

Re: Windows 10 on ARM

#269

Earlier quoted context omitted.

Have you seen this? http://pgslab.com/ It's billed as a handheld gaming system but you don't have to play games on it. Runs Windows 10 on a 5.9-inch 1920 x 1080 screen. Atom processor. Whether it will lever get made is another matter (it's an ex-Kickstarter project now taking pre-orders), but the approach is interesting.

Dual booting isn't a perfect solution but I'm sure it's a lot easier than trying to design a UI that can adapt to screen sizes as disparate as a phone screen and a monitor. I'm a little leary of hardware pre-orders as it's easy to get burned but I'll definitely keep an eye on it.

Same here. But the price does look good....

Re: Windows 10 on ARM

#270

Earlier quoted context omitted.

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…

> Properly coded applications will be using some form of sync primitives to shared data structures. So, when the emulator hits a LOCK xxx instruction This is not always true. See [1] for an example. Because of the semantics of the x86 memory model a sequentially consistent load does not generate a lock'd instruction. When such loads are translated to ARM64, you need to introduce barriers or use a ldacq instruction. […

That doesn't matter because a properly consistent lock will need a sequentially consistent store somewhere in the sequence, and that store will generate the barrier.Something like a ticket lock works in this case because the store will eventually become visible and when it does the ordering of operations proceeding it will have completed.
Post reply on HN