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.
Windows 10 on ARM
261–270 of 290 posts
Re: Windows 10 on ARM
#262Please 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.
Re: Windows 10 on ARM
#263Earlier 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...
Re: Windows 10 on ARM
#264Earlier 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…
Re: Windows 10 on ARM
#265Earlier 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-...
Re: Windows 10 on ARM
#266Earlier 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.
Re: Windows 10 on ARM
#267Earlier 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…
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
#268I 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 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
#269Earlier 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.
Re: Windows 10 on ARM
#270Earlier 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. […