ARM-Based Windows 10 Portable PCs? Hell Yes(thurrott.com) |
ARM-Based Windows 10 Portable PCs? Hell Yes(thurrott.com) |
EXE installer 32-bit x86 64-bit x64 32-bit ARM 64-bit ARM
MSI installer 32-bit x86 64-bit x64 32-bit ARM 64-bit ARM
Portable Zip 32-bit x86 64-bit x64 32-bit ARM 64-bit ARM
Click hereThis is already a usability problem, and adding 2 more target chipsets makes it worse.
Given both bandwidth and smart programmers, couldn't Microsoft make an installer creator that works on all the above architectures and installs the right version of the program? No problem shipping 4x too much code right - most installers that are big at all, are big because of assets, not code size.
I guess politics vs the Windows Store team would prevent this from happening within Microsoft, but given how awful the Windows Store is and how it still can't be used to download and install boring oldschool desktop applications, this is a usability nightmare waiting to happen - despite the obvious benefits of not being locked into a single chipset architecture anymore.
You don't need to use Microsoft's installer technology either. Installers are simple programs. You can roll your own or use third-party installer technology like NSIS. I remember old versions of Chromium had a very simple "installer" which was just a dialog that ran on first launch and asked you for some basic settings.
The architecture problem is easily solvable too. Simple programs can just target the lowest common denominator (32-bit x86.) You can simulate "fat binaries" by having a 32-bit x86 wrapper program that includes builds for other architectures as data, extracts the correct one to the Temp directory and runs it (I think Bvckup 2 does this.) For large programs, you can have an online installer which picks the right version and downloads it (with options on the website to download an offline installer.) Also, the website itself can point the user to the correct download. It doesn't even need JavaScript to do this, since the user's architecture will be in their user agent string. Use this information to emphasize the correct option in the UI. Maybe even hide the other options behind an "Other downloads" link.
They demo Photoshop running on a Qualcomm processor: https://www.youtube.com/watch?v=A_GlGglbu1U&feature=youtu.be
2. Existing "desktop app" authors can opt to package their app in a way that will make it possible to distribute through the Windows Store.
https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...
"it still can't be used to download and install boring oldschool desktop applications"
it can.
https://msdn.microsoft.com/windows/uwp/porting/desktop-to-uw...
So, ideally, you'd just have one download.
You can also make fat packages, if you don't wanna distribute through the store.
In my head I think "Google download draftsight, click click, how hard is that?", then I remember some of the guys I work with csn hardly read but at least this guy can draw rectangles in DraftSight.
I put Linux on my SOs laptop, she llove it, but I still have to remind her to install updates occasionally.
The right balance for notifications, nagware, user interaction, download and installing things, is hard.
http://semiaccurate.com/2016/12/07/qualcomm-announces-10nm-c...
Furthermore, if the x86 emulation turns out to be as fast as they promised and demo'ed, will this kind of technology be developed for desktop linux? Is it even necessary as most apps tend to be open source and can recompile already?
Windows 10 being an entry point to get these machines into the market is perfectly fine.
Well, that could be clearer.
> Perhaps Surface phone isn’t a phone in the traditional sense. Perhaps it is, instead, just a new kind of PC with a small—for PCs; I’m hearing 6-inches—screen.
This sounds a lot like what others have been doing / try to do for a while now with Android devices (albeit not hugely successfully ... yet). So it's not surprisingly that Microsoft is considering jumping on that bandwagon.
The two keys will be performance and compatibility for the x86 emulation. If they can get it to the point where it's effectively as fast as Intel's low power Atoms while still keeping broad Win32 app compatibility, then Microsoft's Continuum concept is back on track to become a game changer.
Intel didn't hose Microsoft, it hosed Intel.
Microsoft was already developing for ARM so nothing changed for Microsoft. Intel stopped developing for smartphones and tablets so something changed for Intel.
Windows 10 is free on small screen devices so Microsoft didn't even lose any revenue....
I'm not sure I follow your logic. Surely you'd agree that implementing Continuum running x86 apps on Microsoft's rumored Surface Phone would have been far easier if Intel hadn't cancelled Broxton and MS had been directly able to use it as the target processor?
Would an ARM based windows device achieve an ipad style battery life and instantaneous experience? Or is it more linked to the architecture of the system?
Continuum? Windows laptops with better battery life?
Most win32 software is going to suck on a touch screen, so I'm not really seeing this help them in mobile.
Not going to happen. There's a performance hit that almost certainly comes along with emulation. Battery life is likely to get worse with x86 Windows emulation on ARM.
Also, by the time Intel stopped pushing x86 in mobile devices they were producing chips that were competitive with ARM chips when it came to power draw.
People forgot this. It was price that killed Intel in this space. They couldn't get the price down to ARM chips. They subsidized hard to get even close, but it ended up just costing them too much just to have even a presence.
In any case, many users may just be wanting to run older enterprise apps, and so even then, with the translation penalty, they'll probably be quite snappy.
From what I read, doing binary translation from x86 to ARM is actually not that hard since ARM has many more registers, so I'm sort of hopeful they get decent perf from it.
Phone mode = UWP touch apps
Docked continuum = Full desktop x86 apps (and UWP)
Nope. Windows NT was written to be cross-platform. It wasn't even developed on an x86 processor.
And NT development started at the end of the 1980s, before Linus even thought of writing his x86-specific operating system. (Because he only had x86.)
But to me the main problem was having built an iOS style environment, completely locked down, with no way to install anything unless you pay money to microsoft through the windows store (and redevelop your app). There was no technical reason to prevent regular .net apps from running directly on windows RT.
So it was a subpar experience compared to iOS without the power and flexibility of windows.
Lumia and Surface 1 and 2 were #2.
Of course, the software is a mess, because nobody has bothered to build versions for RT in years, and none of the regular x86/x64 Windows software is compatible with RT.
Never since then. Oh, I'm even in the fast update pool. What do you people _do_?
Hah!
> And even better, Microsoft has developed an emulation technology that allows Win32 applications to launch and run unmodified on ARM-based PCs. And to do so with what I am assured is excellent performance.
I don't believe it.
My understanding is Microsoft actually has some pretty cool and fast tech for this already: the Xbox 360 emulation on Xbox One.
https://www.extremetech.com/mobile/221881-apples-a9x-goes-he...
This year's chip is even more powerful:
http://www.theverge.com/2016/9/16/12939310/iphone-7-a10-fusi...
I'm also a bit skeptical about the emulation part, but if it's less than 10% overhead out of the gate, it should be okay, and I assume Microsoft could continue to optimize it over the years.
I'll believe it when I see some benchmarks.
https://www.extremetech.com/mobile/221881-apples-a9x-goes-he...
http://www.theverge.com/2016/9/16/12939310/iphone-7-a10-fusi...
There will probably be a crazy restriction like App Store only.
Oh and the whole MSI 32/64/ARM pile of crap as well.
It will be a harder sell the second time around, too as Windows RT burned a lot of people, and fewer trust Microsoft than before.
That means unlike WinRT, almost all of your apps will be usable, no confusion about it like what befell the WindowsRT.
Re: Windows on ARM, I run Windows IoT on a Raspberry Pi. Shows they have a good lot of it running, eg the full UWP UI system, kernel etc. Imagine it's the translation part that's deleted things.
My argument is that it's not going to be as power efficient as using x86 natively. There's no getting around that.
I'd suggest it has more to do with the size of the silicon wafer rather than the performance.
If you have developed a portable OS, it really doesn't matter whether ARM was first or last or inbetween.
I'd heard the battery life wasn't great but didn't know about it taking a long time to wake up.
Probably these new ARM machines won't support legacy hardware, though that may not be relevant nowadays.
2. Xbox 360
3. Windows Phone 7 (on leftover chunks of Windows CE) on ARM
4. Windows Phone 8/Windows RT
5. Windows 10 on ARM
So, by my count, this might be iteration 6? (Though maybe more like 5 Part 2.)
I have tried it in CLR and native (machine code via .NET Native) modes. Both work great.
I'm pretty sure my Pi runs on an ARM chip, anyway
From your examples, I believe gamma settings would be accessible, but every tool I've seen that reliably monitors all network traffic uses a kernel-level driver and I don't think you can install kernel-level drivers from the Store right now.
Jobs' return (as a consultant) 1997, promoting technologies from NeXT. Watch basically everyone asleep at the wheel except Jobs, the man with a plan. https://www.youtube.com/watch?v=4QrX047-v-s
WWDC Q&A - 'the art of saying no' https://www.youtube.com/watch?v=6iACK-LNnzM
Jobs' hostile takeover in July by doing a (probably illegal?) stock dump https://en.wikipedia.org/wiki/Gil_Amelio#Apple_Computer
Announcing a Deal with Microsoft as de facto CEO in August, booed by the crowd https://www.youtube.com/watch?v=IOs6hnTI4lw
Internal meeting in September 1997 https://www.youtube.com/watch?v=9GMQhOm-Dqo
iMac introduction 1998 - Apple is back https://www.youtube.com/watch?v=oxwmF0OJ0vg
Macworld 1998 - Apple is essentially saved as a company https://www.youtube.com/watch?v=gdYiqVzPjAc
OSX Strategy reveal (if you only have time for one presentation, watch this one) https://www.youtube.com/watch?v=E5dWDg6f9eo
1999 - OSX Server launch https://youtu.be/NuCYHrSig94?t=48m40s
2000 - OSX launch https://www.youtube.com/watch?v=Ko4V3G4NqII
It wasn't until OS X that Unix/Linux developers started coming to the Mac. (see this 2002 Mac magazine ad: "Sends other UNIX boxes to /dev/null." http://xaharts.org/funny/Apple_Mac_OS_X_Unix_ad.html)
The only advantage of having an Intel processor would be for the old-style traditional apps, and if you allow those, you have all sorts of problems. They're not sandboxed like runtime apps, and you can't stop them from eating your battery. It's actually better to run them in an emulator.
That's precisely what MS is allowing. From Thurott's article:
"Even better, Windows 10 on ARM will supply a long-rumored feature: The ability to run 32-bit Win32/x86 desktop applications—Apple iTunes, Adobe Photoshop, Google Chrome, whatever—directly on the system, unchanged."
I suspect that MS probably would have very much preferred not to have to use emulation, which is always a tricky business, for Continuum on the Surface Phone. Curbing resource intensive apps is a vastly less complex engineering problem.
How many have you bought? How many has anyone bought?
> The ability to run 32-bit Win32/x86 desktop applications—Apple iTunes, Adobe Photoshop, Google Chrome, whatever—directly on the system, unchanged."
True, but they're in an emulator. Pretty sure they don't have access to the whole system, which they would on a standard Windows 10 device.
If they're going to let people build/distribute native ARM binaries for Windows 10... then I'm even more impressed. I guess I would've expected that to be mentioned though.
If this is the case, that would certainly invalidate my comment about the compatibility matrix. I guess in that scenario, I'd agree and hope that those folks are working on a "fat binary" or "universal binary" or something to aid with the potential confusion.
Hasn't that been possible since Windows RT?
You mean like qemu?
> Certainly nothing that worked as well as Apple's Mixed Mode Manager or Rosetta.
I think the parent was alluding to the fact that with GNU/Linux and/or free software in general there isn't the same kinds of requirement to get binary lumps of code running on alien architecture.
No.
> there isn't the same kinds of requirement to get binary lumps of code running on alien architecture.
Are you implying that this has something to do with the software being free?
In 2006, I used Time Machine to back up my G5, and then restore it onto my new Intel Core Duo (both iMacs!). The migrated apps just worked, regardless of whether they were free software or binary blobs.
This has nothing to do with software freedom. It's about having a good user experience: when your users migrate from an old machine to a new one, it just works, period.
Linux doesn't have this requirement because it prioritizes developers over end users. I'm not bashing Linux here, I use it often and appreciate it for what it is. But an honest assessment tells us it has never come close to Apple-level smoothness in architectural transitions.
Perhaps I have misunderstood the use of the word 'story' in your first post.
> Are you implying that this has something to do with the software being free?
No, but I am asserting that I typically don't need to run non-native code on my computers because I can obtain or generate native code for any given architecture [1] I happen to be using.
I expect that where people are beholden to others, say if they are using non-free software, to create binaries that they can use on specific pieces of hardware, then yes in that case it will have 'something to do with software being free'.
> In 2006, I used Time Machine to back up my G5, and then restore it onto my new Intel Core Duo (both iMacs!). The migrated apps just worked, regardless of whether they were free software or binary blobs.
I'm not sure I appreciate the usefulness of this feature as much as you do -- you were obliged to run that software, in both instances, on hardware available exclusively a single vendor. In that scenario I would have expected to be able to run native code on both platforms.
Secondly, you only rarely need to because everything you use is in the package management system, thus compiled for the platform you are on (and against the same versions of the libs as everything else, thus only one, up to date, version of each lib and only the libs you need).
The only reason I've sometimes do qemu-system-arm and chroots is I'm a software developer often working on ARM Linux (from x86 Linux).
Third, I will also point you to: https://wiki.debian.org/Multiarch
But normally, you use a pure system. All 32bit, all 64bit or all ARM, etc etc. Closed crap can muddy your system, for instance requiring (normally old) versions of 32bit libs on a 64 bit system, but the solution to that is to not use closed crap.
"ARM-Based Windows 10 Portable PCs!? Hell Yes!"
So if you recompile Win32 programs to run on this version of Windows 10 on ARM, they will be able to do all the (good and) bad things they can do on the x86 version....
I don't think we have details if the new plans include allow developers to cross-compile Win32 apps to ARM, in addition to the x86 emulation.